Re: CVS diff and unknown files.

[Sergei Organov]

Todd Denniston <address@hidden> writes:
> Sergei Organov wrote:
> > 
> > Paul Sander <address@hidden> writes:
> > > On Jan 24, 2005, at 6:20 AM, address@hidden 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.