[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Question about merging and branch management

From: marlene cote <mcote_at_juniper.net>
Date: Wed, 28 Oct 2009 10:44:19 -0400

Todd,
Thanks for your helpful response.

---------------------
Regards;
Marlene Cote
10 Technology Park Drive
Westford, MA 01886
Phone #:1-978-589-0612
Fax #:1-978-589-0064
 "Excellence, can be attained if you...
 Care more than others think is wise....
 Risk more than others think is safe....
 Dream more than others think is practical....
 Expect more than others think is possible."

 

 

-----Original Message-----
From: Gleason, Todd [mailto:tgleason_at_impac.com]
Sent: Wednesday, October 28, 2009 10:34 AM
To: Marlene Cote; users_at_subversion.tigris.org
Cc: Eric Peterson
Subject: RE: Question about merging and branch management

> -----Original Message-----
> From: marlene cote [mailto:mcote_at_juniper.net]
> Sent: Tuesday, October 27, 2009 1:10 PM
> To: users_at_subversion.tigris.org
> Cc: Eric Peterson
> Subject: Question about merging and branch management
>
> how do folks handle branch merges? Do you create one dev branch for a
> project, and sync from TOT periodically, or do you create new branches
off
> of TOT and merge from the previous dev branch to the new branch? I
tried
> both of these today, and found many fewer files get merged with the
second
> approach. I need to understand the impact this approach would have
down
> the road when I try to reintegrate to TOT?

I think the second is less effort to maintain, but you do have to switch your developers over to the new branch each time you do this. Also, I expect you'll see that the history looks a little weird, because if you make a change in branch A, and merge it to branches B, then C, then D, then E, and then finally back to trunk, then what you're going to see in the trunk, even when you show the merged revisions, may not be so helpful. The trunk just has E's merge, part of which was the merge from D, part of which was the merge from C...all the way back to A.

The down sides with merging repeatedly from the trunk to a branch are the time to merge, plus all the changed files, which will bloat the repository prior to version 1.6 ( see http://subversion.tigris.org/svn_1.6_releasenotes.html#rep-sharing ).

Personally, with a 1.6 repository I would tend towards repeatedly merging to the branch rather than creating a new branch. I would only go to a new branch after merging all of that branch's changes to the trunk. But there's certainly room for personal preference.

--Todd

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2412144

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-28 15:50:04 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.