Mailing-List: contact gump-help@jakarta.apache.org; run by ezmlm
Message-ID: <3EBD1482.8050705@apache.org>
Date: Sat, 10 May 2003 17:02:26 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4b) Gecko/20030507
MIME-Version: 1.0
To: Gump code and data <gump@jakarta.apache.org>
Subject: Re: Why cvsdir? [was Re: cvs commit: jakarta-gump/python/gump
 view.py]
References: <008d01c3164f$ad815e70$616feb43@wdn086> <3EBBE5CE.801@apache.org>
 <b9gpms$3np$1@main.gmane.org>
In-Reply-To: <b9gpms$3np$1@main.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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.

Ahaaa.

> 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 
last-known-good-stuff.

  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.
http://nagoya.apache.org/wiki/apachewiki.cgi?WhyCvsDir

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------