On Thu, 26 Jan 2006, John Szakmeister wrote:
> 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/*
> A proj/a
> A proj/a/b
> A proj/a/b/c
> A proj/a/b/c/d
> :: svn ci -m '' proj
> Adding proj/a
> Adding proj/a/b
> Adding proj/a/b/c
> Adding proj/a/b/c/d
>
> Committed revision 1.
> :: svn cp file://`pwd`/repo file://`pwd`/repo/a -m ''
>
> Committed revision 2.
> :: svn ls -R file://`pwd`/repo
> a/
> a/b/
> a/b/c/
> a/b/c/d/
> a/repo/
> a/repo/a/
> a/repo/a/b/
> a/repo/a/b/c/
> a/repo/a/b/c/d/
>
> 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).
It is consistent with the API in that if the target exists, it will use
the basename of the source to create a child in the target. You could
argue that this should use the basename of the URL of the source, but not
if the source is the root of the FS... Well, you can always specify the
full destination name. But this is really outside of the real question.
The repository still allows copying a directory into a descendant of
itself, and it works fine.
>
> > > 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
> > change).
>
> 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
> call. :-)
>
:-) But if we remove the posibility from the repository as well, you
couldn't do this kind of things, even *with* mucc.
The problem for me is that I'll need to duplicate the logic in the cmdline
client in the compat wrapper, so I want to avoid making it more complex
than necessary. Also, to reply to Julian, I doubt that people really
depend on the ability to copy a WC root into itself becaus that's the only
special case of this that works. Removing the capability to copy an URL
into an descendant, however, seems more obstructive to me, so I don't want
to do that.
I am still for effectively reverting r14401 to avoid complexity for a very
special case.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 26 15:11:29 2006