Re: feature suggestion: adressing the repo relative to working copy url

[Lorenz]

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 repository root
>> >/to the server root
>> >//   to the URL scheme
>> >  ^/../  to a sibling repository beneath the same SVNParentPath location
>> 
>> I am aware of the svn:externals syntax, but in light of the fact that
>> ^/ was alread adopted, I thought it best to stick with the ^
>> 
>> If the cmomand line client accepts the ^  as the "translate the
>> following path to an URL" marker, then anything after it could be
>> interpreted as a normal path.
>> 
>> ^/   repo root relative
>> ^/../namesibling repo
>> 
>> ^subpath subpath of the  current working copy folder
>> ^../ parent
>> ^../path sibling
>> ^../../  grand parent
>
>If the first of these four were changed to require a ./ path component,
>we could repurpose the ^foo/ syntax to something else:
>
>^./subpathsubpath relative to URL of cwd
>^foo/ as defined by a --config-option=config:short-urls:foo=bar 
> config option
>[...]

the last is an independent idea for an additional feature, right?

'foo' would be a shortcut for a base URL? 
I think, without some sort of indicator, it looks to much like a path.
I would prefer to mark a shortcut explicitly as such.
No idea how though, another prefix? Perhaps '^:shortcut/" would do?


But back to original topic: I could live with using '^./' as the
general prefix for "current working copy folder relative addressing".

so my 4 examples above would change to:

^./subpath  subpath of the  current working copy folder
^./../  parent
^./../path  sibling
^./../../   grand parent
-- 

Lorenz

Re: 1.10.0-alpha2 is up for signing

[Johan Corveleyn]

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 committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thank you!

Summary
---
+1 to release

Platform

Windows 7 SP1 (x64)
Microsoft Visual Studio 2013

Verified

Signature and sha1 for subversion-1.10.0-alpha2.zip.

Contents of subversion-1.10.0-alpha2.zip are identical to tags/1.10.0-alpha2,
and to trunk@1783880 (except for expected differences in svn_version.h
and svnpubsub, svnwcsub and nominate.pl (symlinks vs. file contents), and
generated files).

Tested
--
[ Release build x86 ] x [ fsfs ] x [ file | svn | http ]

Results
---
All tests pass, except patch #69 (add and remove executable file) because
it tickles the antivirus. This is a known test-suite issue,
see https://svn.haxx.se/dev/archive-2017-01/0075.shtml.

Dependencies

Httpd 2.4.16
Apr 1.5.2
Apr-Util 1.5.4
OpenSSL 1.0.2k
Serf 1.3.9
SQLite 3.17.0.0
ZLib 1.2.11

Signature
-

subversion-1.10.0-alpha2.zip:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCgAGBQJYrjhiAAoJELWc5tYBDIqtBrIQALCj3u7KVCPI3vQzZQYXjOGn
GdhONfRYYC1ISY45YFMGMXHi4x2LVx2SUwCaOexYVAQa/1JETPHqI9RbJsYSQzzD
8vK5PhCiQyFATIty1YkHE09dAzDx5YmI8r0FnJa1psTc/VybNkIN5OdGdnolifN1
7uZ7LSHEGlrx4YLuAZUBVntHpE0J23KfnldU1/YCwtWKXL/mOgplRly0d5dR8XeG
IEFpSbK0oozSxuQwAaeKaS/JmINDKe4qcJTHXwgyAxr4mkpb3ZRzz09z+7/1GDGh
hOGx+8u6H6oz+jY+GlAhCeGYQb1tXu5Yj8ouIeBeYHq5dqSmv5mw7xSqh+BRN0yI
Sa6hzDESPIOCa5G0A3sRhUc6k5eKkEZ9TXGjWEBChdTahers0hfCw4lpz3QXYk4e
huHfACpphzCigOJLTZLe1t+w96jqAxJ13N+7k6trFRfxCqnMCDMUSFNDDJwGTtDF
/o9dc0lbO8t2oXgVfHcnaJUqWGCN0mV6MSZ3H3A751rDBbflwW3MJr6lqHWwH5l1
aQ9qOGkUHObszmV4tYzbzG76fGTcgGczrYLneZnLXnOT0/h4I3ySYwxuSdhOg6Lk
XH4alqVUdkcJQX7cPBqmgLuhLx8cAF4CvB/EADmK2ysB/q+5oeHHYu/X6skCX7qT
fe2WUAyq6N14RfNkyAsV
=Ikvv
-END PGP SIGNATURE-

