Imagine you have a bunch of source files in a branch that you are working on that are add/modified/deleted. Then suppose you decide to halt development on that branch for a while and go back and work on something else in the trunk. You are NOT merging the branch at this time.
Normally I would check in all my changes to the branch then do a Team->Switch and select the trunk and start work. However, I noticed that if I didn't check in my changes, Subclipse happily changed the subversion URL of my working copy to trunk and left all my changes intact.
My question is this: Did Subclipse do a merge for me behind the scenes or did it just switch the URL to trunk and do an update... presumably in an attempt to avoid losing my changes?
If it's the former, I have a new-found respect for subclipse/subversion. If it's the latter then, it seems like it should be an illegal operation to do a subversion "switch" while you have a modified working copy because you are in effect trashing the trunk!!
You can absolutely switch when you have modified sources. That is a perfectly normal use-case. Imagine you were working on trunk but not finished with your work and had to work on something else. The solution would be to create a branch for your new work, switch to the branch, commit to the branch (which will get rid of the local modifications) and then finally switch back to trunk.
This is how Subversion is designed to work.
Related
I don't understand something that is happening on my Eclipse and I am wondering if this is my Eclipse problem or if this is actually a feature. I have a trunk and a branch. On the repository they are the same so no changes have been commited since I created the branch. After making the branch I switch on my workspace the project from trunk to branch. Then I started working and changing on the branch. Suddenly I wanted to see something on the trunk because I got lost in my changes. So I switch to the trunk. I was surprised when Eclipse did not remove my changes and it was as if no switch was made. The changes continued being there.
Is this normal?
Can someone explain?
Thanks,
David
This is perfectly normal, and the way the svn switch is suppose to work.
Here's a common scenario. You're working on trunk, and realize that your changes should be applied to a branch instead. You simply do switch and you are now on a new branch and your changes are now applied to the new branch. Many times, I'll be working on one stream (a branch or trunk), and realize that my changes are too experimental and big to go into the current development stream. I'll create a new branch and switch to it.
There is no reason with gigabyte fast disks, and gigabyte networks to be skimping on working directories. I tell developers to dedicate a working directory for each project and branch. Otherwise, if they keep switching back and forth between various development streams, they're going to forget and do development in the wrong place.
With almost any svn client you can:
check out a project
make some changes
switch back and forth to any truck/branch
preserve your changes along the way
In other words, nothing specific to eclipse here.
see: svn switch
I prefer to have separate eclipse projects per branch and also change the project name to something like myProject-24 so when the branch is checked out again down the road, the default project name has some branch identifier on it.
This also enables you to make changes on a per branch level and do single commits across the branches; even if they're in discreet eclipse projects.
The functionality you are looking for can be reached by doing the following
Right Click on the folder that should be replaced
Click on "Replace With ..." from the context menu
Click on "Branch ..."
Select the branch you want to take a look at from the dropdown box
ATTENTION: This is replacing your local changes. It is not possible to reverse this.
Greetings
Tobi
Suppose I have the following senario:
Trunk is my main development line where programmers commit to when done.
Branch V1.0 is a branch I created when releasing version 1.0.
The programmer is working on the trunk but needs to switch to the branch in order to fix bugs.
When switching back to the trunk Subversion will give me the latest in the SVN repository which does not include the recent changes.
So, in order to switch he will have to commit what he has because otherwise the changes are "lost". I know they are still kept in the local repository but it would still mean restoring them one by one once he switchesback.
Am I missing something here?
Edit:
Now I am thinking down these lines:
Each programmer would have his own "private" development branch off of the trunch. He could commit to there whenever he wants. When he has finished what he has written he can them merge it into the trunk. He starts again for the next assignment.
If at any point he is required to fix a bug in some other release he can just commit to his own private branch, fetch the odl release and fix it. Then, after committing the changes to the fix, he can easily switch back to his own development branch.
Would that work?
I think that subversion is not thought for switching as you described. A solution would be to have two workspaces, one for the branch and another one the trunk, so you can switch from one to another without problems. I know it is not a nice one.
Consider switching to a version control tool that is better suited for your approach. My own suggestion is Mercurial, coupled with MercurialEclipse. The only drawbacks I'm aware of are that Subversion is better suited to store binary files and that Mercurial's subrepositories don't work so well as Subversion's externals.
In Mercurial your programmers would be able to commit their changes to their private repositories, merge and commit locally again, and then push the resulting changes to an official repository, from which other programmers would pull them into their own private repositories.
The best solution for such purposes is to have two separate working copies. One for working with trunk and one working with the branch.
Update: We ended up using a process very much like this schema (thanks to neuro for the link). We massaged out repository into a state where default is stable (and has the same code as our production environment), we have a dev branch, feature branches for new stuff and use release branches for releases. All seems to be working perfectly.
Backstory
Our team has recently switched from using SVN (using ToroiseSVN Windows client) to Mercurial (using TortoiseHg Windows client) for version control. We have successfully exported our SVN repository and imported it into a Mercurial repository.
We now have a Mercurial repository where we can see the entire history of revisions (changesets in Mercurial).
How we did it in the old days
Life was simpler in the old days; our development process was not really multi-stream like it is now. The trunk was used to hold all code - even changes that were still in-flight (as long as it didn't break the trunk). When it came to managing releases with SVN, we would checkout the trunk (which holds all code), revert the individual changes we didn't want as part of the release, and create a tag for it.
Cherrypicking the code we want with SVN was easy. Bug-fixing previous releases and ensuring it was part of the trunk was simple too.
What we are doing now
In Mercurial, we need to be able to get a snapshot of the "trunk" (default in Mercurial) with individual changes reverted out. We can do this using hg revert.
To snapshot this, we have created a "named branch" - let's call it Build-4.0.1 for now.
Where the challenge arises
Development continues on default as normal when a bug is found in Build-4.0.1. Let's assume the bug is in one of the reverted files. We change the code from the branch for Build-4.0.1, create a new "named branch" (Build-4.0.2) and want to merge it back into default without pushing the reverted code over the top of newer code. How can we accomplish this?
Alternatively, is there a better workflow for managing the releases and our code in Mercurial? I quite like the look of this wonderful SO answer on managing release branches, although I am not sure how we can transition to it from the state we are in now (with in-flight stuff in default).
Note: I have looked at the Transplant extension, but haven't used it yet - could it be part of the solution to this challenge?
Well, to begin with, your use of revert seems strange to me. Usually it is used to revert modifications done to the working copy back to the version of the repository.
The usual way to get the working copy to some point backward is to update :
hg update -r 1234
from there, you can tag, modify, commit, etc.
To merge back you only have to merge your release branch to the default branch. It will work like a charm, unless it is to different/old a release.
Transplant works fine, but do something a bit different from merge : it take your changeset as a "diff" and apply it as a new modification.
To manage your releases, you can look this other answer (by me) :
How to use mercurial for release management?
What we use is a clone / main branch that holds the most stable version, which is released at some points. On this clone : branch, we can fix critical bugs (hotfix). In parallel, we use a dev clone / branch to develop. The hotfixes are merge as soon as completed from stable to dev. When the current development is done, we merge the dev on stable / default.
This schema is pretty good to understand things :)
Good luck !
Going through all the changes and taking out the ones you don't want is not a common way of creating a release, to put it mildly. The Common Branching Patterns section in the SVN book suggest some more popular work flows:
release branches: create release branch from unstable trunk, fix bugs to stabilize it, cherry pick bug fixes between them while the branch is in maintenance mode.
feature branches: keep the trunk stable and ready for release by only merging in the feature branches that you want
The second one is probably the best fit here, because it gives you a place to put experimental or risky changes until you feel confident about them - these are the changes you would have reverted before a release in your old workflow.
Both of these branching patterns should carry over just fine to mercurial. In case you go for the first approach, note that mercurial (since 2.0) now has a graft command, you no longer need the transplant extension.
I am looking forward to merge my code which I developed in a branch of SVN to the trunk. I am using Eclipse and I have been using Team->Commit to commit my updates to the SVN. But I haven't done a merge before. Please help me with this.
First of all make sure you are up to date. Update your working copy of the target branch, ie. where you are merging into. In this example we're working on the trunk of "core" and we want to grab the changes that have happened in the maintenance branch and merge them.
Resolve any conflicts. There should be no conflicts at this stage between the working copy and the repository.
Select the SVN merge option on the working copy. In Eclipse this is going to be found under the "Team" menu and called "Merge Branch".
SVN: Merging in Eclipse
Change the From URL to the specific branch you want to be merged into your working copy. In this example we're looking for the p400 maintenance branch (./core/branches/p400).
Change the From Revision to the last revision that was merged into the target branch. Essentially you don't want to keep merging the whole branch history, you just want to include those changes since the last time you merged. There is no easy way to determine the last merge point at this time in Subversion. You have to review your message log and look for the last commit that talks about merging. If you are disciplined about the commit messages you use for merging this should be easy (see below). Make a note of what that revision is -- you'll need this later when you commit your changes.
SVN: Merge with Eclipse
Change the To Revision to the latest (i.e. head). Make a note of what that revision is -- you'll need this later when you commit your changes.
Click Merge and wait. Depending on how big the differences are this may be quick or Eclipse my just fall over. If you have such an enormous change that you can't get it done in Eclipse you may need to make the range of revisions you are merging smaller. Or you may even have to skip certain revisions and do them manually if they are massive. We've had this problem from time to time when updating large third-party libraries. The vast majority of the time you will be fine.
Review changes and resolve conflicts. Once the merge is complete, look through the changes made to your working copy and make sure you address any conflicts you find.
Once all the changes have been resolved in the target working copy, check them in with a single commit. The reason you're not doing lots of commits is that these are changes that should have been documented in the branch from which you merged. The commit message needs to be in a specific format that details the merge and is easy to find in the future. We use the following format, but you can use anything that works for you -- as long as you stick to it.
Merging [source] to [target]; [repository]. Merge rev [start]:[end]
Enjoy!
In eclipse we have an option to merge. Right click the project , you will see "Team" option and on clicking it you will see merge option. There are three different options you can see in the merge.
To successfully merge the changes from the branch to the trunk, we need to switch the local workspace to the trunk (but make sure all the changes are committed to the branch before that). Once we do that we can use merge option and select "2 URLs" option. I put url for trunk as url 1 and the branch I wanted to merge as url 2. I could see all the incoming changes I selected "OK". All the changes are in my local now (at this point my workspace is linked to the trunk). Then I committed my changes to the trunk and hence merge from branch to the trunk was successful.
I would like to add for Point 8 .Review changes and resolve conflicts. ---
When working on conflicts manually- when you do copy from right to left on chunks of code - Be careful
Sometimes chunk of code gets added, sometimes it properly replaces the chunk.
Make sure there is no duplicate chunk of code.
Also, this is helpful-- What is the proper way to do a Subversion merge in Eclipse?
this may be a naive question, but, as asked in the object, what is the actual way used by versioning softwares to merge a branch back into the main trunk without generating broken code?
Here's a quick example: I make a branch out of the main trunk for the program "Hello World Power edition". I add support for Klingon. This is a radical change that changes the way the function printHelloWorld() works.
Meanwhile, because of bug #749 that cause "Hello World" to be written "Helo World", the function printHelloWorld() in the main trunk has been changed.
Now, the problem that I see here is: when i merge by branch back to the main trunk i experiment a clash in the function printHelloWorld() within the file sayHello.py
How does a VCS program know how to add the Klingon support from my branch and keep the bug fix in the main trunk? What are the human-driven or software-driven strategies to avoid this?
Thanks in advance.
How does a VCS program know how to add
the Klingon support from my branch and
keep the bug fix in the main trunk?
VCS knows nothing about semantic of your source code it sees it as a bunch of text/binary files. VCS system uses diff / merge algorithms to detect conflicts between yours and current file version. It is your responsibility to resolve such conflicts because only you know semantic of these changes. Some VCSs like SVN would require you to update your working copy with latest changes from trunk before allowing you to commit changes to make sure that nothing is lost.
To make sure that you didn't break anything and all previous bug fixes were not broken you should use code reviews, unit tests and other practices. Continuous integration is a good way to keep software healthy.
In such a case the version control system can't merge automatically, you have to do the merge by hand. Good unit tests will help you to ensure that no functionality is lost.
Before you can merge your branch back to trunk, the version control system will update your working copy with the changes in trunk since you branched out. It will just not allow you to merge without this update. This ensures you get all the bug fixes in the trunk in your next commit.
A good strategy for working on a branch is to port changes in trunk into you branch on very regular basis. This ensures that you don't drift too apart from trunk, leading you to have problems when you eventually merge back into trunk.