Menu
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).
703
It never should have been committed. You can use svn merge to “undo” the change in your working copy, and then commit the local modification to the repository. All you need to do is to specify a reverse difference.
Basically that means a temporary clone of the (feature) branch is created, a sync merge is made from the parent branch to the temporary branch, and finally the parent branch is replaced by the temporary branch. In other words, the temporary branch contains all changes made to the (feature) branch and parent branch.
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.
199
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.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