-- 
Johan

RE: Bug in "svnrdump" ?

[bert]

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: Doug Robinson
Cc: dev
Subject: Re: Bug in "svnrdump" ?

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 r3 corresponding to step 3. This feature 
(dump a subtree) is not possible with 'svnadmin dump'.

So the bug is that svnrdump doesn't know how to handle a copy source 
that's outside the subtree being dumped.

That's rather poor. I believe the desired behaviour would be to replace 
the 'copy' with a full 'add', and I believe that behaviour is 
implemented somewhere else -- is it in svndumpfilter and/or svnsync?

If you could file a bug report that would be very helpful, thanks.

- Julian


> If so then it has a reproducible bug:
> --
> 1. Add following files into an empty repo.
>
>A /A
>
>A /A/AA
>
>A /A/AA/a.txt
>
>A /A/AA/b.txt
>
> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>
>A /B (from /A:1)
>
>D /B/AA/a.txt
>
> 3. Copy folder B/AA to folder B/Trunk/AA
>
>A /B/Trunk
>
>A /B/Trunk/AA (from /B/AA:2)
>
> 4. run svnrdump command to dump B/Trunk folder.
>
> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>
> * Dumped revision 0.
>
> * Dumped revision 1.
>
> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
> --
>
> Is this known already?  Should I file a bug?

Re: Bug in "svnrdump" ?

[Doug Robinson]

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 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 r3 corresponding to step 3. This feature (dump a
> subtree) is not possible with 'svnadmin dump'.
>
> So the bug is that svnrdump doesn't know how to handle a copy source
> that's outside the subtree being dumped.
>
> That's rather poor. I believe the desired behaviour would be to replace
> the 'copy' with a full 'add', and I believe that behaviour is implemented
> somewhere else -- is it in svndumpfilter and/or svnsync?
>
> If you could file a bug report that would be very helpful, thanks.
>
>
> - Julian
>
>
> If so then it has a reproducible bug:
>> --
>> 1. Add following files into an empty repo.
>>
>>A /A
>>
>>A /A/AA
>>
>>A /A/AA/a.txt
>>
>>A /A/AA/b.txt
>>
>> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>>
>>A /B (from /A:1)
>>
>>D /B/AA/a.txt
>>
>> 3. Copy folder B/AA to folder B/Trunk/AA
>>
>>A /B/Trunk
>>
>>A /B/Trunk/AA (from /B/AA:2)
>>
>> 4. run svnrdump command to dump B/Trunk folder.
>>
>> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>>
>> * Dumped revision 0.
>>
>> * Dumped revision 1.
>>
>> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
>> --
>>
>> Is this known already?  Should I file a bug?
>>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: 1.10.0-alpha2 is up for signing

[Evgeny Kotkov]

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
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.

Just in case, I should be able to provide a signature at the beginning
of the next week.

(We have holidays here, and I think I'll be unavailable until then.)


Regards,
Evgeny Kotkov

Re: feature suggestion: adressing the repo relative to working copy url

[Daniel Shahaf]

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
> >/to the server root
> >//   to the URL scheme
> >  ^/../  to a sibling repository beneath the same SVNParentPath location
> 
> I am aware of the svn:externals syntax, but in light of the fact that
> ^/ was alread adopted, I thought it best to stick with the ^
> 
> If the cmomand line client accepts the ^  as the "translate the
> following path to an URL" marker, then anything after it could be
> interpreted as a normal path.
> 
> ^/repo root relative
> ^/../name sibling repo
> 
> ^subpath  subpath of the  current working copy folder
> ^../  parent
> ^../path  sibling
> ^../../   grand parent

If the first of these four were changed to require a ./ path component,
we could repurpose the ^foo/ syntax to something else:

^./subpathsubpath relative to URL of cwd
^foo/ as defined by a --config-option=config:short-urls:foo=bar 
config option

> and so on
> 
> The only difference to the svn:externals syntax you need to keep in
> mind is that on the command line you always need the ^ in front.
> 
> 
> I think my proposal for using ^^/ as working copy root is not
> absolutely neccessary, by the way.
> You can always get there with the appropriate number of ../  8-)

