[GRASS5] Using CVS to manage "experimental" vs. "stable" trees

[Bernhard Reiter]

On Tue, Apr 23, 2002 at 06:09:18PM +0000, Carl Worth wrote:
> On Apr 23, Bernhard Reiter wrote:

>  > As a project it is quite unique, we are matching a broader range
>  > of people in a huge project. Users and developers.
>  > We have to be careful.
> 
> I can appreciate that. I do realize that the diverse nature of GIS
> applications gives GRASS a very broad audience, (with primarily
> non-programmers I would imagine -- many of which probably end up
> having to do some programming to get the job done). ;-)

Very true.

> So, with that, I'm willing to put effort into making the grass51 tree
> very good. I've seen lots of redundant code in GRASS that I want to
> refactor into shared modules/libraries. I've seen several problems
> with artificial hard-coded limits that I would like to eliminate.

Hurray!
This is much needed.

> I have a lot of ideas for exploring with GRASS and I'm glad to have an
> area like the grass51 module where I can explore and rip things apart
> without impacting those who are trying to make a release.

I think you see the point.
If you are getting too experimental at some points,
we still might thing about using branches on grass51. :)

> But, on the flip side, if I start copying modules over into the
> grass51 directory, there are two immediate concerns:
> 
> 	1) Each file will thereafter be forked. If new changes are
>            made within the grass module, then grass51 will be missing
>            them.

True.  We have to track what is going on in the grass5 tree a bit.
Most content like changes will be easy to pull over.

> 	2) All history will be lost as files are copied from grass
>            over to grass5.

If you not the revision, it still can be tracked.
But not as easily with automatic tools as before.

> Maybe the GRASS development community accepts both of these as
> necessary evils and acceptable since the code needs to be changed so
> much anyway?

I see no other alternative.

> If so, I'll forge ahead. 

Please carefully do.

> But, I tend to be very careful before
> creating forked development paths like this.

Another danger is that too many experiments will change the
character of GRASS too much. Some consensus on the list seems to be
that GRASS should mostly keep its character and some best practice.

For example, we think the programming language for the core is C so far.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20020423/4cd4e625/attachment.bin