Our team uses Eclipse to develop a software product, and recently we switched to Subversion to do our source control/version management. At first our team was still committing directly to the trunk as we were new to Subversion's way of source control and things needed to be drawn out still.
At some point I made my first real branch from the trunk to do development for a specific project within our product. Suppose the branch is called DEV_PROJ.
Later as our team knew better how to work with Subversion from Eclipse, I put the team on our first real development branch, not for a specific sub-project but to keep track of different versions. Suppose the branch is called DEV_VERS. Now we are working on that branch and no longer committing directly to the trunk. DEV_VERS was branched from the latest version of the trunk and there have been no commits to the trunk since then.
In between the two branches about two/three months passed and there have been a lot of changes to the trunk before I made the version branch. Now the time has come for me to merge the changes from DEV_PROJ to the DEV_VERS branch to incorporate the project in our new version branch.
What I did first was merge the latest version of the trunk to my DEV_PROJ branch (forward merge?), thinking that would minimize the difference between the two branches while keeping the changes specific to the project.
What I'm trying now and what I'm having problems with is merging the DEV_PROJ to the DEV_VERS branch. Right-click, Team/Merge my DEV_VERS project to start the merge, there are three tabs to choose from: URL, 2 URLs, Reintegrate. As far as I know this is not a reintegration merge, that would be from branch toward the trunk and not between branches that are not directly related. I also don't need to merge two branches towards my branch so I skip 2 URLs tab.
So I choose the first one, URL. As the source I take my project from the DEV_PROJ branch, Revisions: Start from copy, Depth: Working Copy. In a second try, I also chose to Ignore Ancestry. Both tries I push the Preview button to get an overview of what files are target for merging.
What I see is that there are a lot of files that are candidate for merging, that have not been changed in my DEV_PROJ branch. So the (subversion) merging process sees a lot more merging candidates than I had expected. The files I added to the DEV_PROJ branch appear as "Added", but a whole lot of files that I know I didn't change in that branch appear as "Modified" or "Tree Conflict" in the merge overview.
My questions:
Is this the right way to merge between branches? If not can it be done directly using the merge menu (URL, 2URLs, Reintegrate)?
Is my first step (forward merge trunk to DEV_PROJ) the reason why there are merge candidates that were not supposed to be there?
If there is no direct way of merging these branches correctly, then I only see one option. That is merge the DEV_PROJ to the trunk (reintegrate), and then merge the trunk towards the DEV_VERS branch (forward merge). Would this be the right way to do this? If so, is it the only way to do this?
Eclipse: Helios Service Release 2, build: 20110218-0911
SVN server: 1.6.15
Eclipse SVN plugin: SVNKit 1.3.2 (2.2.2.I20100512-1900) // SVN Connector (2.2.2.I20100512-1900) // SVN Team Provider (0.7.9.I20100512-1900)
If I understand your question correctly, this is the state of your project:
_________________ B DEV_PROJ
/
A /
---------------------------------- trunk
C \
\_____________ D DEV_VERS
And you want all changes from A -> B in your DEV_VERS branch.
If so, what I would do is the following (the following is the command line equivalent, but it should be easy to find the Eclipse SVN GUI equivalent):
Find the revision of A:
svn log --stop-on-copy URL_OF_DEV_PROJ
The earliest commit revision number is the revision number of point A
Find the revision of B:
Assuming you want to merge all changes in the DEV_PROJ branch, the value of B is simply HEAD
Checkout DEV_VERS:
svn co URL_OF_DEV_VERS
Inside the directory of the checked out code from step 3, merge the changes from A to B as follows:
svn merge -r<RevisionOfA>:HEAD URL_OF_DEV_PROJ .
In short, what you're doing is taking the difference between A and B and merging it to DEV_VERS
Related
My current SubVersion workflow is like so:
The trunk is used to make small content changes and bug fixes to the main source code.
Branches are used for adding/editing enhancements and projects.
So, trunk changes are made, tested, committed and deployed pretty quickly. Whereas, enhancements and projects need additional user testing and approval.
At time, I have two branches that need testing and approval at the same time. I don't want to merge to the trunk and commit until the changes are fully tested and approved.
What I need to do is merge both branches to one working copy without any commits.
I am using Tortoise SVN, and when I try to merge the second branch, I get an error message:
Cannot merge into a working copy that has local modifications
Is there a way that I can do this without committing either merge?
You currently have the trunk and 2 branches A and B (which are both branches from the trunk). I suggest you create yet another branch called AB as follows:
Switch your working folder to the trunk, if not there already
Update the latest and make sure you have no local modifications. If you do, either commit them (to the trunk) or revert them as appropriate.
Do one last update of your working folder from the trunk. Note the revision number you have updated to (call it revision R).
In the repo, copy revision R of the trunk to a new branch called "AB" (Do not switch your working folder to AB yet)
Merge your working folder with A.
Switch your working folder to AB.
Commit your working folder (to AB) and update (from AB).
Switch your working folder to the trunk.
Merge your working folder with B.
Switch your working folder to AB.
Commit your working folder to AB.
Test, and commit any fixes to AB.
When it's working and you're ready to merge everything to the trunk, do a final commit (to AB), then update your working folder (from AB).
Switch your working folder to the trunk.
Merge your working folder with AB
Test and fix
When it's working, commit working folder to the trunk.
Go out for beers
We had a similar workflow at one point. The solution I finally landed on was to keep multiple local copies, basically one per branch. Got a bit dicey at times with shared databases but overall it was very successful.
you can checkout another copy of the branch you want to merge into at a different place on your local drive, merge into it and then commit it. Then delete the whole 2nd working copy and return to your current task.
But it does seem that you are trying to subvert your own working practices - unless you want to just merge 2 branches together to commit all the work simultaneously and delete the 2 old branches... but then, what's stopping you from committing to them and merging normally in such a case?
Every merge operation is done in your local sandbox. You do not have to be worried until you commit some junky code.
I don't know the whole deploy process you do but what you can do is:
switch to branch A
merge branch A with branch B
build the app, deploy and test it
If all works fine you can commit all changes (you are on branch A). Then you can switch to trunk and merge with branch A. After all conflicts are solved you can commit on trunk and that is all.
Eric, " I may want to only deploy one change at a time..." and "merge two branches to one working copy without committing" are incompatible requirements: or you'll test branch after branch or mix two branches in one big mix.
Version A Anyway - you can merge any node with any node inside repo-tree, not only somebranch with trunk. I.e., in common, #JoelFan workflow is good, but - require less actions
copy HEAD of trunk to AB
Merge AB with A
Commit mergeset, test etc...
Merge AB with B
Test merged results
Merge to trunk and delete temporary AB-branch
Version B is 2-URL merge. svn help merge, "2-URL Merge Example" part as start. You can merge 2 independent branches into third in one command merge BRANCHA[#N] BRANCHB[#M] [TRUNK_WCPATH]
Our dev team works inside existing projects, and deploys on completely separate environments. The work we do is not never expected to be merged back into theirs, but we are required to stay in line with them. They use the traditional trunk-branch (but not really tags) setup. A branch is created for a production release, and then development continues on it as they release.
The way our team does it, we copy their release branches to our own trunk (initially), which itself contains trunk/branches/tags. During development we are on trunk, and tagging for production releases. When we update from their latest release, its often impossible to do a straight merge from that branch to our trunk. It seems much cleaner and trouble-free to start with their branch, merge in our work, and eventually rename it to trunk.
All of a sudden I feel like a subversion dummy text generator...
Given the constraint that we can't change the other team's workflow, is there a better flow for us? Let me know if I'm missing something in the explanation too.
thanks.
Two main principles:
Vendor branches
Merge often
Due to ignorance of rule 2 you get "Merge hell" as expected
For more reasonable workflow (read about Vendor branches in Net, it has a lot of information) you can
Not just copy upstream branch to your trunk, but create vendor-branch (branch) in your repo, link it with svn:externals to source branch (without fixing source-revision in URL, link to moveable HEAD)
Copy branch to (empty) trunk
Monitor commits into upstream repo (SVNMonitor, CommitMonitor) and on every commit to upstream branch merge your vendor-branch with your trunk (svn 1.6-1.7 will be better than older versions)
After finishing upstream brach and starting new you can or edit externals definition in old branch (for next branch URL) or delete branch completely and start new (deleting all from your trunk not needed, only merge from new branch content)
I have an SVN branch and a trunk. The trunk changes regularly and the branch doesn't.
Every now and then (let's say once per week) I want to update the local working copy of the branch with the latest changes of the trunk.
Ideally I would want to do this the same way as I do it with the latest version of the branch: with Eclipse : Team->Synchronize, so I can review all changes before updating.
Is this also possible with a different repository (for example : trunk) ?
If not, how do people review the changes before updating then??
I looked at Team->Merge, but this seems to update the changes directly to my working copy, without the possibility to review the changes first (the Preview-function is confusing, I think, and doesn't provide the nice side-by-side view of changes/conflicts that Synchronize has).
The right way to do this is with Merge. Subclipse includes a merge client that makes this easy to do. You are right that it does not give you a true preview, but the way it works is better from a Subversion perspective. The Merge Results view UI is basically the same as the Synchronize view. It lets you easily examine every change that the merge made in your working copy and the Eclipse compare editor that it opens makes it very easy to take out any parts of the change that you do not want in your code before you commit.
The problem with trying to do this from the Synchronize view is that you are then doing the merge yourself using code editors and Subversion has no awareness of what is merged. If you let Subversion first do the merge, then it can update all of its metadata properly and it is perfectly fine for you to then fixup the code to be the way you want it before you commit the results of the merge.
I'd checkout both branch and trunk as a separate eclipse projects into workspace. Then use some merging tool, for example meld to merge changes between them. After merge you can refresh branch in Eclipse and synchronize it with svn repository - now you can review all changes. (it's how I do it, since I do not believe svn eclipse plugin ;))
I agree that it is not really intuitive by design, but Mark is right, you "synchronize" your changes when committing them back to the trunk:
first make sure your local branch is completely synchronized with your repository branch (no changes)
Team -> Merge... your local copy of the branch with the repository trunk
you now have a local version of that merge
you can locally edit this version, make sure tests are working and there are no compiler errors
finally you synchronize your local merged branch version with the repository branch and commit all changes that have been made
besides, the same way you'll merge your branch back into the repository trunk
make sure all changes of your branch are committed to the repository branch
switch to the trunk Team -> Switch...
merge your trunk with your branch Team -> Merge... (Tab 'Reintegrate')
you now have a local version of the merge, you may edit the changes and review them, make sure that you have a working version now
synchronize your local trunk (merged version) with the repository trunk
commit all changes that you want to appear in the trunk
i recommend to commit all changes that you've made locally to your merge, since you've tested them locally. if you commit just a few changes, make sure the repository version is still working then with missing changes
I used to work with CVS where it was no problem to compare HEAD to any branch, branch to branch or branch to HEAD. Now on SVN I have some changes on trunk I need to put on a branch, but can't seem to find an option to compare given branch to trunk.
Is it possible to have a branch project in workspace and compare it to trunk?
right-click on the project and choose Compare With, Branch/Tag (this is with subclipse)
APPENDED
What version of the svn client are you using? When I open the Compare With dialog on a project checked out from branch it lets me enter any URL (including trunk) and any revision to compare it to.
A common scenario when using source control is to have a development branch along with versioned release branches. We use CVS, with HEAD as the development branch, and a branch named e.g. release-6-2 for the current release of a product.
Development of new features go into the development branch only, but bug fixes sometimes have to be checked into both the development branch and the current release branch. This can get quite tedious at times, so I am looking for practical ways to accomplish this.
When a file to be commited is in synch on the two branches, I am in particular looking for a quick "commit to these branches" solution.
(We use CVS as our source control system, so any CVS-specific answers are nice. However, it is also interesting to see whether other source control systems can offer a better way.
On the client side we use Eclipse, so Eclipse solutions are good. But if you have a non-Eclipse solution, that is fine too.)
Apply your fix to the oldest release branch required. Then merge the change to the next release branch and so on until you merge from the last release branch to the HEAD.
Say the oldest version of your product is 1.0 and you also have 1.1 and 1.5 releases. New features for the next release are being added to the HEAD. If a bug is found in 1.0, you apply the fix to the 1.0 branch. Merge from 1.0 to the 1.1 branch. Merge from 1.1 to the 1.5 branch, and finally merge from the 1.5 branch to the HEAD.
Merging from branch to branch is better than applying the fix manually to each branch.
With CVS you have to mannually keep track of what versions are merged, so that you do not include the same revisions when you do your next merge.
If you change to use Subversion, merging from branch to branch is easier. Eclipse's subversion tool will keep track of what revisions you have previously merged, greatly simplifying the task of doing repeated merges between two branches.
Changing to Subversion from CVS is easy(ish). You won't be the first to have made such a move.
Like awalshe said, it's better to merge between branches. To cherry-pick a merge, the method described in Pragmatic Version Control using CVS is very good:
In the branch - tag (PRE_FOO) before the change, make the changes and commit, tag after the change (POST_FOO). Then, in trunk, merge using the tags:
cvs up -j PRE_FOO -j POST_FOO
Merging between branches is much easier and safer in SVN, and it's trivial to convert your entire CVS history to SVN - see cvs2svn. You should use either SVN 1.5, or - with earlier SVN versions - svnmerge.