Thanks both for your feedback.
In our case, we are migrating an application to a new environment and
started building the 2 next versions of the software (each version adds
some new functionality and is handled by a separate team).
We developed the main app in the trunk and branched early so that
building the new functionalities could get started before the trunk get
to testing.
As we go, the 2 new branches needed to get the latest changes from the
trunk (mostly bug fixes) and we did synchronization merge from the trunk
to the branches.
Now we are to the point were the next version (branch1) will become the
new trunk. So a merge as describe by Patrick will work for us.
In the future, branch2 will get synchronized from the trunk and when
the time is right will be merged to the trunk.
It seems to me that it is a common scenario.
Thanks,
Aymeric.
>>> Ben Collins-Sussman <sussman@collab.net> 6/24/2004 2:36:13 PM >>>
On Thu, 2004-06-24 at 13:19, Patrick Dean Rusk wrote:
> I shudder to contradict Ben, but I don't think his response is
correct.
Am I that intimidating? :-)
>
> I recently did a lot of work in a Subversion branch that affected
about 500
> files of a 2500 file project that was actually stored in PVCS. Over
the
> three weeks I did branch work, I was careful to merge changes daily
from the
> PVCS trunk into my Subversion trunk and then into my Subversion
branch. At
> the end, all trunk changes were represented in the branch, as well as
my own
> changes.
>
> Having done that, the final merge was a simple command to merge the
HEAD of
> my branch into the HEAD of trunk. In other words, leave off all
revision
> information entirely. That essentially replaces trunk with the
contents from
> the branch, which is what you want to do if you've been careful to
> continually keep the branch up-to-date with trunk changes.
This scenario works only if you know that all changes in the trunk are
already in the branch, because in the end, you're effectively
converting
the trunk into a perfect copy of the branch! If the trunk contains
*any* change that isn't in the branch, then that change will be
*removed* when you run a merge command that compares the tips of both
branches.
That scenario doesn't seem so common to me; after all, most lines of
development truly diverge in different directions. In the scenario
you
describe, you're going through very specific measures to guarantee
that
the branch is always a strict "superset" of the trunk. I've never
seen
any other group live by such a strict policy. Maybe I've not seen
enough of the world. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 24 22:10:56 2004