"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.
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...
> 2. schedule and new-name
>
> When a file is moved, the entries files should be adjusted as such:
>
> 1a. The entry for the original filename should be given
> schedule='move-to'. This will indicate that the file is to be deleted
> (as schedule='delete') when committing, but also that the file is to be
> treated as renamed for other situations. It will also be given the
> attribute new-name, with the value of the new filename (relative to
> what? I have not yet decided the best answer for that yet. It should be
> chosen such that the new file can be found.)
That parenthetical part is one of the hard questions, yes :-)
> 2a. The entry for the new filename should have schedule='move-from' and
> the attribute old-name with what the filename was originally (again,
> I am not yet certain what it should be relative to, just that we should
> be able to correctly determine the original filename.)
Instead of these new 'schedule' types, why not just have new
attributes:
moved-to='dest path'
on the source file's entry, and
moved-from='src path'
on the dest file's entry? The schedule flags can remain as they are
now (deleted, copied). This has the added advantage that a new style
WC would (probably) continue to work even if the client downgraded for
some reason.
> If the entry for the old filename already has schedule='move-from', then
> this is the 2nd step of '[case 2]' above, and we need to do this instead:
>
> 1b. Find the entry for the original filename, based on the old-name
> attribute. Set *that* entry's new-name to the correct new name.
Yup; conceptually this remains true either way.
> 2b. Delete the entry for the old filename.
>
> 3b. Create an entry for the new filename, as in step 2a above.
>
> Then, undoing a move should consist of:
>
> $ svn mv foo bar
> # oops
> $ svn revert foo
> # or, svn revert bar
>
> and not this, which is currently what's required:
>
> $ svn mv foo bar
> # oops
> # svn revert foo
> # svn revert --recursive bar
> # rm -rf bar
Agreed.
> Alternatively, with enough intelligence, this should work:
>
> $ svn mv foo bar
> # oops
> $ svn mv bar foo
>
> This sort of thing should (hopefully) leave everything in the original
> state, without reverting the *contents* of any changed files.
> 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.
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).
Would you like to link to this thread from issue #898?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 11 00:34:33 2005