Hello.
Subversion includes many types of connection:
* svnserve - plain password over network
* svnserve + ssh - secure, but unusable slow
* http - plain password over network
* https - secure
In the case of svnserver default instead of the password hash is transmitted
over the network, and
Hi Julian,
Thanks for responding.
On Thu, Jan 15, 2015 at 12:55 AM, Julian Foad
wrote:
> Hi Patrik.
>
> Thanks for the report.
>
> I agree there's something wrong with the range calculations you point out.
>
>
> In order to help me follow along and examine the source code, please could
> you sa
Philip Martin writes:
>> + /* Any previously cached children now have a new WCROOT. */
>> + for (hi = apr_hash_first(scratch_pool, db->dir_data);
>> + hi;
>> + hi = apr_hash_next(hi))
>> +{
>> + const char *abspath = apr_hash_this_key(hi);
>> + if (svn_dirent_is_ancest
phi...@apache.org writes:
> Author: philip
> Date: Thu Jan 15 16:11:57 2015
> New Revision: 1652157
>
> URL: http://svn.apache.org/r1652157
> Log:
> Fix issue 4550, failed to run workqueue item due to earlier use of
> wrong wcroot.
>
> * subversion/libsvn_wc/wc_db.c
> (svn_wc__db_init): Update w
Bert Huijben wrote:
> It could be that it is already there, but there should be inheritance of
> copyfrom values within added directories.
Thanks for the heads-up. It looks like that may be broken here too. I'll check.
This sort of nonsense is why I'm working on deduplicating the dump and load
c
It could be that it is already there, but there should be inheritance of
copyfrom values within added directories.
Only when the revision number (or path) changes you will get a new copyfrom.
(This is what you see on a mixed revision copy… There should also be a delete
in that case now, althou
I found in another bug in 'svnrdump load'.
When my additional testing runs 'svnrdump load' on a dumpfile produced by
'svnadmin dump' (non-deltas mode), some tests including copy_tests.py 7 and 11
fail.
When loading an add-with-history froma non-deltas dumpfile, on reading the new
properties, t
On 15 January 2015 at 16:20, Branko Čibej wrote:
> On 15.01.2015 13:38, i...@apache.org wrote:
>> Author: ivan
>> Date: Thu Jan 15 12:38:13 2015
>> New Revision: 1652076
>>
>> URL: http://svn.apache.org/r1652076
>> Log:
>> Fix mostly theoretical data corruption in log-addressing enabled FSFS
>> re
On 15.01.2015 13:38, i...@apache.org wrote:
> Author: ivan
> Date: Thu Jan 15 12:38:13 2015
> New Revision: 1652076
>
> URL: http://svn.apache.org/r1652076
> Log:
> Fix mostly theoretical data corruption in log-addressing enabled FSFS
> repositories when physical-to-logical index will be more than
I corrected the dump-load format documentation in r1652064, with wording
similar to the patch I had given here. I confirmed by code inspection that
svndumpfilter had behaved this way since Subversion 1.0.
- Julian
I (Julian Foad) wrote on 2015-01-13:
> 1. When a revision has no revprops, svnad
Hi Patrik.
Thanks for the report.
I agree there's something wrong with the range calculations you point out.
In order to help me follow along and examine the source code, please could you
say exactly which programs and versions you are using for each step? Are you
using 'svndumpfilter' for th
Branko Čibej wrote:
> On 15.01.2015 09:51, rhuij...@apache.org wrote:
>> URL: http://svn.apache.org/r1651980
>> Log:
>> Resolve the issue identified in r1651963, by properly calculating the depth
>> of the location where the moved to information should be stored after
>>another
>> move.
>>
>
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: donderdag 15 januari 2015 10:35
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1651980 - in /subversion/trunk/subversion:
> libsvn_wc/wc_db.c tests/libsvn_wc/op-depth-test.c
>
> On 15.01.2015 09:51
On 15.01.2015 09:51, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Thu Jan 15 08:51:47 2015
> New Revision: 1651980
>
> URL: http://svn.apache.org/r1651980
> Log:
> Resolve the issue identified in r1651963, by properly calculating the depth
> of the location where the moved to information s
Hi Joshua,
Thanks for this very clear bugreport.
I added a testcase for this issue in our test suite in r1651963, which made it
easy to debug the actual issue.
The issue was fixed in r1651980, and nominated for backport to 1.8.x in
r1652010.
Thanks for reporting, a
15 matches
Mail list logo
