Thanks Philip for sharing your insight into the lock mechanisms.
Sorry about the delay, wanted to find time to investigate.
On 24 feb 2014, at 19:56, Philip Martin philip.mar...@wandisco.com wrote:
Thomas Åkesson thomas.akes...@simonsoft.se writes:
Svn does not allow locking non-existent
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
On Sun, Mar 2, 2014 at 2:54 AM, Philip Martin
philip.mar...@wandisco.comwrote:
There is a problem with the FNV1a checksums in format 7: the on-disk
representation for big-endian systems, like SPARC, is different from
that of
On 03.03.2014 14:03, Philip Martin wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
On Sun, Mar 2, 2014 at 2:54 AM, Philip Martin
philip.mar...@wandisco.comwrote:
There is a problem with the FNV1a checksums in format 7: the on-disk
representation for big-endian systems, like
Hello,
Another approach is to dump 'svnlook proplist' altogether and use 'svnlook
propget svn:mime-type' and 'svnlook propget svn:eol-style' instead. That could
be maximally backward compatible without introducing XML.
Regards,
Leo
From: Ben Reser
A customer found that 'svnsync' errored out on trying to sync a revision in
which the source repository introduced some mergeinfo starting with r0, similar
to this example:
$ svn propget svn:mergeinfo ^/foo@1234567
/bar:0-100,111,122
The svnsync error message was:
$ svnsync
Stefan Fuhrmann wrote:
Stefan Fuhrmann wrote:
Julian Foad wrote:
Stefan Fuhrmann wrote:
Julian Foad wrote:
-- a quick optimization API -- the definitely/maybe question -- like the
existing implementations but documented properly and named
appropriately; and
-- (perhaps) a definite
On 03.03.2014 17:24, Julian Foad wrote:
* Make 'svnsync sync' strip out the revision 0 from that mergeinfo? Or make
it strip out the whole mergeinfo property if it fails to parse? Or just that
line of the property value? (If we do something like that, I'd like us to do
it everywhere we
I've been experimenting with a SPARC Solaris build recently and the
non-portable use of find in Makefile.in is annoying, it means that the
'make clean' target fails. There are two uses of
find some/path -mindepth 1 -maxdepth 1 -print0 | xargs -0 rm -rf --
Solaris find doesn't support
On Mon, Mar 03, 2014 at 05:34:22PM +, Philip Martin wrote:
I've been experimenting with a SPARC Solaris build recently and the
non-portable use of find in Makefile.in is annoying, it means that the
'make clean' target fails. There are two uses of
find some/path -mindepth 1 -maxdepth 1
On Tue, Mar 4, 2014 at 12:06 AM, Evgeny Kotkov
evgeny.kot...@visualsvn.comwrote:
Hi Stefan,
Except for the typo, you patch looks good.
I like that we get around the chicken/egg
problem with the revnum vs. HEAD check.
Please commit.
I fixed the typo and committed this patch in
10 matches
Mail list logo