On 17 Sep 2001 13:46:02 -0500
cmpilato@collab.net wrote:
> Mo DeJong <supermo@bayarea.net> writes:
>
> > Thanks for the reply Mike. Could I bother you to elaborate a bit more
> > on why doing a `svn add foo.c` and then a `svn delete foo.c` to change
> > your mind before a commit is wrong? Shouldn't the user think of add
> > and delete as inverse operations?
>
> Add and delete may be inverse operations, but the 'add' and 'delete'
> client subcommands are a bit misnamed. `svn add' does not add a file
> to the repository, it merely "schedules" a file for addition to the
> repository. Likewise, `svn delete' merely schedules a file for
> deletion from a repository. Those actions don't really happen until a
> commit occurs.
Yes, but by the same token you could just say that these commands
just add or delete a file to the WC. We don't need to assume that
the user doing the add will be the person doing the commit. A
contributor might send us a patch that adds some new files and
deletes others. The developer assigned to review patches would
actually make the decision as to wether or not to commit to the
repository.
> Actually, let's look even at their inverseness a little bit, too. If
> "add" and "delete" are truly inverse actions, then "unadd" == "delete"
> and "undelete" == "add". But "undelete" is certainly not "add". The
> action sequence "delete foo; add foo" is not a no-op -- it's what we
> call a "replace" operation, and is used to restart the version history
> for "foo."
That is an interesting point. The add/delete operations would be the
same in the case of a new dir or file but a delete on an existing
dir or file seems to call out for an undelete operation. What if
we toss unadd and kept undelete but renamed it to "resurrect"?
The subcommand would be used to bring a deleted entry back to life?
> There is one optional idea I'd like to throw on the table (since there
> don't seem to be enough things to debate about these days).
Well, now is the time to hash out usability issues. After 1.0 it will be too late.
> It occurs
> to me that perhaps unadd and undelete could disappear entirely in
> light of `svn revert.' Can "revert" be used to completely restore a
> given working copy file or directory to it's uncommitted state?
>
> Wouldn't it be cool to do:
>
> svn up .
> svn add foo.c
> svn rm bar.c
> echo "crap, i didn't mean that."
> svn revert .
>
> and have nothing look any different? But that requires more
> brainshare than I have to give right now. Anchors... targets...
> anchors... targets...
That certainly sounds like something revert should do. That would
provide the current undelete functionality but it would not give us
the ability to do a `snv undelete dir` on a directory delete that
has already been committed.
cheers
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006