The working copy root is a fluid concept: sometimes people root their
wc's above or below the branch root.  It might be nice to have a syntax
that will mean "relative to the branch root"... that is, to have the
design specify a syntax that will mean "relative to the branch root"
when we invent a concept of "branch roots".

Cheers,

Daniel

Re: Glob syntax for svndumpfilter exclude --pattern

[Branko Čibej]

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 treating slash as special in
>> > paths. A user might well expect it to match, knowing that the pattern
>> > "/trunk//README" *will* match due to our canonicalizing the input
>> > patterns before matching. So there is an inconsistency there.
>>
>> But the user didn't write /trunk//README, she wrote /trunk/*/README
>> which can't be canonicalized to /trunk/README. Remember these are not
>> paths but glob patterns, if we started "canonicalizing" them it'd be --
>> well, interesting -- to try to avoid side effects.
>
> Yes, I know, and I don't propose it. 

For the record, I seem to recall that I chose the glob variant that does
not treat / as special precisely because APR's glob flavour does not
provide ** (i.e., the recursive form of * when / is special).

-- Brane

Re: feature suggestion: adressing the repo relative to working copy url

[Lorenz]

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 hierarchy than ^/, but its not, so this notation might be slightly
>> misleading.
>
>In windows cmd.exe, ^ is a special character so there is already a need
>to type ^^/ instead of ^/. This is a common pitfall for Windows users.
>In cmd.exe ^^/ would need to be typed as / which is getting a bit long.
>
>When ^/ was introduced, this problem was already known but accepted.
>It is not easy to find a syntax which does not overlap with something
>already used by various shells on various operating systems.

if you put the path in quotes you don't need to double up the ^.


>> Alternative idea:
>> ^./  -- repo URL for .
>> ^../ -- its parent
>> ^.../ -- its grand parent
>> In particular the .-Notation would not be the general case a/../b but would
>> only be allowed exactly as shown at the start of the URL.
>
>Note that several relative URL notations were already defined for the
>svn:externals property. You might want to avoid overlap with these and
>perhaps try to find something that looks sufficiently different.
>
>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
>/to the server root
>//   to the URL scheme
>  ^/../  to a sibling repository beneath the same SVNParentPath location

I am aware of the svn:externals syntax, but in light of the fact that
^/ was alread adopted, I thought it best to stick with the ^

If the cmomand line client accepts the ^  as the "translate the
following path to an URL" marker, then anything after it could be
interpreted as a normal path.

^/  repo root relative
^/../name   sibling repo

^subpathsubpath of the  current working copy folder
^../parent
^../pathsibling
^../../ grand parent

and so on

The only difference to the svn:externals syntax you need to keep in
mind is that on the command line you always need the ^ in front.


I think my proposal for using ^^/ as working copy root is not
absolutely neccessary, by the way.
You can always get there with the appropriate number of ../  8-)
-- 

Lorenz

Re: feature suggestion: adressing the repo relative to working copy url

[Stefan Sperling]

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, so this notation might be slightly
> misleading.

In windows cmd.exe, ^ is a special character so there is already a need
to type ^^/ instead of ^/. This is a common pitfall for Windows users.
In cmd.exe ^^/ would need to be typed as / which is getting a bit long.

When ^/ was introduced, this problem was already known but accepted.
It is not easy to find a syntax which does not overlap with something
already used by various shells on various operating systems.

> Alternative idea:
> ^./  -- repo URL for .
> ^../ -- its parent
> ^.../ -- its grand parent
> In particular the .-Notation would not be the general case a/../b but would
> only be allowed exactly as shown at the start of the URL.

