Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 04:39:23 +0400:
> > From: 'Daniel Shahaf' [mailto:d.s_at_daniel.shahaf.name]
> > Sent: Wednesday, July 10, 2013 4:25 AM
> >
> > Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 04:17:37 +0400:
> > > From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> > > >
> > > > Run 'svn add wc/B_at_2.txt@'.
> > >
> > > Did you mean "svn add wc\B\@2.txt@" ?
> >
> > Forward and backward slashes are interchangeable when using svn on
> > windows.
>
> They are... I've only meant that "svn add wc/B_at_2.txt@" lacks a slash after "B"...
> The interesting thing is - this is exactly how it's displayed in an error message:
>
> ----------------------------------------
> > In particular
> > svn add wc\B\*
> > results in
> > svn: E200009: 'wc/B_at_2.txt': a peg revision is not allowed here if
> > there's a file "@2.txt" inside "B".
The glob is expanded by the shell, so svn sees
['svn', 'add', 'wc/B/@2.txt'],
so it parses out target 'wc/B/' with peg '2.txt' (this part is arguably
a bug), and stripping the slash off the end is normal (see
svn_dirent_canonicalize() in if you're curious).
> ----------------------------------------
>
> > Just do: svn add wc\B
> >
> > (if B is alreadyed versioned, add --force to that command)
>
> This works, yep. But this looks more like a workaround (in case "B" itself is already versioned).
> I don't say this is a critical bug, but I think if "svn add wc\B\*" syntax is working in one case,
> It should work in all cases, independently of directory contents....
Globs are expanded by the shell, so that's just another facet of the
original bug, whereby 'svn add' requires escaping '@' signs in
filenames. Feel free to file an issue about that, so we don't forget
it.
(But please check first if there is, or was, another issue for this.)
Received on 2013-07-10 02:46:35 CEST