>
> "Oliver Klozoff" <stevieoh@fastmail.fm> writes:
> > Proposal: Genuine WC Moves
> >
> > Everyone agrees that genuine renames are needed, and that
> they can't
> > really be implemented until v2.0 because it will require
> incompatibly
> > extending the protocol to have a 'rename' command. This
> proposal only
> > concerns genuine renames within a WC.
>
> We have compatibly extended the client/server protocol in the
> past, and I see no reason we couldn't do it again here. If a
> server were recent enough, the client would do a real rename;
> if not, it would do
> copy+delete.
That's fine. Someone *else* told me that over-the-wire genuine
renames should be a 2.0 thing (don't remember who).
> So we shouldn't *assume* this must wait till 2.0. Instead,
> try to design it to be 1.x-compatible, and if we discover
> there's no way to do that, then we can say it must wait till 2.0.
>
> (FWIW, my instinct is that this could be done in 1.x.)
>
> > Part I: Genuine WC Moves
> >
> > 1. 'moved' attribute
> >
> > In the entries file, we have a 'copied' attribute. This
> attribute
> > indicates that the file has been copied from another WC
> item. Certain
> > operations are prohibited on copied files for technical
> reasons -- for
> > example, one cannot use an item with copied="true" as the
> source for
> > another copy operation.
> >
> > I propose adding a 'moved' attribute for all files that were
> > affected by a mv operation. This 'moved' attribute will partially
> > behave as copied="true", in that it will prohibit moved files from
> > being used as the source of a copy:
> >
> > # [case 1]
> > $ svn mv foo bar
> > $ svn cp bar bar2
> > # no way jose
> >
> > However, entries with the 'moved' attribute *should* be allowed to
> > move again, so that this:
> >
> > # [case 2]
> > $ svn mv a b
> > $ svn mv b c
> >
> > should be no different from this:
> >
> > # [case 3]
> > $ svn mv a c
>
> This may be ovekill...
Okay, if you guys don't think it's necessary, then maybe it isn't.
> > Things to consider
> >
> > * sussman wants to know: what should happen when the user
> does this?
> >
> > $ svn mv A B
> > $ svn commit B
> >
> > It can either fail (and succeed only if the user does
> 'svn commit
> > A B'), or it can behave as 'svn commit A B' does currently.
> I think
> > that it's easiest if both 'svn commit A' and 'svn commit B'
> behave as 'svn commit A B'
> > would do today.
>
> Ick -- I think having it fail is much better. If someone
> explicitly names one target, but not the other, the safest
> thing we can do is remind them of it, and then do nothing
> while the user decides the next step.
The problem I see with this is that to me, the names 'A' and 'B'
both refer to the same file ('A' being the "old name", and 'B'
being the "new name"). So requiring 'svn commit A B', to me,
is similar to requiring 'svn commit foo foo' -- it's just redundant.
>
> There's enough handwaving in Part II that I won't bother to
> review it (no insult intended, of course -- handwaving is
> healthy & useful, it just doesn't always demand a technical response).
Yeah, Part II is more of a vague idea at this point.
>
> Would you like to link to this thread from issue #898?
>
I have no idea. I don't know what issue #898 is, and subversion.tigris.org
is down *again* right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 15:29:54 2005