gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Why cvsdir? [was Re: cvs commit: jakarta-gump/python/gump]
Date Sat, 10 May 2003 15:02:26 GMT

Sam Ruby wrote, On 09/05/2003 19.50:

> Let's look at the initial use case for Gump... a batch and overnight 
> build all.
> First day a clean checkout is done.  Imagine a build is done in that 
> directory.  Now what do we do on day two?
> 1) We could rm -rf followed by a clean cvs checkout.
> 2) We could have done the initial checkout to another location, and then 
> synchronize the two.  There are commands like rsynch which do this very 
> efficiently, even when the source and target are on the same machine.

Cool, I get it.

> Option 2 has a number of secondary advantages.  First is that because a 
> cvs update is done on the second day, you can actually get a list of 
> what files have changed.  This is a very useful report to have when you 
> find a failure or want to know if your change that you committed at the 
> last minute made it in.


> Another advantage is the one that Stephan mentioned.  By having a clean 
> checkout local, you can do a lot more experimental changes on your build 
> copy always knowing that you can resynch back to [or easily diff 
> against] the point where you last checked out (which may be different 
> than the current state of the CVS repository).

Yes, this was the only use-case I understood.

> Finally, a cvs update is often more bandwidth friendly than a complete 
> checkout.

Yup, makes sense from a batch and overnight build system.

> Now as to what I would consider common, day to day, interactions:
> 1) resynch with cvsdir (i.e., wipe out my changes)
> 2) update basedir against the cvs repository (i.e. merge)
> That's it!  Updating cvsdir is generally best done in batch, or can be 
> relegated to a menu option.

So it means IIUC that cvsdir is basically useless for day2day coding, 
when I don't want to wipe out stuff (I reckon it a not-so-common feature 
for "normal" builders).

Ok then, I will assume that cvsdir is just a local CVS "cache" of 

  1) cvs update (basedir)
  2) get from cache (cvsdir -(clean)-> basedir)
  3) update of cache (cvsdir)

It makes sense. Thanks for bearing me, yesterday was a hellish day.
I will do the changes ASAP.

I added your explanation to the Wiki, it seems very important as a 
use-case doc.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message