[GRASS5] Re: Windows grass binaries / GRASS branching

[John Huddleston]

Hi Markus, (et al)

Tagging a tree allows us to manage a time slice of Grass.
If we are satisfied at any particular point, check out only
those files into your working copy that are appropriate for
that distribution, and tag them.  For example

cvs tag Grass_50B

This allows us, as CVS grass developers, to always checkout
that "branch".

cvs co -r Grass_50B

This creates a "sticky tag" in our local directories and the
files cannot be committed.  The user must type the 
'cvs update -A' command to release the sticky tag.

Further, if Bernhard or yourself is going to give a copy to
someone without the CVS subdirectories, then use export

cvs export -r Grass_50B grass

Then tar up that grass directory as a snapshot without the 
CVS directory and files.   To bring all files up to a particular
revision with the CVS repository, you would type

cvs commit -r 5.0

Cat your local CVS/Entries files to see the current versions of
the files. 

Branching uses the TAG concept and the CVS manages
this "branch" with the TAG within the file.  Literally, there
are not two files.  There is always one file.   However, within
the repository the RCS file keeps the information required 
for CVS to manage it.  To the user, it is maintaining several
releases in parallel.  See Chapter 5 on the cvs.ps user manual.
For example,

cvs tag -b Experimental_Grass5_0beta9

This splits off a branch based on the current versions in the 
working copy.  This creates the branch in the repository.  This
does not automatically switch the working copy to be on this
branch.    To do this, the user would type

cvs update -r Experimental_Grass5_0beta9

Once the user has the working copy tied to a particular branch,
it will stay there until switched to another branch or switched
back to the HEAD.

See 'man cvs' for details online.   Read the manual.

John Huddleston
 
----- Original Message ----- 
From: Markus Neteler <neteler at geog.uni-hannover.de>
To: John Huddleston <jhudd at itc.nrcs.usda.gov>
Cc: <grass5 at geog.uni-hannover.de>
Sent: Friday, May 26, 2000 7:51 AM
Subject: Re: Windows grass binaries / GRASS branching
[snip]

>  [hi all]
> 
> Well, concerning branches: I would like to start the
> stable branch. What I am thinking of is to add a stable
> tag to all stable modules. The rest may stay with unstable
> tag.
> 
> The only problem is the
> src/CMD/lists/GRASS which is parsed for compilation. Either
> we have to hold two lists (stable/unstable) or the compile
> mechanism needs to be modified to 
> 
>  1. ignore non-existing modules (as they might not have been checked
>     out if the stable version was acquired)
>  2. ignore compile errors and proceed, maybe collecting the
>     names of uncompiled modules in a log file.
> 
> Especially 2. would be of general interest, I think.
> If 1. is there, we could modularize the GRASS in a first approach
> into smaller, topic-oriented packages. 
> 
> In fact the best solution would be that the compile script collects 
> the *existing modules* first, then we would get rid of the
> src/CMD/lists/GRASS.
> 
> As the scripting mechanism is quite complex (for me!) I am
> not shure, if I could manage to modify.
> 
> So, what I need:
>  - assistance for the points 1. and 2. (see above)
>  - hints how to apply the branch tags (I think afterwards)
> 
> Thanks in advance
> 
>  Markus


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'