On Wed, Feb 22, 2017 at 01:48:27PM +0100, Johan Corveleyn wrote:
> On Wed, Feb 22, 2017 at 1:01 PM, Bert Huijben wrote:
> >> -Original Message-
> >> From: jcor...@apache.org [mailto:jcor...@apache.org]
> >> Sent: dinsdag 21 februari 2017 23:35
> >> To:
On Wed, Feb 22, 2017 at 1:01 PM, Bert Huijben wrote:
>> -Original Message-
>> From: jcor...@apache.org [mailto:jcor...@apache.org]
>> Sent: dinsdag 21 februari 2017 23:35
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r1783953 -
> -Original Message-
> From: jcor...@apache.org [mailto:jcor...@apache.org]
> Sent: dinsdag 21 februari 2017 23:35
> To: comm...@subversion.apache.org
> Subject: svn commit: r1783953 - /subversion/site/publish/docs/release-
> notes/1.10.html
>
> Author: jcorvel
> Date: Tue Feb 21
Doug Robinson wrote:
Should "svnrdump" be able to dump everything that "svnadmin dump" is
capable of?
I'm pretty sure it should, and this isn't a known bug AFAIK (I just
searched for "svnrdump copy" in Jira).
Thanks for reporting it here.
Can you paste the actual reproduction commands used
Julian:
This has been reproduced on 1.9.5 and 1.8.16. I've attached a dump of the
simple test case repo.
Thank you.
Doug
On Wed, Feb 22, 2017 at 8:50 AM, Julian Foad wrote:
> Doug Robinson wrote:
>
>> Should "svnrdump" be able to dump everything that "svnadmin dump"
Branko Čibej wrote:
On 20.02.2017 17:17, Julian Foad wrote:
> Actually, adding the leading slash is not really relevant. The more
> general case is that pattern "/trunk/*/README" won't match path
> "/trunk/README", as a consequence of not treating slash as special in
> paths. A user might well
On 22.02.2017 15:21, Julian Foad wrote:
> Branko Čibej wrote:
>> On 20.02.2017 17:17, Julian Foad wrote:
>> > Actually, adding the leading slash is not really relevant. The more
>> > general case is that pattern "/trunk/*/README" won't match path
>> > "/trunk/README", as a consequence of not
Stefan Sperling wrote:
>On Wed, Feb 22, 2017 at 03:12:55PM +0100, Harald Kirsch wrote:
>> Am 21.02.2017 um 15:40 schrieb Lorenz:
>> > And why not use "^^/" to denote working copy root relative?
>>
>> Would work for me. But intuitively ^^/ seems to refer even higher up in the
>> directory
Stefan Sperling writes:
> The new 1.10.1-alpha2 release is up for signing.
>
> The proposed 1.10.0-alpha1 release had a compilation problem on Windows.
> The alpha2 release should fix this problem. It is based on trunk@r1783880.
>
> Full committers, please get this release from
That code is in the backing code for svn_ra_replay(), where it also applies to
authz, not on the client.
@Julian Foad Can we use svnsync in this scenario, or does that break in a
similar way?
Bert
Sent from Mail for Windows 10
From: Julian Foad
Sent: woensdag 22 februari 2017 15:11
To:
Julian:
https://issues.apache.org/jira/browse/SVN-4672
Cheers!
Doug
On Wed, Feb 22, 2017 at 9:11 AM, Julian Foad wrote:
> Doug Robinson wrote:
>
>> This has been reproduced on 1.9.5 and 1.8.16. I've attached a dump of
>> the simple test case repo.
>>
>
> Thanks. I was
On Tue, Feb 21, 2017 at 1:54 PM, Stefan Sperling wrote:
> The new 1.10.1-alpha2 release is up for signing.
>
> The proposed 1.10.0-alpha1 release had a compilation problem on Windows.
> The alpha2 release should fix this problem. It is based on trunk@r1783880.
>
> Full
Doug Robinson wrote:
This has been reproduced on 1.9.5 and 1.8.16. I've attached a dump of
the simple test case repo.
Thanks. I was hasty -- I see what's going on. This is dumping a subtree
of the repo (/B/Trunk), and r2 was not dumped because it doesn't touch
the subtree, and it fails on
Am 21.02.2017 um 15:40 schrieb Lorenz:
Harald Kirsch wrote:
[about working copy relative URLs]
This a purely client side path to URL transformation.
So what is needed as a means to tell the client to use the URL
associated with the given path.
there is already the "^/" notation to tell the
On Wed, Feb 22, 2017 at 03:12:55PM +0100, Harald Kirsch wrote:
> Am 21.02.2017 um 15:40 schrieb Lorenz:
> > And why not use "^^/" to denote working copy root relative?
> >
>
> Would work for me. But intuitively ^^/ seems to refer even higher up in the
> directory hierarchy than ^/, but its not,
Daniel Shahaf wrote:
>Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
>> Stefan Sperling wrote:
>> >From 'svn help ps':
>> > The URL may be a full URL or a relative URL starting with one of:
>> >../ to the parent directory of the extracted external
>> >^/ to the
Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +:
> Stefan Sperling wrote:
> >From 'svn help ps':
> > The URL may be a full URL or a relative URL starting with one of:
> >../ to the parent directory of the extracted external
> >^/ to the repository root
> >/
17 matches
Mail list logo