In the past, we've said that Subversion's interface (I'm talking just
about the command line now) would be very much like CVS's.
However, Ben and I were just sitting here designing some code to
detect changes in the working copy, and we realized that a better
interface convention might be possible for adds/deletes/renames.
Here's what we're proposing (don't worry about implementation, just
ask yourself if the interface makes sense):
1. Adding anything requires the user to run "svn add".
2. Renaming anything requires the user to run "svn rename".
3. Copying anything requires the user to run "svn cp".
4. Deleting anything is done simply by deleting the thing --
Subversion will detect the deletion automatically and do the
right thing when you commit.
The pattern here is that anything which is creating a new file
somewhere requires an svn command, but mere removal does not. This is
because it's much more common to accidentally create random files in a
working copy (backup files, patch files, scratch pads, whatever) than
to accidentally remove a file that's under version control.
Therefore, new files should not be automatically added; a new file
should be presumed unimportant until the user indicates that she wants
it under version control. Once a file is under version control, the
user is presumed to be treating it with the respect it deserves.
So item #4 is the new idea. In CVS-land, you'd first remove an
object, then run "cvs rm", and then commit. We're proposing to omit
the middle step. Here's the justification:
There are basically three circumstances where one removes a working
copy file that's under CVS control:
A. accidentally
B. on purpose, but only to do an immediate update to revert the file
C. on purpose, because one really wants to delete the file
Circumstance (A) is rare. And even if you do accidentally remove a
file, you can recover it easily with "svn revert" before the commit;
or if you discover the accident after you've committed, you can
retrieve the most recent live version of the file and resurrect it.
So A is not a real problem; no information can really be lost, except
local edits, which software is powerless to protect anyway (after all,
the user deleted the only record of them).
Circumstance (B) is an artifact of CVS not having an explicit "revert"
command. In the future, people will find it odd that we used to
remove files in order to revert them. :-) In Subversion, you wouldn't
remove a file to revert it, you'd just run "svn revert". To ease the
transition, Subversion can print a warning when update is run on a
deleted file, saying "File foo.c deleted; run svn revert to undo" or
something like that.
That leaves Circumstance (C), and since circumstances A and B are
shown to be irrelevant or easily recoverable, it makes sense to simply
take C as indicating the user's actual desire -- that the file be
removed.
As it happens, this matches up very nicely with the implementation on
the working copy side (I won't go into details, ask Ben if you're
curious :-) ). This is a side-benefit -- clearly, the user interface
should be what's most convenient for users, but I think it's also nice
when it matches how the code works underneath.
Thoughts?,
-Karl
Received on Sat Oct 21 14:36:09 2006