[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question regarding change set and release managment

From: Todd Denniston
Subject: Re: Question regarding change set and release managment
Date: Fri, 30 Apr 2010 10:20:36 -0400
User-agent: Thunderbird (X11/20100318)

Yao, Li Xun (Eric) wrote, On 04/27/2010 08:06 PM:
> Question: 

Requirement 1:
> multi developers working on different change sets at the same time

Requirement 2:
>  and we want to have whichever change set pass user acceptance testing move 
> to production first. 

Requirement 3:
> We don't want to have each change set impact each other since 
> some change set may need to rework several times. 

Current methodology:
> To do this I have to create branch for each change set and merge the 
> change set back to chunk after the testing is completed, 
> and then create release tag in trunk for production deployment. 

> If there anyway to do it without branch?
Yes. The developers can not check any changes from their sandbox in until 
Requirements 2 and 3 have
been satisfied.  This however would risk loosing any known working states of 
the developers while
they rework.

Branches however help the developers stay sane while working under Requirements 
2 and 3.

with what little you have written, it sounds as if the organization either is 
suffering from

and someone (you?) is trying to take them to a "Merge-a-phobia" state

 Brad Appleton has some decent ideas on how to work business practices 
(Requirements 2 and 3) into
configuration management systems

my guess at why your org is suffering either "Branch-a-holic" or "Merge-mania" 
is because you are
Branching per task:
instead of Branching per major task, with a smattering of "Personal Activity 
Branch"'s as
workers/task leads see fit:
but these are only guesses with limited information, use at your own risk.

<SNIP Obnoxious banner>

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]