Re: Re: pybloxsom (fwd)

Hi guys, since everyone is talking about CVS-fu stuff, I'd like to give 
some thoughts on how one can structure the branches to something that 
may be developer friendly.

Here at work we use branches as a versioning tool. HEAD will always 
have the latest released version, but HEAD does not contain bleeding 
edge stuff. We have a DEVEL branch for that. Everytime DEVEL goes 
final, we then merge to HEAD (which contains the previous version) and 
we also create a version branch and tag (PYBLOSXOM_1_2 for the branch 
name, and pyblosxom_1_2 for the last point release tag) This enables 
bug fixes specific to PYBLOSXOM_1_2 release. Hackers might want to fork 
off from the PYBLOSXOM_1_2 branch and create their own uber fix, or 
just fork of DEVEL to keep in line with the DEVEL changes. Graphically, 
the CVS tree would look like this:

                                                /> Some DEVEL forks
   /------+------------------+------------------+---> DEVEL branch
  /       |                  | (merges to HEAD)
|        v pyblosxom_1_2    v pyblosxom_1_3 (tag level)
+ -------+------------------+> HEAD (Will just contain the latest 
versions)
          |                  |
           \-+-> PYBLOSXOM_1_2  \-> PYBLOSXOM_1_3 (Release branches off 
HEAD)
             |
              \> pyblosxom_1_2_1 (bug fix tag)

Have I told you that I suck at Asci drawings? :)

BTW, on top of this, there are several conventions to follow:

1. Branch names must be CAPITALIZED
2. tag names are small letters
3. HEAD will just be final released versions. This is so that people 
new to pyblosxom can check out a working copy without problems that 
people working off DEVEL might encounter.

This is just a suggestion. In practise it can be hard to follow if a 
developer checks out a wrong branch and checks in to HEAD (there is no 
erm.. security in cvs) so developers have to be in sync on what to do, 
there's no way to make HEAD read-only.

But if developers just work of DEVEL, and a release technician does the 
dirty work of merging to HEAD and creating the necessary branches, it 
would be a solid system to work on. Bug fixes could just check out 
PYBLOSXOM_1_2 branch and work on fixing bugs, tags as necessary if he 
does a release from that point (no need to merge to HEAD here).

So what say you?

On 01-Apr-05, at AM 08:25, Steven Armstrong wrote:
> On 03/31/05 20:59, Steven Armstrong wrote:
>>
>> I'm currently writing a short how-to for the "advanced" CVS features I
>> think we should use, namely versioning and branching. I'll post it
>> within a hour or so.
>>
>
> I've finished the how-to, but want to test the whole procedure once
> again in my local repo. I'll try to get that done tomorrow and then 
> post
> it here.
>
> cheers
> Steven
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/Info/Sentarus/hamr30
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyblosxom-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30