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
Related
I have set up an SVN repository that currently has the stable code in trunk and a branch on which new development is happening.
I would like to fix bugs on trunk and have the people working on the branch pick up bug fixes by merging from trunk on a regular basis. My problem is that I can't figure out how to access the trunk version from Eclipse when I need to fix bugs, then access the branch when I do new development.
The only thing I can think of is using the SVN Switch utility to swap between trunk and branch. But, this seems very clunky. I tried switching without committing some changes I made to one of the files, and the file was then in a conflicted state. This doesn't seem like the right way to me.
Any ideas? Thanks in advance for any help.
You have not access trunk-version from Eclipse, because if you want to have sync-merge from trunk to branch you have to have Working Copy of branch, and ^/trunk will be referenced only on merge (which is Eclipse-specific interface)
The normal way to do this is to use switch. Before beginning work you should do switch to make sure you are on the branch where you want the changes to go when you commit. If you have local changes, it is OK, but when you switch it is just like doing an update. You can get conflicts if SVN needs to make updates to the files you have local modification in.
If you do not have any local modifications or unversioned files, then switch will not create conflicts.
My development team recently doubled in size from one (myself) to two. As the sole developer, I was maintaining the trunk as the stable version of our software. I'd make changes in my working copy, test, and only push to trunk once I was sure it was stable.
With the new team member we are trying to come up with the best flow for co-developing the codebase. We have decided that trunk will stay stable; changes are pushed there only after code review and thorough testing. The teammate will create feature branches for features he works on; when he requests a code review, I will do it and then once approved, he will merge the branch into trunk and delete the branch.
We are both using eclipse and the subclipse plugin to manage our working copies.
The problem is that while I can view differences between my working copy and his branch (Team -> Compare To -> Branch), I do not know how to get the code from his branch to merge with my working copy. I want to be able to get his changes without losing any local changes I have made, run his code locally, and have none of this affect trunk. That seems to rule out the option in Eclipse/SVN to switch to another branch/tag/revision, since I need to have his code merged with mine (in order to make sure my working copy's code is consistent with my local database).
We've looked at the SVN Patch feature, instead of using branches perhaps he should send his changes over through a patch which I run?
So the concrete question here is: how do I merge/incorporate changes from a branch with my working copy without touching trunk? I would also be grateful to get suggestions on how we should implement our workflow in a way that takes advantage of the power of svn and eclipse in a way I am missing.
Both of you should have checkouts of trunk and any branches you're both working on. When he is ready to have his branch merged into trunk, you should:
Ensure that his branch builds successfully.
Ensure that your trunk checkout is pristine (no SVN added, modified, deleted, unversioned or ignored files).
Conduct the merge, resolving any conflicts with his help.
Perform a code review, including ensuring that trunk is stable with his changes.
Commit the merge.
Conduct the merge outside of Eclipse, using the SVN command-line. I've seen enough questions here on SO related to Eclipse and Subclipse that tells me the plugin is unreliable.
If it was me managing this workflow, I'd have two checkouts of trunk: one which is meant for merging and is always in a pristine condition, and another in which I can actively develop. That way, I wouldn't need to create a patch of my changes, then merge, then apply the patch.
Hope this helps.
The sad truth is that SVN will probably not be fit for this pattern. Branching creates a lot of pain in Subversion
Check here to get more details.
It was enough for me to update the branch from command line with 'svn up'.
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)
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
I am trying to contribute to a project that uses Subversion. I used Mercurial and its hgsubversion extension to clone the repo. My work takes place on a feature branch.
How do I keep the feature branch up to date with stuff that happens on the default branch (hg speak) aka the trunk (svn speak)?
So I used hg up feature to update to the feature branch, then hg pull which gave me changesets on the default branch. So I did hg merge default, the committed the merge, then tried hg push to send my changesets to Subversion. And Mercurial said: "Sorry, can't find svn parent of a merge revision."
I have finally figured out how to get my repository un-wedged after an event like that described in the question, so that I can continue work without having to re-clone the parent repository (which is, obviously, a quite slow operation when you are pulling from Subversion!). If the "tip" of Subversion outruns you so that you cannot push any more, just make sure that you have the built-in "rebase" extension activated in your Mercurial through a $HOME/.hgrc line like this:
[extensions]
rebase =
And then you should be able to run this command when your repository gets wedged:
$ hg rebase --svn
If I understand this correctly, it dissolves your current branch that has taken you away from Subversion HEAD, and rebuilds it atop the branch "tip" in Mercurial that corresponds to the HEAD in Subversion. From there, you can keep working and successfully do pushes again. It has always worked for me so far; let me know if you run into any problems!
Mercurial as a few different branching modes: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
The one you're describing is 'named branches', which is the most popular when you're working with a repo that's accessed only via mercurial (or hg-git).
However, when you're using hg-subversion so that you're pushing changes to/from subversion, which only nominally has branches, you're better off keeping all of your mercurial changes in the 'default' named branch, and using the 'clones and branches' pattern (which I prefer anyway).
Specifically, that message Sorry, can't find svn parent of a merge revision. isn't a descendant of a revision that has a direct match in subversion.
Were I you, I'd reclone from svn, and then move my work into that repo's 'default' branch with the 'transplant' command (packaged extension). If you want multiple features in parallel w/ hg-subversion use separate clones (they're so cheap), as it's more in line with how subversion thinks about branches.
I needed to figure this out for myself and wrote it up here:
http://notebook.3gfp.com/2010/05/pushing-a-new-feature-from-a-mercurial-repo-into-an-svn-repo/
I haven't yet figured out how to close a branch in subversion and have the mercurial graph look correct.