Paul Burba | 1 Apr 2010 02:43
Picon
Gravatar

Re: 1.6.10 up for testing/signing

On Wed, Mar 31, 2010 at 6:58 PM, Joe Swatosh <joe.swatosh <at> gmail.com> wrote:
> On Wed, Mar 31, 2010 at 1:29 PM, Hyrum K. Wright
> <hyrum_wright <at> mail.utexas.edu> wrote:
>> On Wed, Mar 31, 2010 at 1:01 PM, Hyrum K. Wright <
>> hyrum_wright <at> mail.utexas.edu> wrote:
>>
>>> 1.6.10 tarballs are up, the magic revision is r929659:
>>>
>>> http://orac.ece.utexas.edu/pub/svn/1.6.10/
>>>
>>> Download, test, sign and send your sigs back to me.  (And don't even think
>>> about declaring this as "released" until I say so, for reasons I won't
>>> expound upon here.)
>>>
>>
>> Update: Somebody (read: me) didn't run the bindings tests before rolling the
>> tarball.  There are a few binding test failures, one in the ruby bindings,
>> another couple in the JavaHL tests.  We're investigating those (and help is
>> of course appreciated), but the upshot is: there may be a 1.6.11 shortly.
>>
>> -Hyrum
>>
>
> http://svn.haxx.se/dev/archive-2010-03/0593.shtml

Like Joe, the Ruby bindings tests pass for me.

Paul

(Continue reading)

Philipp Marek | 1 Apr 2010 08:49
Favicon

Re: SQL backend database scheme

Hello Jan!

On Mittwoch, 31. März 2010, Jan Horák wrote:
> 30.3.2010 13:55, Philipp Marek wrote:
> > I looked at that, and I'd like to post two wishes:
> >   * Please provide representations with a SHA1 (or similar) field;
> >     then it's possible to split blocks on manber-borders, to save
> >     space.
> 
> Thank you for respond, this is definitely a good point, I will involve it.
Fine, thank you.
Even if no Manber-blocks would be used at first, it would provide consistency 
checks.

