Re: CVS diff and unknown files.

[Greg A. Woods]

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

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.

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.

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


> 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 
> > 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 :)

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 
> commit?

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

However if you keep in mind that you cannot commit changes to
out-of-date files, the silly "dilema" you pose proves to be even more
nonsensical.

(and if you want to tag specific revisions in the repository without
respect to the state of any working directory then you would use "cvs
rtag" for that)


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


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

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.

-- 
                                                Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>