You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@galois.collab.net> on 2000/09/27 18:42:27 UTC
User interface proposal
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
Re: User interface proposal
Posted by Bryan O'Sullivan <bo...@serpentine.com>.
k> 1. Adding anything requires the user to run "svn add".
k> 2. Renaming anything requires the user to run "svn rename".
k> 3. Copying anything requires the user to run "svn cp".
Fine ideas all.
k> Deleting anything is done simply by deleting the thing --
k> Subversion will detect the deletion automatically and do the right
k> thing when you commit.
I think this is rather a bad idea. If I fail to notice that I've
deleted a file and then do a commit, I've broken the repository. No
matter how easy it may be to revert such a mistake, it should *not* be
trivial to make. In a busy project, any such error takes an
inevitable toll on other people.
k> This is a side-benefit -- clearly, the user interface should be
k> what's most convenient for users, but I think it's also nice when
k> it matches how the code works underneath.
Convenience for users has more than one side in this case. It might
be "convenient" for one user to be able to delete a file without doing
anything magical, but if an inadvertant application of that
convenience causes headaches for three others, you're not winning.
<b
Re: cvs commit confirmation (was: User interface proposal)
Posted by "Jonathan S. Shapiro" <sh...@eros-os.org>.
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
Re: cvs commit confirmation (was: User interface proposal)
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>
> Bob Miller <kb...@jogger-egg.com> writes:
> > As for "svn rm", I'd rather it be explicit, for the reasons others
> > have already cited. (I'd rather that "svn edit" be explicit, too.)
>
> The latter would cause a revolt, probably. :-) CVS working copies are
> editable the moment they appear on disk;
>
(Unless you define CVSREAD.)
>
> if people had to issue a
> command before editing files in Subversion, they'd be surprised and
> almost certainly unhappy.
>
I disagree. There are a lot of people out there (including me, sometimes
:-) who prefer to have unchanged working copies read-only, and
explicitly start a change with `cvs edit'.
(I'll post a longer message about this and other "wishlist" topics that
I've been working on, by the way, hopefully this week.).
Brane
Re: cvs commit confirmation (was: User interface proposal)
Posted by Bruce Korb <bk...@sco.COM>.
Karl Fogel wrote:
> > One of the things I like about Perforce is that default behavior
> > of "p4 submit" is that it drops you into an editor where you
> > can see what all you've changed. Files added, edited, and deleted
> > are listed (Perforce has no rename operation), and you can
> > edit the list while you're editing your log message.
> That's probably too far from the CVS conventions for most users to
> accept (also, CVS has a different, but okay, way of providing similar
> functionality).
Sounds like a good configuration candidate.
I think such a feature would be excellent!
> > As for "svn rm", I'd rather it be explicit, for the reasons others
> > have already cited. (I'd rather that "svn edit" be explicit, too.)
>
> The latter would cause a revolt, probably. :-)
Config issue :-) I prefer either way, myself.
> CVS working copies are
> editable the moment they appear on disk; if people had to issue a
> command before editing files in Subversion, they'd be surprised and
> almost certainly unhappy.
I generally work from read-only copies and make specific pieces
of it editable. I like that behavior.
Except for where it is too little benefit for too much work,
configure it :-) Personal taste & project-wide config files are great.
Re: cvs commit confirmation (was: User interface proposal)
Posted by Karl Fogel <kf...@galois.collab.net>.
Bob Miller <kb...@jogger-egg.com> writes:
> While we're on the topic of user interface...
>
> One of the things I like about Perforce is that default behavior
> of "p4 submit" is that it drops you into an editor where you
> can see what all you've changed. Files added, edited, and deleted
> are listed (Perforce has no rename operation), and you can
> edit the list while you're editing your log message.
>
> I'd like to see that behavior in svn (doesn't have to be the
> default).
That's probably too far from the CVS conventions for most users to
accept (also, CVS has a different, but okay, way of providing similar
functionality).
> As for "svn rm", I'd rather it be explicit, for the reasons others
> have already cited. (I'd rather that "svn edit" be explicit, too.)
The latter would cause a revolt, probably. :-) CVS working copies are
editable the moment they appear on disk; if people had to issue a
command before editing files in Subversion, they'd be surprised and
almost certainly unhappy.
Re: cvs commit confirmation (was: User interface proposal)
Posted by Bob Miller <kb...@jogger-egg.com>.
Bob Miller wrote:
> One of the things I like about Perforce is that default behavior
> of "p4 submit" is that it drops you into an editor where you
> can see what all you've changed. Files added, edited, and deleted
> are listed (Perforce has no rename operation), and you can
> edit the list while you're editing your log message.
Please disregard this. I know better now.
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
cvs commit confirmation (was: User interface proposal)
Posted by Bob Miller <kb...@jogger-egg.com>.
Karl Fogel wrote:
> Of course. Only commits can affect the repository, and a commit
> always succeeds entirely or not at all.
While we're on the topic of user interface...
One of the things I like about Perforce is that default behavior
of "p4 submit" is that it drops you into an editor where you
can see what all you've changed. Files added, edited, and deleted
are listed (Perforce has no rename operation), and you can
edit the list while you're editing your log message.
I'd like to see that behavior in svn (doesn't have to be the
default).
As for "svn rm", I'd rather it be explicit, for the reasons others
have already cited. (I'd rather that "svn edit" be explicit, too.)
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
Re: User interface proposal
Posted by Karl Fogel <kf...@galois.collab.net>.
John P Cavanaugh <ca...@soco.agilent.com> writes:
> Im still assuming though that these things still dont "happen" in the
> DB until a svn commit, right???
Of course. Only commits can affect the repository, and a commit
always succeeds entirely or not at all.
Re: User interface proposal
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Wed, Sep 27, 2000 at 01:42:27PM -0500, Karl Fogel wrote:
> 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.
>
> 4. Deleting anything is done simply by deleting the thing --
> Subversion will detect the deletion automatically and do the
> right thing when you commit.
Ouch... I personally dont like this one. I think this is attempting
to be too smart. Make them do a "svn rm" and just be done with it.
Im still assuming though that these things still dont "happen" in the
DB until a svn commit, right???
--John Cavanaugh
Re: User interface proposal
Posted by Karl Fogel <kf...@galois.collab.net>.
Jim Blandy <ji...@savonarola.red-bean.com> writes:
> 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.
Very well put.
Okay, list, you win: we'll go for conservative consistency and have
"svn rm". :-)
Re: User interface proposal
Posted by Jim Blandy <ji...@savonarola.red-bean.com>.
> 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.
Re: User interface proposal
Posted by Karl Fogel <kf...@galois.collab.net>.
pohl <po...@screaming.org> gave permission to quote:
> I think this is a beautiful interface. It's what I'd like
> cvs to be. Incidentally, I think "svn resurrect" should be
> the actual incantation for restoring an accidentally removed
> file.
Yep -- as with CVS, there are synonyms:
svn resurrect
svn revert
svn rvt
Re: User interface proposal
Posted by Joerg Bullmann <jo...@fontworks.com>.
At 3:33 PM -0700 27/9/00, Bruce Korb wrote:
>Ed Korthof wrote:
>> Alternately -- if I can turn the implicit delete behavior off via
>> configuration, then I'd be happy.
>
>Yep. Make it all configurable, but in any event a suggestion
**Please don't**. How does the user know what to do? He tries
finding out how your installation is configured? Users are
thus forced to dig for even more info than they need to anyway.
Making it configurable is even worse than the original proposal
> 4. Deleting anything is done simply by deleting the thing --
> Subversion will detect the deletion automatically and do the
> right thing when you commit.
What the average treetrunk using the tool later will
easily understand is "svn rm". Here, it is as obvious
as possible that THIS remove has something to do with
SVN and not with the shell.
For SVN to be a success, it needs to have maximum everyday
robustness, not only in terms of factual reliability but
also in perceived reliability. And if users feel the can't
trust SVN because it "mysteriously removed files from the
repository -- and I had only deleted my messed up working
copy from the sand box", that's really bad. And -- worst
of all -- it will happen.
Please, please, please. Do it the "svn rm" way. I'm so glad
that a few others think along the same lines.
And the multi step CVS remove might have had this in mind:
make sure the user really WANTS to remove the file. Put
a few hurdles in the way so that all removes are intended.
Joerg
--
They can take away my Mac when they pry
my cold, dead fingers from my mouse.
Re: User interface proposal
Posted by Ed Korthof <ed...@collab.net>.
On Wed, 27 Sep 2000, Ed Korthof wrote:
> On Wed, 27 Sep 2000, Bruce Korb wrote:
>
> > Yep. Make it all configurable, but in any event a suggestion
> > was made that ought to address all the issues: when the commit
> > command is issued, an editor/viewer is brought up that lets
> > you explicitly see what files are being added, deleted and
> > modified. If there is anything that you do not want in the
> > commit, then edit it out from the view file. :-).
Sorry -- I missed the part about being able to edit the list of changes;
I'm ambivalent about that, since it implies finding structure in the file
produced by the editor session. I don't think it's wrong, I'm just
ambivalent; besides, I've never minded exiting the sesion, aborting the
commit, fixing whatever's wrong and then doing the commit operation again.
However -- that doesn't address the issues brought up wrt implicit
deletions -- because it's quite possible for a user to fail to notice an
unintentional deletion. Esp. if subversion offers non-interactive commit
operations (as cvs does) ... I don't know if that's the plan, but I
wouldn't be surprised if some people wanted that feature.
thanks --
Ed
--
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
| Ed Korthof | edk@collab.net | 415-247-1690 |
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
Re: User interface proposal
Posted by Ed Korthof <ed...@collab.net>.
On Wed, 27 Sep 2000, Bruce Korb wrote:
> Ed Korthof wrote:
> > Alternately -- if I can turn the implicit delete behavior off via
> > configuration, then I'd be happy.
>
> Yep. Make it all configurable, but in any event a suggestion
> was made that ought to address all the issues: when the commit
> command is issued, an editor/viewer is brought up that lets
> you explicitly see what files are being added, deleted and
> modified. If there is anything that you do not want in the
> commit, then edit it out from the view file. :-).
The way I use CVS, I get that -- when you don't put in the commit message
on the command line, it pops up an editor session (via EDITOR) where the
file you're editing includes a list of files modified, added, and deleted.
I'd definitely agree that it's important that subversion offers similar
functionality ... I know I'd be very unhappy otherwise.
thanks --
Ed
--
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
| Ed Korthof | edk@collab.net | 415-247-1690 |
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=
Re: User interface proposal
Posted by Bruce Korb <bk...@sco.COM>.
Ed Korthof wrote:
> Alternately -- if I can turn the implicit delete behavior off via
> configuration, then I'd be happy.
Yep. Make it all configurable, but in any event a suggestion
was made that ought to address all the issues: when the commit
command is issued, an editor/viewer is brought up that lets
you explicitly see what files are being added, deleted and
modified. If there is anything that you do not want in the
commit, then edit it out from the view file. :-).
Re: User interface proposal
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Ed Korthof <ed...@collab.net> writes:
> 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.
Hmmm, actually, (Karl), this is the best argument against automatic
deletion-detection I've yet heard.
If somebody temporarily moves a file "out of the way", either
accidentally or intentionally, we *don't* want `svn commit' to infer
that the file has been deleted!
Re: User interface proposal
Posted by Ed Korthof <ed...@collab.net>.
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 |
+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=