Regarding "svn edit", I don't have a principled opinion one way or the other
about whether this should be required. My personal bias is that I like the
current CVS behavior. I do not use CVSREAD, which may bias my view.
However, I see no reason why "svn edit" should be excluded. That is, a "svn
edit" command might be useful even if I can just edit in the file system.
In particular, for those people who like the 'CVSREAD' behavior, it seems to
me that "svn edit" could usefully make a marker of some kind in the
client-side information recording the fact that the file was edited
intentionally. This may be useful, and it provides a uniform command
interface for both styles of working.
For those who do *not* use CVSREAD, however, I would not require it. It is
uncomfortable when too many tools try to take over my environment. Here, for
example, is an extreme proposal that I do NOT advocate, just to illustrate
the point: svn could be a shell.
Brief anecdote: Many years ago we built a debugger at Bell Labs whose
default behavior if all else failed was to try exec'ing your command in the
obvious way. The idea was that *all* of your commands should be under the
control of the debugger, and you could decide later which ones you actually
felt like debugging. We put it in because it was "clever", and it helped us
illustrate a point to an executive at Bell Labs.
When we released the debugger internally for people to use, we found to our
surprise that a great number of people simply made the debugger their shell.
Back to the main thread: svn takes over the "mv" and "rm" commands (and
presumably "cp", though I haven't seen that mentioned yet) because it must.
Interface regularity would argue that commands related to namespace
manipulation should therefore have svn equivalents. svn edit is not a
namespace command. Perhaps svn should include it, but its omission will not
cause user confusion.
As I say, no strong opinion pro or con.
shap
Received on Sat Oct 21 14:36:09 2006