[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: r14401 and copy mydir mydir

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2006-01-26 17:27:14 CET

Peter N. Lundblad wrote:
> On Thu, 26 Jan 2006, John Szakmeister wrote:
>>>>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
> :-) But if we remove the posibility from the repository as well, you
> couldn't do this kind of things, even *with* mucc.

Yes... I didn't follow that "discrepancy" sentence. The discrepancy we're
talking about is the ability to copy into a child (or grandchild) directly in
the repository but not in the WC, yes? Our "svn" command-line client can't do
any but the most trivial rearrangements atomically in the repository anyway.

(What's mucc? A very quick Google revealed lots of University Cricket Clubs
and the like.)

> 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.

Right. I didn't realise that deeper copies didn't work. In that case, yes,
it's an even sillier special case than I thought.

> 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 think that's a very odd capability to have. What's it for? I can't see any
good reason to have it. I've got a feeling the reason we allow
copy-into-itself might be just because the implementation of the repository
made it happen naturally, and nobody thought of adding special-case code to
forbid it.

Still, I don't think that not having it on the WC is a reason to forbid it on
the repository now.

> I am still for effectively reverting r14401 to avoid complexity for a very
> special case.

+1. If anyone wants to argue for adding in a full capability of WC
copy-into-itself, that's a separate issue for later.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 26 17:55:44 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.