Re: CVS diff and unknown files.

[Paul Sander]

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)

Agreed.

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

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

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.