Branko Čibej wrote:
> On 26.01.2015 15:50, Julian Foad wrote:
>> Excellent. Is anyone able to lend a hand with one of these two of the tasks
>> I listed:
>>
>> - Bypass authz when dumping with svnrdump, otherwise a partial dump is
>> obtained for tests using authz, making those tests fai
On 26.01.2015 15:50, Julian Foad wrote:
> Branko Čibej wrote:
>> On 26.01.2015 14:13, Julian Foad wrote:
>>> I attach the latest version of my dump/load cross-checking patch.
>>>
>>> Do we want to commit this? I think we should. It has been very useful in
>> uncovering dump/load bugs and incon
On Mon, Jan 26, 2015 at 7:57 AM, Julian Foad
wrote:
> Hi Bert! Thanks for airing your concerns.
>
> Bert Huijben wrote:
> > I see added value in these tests, but can we please make this behavior
> optional
> > before enabling for everybody all the time?
>
> Certainly! That's one of the three TODO
Hi Bert! Thanks for airing your concerns.
Bert Huijben wrote:
> I see added value in these tests, but can we please make this behavior
> optional
> before enabling for everybody all the time?
Certainly! That's one of the three TODO tasks I listed.
> I don't see why every test in the testsuite
Branko Čibej wrote:
> On 26.01.2015 14:13, Julian Foad wrote:
>> I attach the latest version of my dump/load cross-checking patch.
>>
>> Do we want to commit this? I think we should. It has been very useful in
> uncovering dump/load bugs and inconsistencies.
>
> Absolutely +1, more tests can't
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 26 januari 2015 15:17
> To: dev@subversion.apache.org
> Subject: Re: Testing equality between svnrdump and svnadmin dump
>
> On 26.01.2015 14:13, Julian Foad wrote:
> > I atta
On 26.01.2015 14:13, Julian Foad wrote:
> I attach the latest version of my dump/load cross-checking patch.
>
> Do we want to commit this? I think we should. It has been very useful in
> uncovering dump/load bugs and inconsistencies.
Absolutely +1, more tests can't hurt.
-- Brane
I attach the latest version of my dump/load cross-checking patch.
Do we want to commit this? I think we should. It has been very useful in
uncovering dump/load bugs and inconsistencies.
It needs a bit more work first, as noted in the log message:
### TODO:
- Put back the dumpfile parser's abi
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
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
Bert Huijben wrote:
> I haven't reviewed all of this, but I'm wondering why in your patch
> [[
> def parse_path(self):
> - path = self.parse_line('Node-path: (.+)$', required=False)
> - if not path and self.lines[self.current] == 'Node-path: \n':
> - self.current += 1
> - path =
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: dinsdag 13 januari 2015 15:22
> To: Branko Čibej
> Cc: dev@subversion.apache.org
> Subject: Re: Testing equality between svnrdump and svnadmin dump
>
> The next version of my t
The next version of my testing patch is attached. It pipes each dumpfile
through svndumpfilter and checks that a no-op filtering does not change
anything.
This finds some differences between svnadmin and svndumpfilter:
1. When a revision has no revprops, svnadmin outputs an empty properties
se
Branko Čibej wrote:
> On 12.01.2015 13:54, Julian Foad wrote:
>> svnmucc_tests.py 2 'basic svnmucc tests' generates a no-op modification
>> to an empty file, in revision 16. 'svnadmin dump' outputs this:
>> [[[
>> I: Node-path: boozle/buz/svnmucc-test.py
>> I: Node-kind: file
>> I: Node-action:
On 12.01.2015 13:54, Julian Foad wrote:
> I (Julian Foad) wrote:
>> The few differences I have found seem to be already known (but not
>> necessarily
>> adequately addressed). These include: svnrdump always sets 'Prop-delta:
>> true' even when unnecessary; svnrdump doesn't output some of the
>>
I (Julian Foad) wrote:
> The few differences I have found seem to be already known (but not
> necessarily
> adequately addressed). These include: svnrdump always sets 'Prop-delta:
> true' even when unnecessary; svnrdump doesn't output some of the
> checksum headers that svnadmin does; they put
For Your Interest,
I am having some success with testing for equality between the outputs of
svnrdump and svnadmin dump.
The attached patch makes the test suite run both 'svnadmin dump' and 'svnrdump
dump' on the sandbox repository (if created) after each test, and compare the
results. This i
19 matches
Mail list logo