Note that several relative URL notations were already defined for the
svn:externals property. You might want to avoid overlap with these and
perhaps try to find something that looks sufficiently different.

>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
/to the server root
//   to the URL scheme
  ^/../  to a sibling repository beneath the same SVNParentPath location

Re: Glob syntax for svndumpfilter exclude --pattern

[Julian Foad]

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 expect it to match, knowing that the pattern
> "/trunk//README" *will* match due to our canonicalizing the input
> patterns before matching. So there is an inconsistency there.

But the user didn't write /trunk//README, she wrote /trunk/*/README
which can't be canonicalized to /trunk/README. Remember these are not
paths but glob patterns, if we started "canonicalizing" them it'd be --
well, interesting -- to try to avoid side effects.


Yes, I know, and I don't propose it.

- Julian

Re: feature suggestion: adressing the repo relative to working copy url

[Harald Kirsch]

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 command line client
that you what to start a URL beginning at the root of the repository
your working copy was checked out from.

As I see it, the client already interprets the leading "^" as "convert
the following path to an URL".

"^/" then translates to "repository root"


So "^path" could be interpreted as a path relative to the current
working copy folder (including sequences of "../" as needed).


Looking at the commit for the improvement that introduced the ^/ 
notation, it also contains the strict refusal to accept '..' in a path:


libsvn_subr/opt.c:

 870827 julianfoad 2008-04-22 17:21:36 +0200 (Di, 22. Apr 2008) 
 _("URL '%s' contains a '..' element"),


I could not find a rationale for this, but it is likely a security 
consideration. The patch was from Troy Curtis Jr 
(troycurti...@gmail.com). It would be good to know the arguments, why 
'..' is not allowed, before it is (re)introduced.




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, so this notation might be 
slightly misleading.


Alternative idea:
^./  -- repo URL for .
^../ -- its parent
^.../ -- its grand parent
In particular the .-Notation would not be the general case a/../b but 
would only be allowed exactly as shown at the start of the URL.


Harald

Re: Bug in "svnrdump" ?

[Julian Foad]

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 r3 corresponding to step 3. This feature 
(dump a subtree) is not possible with 'svnadmin dump'.


So the bug is that svnrdump doesn't know how to handle a copy source 
that's outside the subtree being dumped.


That's rather poor. I believe the desired behaviour would be to replace 
the 'copy' with a full 'add', and I believe that behaviour is 
implemented somewhere else -- is it in svndumpfilter and/or svnsync?


If you could file a bug report that would be very helpful, thanks.

- Julian



If so then it has a reproducible bug:
--
1. Add following files into an empty repo.

   A /A

   A /A/AA

   A /A/AA/a.txt

   A /A/AA/b.txt

2. Svn copy folder A to folder B, and then delete /B/AA/a.txt

   A /B (from /A:1)

   D /B/AA/a.txt

3. Copy folder B/AA to folder B/Trunk/AA

   A /B/Trunk

   A /B/Trunk/AA (from /B/AA:2)

4. run svnrdump command to dump B/Trunk folder.

# svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump

* Dumped revision 0.

* Dumped revision 1.

svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
--

Is this known already?  Should I file a bug?

Re: Bug in "svnrdump" ?

[Doug Robinson]

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" 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 please. (It isn't
> clear from your description where the commits are, for example. If one
> commit per numbered step, then presumably as it fails on dumping r2 then
> what are steps 3 and 4 for?)
>
> What svn version this is?
>
> - Julian
>
>
>
>> If so then it has a reproducible bug:
>> --
>> 1. Add following files into an empty repo.
>>
>>A /A
>>
>>A /A/AA
>>
>>A /A/AA/a.txt
>>
>>A /A/AA/b.txt
>>
>> 2. Svn copy folder A to folder B, and then delete /B/AA/a.txt
>>
>>A /B (from /A:1)
>>
>>D /B/AA/a.txt
>>
>> 3. Copy folder B/AA to folder B/Trunk/AA
>>
>>A /B/Trunk
>>
>>A /B/Trunk/AA (from /B/AA:2)
>>
>> 4. run svnrdump command to dump B/Trunk folder.
>>
>> # svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump
>>
>> * Dumped revision 0.
>>
>> * Dumped revision 1.
>>
>> svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
>> --
>>
>> Is this known already?  Should I file a bug?
>>
>> Thank you.
>>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.


