info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS diff and unknown files.


From: Greg A. Woods
Subject: Re: CVS diff and unknown files.
Date: Thu, 27 Jan 2005 15:36:06 -0500 (EST)

[ On Wednesday, January 26, 2005 at 21:05:46 (-0800), Paul Sander wrote: ]
> Subject: Re: CVS diff and unknown files.
>
> 
> 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.

Developers who think they require add-time triggers need their heads
examined, but if they really think they want to implement them then they
have all the power of any programming language they desire to do so in
a pogram that they build over and above and outside the core CVS program.

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

That's pure and utter bullshit.

These so poortly named "triggers" in CVS now were a poor idea from the
start which have been misperceived by folks such as yourself (and no
doubt your blathering on about your misperceptions has only spread the
problem further) and they've been rather poorly implemented to boot.

If you think you want policy control over working directories then
either you're using the wrong tool for the job, or you need to think
more like a true toolsmith and build your policy enforcement tools over
and above and outside the core CVS program where they belong.


> It's frequently said to users that "tags apply to the versions in your 
> workspace" when "cvs tag" is used.

If that's the way it is being said then that is misleading.

Tags applied by the "cvs tag" command go, by default, against the
BASE REVISIONS of the files in the workspace.

(and besides, files in the working directories don't really have
revisions -- they were derived from their base revision and they may, or
may not, have local changes)

>  But on the other hand, 
> having an atomic commit/tag operation would be useful if it existed...

once again you're trying to use, or thinking of using, the wrong tool
for the job.

CVS does not, should not, and need not, try to guarantee atomicity for
higher-level SCM abstractions.


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

Well obvsiously cvs does remember the base revision of a locally removed
file (1.3 in this case):

5:31 [1872] $ cvs status which.csh
===================================================================
File: no file which.csh         Status: Locally Removed

   Working revision:    -1.3    Tue Jun 17 21:13:33 2003
   Repository revision: 1.3     
/cvs/master/m-NetBSD/main/src/usr.bin/which/Attic/which.csh,v
   Sticky Tag:          netbsd-1-6 (branch: 1.3.12)
   Sticky Date:         (none)
   Sticky Options:      (none)


The bug in "cvs tag -F" is that it just doesn't make use of that memory.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]