Re: Another stupid question ...

[david]

> If I get cvs checkout <myproject> to work.  Can others do the same?  And,
> does this mean that CVS "cares" who all has complete copies of the projects
> or ... does it only count when any of us checkin?  I am a Visual SourceSafe
> guy and this is a little different.
>
Yes, it is different.  In my experience, it is better.

CVS allows everybody to have their own copies, or "sandboxes", and use
them as they please.  They can modify files at will, and CVS doesn't care.
Eventually, developers will want to check in, and then CVS handles the
details.
 
> I want to have several developers use my CVS server.  Can someone explain
> some scenarios?

OK, here's a typical one.

Alice and Bob each check out their copies, and work on separate projects.
(If they're working on the same project, and not communicating, you've
got problems that no version control system is going to fix.)  Alice
finishes first, and checks in her changes.  The repository now 
reflects the original code with Alice's changes.

Now, Bob finishes his project and tries to check in.  He is told that
some of the files he's attempting to check in have changed.  He then
updates his sandbox ("cvs update") and gets the new changes merged
in.  There are files only Alice or only Bob have changed, and these
are no problem.  There are files both have changed, and in this case
CVS does the merging as best it can.

Most of the time, in these cases, Alice's and Bob's changes will be
in different parts of the source file, and in most of these cases
CVS simply does the right thing.  If Alice and Bob have both changed
the same part of the same file, then CVS will tell Bob there were
unresolved conflicts and give him a new version of the file with
conflict markers in it.  Bob is then expected to fix the conflicts to
come up with a version of the file that works for both Alice's and
Bob's changes (again, if these are incompatible you've got bigger
problems), and check everything in.

This development model is generally superior to the one-person-has-the-
file-at-a-time model.  The latter model doesn't prevent two developers
from needing to modify a file at one time, it just makes it awkward
for them to work around the version control system.

This applies when the files to be changed are text files that will
have some lines changed and some the same.  Programming language
source files are excellent examples, and CVS was originally created
to deal with such files.  If you are dealing with files that can't
be merged well, such as picture files, CVS doesn't work nearly as
well.

  And, do we checkout everything to get a local copy to begin
> to build or can we just get a read only version and then checkout single
> files?
> 
That isn't a valid question in CVS, because CVS shares only one meaning
of "checkout" with VSS.  The shared meaning is acquisition of files with
the ability to check them back in (as opposed to, say, "cvs export",
which gives you a snapshot of the files and no ability to check back
in).  The meaning VSS has that CVS doesn't is acquisition of a writeable
version of the file with a lock.

In CVS, everybody checks out everything, but nobody has an exclusive
lock.  If you want advisory locking (which in my experience works as
well as exclusive locking), look at the "cvs edit" facility along with
"cvs watch".  You can set CVS to have checked-out files read-only,
to remind developers to "cvs edit" them.

-- 
Now building a CVS reference site at http://www.thornleyware.com
address@hidden