[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 21:05:46 -0800

On Jan 26, 2005, at 11:06 AM, address@hidden wrote:

[ On Wednesday, January 26, 2005 at 01:01:55 (-0800), Paul Sander wrote: ]
Subject: Re: CVS diff and unknown files.

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.

Well since I believe the design to be correct and the best possible for
the goals and requirements, it's certinaly not an ugly wart.

Okay, so we're in violent agreement on that small point!  :-)

What would be ugly would be some all-knowing big-brother implementation
that forced policy on everyone despite the fact that everyone's needs
differ.  (and I'm talking of course about multiple groups each with
their own repositories, not multiple individuals using the same repo)


If you want these kinds of policies then you can trivially implement
them over and above the core "cvs" program using wrapper programs and/or
scripts.  Even your stupid "register adds in the repo" nonsense can be
easily implemented by wrapper programs and a tiny registry on the server.

What "register adds in the repo" nonsense are you talking about? The proposal I made simply requires a contact with the server to run the add-time triggers; it does NOT require add-time modifications of the repository by the CVS server itself. If the triggers drop turds in the repository, then that's a different matter. Also remember that my proposal includes a way to shut off the add-time triggers as a client configuration, deferring them to commit time to accommodate users like you.

Another point that I would like to make, however, is that CVS can become more feature-rich, support multiple policies, and have a simpler user interface (in most use cases, at least) all at the same time. The problem is that most of us here are too close to the implementation to take a fresh view of the problem.

In the core CVS program the "cvs add" and "cvs remove" operations must
be fixed to be equivalent to "vi file.c" -- i.e. operations which _ONLY_ affect the local working directory and which _NEVER_ contact the server.

See above. If there are no add-time triggers, then I can live with what you say. On the other hand, some shops REQUIRE add-time triggers, and if add-time triggers are used then contacting the server is REQUIRED to make them run. I had hoped that this was clear in the last go-round, but apparently not.

Policy goes above -- it is not hard-coded in the core functionality.

Agreed. But the tool must be sufficiently flexible to allow robust implementations of policies. Sometimes triggers are the right way (and wrapper scripts are not), and we've identified one area here where CVS is not sufficiently flexible.

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

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
below. Consider the following use-case where the intent of tagging is
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 :)

No, CVS shouldn't say anything about the unknown file. The tag is being
applied to the base revisions of the files in the working directory.  A
newly added, but uncommitted, file is simply like any other changed file
in the working directory and the '-F' should ignore it just as it
ignores the changes to files that are already in the repository.

I.e. that is a bug, pure and simple.

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

That's a nonsensical question.  Tags can only be applied to revisions
that are already in the repository.  Tags applied with "cvs tag" always
begin with the base revisions that the working directory was created

Remember, I take a user-centric view of the world when I discuss CVS. It's frequently said to users that "tags apply to the versions in your workspace" when "cvs tag" is used. But after the user has edited a file, there are suddenly two possible versions to which a tag might be applied. You and I know that the version that gets the tag is really the one that's listed in the Entries file, but the user may expect the "cvs tag" to create a side-effect in his workspace that causes the versions created by a later commit to be tagged.

In this case, the user needs to be educated. But on the other hand, having an atomic commit/tag operation would be useful if it existed...

 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.

The "cvs tag" and "cvs rtag" commands can already do exactly what he
wants, and what he expects -- and the ordering of commands is not
"bogus", but rather a clear and obvious progression of steps.  Things
have to be done in the proper order.  You can't commit changes you
haven't made yet, for example.

As I recall, the user wanted to perform the following steps:

cvs update
cvs rm foo
cvs tag bar
cvs commit

The problem was that "cvs tag" was complaining that it could not tag the foo file. This is because CVS didn't remember what version it had after the rm. In this case, the user is expecting one of two things: Not tag foo at all, or apply the tag to the version of foo that was left in the workspace by the last update. In both cases, the current behavior of CVS (to complain and exit) is wrong, and the user must go through many hoops to undo the rm to complete the tag successfully, then repeat the rm.

Somewhat similar problem exists with 'cvs remove' (here the problem is
even harder to avoid as 'cvs update' re-creates missing files not
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.

No, this one is a bug, pure and simple.

The uncommitted remove is no different than ny other uncommitted change
and the '-F' should work as advertised.

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

There's nothing to consider about them.  They are both bugs.  They are
both bugs that stem from some of the very poor implementation hacks that
were done when CVS was first split into separate client and server
processes, but they are bugs none the less.

I think they existed before that, all the way back to Grune's original scripts. At least we agree that they're bugs. But there's room to debate (rather heatedly, no doubt!) what the "correct" behavior should be. But for the record, I personally don't care about the tag vs. add/remove issue; none of my use cases trip over it.

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]