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.
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."
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). 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...
---------------------------------------------------------------------
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