[ 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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs