RE: CVS server/db doesn't keep track of where you checkout the files?

[Arthur Barrett]

Jirong and Bob,

> > Just to give some info, I have worked with ClearCase a lot.

It sounds a little like you don't know much about CVS.  Please spend
some money on a good book, and spend some time reading it.  I can
recommend 'Essential CVS' which I didn't write, and 'All About CVS'
which I did have a hand in writing (but that is mostly about CVSNT -
read on...).


> > So far, one thing I find very comfortable or uncomfortable 
> > is: CVS server or database seems doesn't care where you 
> > store the checkout files. 
> 
> The client working copy tracks the server.  But the
> server does not track working copies.  This is typical of 
> most version control systems in popular use.

And all men are liars and all women fixated on shoes.  

Of course software and people are not accurately generalised.

Many version control systems (including CVS) that I have used do track
where working copies are.  Most do it very poorly.  

Since you are familiar with ClearCase, let's use it for an example: you
create a dynamic view and publish it and the user mounts it on their
windows pc as N: drive and copies the contents to c: drive, disconnects
their laptop, goes home and works on the software for a week.  The
ClearCase admin will swear black and blue the working copy is on the
dynamic view (N:) but is it really?  No.  

>From memory, the CVS history file does track what the local directory is
for each command executed, and CVS watches track the location of
workspaces - and it does a marginally poorer job of it than ClearCase
does.  For the most part this behaviour is deliberate - ClearCase has a
much higher administrative overhead (both in terms of people time and
CPU time) which the CVS designers deliberately avoid(ed) - and tracking
the exact location of the workspace/sandbox was seen as wasted effort.

To see if the CVS server is tracking working copies - use the 'cvs
editors' command.

CVS really is not anything at all like ClearCase, but it can be used to
solve similar business problems - though usually with a very different
process/workflow.  There is more than one SCCM software system - mostly
because different software  does different things better - the best
software for your SCCM system will depend on your business requirements.


I primarily work on the CVSNT 2.x and EVSCM 3.x adaptations of CVS and
my goal is to keep it a low-overhead system whilst also allowing it to
support as many different SCCM methodologies as possible.  One day I'd
like to say we are even as flexible as CC (but I can't yet) - but of
course at much lower TCO.  We are getting close with EVSCM...

Regards,


Arthur Barrett