[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS diff and unknown files.

From: Paul Sander
Subject: Re: CVS diff and unknown files.
Date: Wed, 26 Jan 2005 01:01:55 -0800

On Jan 25, 2005, at 9:29 AM, address@hidden wrote:

Todd Denniston <address@hidden> writes:

Paul had a case for desiring in certain cases to contact the server on add. Both cases _are valid_, my desire would be for add to contact the server
only when an extra flag is passed.

Well, I believe Paul case (lost productivity) is valid, but has nothing
to do with 'cvs add', sorry. There is currently no way for CVS to force
the user to run 'cvs add' as soon as he creates a file in the working
copy anyway, so the user can be unaware about the problems for an
undefined time period no matter how 'cvs add' is implemented.

CVS doesn't have to force the user to run "cvs add" as soon as possible. But for those who religiously add files as soon as they create them, they won't have to wait to find errors that can be detected at add time. Those of you who prefer to wait to discover these errors can do so by postponing the adds as long as you like, and in fact my proposal allows for disabling the checks altogether at add time and catching them at commit time instead as CVS currently does.

The whole point is to *enable* early detection of these kinds of problems for people who need the help, while letting those who don't care maintain their status quo. A large part of the CVS audience these days is in mixed-platform shops where naming conventions must be strictly enforced to maintain a smooth process end-to-end. These are the people who need the help, and it should not require an act of an admin and the possible loss of history to recover from a stupid mistake that could have been avoided early on.

continuation of Pauls' arguments leads me to the requirement for CVS to
notice new/removed files/directories automatically making 'cvs add' and
'cvs remove' obsolete in the first place, not that I'm in favor of the

I'm afraid I don't see how this is a logical continuation of my arguments. I think it's unlikely that CVS will ever be able to second guess the user's intent when files appear or disappear in the workspace. The add and remove commands are clearly necessary to signal the introduction and abandonment of sources.

I do believe that 'cvs -n commit' is the right way to check if the
repository is willing to accept changes. If one needs functionality to
check only additions and/or removals, then this functionality could be
provided through 'cvs commit' so that it would be possible not only to
check, but also to commit additions and/or removals only. This way
Pauls' requested 'cvs add' functionality will be available through 'cvs
-n commit -O add', provided the '-O add' means "additions only". This is
IMHO more logical and consistent than -C switch proposed for the 'cvs

So, to add a file, the user must:

edit file
cvs add file
cvs -n commit file
edit file
cvs commit file

Why not just skip the third step and run the check in one command? It's the addition of optional capability by adding to the command stream that makes clunky user interfaces. Things that are done together should be done in the same commands.

Adding more command line options to the second command doesn't help, either, because it just makes the learning curve higher. It's a much simpler user model and implementation to just put in the add hook and edit .cvsrc to shut it off. That way, you set it once and forget it; you don't have to continually remember to run some arcane series of commands to do simple things.

The other thing to consider here is that by adding the second command, you put responsibility of enforcing policy on the user, not on the tool. That opens up avenues for mistakes that are more natural than procedure. The proposal that I'm making prefers procedure while keeping the barrier low for those who believe that they can defeat it safely.

Making changes to the working copy (be it editing existing files or
adding/removing files/directories) and verifying these changes against
the repository are separate activities. Let them continue to be
different activities, please.

You obviously view your toolset as a small collection of primitive tools that you can combine in arbitrary ways to cool and useful things. And when you say you want to "this" then all you need to do to "this" is "that and that and the other thing, no problem."

But then there's the other half of the users, who say "All I want to do is this, and don't bother me with the details." All they want to do is accomplish some common task that happens to be what you consider to be two primitives. But since configuration management isn't interesting to them, they want one command to do what they want. Sure, it could be scripted, but then they to learn still more tools, which they won't do because they think the learning curve is too high. It's way easier to make the tool perform the sequences of actions that the user wants than to make the users remember every nuance of some tool they prefer not to use in the first place.

Take another example, like creating branches:

cvs tag -b branch
cvs update -r branch

Seriously, how many times do your developers do the first without the second? "All I want to do is create a branch and work on it, and don't bother me with the details." Why in the world should they have to give two commands? They'll forget the second one half of the time and wonder why their code's going to the wrong place. Now I'm not proposing any changes to this specific set of commands (at this time), but I point out that there are still lots of places where usability could stand some thought.

In my point of view, the optimal CVS behavior is the following:

1. Neither 'cvs add' nor 'cvs remove' ever contact repository (-C
   aside, see below).

2. To check if the changes are OK without actually committing them,
   including addition and removal of files, 'cvs -n commit' should be

3. -O (add|remove|change) option could be implemented in 'cvs commit' if
   somebody finds enough sense in it (I don't).

4. Provided -O is implemented, -C option for add (and remove) could then be implemented to be semantically the same as running 'cvs add files'
   followed by 'cvs -n commit -O add files'. I.e., it will warn about
   the problems, not prevent the operation.

   [By the way, why is it -C, and not -c? There is similar option for
   cvs tag called -c]

Why not just skip step 3 and just have "cvs add" run "cvs -n commit" with an option to shut it off? To answer my own question, it's because the set of possible actions are different at add time and commit time. Commit triggers sometimes run style checkers or deployment scripts (or other things) that just aren't appropriate at add time.

Besides, concerning informing the user about problems ASAP, I find
myself using 'cvs add' and 'cvs remove' as *late* as possible (as close
to the commit as possible) due to the oddities in CVS behavior described below. Consider the following use-case where the intent of tagging is to
mark the repository state just before committing of a set of changes
that includes adding and/or removing of some files:

$ cd working_copy
$ echo a > a
$ cvs add a
cvs server: scheduling file `a' for addition
cvs server: use 'cvs commit' to add this file permanently
[... time passes ... and now I'm ready to commit...]
$ cvs update
$ cvs tag -F before-my-changes
cvs server: nothing known about a
cvs [server aborted]: correct the above errors first!

Oops! Need to remove file back to be able to tag the repository!

Doesn't error "nothing known about a" look funny by the way? Shouldn't
'cvs update' show "N" meaning "nothing known" instead of "A" as the
status of the file then :)

You're falling into the same trap that Greg does, which is to think that the way CVS works today is the way that it simply must work (except when he has an idea to make it better for himself). I agree that your use case points out another ugly wart in the way that CVS was designed and implemented.

But consider this: "All I want to do is tag my files before I commit them, and don't concern me with the detail". Okay, which versions do you want tagged, the ones that appear in your workspace when you did the update, or the ones that will appear in the repository when you commit? The tag command should be changed to do what you want and expect, not to force you into some bogus sequence of commands just to satisfy the tool.

Another possible approach would be to have the update move your tags for you, perhaps as an option. Or if the tags are moved to track common ancestors for subsequent merges, perhaps a commit that doesn't appear in your sample command stream should move the tags. These are all things that should be considered when thinking about improving the UI, because these are kinds of things that would make CVS both powerful and easy to use, rather than powerful and clunky. Simply exposing more and more primitive operations, while useful for process automation, doesn't help the users.

Somewhat similar problem exists with 'cvs remove' (here the problem is
even harder to avoid as 'cvs update' re-creates missing files not marked
with 'cvs remove'):

$ rm b          # don't need this file anymore
$ cvs remove b  # need this to prevent 'update' from re-creating it.
cvs server: scheduling `b' for removal
cvs server: use 'cvs commit' to remove this file permanently
[... time passes ... and now I'm ready to commit...]
$ cvs update
$ cvs tag -F before-my-changes
cvs server: Tagging .
cvs server: skipping removed but un-commited file `b'

Oops! Need to undo the 'cvs remove' of the file to be able to correctly
tag it in the repository.

Again, this is a human factors issue that wasn't well considered when CVS was designed. If you want to tag the versions of the files that appeared in your workspace as the result of the update, then CVS should remember that result and not erase the version number in its metadata when it flags the removal.

I wonder if the above two issues are going to be fixed as a side effect
of the proposed 'cvs add' implementation as well. I think the first
error should only be generated if the user provided '-c' to the 'tag'
command. As for the second case, I think that without '-c' cvs should
tag the file (either silently or issuing a warning), and with '-c' it
should abort the whole operation.

I don't believe that these issues have been considered as part of either "cvs add" proposal.

Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]