On Thursday 26 January 2006 05:02, Peter N. Lundblad wrote:
> On Thu, 26 Jan 2006, John Szakmeister wrote:
> > On Wednesday 25 January 2006 17:40, Peter N. Lundblad wrote:
> > [snip]
> > > I wonder why we support this case at all. I think the right fix should
> > > have been to disable this case (which was, presumably, supported by
> > > accident because the child was added after the check).
> > The decision was made to allow it to work for the WC because 'svn cp
> > url://path url://path' works for all 3 RA layers. It seemed like it was
> > an intentional feature as a result, so we moved to support the WC case
> > rather than removing the capability from the RA layers.
> But the RA layers do support the general case, not just this special case,
> don't they?
Do you mean they support 'svn cp url://path url://path/sibling'? Hm. I'm not
sure I've really tried that out. Doing this with file:// leads to
interesting results though, at least if you try that with the root directory:
:: svnadmin create repo
:: mkdir -p proj/a/b/c/d
:: svn co file://`pwd`/repo proj
:: svn add proj/*
:: svn ci -m '' proj
Committed revision 1.
:: svn cp file://`pwd`/repo file://`pwd`/repo/a -m ''
Committed revision 2.
:: svn ls -R file://`pwd`/repo
So it seems like there might be a bug in the root case ('a/repo/' should not
be in the listing... it should be 'a/a/' . :-) So the general case seems to
work (for file://, at least).
> > Personally, I'd be fine with disabling the case, but I think we should be
> > consistent and drop that ability from the RA interface as well.
> Why? In the URL case, you won't wind up with a cycle because you copy an
> existing version. See also issue #1367. I think r14401 should be reverted
> and the check in copy.c fixed (which it will be automatically after my API
Because I think it's important that we operate in very much the same way
whether it's via RA or WC, where possible. Having a discrepancy like this
means that you can't make these change atomically without tools like
mucc--which isn't available on Windows. I don't have a strong opinion
whether or not copy succeeds or fails in this case, but I'd prefer we be
consistent. Seeing as how you're contributing much more to the project than
I am these days, I'd say you're in a better position to make the judgment
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 26 11:27:31 2006