test.dump
Description: Binary data

Re: Bug in "svnrdump" ?

[Julian Foad]

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 please. (It isn't 
clear from your description where the commits are, for example. If one 
commit per numbered step, then presumably as it fails on dumping r2 then 
what are steps 3 and 4 for?)


What svn version this is?

- Julian




If so then it has a reproducible bug:
--
1. Add following files into an empty repo.

   A /A

   A /A/AA

   A /A/AA/a.txt

   A /A/AA/b.txt

2. Svn copy folder A to folder B, and then delete /B/AA/a.txt

   A /B (from /A:1)

   D /B/AA/a.txt

3. Copy folder B/AA to folder B/Trunk/AA

   A /B/Trunk

   A /B/Trunk/AA (from /B/AA:2)

4. run svnrdump command to dump B/Trunk folder.

# svnrdump dump file:///tmp/test/B/Trunk > Trunk.dump

* Dumped revision 0.

* Dumped revision 1.

svnrdump: E160013: File not found: revision 2, path '/B/AA/a.txt'
--

Is this known already?  Should I file a bug?

Thank you.

Re: svn commit: r1783953 - /subversion/site/publish/docs/release-notes/1.10.html

[Stefan Sperling]

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: comm...@subversion.apache.org
> >> Subject: svn commit: r1783953 - /subversion/site/publish/docs/release-
> >> notes/1.10.html
> >>
> >> Author: jcorvel
> >> Date: Tue Feb 21 22:34:48 2017
> >> New Revision: 1783953
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1783953=rev
> >> Log:
> >> * publish/docs/release-notes/1.10.html:
> >>   (#conflict-resolver): generalize local change "delete directory" to
> >>"delete item".
> >
> > Usually we use the term 'node' to describe 'some thing in the working copy' 
> > instead of item.
> 
> I just used whatever stsp already used in that table. So, stsp?
> 
> IMHO, node sounds a bit too technical for end-users (to me, it sounds
> more like a node in a cluster, or some other infrastructure), and
> since these are the release notes ... But I dunno, doesn't matter too
> much to me.

I have been using "node" as a libsvn_wc-specific term, and "item"
in user-facing documentation.

Re: svn commit: r1783953 - /subversion/site/publish/docs/release-notes/1.10.html

[Johan Corveleyn]

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 - /subversion/site/publish/docs/release-
>> notes/1.10.html
>>
>> Author: jcorvel
>> Date: Tue Feb 21 22:34:48 2017
>> New Revision: 1783953
>>
>> URL: http://svn.apache.org/viewvc?rev=1783953=rev
>> Log:
>> * publish/docs/release-notes/1.10.html:
>>   (#conflict-resolver): generalize local change "delete directory" to
>>"delete item".
>
> Usually we use the term 'node' to describe 'some thing in the working copy' 
> instead of item.

I just used whatever stsp already used in that table. So, stsp?

IMHO, node sounds a bit too technical for end-users (to me, it sounds
more like a node in a cluster, or some other infrastructure), and
since these are the release notes ... But I dunno, doesn't matter too
much to me.

-- 
Johan

RE: svn commit: r1783953 - /subversion/site/publish/docs/release-notes/1.10.html

[Bert Huijben]

> -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 22:34:48 2017
> New Revision: 1783953
> 
> URL: http://svn.apache.org/viewvc?rev=1783953=rev
> Log:
> * publish/docs/release-notes/1.10.html:
>   (#conflict-resolver): generalize local change "delete directory" to
>"delete item".

Usually we use the term 'node' to describe 'some thing in the working copy' 
instead of item.

Bert