[development] Tracking modules via CVS, WAS: Re: CVS branch work best practices?

[Khalid Baheyeldin]

On 2/5/07, Greg Knaddison - GVS <Greg at growingventuresolutions.com> wrote:
>
> On 2/5/07, Khalid Baheyeldin <kb at 2bits.com> wrote:
> > Up to now, I was using CVS  to track  Drupal 4.7 core and modules. The
> new
> > system does complicate matters, since it is quite acceptable to do:
> >
> > DRUPAL-5 as a branch
> > DRUPAL-5--1-0 as a tag
> > ... changes
> > DRUPAL-5--1-1 as a tag
>
> there should be a DRUPAL-5--2 branch from the same branch point as the
> DRUPAL-5  branch before this next step:


I agree that would make the matter less of an issue.

However two points:

1. The new release system does not enforce a branch for the major number. I
know
because I used tags only for a 1.1 and 2.0 and the system just accepted it.

2. There is now more overhead per module for those who check it out. A
directory
per tag per module.

Right now I just have:

drupal/

drupal/HEAD
drupal/HEAD/drupal
drupal/HEAD/contributions

drupal/47
drupal/47/drupal
drupal/47/contributions

drupal/5
drupal/5/drupal
drupal/5/contributions

And that is it.

Under this scheme one has to maintain a sandbox directory for each branch of
a module
separately.

> ... changes
> > DRUPAL-5--2-0 as a tag
> >
>
> Please see my earlier post for clarification:
> http://lists.drupal.org/pipermail/development/2007-February/022380.html
>
> I'm mostly representing dww's point of view on this idea.
>
> > If you do an update from CVS while changes are in but before the module
> is
> > tagged
> > you have the chance of getting unstable code.
>
> Which has always been the case with the old system.  Right?  The old
> DRUPAL-4-7 branch of contrib isn't known to be stable so if you
> updated down that you could get anything (stable, unstable, buggy,
> etc.).
>
> Regards,
> Greg
>



-- 
2bits.com
http://2bits.com
Drupal development, customization and consulting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070205/44a4ef0a/attachment.htm