> >   * Furthermore, how about allowing the plain data to reside in files?
> >     Would make the database much smaller, and then these data blocks
> >     could possibly be shared among multiple repositories.
> >     (Really easy, too, if they're named by their SHA1, for example).
> >     That should allow for zero-copy IO, too (at least for sending data).
> 
> The question is, how much faster it would be.. I would like to make a
> simple test to simulate this soon and estimate the percentage difference..
That would be very interesting to me.
I just know of some similar system where bitmaps were fetched out of a 
database - instead of just using Apache and static paths the whole data was 
transferred multiple times over multiple sockets ...

> Another point is a simple backup of the SQL database, using an existed
> global backup system in a company, which is one of the main benefits of
> the SQL backend. Would the external plain data be a problem for global
(Continue reading)

Julian Foad | 1 Apr 2010 11:41
Favicon

Re: 1.6.10 up for testing/signing

On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
> 1.6.10 tarballs are up, the magic revision is r929659:
> 
> http://orac.ece.utexas.edu/pub/svn/1.6.10/

For me, the new test 'svnadmin_tests.py 19' fails on BDB (but passes on
FSFS).  Is this known?

[[[
$ subversion/tests/cmdline/svnadmin_tests.py
--bin=/home/julianfoad/local/subversion-1.6.10/bin --fs-type=bdb
--verbose 19
CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync
"--fs-type=bdb" <TIME = 0.077871>
CMD: svn import -m "Log message for revision 1."
svn-test-work/local_tmp/greekfiles
file:///home/julianfoad/src/subversion-1.6.10/svn-test-work/local_tmp/repos --config-dir
/home/julianfoad/src/subversion-1.6.10/svn-test-work/local_tmp/config --password rayjandom
--no-auth-cache --username jrandom <TIME = 0.060466>
Adding         svn-test-work/local_tmp/greekfiles/A
Adding         svn-test-work/local_tmp/greekfiles/A/B
Adding         svn-test-work/local_tmp/greekfiles/A/B/lambda
Adding         svn-test-work/local_tmp/greekfiles/A/B/E
Adding         svn-test-work/local_tmp/greekfiles/A/B/E/alpha
Adding         svn-test-work/local_tmp/greekfiles/A/B/E/beta
Adding         svn-test-work/local_tmp/greekfiles/A/B/F
Adding         svn-test-work/local_tmp/greekfiles/A/mu
Adding         svn-test-work/local_tmp/greekfiles/A/C
Adding         svn-test-work/local_tmp/greekfiles/A/D
Adding         svn-test-work/local_tmp/greekfiles/A/D/gamma
(Continue reading)

Philip Martin | 1 Apr 2010 12:17
Favicon

Re: 1.6.10 up for testing/signing

Julian Foad <julian.foad <at> wandisco.com> writes:

> On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
>> 1.6.10 tarballs are up, the magic revision is r929659:
>> 
>> http://orac.ece.utexas.edu/pub/svn/1.6.10/
>
> For me, the new test 'svnadmin_tests.py 19' fails on BDB (but passes on
> FSFS).  Is this known?

That test is skipped on trunk because it attempts to open an FSFS
revprop file.  You made the change in r906587 :)

--

-- 
Philip

Julian Foad | 1 Apr 2010 12:43
Favicon

Re: 1.6.10 up for testing/signing - merge tests failing

On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
> 1.6.10 tarballs are up, the magic revision is r929659:
> 
> http://orac.ece.utexas.edu/pub/svn/1.6.10/

For me, merge_tests.py 45 77 79 124 126 all fail, on serf/fsfs.  Here's
the command and the end of the 'tests.log' output for test 45:

$ make davautocheck CLEANUP=1 FS_TYPE=fsfs HTTP_LIBRARY=serf

[[[
CMD: svn up svn-test-work/working_copies/merge_tests-45.E_only
--config-dir
/home/julianfoad/src/subversion-1.6.10/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom <TIME = 0.077241>
At revision 7.
CMD: svn merge -r5:4
http://localhost:28541/svn-test-work/repositories/merge_tests-45/A/B/E
svn-test-work/working_copies/merge_tests-45.E_only --dry-run
--config-dir
/home/julianfoad/src/subversion-1.6.10/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom <TIME = 0.255633>
CMD: svn merge -r5:4
http://localhost:28541/svn-test-work/repositories/merge_tests-45/A/B/E
svn-test-work/working_copies/merge_tests-45.E_only
--config-dir
/home/julianfoad/src/subversion-1.6.10/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom <TIME = 0.266729>
=============================================================
Expected '__SVN_ROOT_NODE' and actual '__SVN_ROOT_NODE' in output tree
(Continue reading)

Julian Foad | 1 Apr 2010 13:05
Favicon

Re: 1.6.10 up for testing/signing

On Thu, 2010-04-01 at 11:17 +0100, Philip Martin wrote:
> Julian Foad <julian.foad <at> wandisco.com> writes:
> 
> > On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
> >> 1.6.10 tarballs are up, the magic revision is r929659:
> >> 
> >> http://orac.ece.utexas.edu/pub/svn/1.6.10/
> >
> > For me, the new test 'svnadmin_tests.py 19' fails on BDB (but passes on
> > FSFS).  Is this known?
> 
> That test is skipped on trunk because it attempts to open an FSFS
> revprop file.  You made the change in r906587 :)

OK, I remember fixing that test on trunk, now that you've reminded me.

So that's harmless.

I do wonder how we managed to get this far with the release with this
test failure not discovered.

- Julian

Julian Foad | 1 Apr 2010 13:40
Favicon

Re: 1.6.10 up for testing/signing - merge tests failing

On Thu, 2010-04-01 at 11:43 +0100, Julian Foad wrote:
> On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
> > 1.6.10 tarballs are up, the magic revision is r929659:
> > 
> > http://orac.ece.utexas.edu/pub/svn/1.6.10/
> 
> For me, merge_tests.py 45 77 79 124 126 all fail, on serf/fsfs.

If I roll the 1.6.x branch back to r929629, it passes.

- Julian

>   Here's
> the command and the end of the 'tests.log' output for test 45:
> 
> $ make davautocheck CLEANUP=1 FS_TYPE=fsfs HTTP_LIBRARY=serf
> 
> [[[
> CMD: svn up svn-test-work/working_copies/merge_tests-45.E_only
> --config-dir
/home/julianfoad/src/subversion-1.6.10/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom <TIME = 0.077241>
> At revision 7.
> CMD: svn merge -r5:4
> http://localhost:28541/svn-test-work/repositories/merge_tests-45/A/B/E
> svn-test-work/working_copies/merge_tests-45.E_only --dry-run
> --config-dir
/home/julianfoad/src/subversion-1.6.10/subversion/tests/cmdline/svn-test-work/local_tmp/config
--password rayjandom --no-auth-cache --username jrandom <TIME = 0.255633>
> CMD: svn merge -r5:4
(Continue reading)

Philip Martin | 1 Apr 2010 13:53
Favicon

Re: 1.6.10 up for testing/signing - merge tests failing

Julian Foad <julian.foad <at> wandisco.com> writes:

> On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
>> 1.6.10 tarballs are up, the magic revision is r929659:
>> 
>> http://orac.ece.utexas.edu/pub/svn/1.6.10/
>
> For me, merge_tests.py 45 77 79 124 126 all fail, on serf/fsfs.  Here's
> the command and the end of the 'tests.log' output for test 45:
>
> $ make davautocheck CLEANUP=1 FS_TYPE=fsfs HTTP_LIBRARY=serf

My tests on Debian stable are still running but I see failures for
merge_tests.py 45 79 124 126, however 77 is a pass.

--

-- 
Philip

Paul Burba | 1 Apr 2010 14:08
Picon
Gravatar

Re: 1.6.10 up for testing/signing - merge tests failing

On Thu, Apr 1, 2010 at 7:40 AM, Julian Foad <julian.foad <at> wandisco.com> wrote:
> On Thu, 2010-04-01 at 11:43 +0100, Julian Foad wrote:
>> On Wed, 2010-03-31 at 13:01 -0600, Hyrum K. Wright wrote:
>> > 1.6.10 tarballs are up, the magic revision is r929659:
>> >
>> > http://orac.ece.utexas.edu/pub/svn/1.6.10/
>>
>> For me, merge_tests.py 45 77 79 124 126 all fail, on serf/fsfs.
>
> If I roll the 1.6.x branch back to r929629, it passes.

Hi Julian,

Doesn't really help you, but those all pass for me:

C:\SVN\src-branch-1.6.x\Release\subversion\tests\cmdline>python
C:\SVN\src-branch-1.6.x\subversion\tests\cmdline\merge_tests.py 45 77
79 124 126 --http-library serf --cleanup
PASS:  merge_tests.py 45: target inherits mergeinfo from nearest ancestor
PASS:  merge_tests.py 77: subtrees added after start of merge range are ok
PASS:  merge_tests.py 79: merge --reintegrate with renamed file on branch
PASS:  merge_tests.py 124: no self referential filtering on added path
PASS:  merge_tests.py 126: merge --reintegrate with subtree mergeinfo

The likely culprit would seem r929603...can you confirm that is where
the failure starts?

Do you see the same failures on trunk?

Anyone else seeing this?
(Continue reading)

Julian Reschke | 1 Apr 2010 14:17
Picon
Picon

Re: Experiences of a Subversion FS backend developer

On 31.03.2010 21:20, C. Michael Pilato wrote:
> ...
>    - "WebDAV sucks.  Period."
> ...

Out of curiosity: what's the relation to writing a Subversion FS backend?

Best regards, Julian

PS: and, of course, it's not true :-)


Gmane