RE: Basic usage question

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Sunday, January 20, 2002 9:01 PM
> To: address@hidden
> Subject: Re: Basic usage question
> 
> 
> In article <address@hidden>, Wade 
> Williams wrote:
> >Myself and another programmer are working on a project.  
> We're working
> >mainly on different sections of the code.
> >
> >Day 1:  I checkout the project
> >Day 2:  I make changes and commit them, and then continue 
> working on my
> >working copy.
> >Day 3:  Programmer B makes changes and commits them
> 
> If B does a module-level commit, then B's commit attept 
> should fail with
> the ``up to date check failed'' diagnostic on files that you 
> commited on
> day 2, assuming that B did a checkout before day 2, and has 
> not updated
> since then.  Thus B is forced to update to incorporate your 
> changes via
> cvs update, resolve any conflicts and try the commit again.
> 
Right.  I understood this to mean that there were "cvs updates"
as needed, although the original poster may not have been aware
of these details.

Basically, you can only commit changes if your files have been
updated to the head or branch tip or something, and if changed
have been checked in you'll have to run an update.  If there
is a conflict, that'll be mentioned in the output and kept as
the file status, and you won't be able to commit your changes
until you've dealt with the conflicts somehow.  (There was an
exchange a few months ago about what does and should constitute
dealing with the conflicts, which need not be repeated now.)

It is possible to merge changes to create an incorrect source
file without causing a conflict; one easy example would be
one programmer removing a member function from a class, with
another one introducing a new use of it.  In practice, this
turns out to be unimportant, since such problems are readily found.

> If people cheat by committing only the files that they modified, they
> can get around the up to date check. But that is a bad idea because
> the changes you make in one set of files can semantically 
> conflict with
> changes in another set of files.

Do you mean "updating only the files that they modified"?  If so,
that's a bad idea as you say, but it seems to be somewhat self-correcting.
People get themselves into trouble that way, and soon find that it's
easier in the long run to update everything.