Understood. So, in your scenario you are using feature branches.
This makes sense to me. You want to keep your feature branch up to
date with what's going on from the trunk. But, how would release
branches come into the picture? And, if there is a critical bugfix
for a particular release, to what branch would you apply the bugfix
(trunk or release) and which direction would you port it back?
On 6/22/05, Ben Collins-Sussman <sussman@collab.net> wrote:
>
> On Jun 22, 2005, at 1:41 PM, John Browne wrote:
> >
> > However, others say it is best to only do 1-way merges. I'm trying to
> > understand any limitations that exist with this....for a future
> > project we will be doing using subversion.
>
> There's no right or wrong answer. It's generally safest to merge all
> in one direction, then all in the other direction. If you start
> merging selected bits in both directions somewhat randomly, it's more
> likely to produce conflicts from repeated-merges.
>
> As someone already said, distributed systems like arch or svk are
> designed to track patches (and merges) from the beginning, so they're
> much better at this sort of "cherry-picking" back and forth.
> Subversion will get there too, someday.
>
> In my experience, I find that the best pattern for a long-lived
> feature branch is to merge *all* of trunk to the branch every week.
> I make sure to merge contiguous ranges of trunk, always picking up
> from the last merge-point. Then, when the branch is finished, I
> merge the whole branch back to trunk by directly comparing trunk and
> branch.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 24 00:06:50 2005