Why cvsdir? [was Re: cvs commit: jakarta-gump/python/gump view.py]

[Sam Ruby <ru...@apache.org>]

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.

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

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

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.

- Sam Ruby

Re: Why cvsdir? [was Re: cvs commit: jakarta-gump/python/gump view.py]

[Nicola Ken Barozzi <ni...@apache.org>]

Sam Ruby wrote, On 10/05/2003 17.59:
> Nicola Ken Barozzi wrote:
> 
>>
>> 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).
> 
> Probably a better way to put this is that you haven't used this and 
> don't see the usefulness of this.  I see it as very useful, particularly 
> if you are either on a slow modem or often disconnected entirely.

Point taken.

Personally I always go on the net on my 56k modem when I need to do cvs 
diffs, but now I see that it can also be done on the local cache files. 
Silly me.

What I really should have said is that IMHO wiping out basedirs and 
replacing with cvsdirs is a not-so-common feature for "normal" builders.

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

Re: Why cvsdir? [was Re: cvs commit: jakarta-gump/python/gump view.py]

[Sam Ruby <ru...@apache.org>]

Nicola Ken Barozzi wrote:
> 
> 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).

Probably a better way to put this is that you haven't used this and 
don't see the usefulness of this.  I see it as very useful, particularly 
if you are either on a slow modem or often disconnected entirely.

- Sam Ruby

Re: Why cvsdir? [was Re: cvs commit: jakarta-gump/python/gump view.py]

[Nicola Ken Barozzi <ni...@apache.org>]

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