> 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.
I don't think you've made your case here.
You argue that people are more careful about removing controlled files
than creating uncontrolled files. And that "[o]nce a file is under
version control, the user is presumed to be treating it with the
respect it deserves." I agree with that.
However, I think the principle is broader and simpler: people are
careful with all changes to controlled files; and they are not so
careful with uncontrolled files.
accidentally delete a file under version control --- that if they do
so, it's almost certainly a deliberate action. Again, I agree.
But here's the problem: the same is true of renaming and copying
versioned files: it's almost always done on purpose, and Subversion
should interpret that as a change that should be committed. You've
failed to establish any distinction between deletes, copies, and
renames.
So now we're back to where we started: we know the behavior we want ---
Subversion should simply notice all changes to controlled files ---
but we can't implement that. That's why we have `svn mv' and `svn cp'
in the first place. So the only rationale left for treating `rm'
differently is `we can figure out how to implement that'. Which is a
weak argument.
that `rm' is different from `cp' and `mv'. Since they can work the
same, they should work the same.
Received on Sat Oct 21 14:36:09 2006