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

[Jirong Hu]

Just to give some info, I have worked with ClearCase a lot.
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. For example,
I can do a "cvs checkout projects" to my home directory, e.g
/home/jirong/projects. Then if I don't like it, I can just go ahead delete
it. If I want to move, I can move it to
/home/jirong/projects_trunk/projects, and continue do whatever I like.

It seems CVS server doesn't keep track where I store the checkouts at client
side. Am I right?

Thanks
Jirong

[Bob Proulx]

Jirong Hu wrote:
> 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. For example,
> I can do a "cvs checkout projects" to my home directory, e.g
> /home/jirong/projects. Then if I don't like it, I can just go ahead delete
> it. If I want to move, I can move it to
> /home/jirong/projects_trunk/projects, and continue do whatever I like.
>
> It seems CVS server doesn't keep track where I store the checkouts at client
> side. Am I right?

That is correct.  The server information is stored in the ./CVS/*
files in the working copy.  Moving the working copy moves those files
along with everything else and so the connection between the two
remains okay.  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.

Bob

[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

[Bob Proulx]

Arthur Barrett wrote:
> > > Just to give some info, I have worked with ClearCase a lot.

I, as I am sure others did too, took a deep breath upon reading that
statement.

> > > 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.

Of course!  All generalities are false, including this one. :-)

In the spirit of comedy I will stand by my statement that "most" do
not track client checkouts.  I am sure that some do.  But I am
thinking that RCS, CVS, Subversion, Git, Mercurial, Bazaar, Monotone,
are arguably some of the most popular software and none of those track
client checkouts where it matters if the client moves the working copy
about on the filesystem.  SVK stands out as different because it
tracks this on the client and the working copy can't be moved about
without breaking things.  Or at least it did when I last used it some
time ago.  Perhaps that has been improved more recently.

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

We are talking about the history file here, right?  (me makes a pained
face) I don't think that is what the poster was asking about!

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

Oh, sure, the 'cvs editors' command.  I don't think that is typical or
popular though.  I always considered that, perhaps wrongly, rather
special purpose.

TTFN!
Bob