Todd Denniston <[EMAIL PROTECTED]> writes: > Sergei Organov wrote: > > > > Paul Sander <[EMAIL PROTECTED]> writes: > > > On Jan 24, 2005, at 6:20 AM, [EMAIL PROTECTED] wrote: > <SNIP> > > > It's unclear if that particular change will be made, or if made > > > whether or not it will stay. The requirement to supply add-time > > > triggers has been identified (by a number of users), which requires a > > > contact with the server. This has undergone some heated debate. > > > > Well, the problem described is in fact not in contacting with server, > > but in requiring write access to the repository. > > > > Is there any sound reason why 'cvs add' and 'cvs remove' commands > > require *write* access to the repo? > > > I believe what Paul means, is that no one has yet owned up to writing or > submitted the patches to implement the changes. > > Please see the linked thread to answer your question.
Wow! Nice discussion indeed! I'm sorry I somehow missed it (apparently thinking that it's yet another discussion about "cvs import" that IMHO is hopelessly broken for the purpose of tracking third-party sources albeit CVS manual suggest otherwise). > Greg & I believe there is no need in the normal case for add to contact the > repo, especially to write, unfortunately it is currently implemented to > connect. I'm another one here who believes Greg and you are right. > Paul had a case for desiring in certain cases to contact the server on add. > Both cases _are valid_, my desire would be for add to contact the server > only when an extra flag is passed. Well, I believe Paul case (lost productivity) is valid, but has nothing to do with 'cvs add', sorry. There is currently no way for CVS to force the user to run 'cvs add' as soon as he creates a file in the working copy anyway, so the user can be unaware about the problems for an undefined time period no matter how 'cvs add' is implemented. Logical continuation of Pauls' arguments leads me to the requirement for CVS to notice new/removed files/directories automatically making 'cvs add' and 'cvs remove' obsolete in the first place, not that I'm in favor of the latter. I do believe that 'cvs -n commit' is the right way to check if the repository is willing to accept changes. If one needs functionality to check only additions and/or removals, then this functionality could be provided through 'cvs commit' so that it would be possible not only to check, but also to commit additions and/or removals only. This way Pauls' requested 'cvs add' functionality will be available through 'cvs -n commit -O add', provided the '-O add' means "additions only". This is IMHO more logical and consistent than -C switch proposed for the 'cvs add'. Making changes to the working copy (be it editing existing files or adding/removing files/directories) and verifying these changes against the repository are separate activities. Let them continue to be different activities, please. In my point of view, the optimal CVS behavior is the following: 1. Neither 'cvs add' nor 'cvs remove' ever contact repository (-C aside, see below). 2. To check if the changes are OK without actually committing them, including addition and removal of files, 'cvs -n commit' should be used. 3. -O (add|remove|change) option could be implemented in 'cvs commit' if somebody finds enough sense in it (I don't). 4. Provided -O is implemented, -C option for add (and remove) could then be implemented to be semantically the same as running 'cvs add files' followed by 'cvs -n commit -O add files'. I.e., it will warn about the problems, not prevent the operation. [By the way, why is it -C, and not -c? There is similar option for cvs tag called -c] 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 :) 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. I wonder if the above two issues are going to be fixed as a side effect of the proposed 'cvs add' implementation as well. I think the first error should only be generated if the user provided '-c' to the 'tag' command. As for the second case, I think that without '-c' cvs should tag the file (either silently or issuing a warning), and with '-c' it should abort the whole operation. -- Sergei. _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs