[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.
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.
- Re: CVS diff and unknown files., (continued)
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/24
- Re: CVS diff and unknown files., Todd Denniston, 2005/01/24
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/24
- Re: CVS diff and unknown files., Paul Sander, 2005/01/24
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/24
- Re: CVS diff and unknown files., Larry Jones, 2005/01/24
- Re: CVS diff and unknown files., Todd Denniston, 2005/01/24
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/25
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/25
- Re: CVS diff and unknown files.,
Paul Sander <=
- Re: CVS diff and unknown files., Greg A. Woods, 2005/01/26
- Re: CVS diff and unknown files., Paul Sander, 2005/01/27
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/27
- Re: CVS diff and unknown files., Greg A. Woods, 2005/01/27
- Re: CVS diff and unknown files., Paul Sander, 2005/01/28
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/28
- Re: CVS diff and unknown files., Todd Denniston, 2005/01/28
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/28
- Re: CVS diff and unknown files., Todd Denniston, 2005/01/28
- Re: CVS diff and unknown files., Sergei Organov, 2005/01/30