[GRASS5] GRASS stable/exp branches

[Eric Mitchell]

> 10. Continue development on the main branch.
> 
> For me this seems to give a good level of control and minimizes the time
> that we have two branches. The only problem that I see is how we back
> out a change that should not have been made to the stable branch. Three
> options I can think of are:
> 
> 1. Insist that the developer who committed the code back it out using
> log files to determine which files to back out.
> 
> 2. Have a cron job to tag the stable tree once a day (or some other
> regular time frame).
> 
> 3. Insist developers tag the stable tree before they make any changes
> and then tag it again after they make their changes (as you suggested
> above).
> 
> I think number 1 should be used as a last resort method. It is a bit
> tedious, but if you did not tag the files and you don't know all the
> files you changed, then it is the only way I know of how to back out a
> commit.

You can use dates to perform cvs merges, too, e.g.

	cvs update -j BAD_DATE -j OK_DATE ...

so as long as you know *when* the changes were made you're ok.

What we do at work to track commits is the following:

Set up a CVS loginfo of the following:

	ALL     $CVSROOT/CVSROOT/domail.pl -h smtp.wherever.com \
			-r /your/cvs/root -f cvs-commits-list \
			cvs-commits-list at wherever.com

Be sure to update the smtp.wherever.com, /your/cvs/root, etc. entries.
The domail.pl script is attached.  This mails the cvs commit message,
with an indication of what files were altered to the mailing list,
cvs-commits-list at wherever.com.

2) Set up a GNU mailman mailing list manager.  Easy to drive via the
web, monthly archives by date/thread/etc.  Create the cvs-commits-list
mailing list, and subscribe all desired developers.  GNU mailman sends
a monthly reminder to all subscribers indicating which mailing lists
they are subscribed to, and how to unsubscribe and change mailing list
options.

3) Monitor the mailing list traffic, and watch who commits what where.
If you see something suspicious, investigate it.  You will always have
the CVS log info to work from, if you are tracking down something.

4) This usually isn't a problem for us at work, as *major* work is
performed on a separate branch, and merged in once it's considered
stable.

5) For bonus points, get Bonsai (http://www.mozilla.com/webtools/bonsai)
running, and have CVS inform Bonsai of changes to the source tree on
the various branches.  Bonsai is a web-enabled CVS query engine, built
on a MySql database.  Want to know who changed anything in a given
directory?  Who and what was changed in a given file over a given period
of time?  Just fill out the query page, and find out.  Also does side-by-
side source comparisons, and "cvsblame", where you get to see who actually
checked in the code on a line by line basis.  Neat stuff.

In summary, I don't think it's necessary to tag changes daily, or
per-checkin, as CVS provides useful means for keep track of what's
changing, and still allows timestamps for revisions where those
methods fail.

> Number 2 I think is feasible but if there were more commits than the one
> made in error, then those commits would have to be done again.

Not necessarily so, using the CVS merge feature, and picking the bounds
of the errant checkin.  Provided of course, that the errant checkin is
sufficiently independent of other checkins (different files, or at least
non-conflicting portions of the same files).

> Number 3 is probably the safest way, but I don't know how we can force
> developers to do this.

I suspect it's easier to connect the CVS repo with a mailing list, and
just let people watch each other.
-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell         mailto:emitchell at altaira.com |
| tel: (301) 809 - 3534    Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR    4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122    Bowie, MD  20716             |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
               ,___
           /"\  / o=\  /"""---===/
          /   \_/  \__/   ---===/
          |    //\   || /""TT""/ //\   || ||""\
          |   //  \  ||    ||   //  \  || ||__/
          |  //--==\ |L--/ ||  //--==\ || || "=,
           \      ---===/
            \____---===/


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