On Thursday 26 January 2006 11:27, Julian Foad wrote:
> 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 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
>
> [...]
>
> > :-) 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.
Sorry, I should've been more clear. I'd prefer that we allow the operation in
the WC rather than forbid it. I assumed that this ability was allowed for a
reason, but it may have just been an implementation detail of the RA layers
that allow this to occur there.
The command line client can most certainly do more complicated rearrangements.
I've had great success in rearranging entire source code trees, modifying the
build environment, and committing it all in one nice changeset.
> (What's mucc? A very quick Google revealed lots of University Cricket
> Clubs and the like.)
It's in the contrib area. It's a tool written by Philip Martin which allows
you to do multiple repository side copies, moves and deletes in a single
commit.
> > 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.
My reasoning was consistency. If it doesn't make sense in the WC, how does it
make any more sense at the RA layer? But I guess that's not enough reason by
itself.
> > 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.
As I said before, I've been away from any real development for a while now.
You guys are certainly much closer to the issues. Please do as you see fit.
I was just voicing an opinion, and trying to answer Peter's original
question. :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 27 02:27:09 2006