On Tue, Mar 4, 2014 at 12:06 AM, Evgeny Kotkov
wrote:
> 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 r1573744. Thank you for
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 r1573744. Thank you for
the review.
> Mind applying equivalent changes to get_root_changes_
Hi Stefan,
> Looks like a reasonable test; please commit.
Committed as r1573730. Thanks for the review!
Regards,
Evgeny Kotkov
I reordered the quoted email a bit in order to make it easier to understand my
response.
On 3/3/14, 9:34 AM, Philip Martin wrote:
> The use of -mindepth 1 -maxdepth 1 is also something I don't understand,
> what advantage is there over simply using a shell expansion? Like this:
>
> rm -rf some/
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 -maxdep
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 -mindepth
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
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
>
>
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 s
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
Sen
On 03.03.2014 14:03, Philip Martin wrote:
> Stefan Fuhrmann writes:
>
>> On Sun, Mar 2, 2014 at 2:54 AM, Philip Martin
>> wrote:
>>
>>> 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 little-
Stefan Fuhrmann writes:
> On Sun, Mar 2, 2014 at 2:54 AM, Philip Martin
> wrote:
>
>> 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 little-endian systems, like x86. Both systems calculate t
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 wrote:
> Thomas Åkesson writes:
>
>> Svn does not allow locking non-existent paths. It is blocked both in
>> libsvn_fs_base/libs
13 matches
Mail list logo
