Re: CVS diff and unknown files.

[Paul Sander]

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.

>  Logical
> 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
> latter.

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
> add'.

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
>    used.
>
> 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.