RE: [lmi] New interim branch 'branch-20061115', and some cvs questions

[Ericksberg, Richard]

NOTE: If these line breaks are a problem, I don't know what else to do.
Outlook creates them this way when I 'Reply' and I have not changed
them. My Options | Mail Format | Internet Format | Automatic wrap is set
to the max allowed [132] for this Outlook version [Outlook 2003 SP2.]

On 2006-11-15 18:12 UTC Greg Chicares wrote:
> The main trunk contains a release candidate that's being 
> tested right now, so I've created a new branch for 
> development in the interim. I'm thinking that we ought to do 
> this regularly, using names generated as 'branch-YYYYMMDD' 
> for consistency (it seems unnecessary to create two branches 
> on the same day), and then merge them into the main trunk as 
> soon as testing is complete. [...]

On 2006-11-16 1:08 UTC Vadim Zeitlin wrote:
> I don't see why shouldn't it be possible to create 2 
> branches per day, for example if 2 persons start working on 
> different subprojects simultaneously.
> And while this could be fixed by using 
> "branche-YYYYMMDDHHMMSS" format, I also believe that symbolic 
> names for branches are more useful than timestamps as they 
> explain much better what changes were done on that branch.

For the reason given above about simultaneous subprojects and for
clarity, I think that the symbolic names would be to more useful for
branches than timestamps. Frankly I think using 'branch-YYYYMMDD' could
cause confusion about what changes go where.

On 2006-11-15 18:12 UTC Greg Chicares wrote:
> I realize that many projects treat the main trunk as a 
> sandbox and put actual releases on branches. Our discipline 
> has been sufficient to keep the main trunk in a releasable 
> state at all times, however, and that has served our business 
> needs well.
>
> We developed the calculation summary on a branch, then 
> applied discipline upon merging it. Perhaps similar projects 
> should be done the same way in the future. They'd be on 
> project-specific branches--distinct from the routine branches 
> described above, whose purpose is to keep the main trunk 
> sacrosanct during formal testing. Does that sound best?

Like we did for 'gnome-xml-branch', I'd like to have a project-specific
branch be the sandbox and MAIN be kept holy for releases. I think this
would be particularly helpful if we ever had ongoing simultaneous
projects but wanted to release partial functionality from any or all.
The wanted code could be ported to MAIN and would reduce the possibility
of having to back out code that should not be released.   

> - What should we do with obsolete branches?

I don't see an advantage to removing them unless a large number of them
becomes difficult to manage. At the very least, you have some historical
reference if you need it.


---------------------------------------------------------
This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 

---------------------------------------------------------