On Wed, 27 Sep 2000, Karl Fogel wrote:
> 4. Deleting anything is done simply by deleting the thing --
> Subversion will detect the deletion automatically and do the
> right thing when you commit.
I don't like this -- it's too easy to miss the fact that you've moved or
deleted the file, and suddenly it's gone from the repository -- depending
on what's missing, it might take a while for the change to be noticed.
> 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.
I'm not so sure that 'accidental' deletions are infrequent -- I've moved
files around when doing tests. Sometimes this is with the expectation
that I'll later run cvs update to revert; but sometimes it's been other
kinds of testing, where I wanted the original file out of the way for a
little while. I think I've probably done commits before moving the
relevant files back ... if the source control system had decided that mean
I wanted the files deleted, I wouldn't have been happy with the results.
That said, I would like a command which allows me to commit the current
set of the directory -- additions and deletions and so on. But I'd want
that to be explicit, not implicit -- ie. I'd want different behavior in
these two situations:
1. commit files A, B, C
2. commit all the files, etc, in directory D
Anyway -- my preference is to require an explicitly delete operation. Of
course -- I don't mind extra complexity in the UI, so long as it's
reasonably contained, and others may feel differently.
Alternately -- if I can turn the implicit delete behavior off via
configuration, then I'd be happy.
My basic dislike of this idea is that the accidental removal of a file
from the repository is (IMO) worse than the accidental addition of
temporary files to it (autosave & whatnot) -- it's possible to recover
from either (though there will be ugliness in the history afterwards).
But the former will frequently break checkouts, while the latter will do
so only rarely.
Guessing the frequency of accidental operations with a new tool (with new
functionality) is a hard one; I don't think it's easy, and I don't think
you should underestimate the ability of your users to misuse their tools.
;-)
> 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.
What I'd be happy with is a system where any deletions of files from the
working copy -- which weren't accompanied by a 'svn rm {name}' -- caused
commits to fail (in much the same way commits fail in cvs fail if the
working copy isn't up-to-date). At that point, I could decide if I really
wanted to delete the file or not ... if not, I'd revert, and if so, I'd
explicitly delete the files.
thanks --
Ed
--
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
| Ed Korthof | edk@collab.net | 415-247-1690 |
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
Received on Sat Oct 21 14:36:09 2006