You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Aymeric Alibert <Ay...@alliantenergy.com> on 2004/06/24 09:58:07 UTC
merging back branch from trunk
In our environment, we currently work with a trunk and 2 branches.
As development in the trunk is getting more stable, we synchronize the
2 branches with the latest changes from the trunk. We did that many
times.
Now, we want to merge all the changes from branch1 back to the trunk.
Can we do a 'regular' merge between branch1 and the trunk?
Or do we have to be worried about the 'synchronization merges' we did
previously and need to exclude them from the merge?
Thanks,
Aymeric.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: merging back branch from trunk
Posted by Michael Ferguson <fe...@gmail.com>.
> 2) Make a copy of the trunk at revision 100 (for illustrative purposes), and
> start working on the branch. Periodically, merge the changes from the trunk
> into the branch. Say 2 days later the repository is at revision 130. Merge
> 100-130 of trunk into the branch. This now makes it *as though* the branch
> was copied from revision 130. Three days later, merge 130-150 into the
> branch. Another 2 days later, when ready to re-merge, merge 150-HEAD from
> the trunk into the branch. Then, merge the HEAD of branch to the head of the
> trunk (making sure, of course, that someone hasn't snuck in another change).
Scenario two is called by many companies "re-baselining" and the
purpose of it is to avoid exactly what Ben metioned, removing any
changes made to the trunk while merging the branch back onto the
trunk.
IMHO a branch should always look like trunk + branch changes before a
merge. After all, your branch, if it is intended to ever be re-merged
onto the trunk, should be fully deployable so it can be tested. I
would consider scenario two to simply be good practice for any
software developer. At the company I work for a developer has to
rebaseline at least once a week to absorb both little things like bug
fixes and entirely new features written by coworkers simultaneously.
> The downsides are that you have to keep track of the incremental merges
> from trunk that you have done and need to make sure that they are
> continuous. Scripting can help this significantly, and the future merge
> tracking should remove this as a source of pain.
I too find it hard in SVN to find where I have to merge from,
especially after a rebaseline. We are very heavily dependant on the
comments in the log for this but I don't think this is a problem
unique to subversion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: merging back branch from trunk
Posted by Patrick Dean Rusk <PR...@foliage.com>.
"Ben Collins-Sussman" <su...@collab.net> wrote
> 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.
Yes, that's very true. And I was careful to keep track of that properly.
That's certainly where the future merge tracking features would come in very
handy.
>
> 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. :-)
"superset" would not be an applicable word in my case, because I removed
many files, moved a lot more others, added a lot, and changed a whole bunch.
I would characterize my branching choice as "I need to change a lot of
stuff, and I want to be checkpointing it into source control along the way,
but I don't want to mess other people up until I'm done, so I'll do it in a
branch and merge it into the trunk later." I suspect that that is a very
common scenario, perhaps the most common reason for creating
developer-specific branches.
Now, a developer faces two choices when doing that.
1) Make a copy of the trunk at revision X, work on it for some amount of
time (while trunk is undergoing separate development), then merge the
changes from X-HEAD in the branch back into a trunk work area, check that
they merge fine, test it all, then commit.
That's the scenario envisioned in the Subversion book. I suggest that it
works well when someone is doing a small localized change. However, I don't
think it's very scalable. For instance, if I jump right to a very stretched
out unrealistic situation, suppose this branch was made a revision 100, and
work was done on it for 2 years. The trunk has undergone 5000 revisions, the
branch 1000, and now we're ready to merge. It's unlikely that merging the
changes from 100-6100 of the branch into trunk will provide something
useful, assuming that trunk and branch have undergone a healthy amount of
refactoring over time. Furthermore, that's 2 years that someone has been
been making changes to something that is increasingly unlike the trunk and
probably bears no resemblance to it in the end.
Now, that's a ridiculous time frame, but drop the time frame down to 1
month, and you have the actual scenario I faced and that many developers
face routinely.
In this scenario, the branch always looks like (trunk + branch changes -
trunk changes since the branch was made). Any testing done in the branch is
therefore highly suspect, since the code doesn't represent a state that will
ever be released.
2) Make a copy of the trunk at revision 100 (for illustrative purposes), and
start working on the branch. Periodically, merge the changes from the trunk
into the branch. Say 2 days later the repository is at revision 130. Merge
100-130 of trunk into the branch. This now makes it *as though* the branch
was copied from revision 130. Three days later, merge 130-150 into the
branch. Another 2 days later, when ready to re-merge, merge 150-HEAD from
the trunk into the branch. Then, merge the HEAD of branch to the head of the
trunk (making sure, of course, that someone hasn't snuck in another change).
That has the distinct advantage of keeping the branch looking at all
times like (trunk + the branch changes). It is a potentially deployable set
of code at all times, making testing more meaningful.
This strategy also reduces the merges to small, manageable chunks that
tend to have fewer conflicts. I found this to be painless as a daily
activity keeping my branch in sync with the latest changes in the PVCS trunk
I was dealing with.
The downsides are that you have to keep track of the incremental merges
from trunk that you have done and need to make sure that they are
continuous. Scripting can help this significantly, and the future merge
tracking should remove this as a source of pain.
Another more subtle downside is that changes merged in from trunk to the
branch will cause the branch's space in the BDB backend to grow
significantly, even for files that haven't otherwise been changed in the
branch. To Subversion, the merge from trunk *looks like* changes made in a
trunk work area, so the full contents of the files get stored in the branch.
I assume that the FSFS doesn't have this problem as much given the way it
stored deltas.
Patrick Rusk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: merging back branch from trunk
Posted by Ben Collins-Sussman <su...@collab.net>.
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
Re: merging back branch from trunk
Posted by Patrick Dean Rusk <PR...@foliage.com>.
I shudder to contradict Ben, but I don't think his response is correct.
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.
Chapter 4 of the Subversion book doesn't describe this scenario, but it
should consider doing so, because I think it likely that people will usually
follow the pattern of applying trunk changes to their branches before
bringing their branch back into trunk.
Patrick Rusk
"Ben Collins-Sussman" <su...@collab.net> wrote in message
news:1088081394.12572.13.camel@localhost.localdomain...
> On Thu, 2004-06-24 at 04:58, Aymeric Alibert wrote:
> > In our environment, we currently work with a trunk and 2 branches.
> > As development in the trunk is getting more stable, we synchronize the
> > 2 branches with the latest changes from the trunk. We did that many
> > times.
> > Now, we want to merge all the changes from branch1 back to the trunk.
> >
> > Can we do a 'regular' merge between branch1 and the trunk?
> > Or do we have to be worried about the 'synchronization merges' we did
> > previously and need to exclude them from the merge?
>
> Yes, you need to be worried about repeating the merges. Look at this
> part of chapter 4:
>
> http://svnbook.red-bean.com/svnbook/ch04s03.html#svn-ch-4-sect-3.2
>
> When merging the branch back to the trunk, you need to make sure to
> exclude revisions that trunk already has. (Hopefully you've been
> writing good commit messages in your branch that describe exactly which
> revisions have been ported from trunk to branch, as the book describes.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: merging back branch from trunk
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-06-24 at 04:58, Aymeric Alibert wrote:
> In our environment, we currently work with a trunk and 2 branches.
> As development in the trunk is getting more stable, we synchronize the
> 2 branches with the latest changes from the trunk. We did that many
> times.
> Now, we want to merge all the changes from branch1 back to the trunk.
>
> Can we do a 'regular' merge between branch1 and the trunk?
> Or do we have to be worried about the 'synchronization merges' we did
> previously and need to exclude them from the merge?
Yes, you need to be worried about repeating the merges. Look at this
part of chapter 4:
http://svnbook.red-bean.com/svnbook/ch04s03.html#svn-ch-4-sect-3.2
When merging the branch back to the trunk, you need to make sure to
exclude revisions that trunk already has. (Hopefully you've been
writing good commit messages in your branch that describe exactly which
revisions have been ported from trunk to branch, as the book describes.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org