Can I update a branch from the trunk without performing a merge?

Question

I probably just haven't thought this through, or perhaps I'm simply unaware of an already existing option in Subversion (I'm certainly no expert).

I'm just wondering, if I've created a branch to start working on some new feature, if there's an easier way to keep the branch up to date with the trunk's most recent revisions without having to go through all the trouble of merging a range of revisions. I would like to be able to simply update and get all revisions from the trunk (and the branch, of course), while my committed changes only affect the branch. Is this possible? Does what I'm asking make sense?

I suppose this isn't really necessarily different from merging a range of revisions; it's just that I use AnkhSVN, which performs all these best-practice checks before allowing a merge, and sometimes it feels like it's a lot more complicated than it needs to be. The idea is that I want to keep my branch up-to-date with any commits other developers may be making to the trunk so that when I eventually do merge my branch into the trunk, everything goes (as) smoothly (as possible).

Solution 1

Keeping your branch up to do date with the latest trunk check-ins is called a merge.

I know merging can be a royal nightmare sometimes, but this is precisely what merging is.

Solution 2

TL;DR; No you must merge, here's some instructions

It's not as bad as you think it is. I will outline the steps from the commandline that I use. I will be using vimidiff to manage the conflicts you can use Meld or someother diff tool that you like. Commands are preceded by the hash '#' mark

<in branch first time from copy>
# svn log --stop-on-copy | tail 
<read the revision that was the copy instruction in this case r229>
# cd ../../trunk
# svn up
<I make note of the latest rivision which is r334>
<now I go back to the branch>
# cd ../branches/branch 
# svn merge -r229:334 svn://url.to.svn.server/project/trunk
<a whole bunch of stuff happens>
< now I check for conflicts >
# svn status | grep ^C
<which outputs something like>
C       public/tools/Diagnostic.class.php
C       public/domain/Report_Setup_Parameter.class.php
C       public/modules/mReports.module.php
<I now revert all these and manually merge them>
# svn revert public/tools/Diagnostic.class.php
...
<revert done now manuall doinng the merge
# vimdiff public/tools/Diagnostic.class.php ../../trunk/public/tools/Diagnostic.class.php
...
<now all the changes are done>
# svn commit -m "Merging trunk into branch 'branch' r:229:334"
commited revision 335

Done, if you do it reguarly then there are not many changes. After the first merge you need to use the revision # of the last merge. Therefore some time in the future the command would look in the svn log to find when the revision of the last merge was, in this case 335. The merge command would look like thuse

# svn merge -r335:370 svn://url.to.svn.server/project/trunk

All other steps are the same.

Solution 3

The idea is that I want to keep my branch up-to-date with any commits other developers may be making to the trunk so that when I eventually do merge my branch into the trunk, everything goes (as) smoothly (as possible).

To achieve that you need to do range-revision merges from trunk. Actually, it is a good practice to do this kind of merge to a branch from time to time to be up-to-date with what is going on in the trunk.

I don't know about the tools for AnkhSVN, but 'pure' SVN has very good tools that make merge operations quite simple. TortoiseSVN is a great tool for Windows and if you like Netbeans there is a very nice graphical support for merge too.

Solution 4

If you're using PHPStorm you can try using the GUI interface https://www.jetbrains.com/help/idea/2016.1/integrating-changes-to-from-feature-branches.html

View more solutions

Comments

[Dan Tao]

@Jack: I suspected this would be the general answer. Perhaps my question should have been, then, why is merging so much more involved than simply updating?

[ChrisH]

The first part of this answer is good, but the --reintegrate option is used when merging the branch back to trunk, so it is not really applicable to the question.

[sbi]

Because merging has to deal with conflicting changes?

[Dan Tao]

@sbi: So does updating, though, potentially.

[pajton]

Having trunk and branch means having a 2 lines of development. Think of it as of 2 paths to a root in a tree. If you want to retrieve the changes from the other line it cannot be too simple, right:)?

[Michael Hackner]

@ChrisH He specifically mentioned merging back to trunk as the last step in the process, so I included it for completeness.

[Jack Marchetti]

@Dan - I think it might just be this difficult in SVN. I recall listening to stackoverflow podcast where Joel/Jeff spoke about how painful this can be. I'm not sure if other Source Control systems do it better.

[Dan Tao]

@pajton: I can see how it must be more complex than a plain vanilla update from the same branch/trunk. But conceptually, I sort of think of the trunk as coming "before" the branch, or in any case being ahead of the branch hierarchically. So I would have liked it if I could continue getting updates from all levels "before" mine--so that I could, for example, branch off a branch, and continue getting all updates from the trunk as well as the parent branch. But it seems it's just a pipe dream...

[Dan Tao]

@Jack: Looks like you're right. After checking out the link provided by Michael Hackner, I think I got a better idea of the issues inherent in updating branch via a system based on revisions.

[sbi]

@Dan: Yes, updating does that, too, and it, too, hurts sometimes. However, branches are often created because it is known before-hand that conflicting edits will take place over a longer period of time - so it's more likely that you will run into conflicts. (And don't forget those times where you merge two branches with conflicting changes into a working copy with more local changes. That's fun...)

[ChrisH]

Fair enough. I just thought it could use some clarification because using --reintegrate when going from trunk to branch would cause problems. In retrospect I should have worded my first comment as a clarification.

[Sander Rijken]

A few additions to this, if you choose "range of revisions", but don't use the history viewer to select what you want to merge, all revisions are merged. This is controlled from the wizard step right after where you choose "Range of Revisions". If you make sure you don't have uncommited changes, and the whole working copy is at a single revision (update at the solution level before you start merging). AnkhSVN will warn you if this isn't the case.

[Tom Bushell]

@Jack - many people claim that Mercurial and Git make merging much less painful. I have no experience with either, but I plan to try Mercurial at some point.

[LightningStryk]

This is one situation I feel GIT supports better. But it really isn't to much pain to just merge from trunk, and a lot of tools will help you, I personally use Cornerstone and it has a "Synchronize" feature which is meant to merge trunk changes into a branch.