[snip]
> 1. svn add foo; rm foo; svn rm/revert foo (completed issue #863)
>
> This is the simplest way to get a "missing, schedule-add" item.
> Running either rm or revert just undoes the scheduling, but with
> a nasty side effect that the item is gone forever. Someday, the
> user should be able to revert just the missingness, not the
> scheduling. (But it's better than having a jammed wc, as we
> used to.) This can live as is.
>
> Other cases to consider:
>
> 2. rm foo; svn rm foo
>
> *** This should work on both files and dirs. Currently fails for
> dirs.
> Will fix this for #962.
>
> 3. rm foo; svn mv/cp foo bar
>
> => We should error on this for now, because ultimately it just
> results in case #1, which while we can't prevent, we can at
> least discourage from happening automatically.
>
> => Someday, when we can control reversion of missingness and
> schedule separately, the correct behavior is two schedulings
> -- D and A, on two missing items. (a susequent 'svn commit'
> will fail, but at least the user will be able to get the
> items back to retry the commit.)
>
> 4. mv foo bar; svn mv foo bar
>
> => This is the same scenario as case #3, except that a dest file
> is in the way. Just like case #3, this should produce an
> error for now, because we don't want to promote the missing
> scheduled-add scenario.
I'd like to point out here that exactly this is the feature I need for my
svn client and I think many IDE-plugins would need also. Producing
an error is not a solution. If not otherwise possible then I'd like to
propose a new command like "svn virtmove" which does nothing
but do a normal "svn mv" without touching the actual working copy files.
background: my svn client (TortoiseSVN) is an extension to the windows
explorer. It's possible to monitor actions the user makes inside the
explorer,
but only AFTER the user did the change. So to keep the user actions in
sync with subversion I really need the possibility to do
renames/moves/deletes
in subversion where the files in the working copy are already
renamed/moved/deleted.
For such a separate function it would be the responsibility of the client to
make
sure that no other changes have been made to the working copy outside
subversion.
btw: that's the feature which prevented me from releasing a first version of
TortoiseSVN until now...
Steve King
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 18:24:44 2003