Merging With Concurrent Development

[Peter Kahn <ci...@gmail.com>]

What pattern works best for handling merging of code between active
branches when concurrent development is going on?

Merge as changes are made?
Merge when branch reaches milestone?
Merge when branch releases?

I have a project with a mainline that has spawned a few versions.  At
present, I have V1 and V2 out in the field and have developers working
on a V3 on the mainline.  I also have a V2 service release branch and
a V1_hotfix branch where active work is on going.

I want to be sure that all HOTFIX1 changes go to SR1 and Main as well
I want to be sure that all SR1 changes go to Main as well
I want to balance effort for testing with that of developing

Repository Layout:
  Project\Main\                           **
  Project\Branches\V2_SR1        **
  Project\Branches\V2
  Project\Branches\V1
  Project\Branches\V1_HOTFIX1  **


Merge-at-Milestone and Merge-at-release offer the least amount of
effort for the day to day developer, but result in the merge being
done by someone who is distant from the changes being merge both in
time and place.  Also, these will allow the branches to drift further
apart making the merges more complex.

Merge-at-change will mean that person who is close to the change
mentally will be merging it, but it will take up time of the
developer.  Also, I'd still want to perform a sanity check to make
sure that all changes were merged from a branch to Main, so I'd need
to do a Merger-at-release anyway.

So, I'm left with several paths that all have costs and all seem not
that great.  Is there another strategy out there that is better?


-- 
Peter Kahn
citizenkahn@gmail.com
citizenkahn@jabber80.com, pkahnpie1@AIM, skype: citizenkahn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Merging With Concurrent Development

[Kevin Greiner <gr...@gmail.com>]

On 10/20/06, Peter Kahn <ci...@gmail.com> wrote:
>
>
> The other thing we are adding is a message-of-the-day for each branch.
> A user checks in to branch A and gets a message back reminding him to
> merge that code to branches C, E, G.  This works provided that I can
> pipe the message back to his client.  If its an email, then the spam
> factor will make it a major annoyance.


Sounds interesting but you'll need to wrap the commit using a script to
display the MOTD. As far as I know, there's no svn features to support what
you want.

Re: Merging With Concurrent Development

[Peter Kahn <ci...@gmail.com>]

On 10/19/06, Bob Proulx <bo...@proulx.com> wrote:
> Peter Kahn wrote:
>
> You could always go into real estate.
>
> Bob

I don't on a blazer so that's out.

Merging early and often is what we'll try.  I just wish the merge
tracking feature was implemented so the end-of-project merge was
simpler.  Hopefully in 1.5.

The other thing we are adding is a message-of-the-day for each branch.
 A user checks in to branch A and gets a message back reminding him to
merge that code to branches C, E, G.  This works provided that I can
pipe the message back to his client.  If its an email, then the spam
factor will make it a major annoyance.



-- 
Peter Kahn
citizenkahn@gmail.com
citizenkahn@jabber80.com, pkahnpie1@AIM, skype: citizenkahn
http://kahnstipation.blogspot.com | http://analogoustendencies.blogspot.com/
Awareness - Intention - Action

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Merging With Concurrent Development

[Bob Proulx <bo...@proulx.com>]

Peter Kahn wrote:
> What pattern works best for handling merging of code between active
> branches when concurrent development is going on?
> 
> Merge as changes are made?
> Merge when branch reaches milestone?
> Merge when branch releases?

Merge early, merge often.  When things are fresh in people's heads and
very close together the merge will work perfectly.  After a long time
when the files have drifted apart a ways then conflicts will occur and
the changes will be so long out of people's heads that they won't
remember the changes.  Merge as early as possible.

> So, I'm left with several paths that all have costs and all seem not
> that great.  Is there another strategy out there that is better?

You could always go into real estate.

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org