At this moment, I am the only person working on a project in svn. To stay legit, I am suppose to make changes to a branch and then merge those changes into trunk: so my branch and trunk are basically identical. Currently I have two working copies, one for the branch and one for trunk. I make the changes to the branch working copy and commit those, then I perform an svn merge on the trunk working copy from the branch location and then commit those changes. Question: can I change my process so that I only have one working copy and switch between the branch and trunk as follows?: 1) switch to branch, make changes and commit. 2) switch to trunk, commit. 3) repeat.
A:
Yes you can do this, using svn switch.
If your working copy is currently from the branch, and you've committed your changes to the branch:
svn switch svn://server/path/to/repo/trunk
Then to go back to the branch:
svn switch svn://server/path/to/repo/branches/xxx
Richard Fearn
2010-10-19 19:40:03
Are there any drawbacks using the switch process compared to my current two-working-copies-merge process? i.e. does svn store any meta-data about revisions when I perform a merge which I'd be losing out on?
Stephen Swensen
2010-10-19 19:46:04
Not as far as I know. Depending on which version of Subversion you're using, metadata *is* stored, but this metadata is committed to the repository when you commit the merge (so it's retained across `switch`es). See this: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.mergeinfo
Richard Fearn
2010-10-19 19:56:11
nice link, thanks
Stephen Swensen
2010-10-19 20:21:25
+2
A:
You can with one additional step.
1) switch to branch, make changes and commit. 2) switch to trunk, svn merge commited branch changes, commit. 3) repeat.
kevpie
2010-10-19 19:45:03
interesting additional step: please explain why this step is necessary. i.e. do i get additional meta-data performing the svn merge here? (because otherwise, my working copy should already be where I want it to be since the branch is always slightly ahead and I've just switched from it).
Stephen Swensen
2010-10-19 19:49:19
Once you have committed there are no modified changes that will persist after doing the switch. Switch will change the checkout state from the path/revision to the target path/revision. Only uncommitted changes will persist. So the merge needs to apply changes from the previous commit. Hope this helps.
kevpie
2010-10-19 19:55:06
Thanks, I will try this method and come back and mark yours as the correct answer if all goes well :)
Stephen Swensen
2010-10-19 20:12:45
+1
A:
As the previous answers suggest, it is possible to stay with a single working copy by switching back and forth. There's nothing technically wrong with it, the operation is semantically identical. However, I would stay with the two working copies due to the following reasons:
- You would still have to svn merge the changes after the switch, because the switch reverts the (now committed) changes, as pointed out by the first answer.
- You can't avoid the merge by quickly copying your changes back after the switch, because the merge operation records meta data for the commit (svn:mergeinfo in svn >= 1.5, as linked in comment by Richard Fearn).
- With separate working copies, you have a 'clean' test environment for the branch, without your unversioned/uncommitted trunk changes.
- If you have uncommitted changes in your trunk working copy because you are working on the trunk when you need to fix the branch, there's a risk you accidentally commit something that was not supposed to be part of the fix. Twice - first in the branch commit, then in the trunk commit.
The only downside to having two working copies (at least that I can see) is that you may have to do an svn update before making the fix. You didn't mention your reason for wanting to change your process?
Mikkel Blanné
2010-10-19 23:56:29
@Mikkel Blanne: +1 for the advice, but I'm going to try out the switch method. The reason I want to change my process is because I am working on a Grails project with IntelliJ with a team in another company so a lot of my configurations and settings are different than what is in svn (or they aren't in svn at all) so I don't want to a) go through the process of changing all my configurations upon fresh check-out of a branch (there are 4 sub-projects total), and b) maintain multiple configurations for multiple working copies... seem reasonable?
Stephen Swensen
2010-10-20 00:49:37
So you do have local modifications :) You could make a diff/patch file with the changes, and store it close by. Then you can always easily apply the patch to a fresh checkout. That works best if you don't need multiple configurations.
Mikkel Blanné
2010-10-20 01:07:33
Interesting, can you point me to any resources about this technique?
Stephen Swensen
2010-10-20 01:12:41
But if you need local modifications in the branch anyway for testing it, then you don't gain a lot by the separate working copies, and I think I would go with the switch/change/commit/switch/merge/commit approach. Unless you happen to work on different things simultaneously.
Mikkel Blanné
2010-10-20 01:16:22
On the command line: "svn diff > config.patch", then elsewhere "patch -p0 -i config.patch", depending on paths. TortoiseSVN has a GUI element for it. See an explanation for the command line version here: http://ariejan.net/2007/07/03/how-to-create-and-apply-a-patch-with-subversion/
Mikkel Blanné
2010-10-20 01:23:16