Yesterday I was given a new assignment. Of a certain system all development was stopped a month ago. The latest version, deployed and tested on the test environment, will not continue to be deployed on the production environment. The current version running on production is almost a year old. All new functionality developed after this version will be withdrawn, except for two changes. The assignment is to implement only these two changes on the version current running in production.
All the Java code is nicely stored in subversion. There is a tag of the version current running on the production environment, as well as several tags of later versions which has not been deployed to production, only to the test environment. And the trunk is the latest developemnt code, as it should be. How are we going to this, so the trunk can be used in future to contitue development?
My first thought was to create a branch and continue development with this branch. But this leaves us with a trunk that will not be used any more. Not nice and quite confusing for further development and maintenance. For a nice situation we have to move the trunk back to a tagged version or to a branch.
Searching with Google, all I could find was information to merge a branch with the trunk. But that would result in lots of merging conflicts, because lots of changes were made after the tagged ‘production’ version. A path I didn’t want to go to. There must be an easier way.
The available tools are also a part of the problem. I can only use the subversion plug-in in Eclipse, Subclipse, because it’s not allowed to install software on your own (policy by the company where I was hired). So no Tortoise :-(.
The solution I’ve finally chosen is to go to the subversion perspective in Eclipse and to retrieve the history of the tagged version which is currently in production. Then note the revision number of the latest code change of this tag (excluding the revision of the tagging itself).
Then in the normal Java perspective checkout the trunk of the project in your workspace and retrieve the history of the trunk. You might need to press the "Get All" button to retrieve the full history. Find the revision number you noted and select all later revisions (select the revision right after your noted revision -one above- and while shift-pressed select the latest revision -the first one on top of the list).
With the alternate menu (right mouse click on the selection) you select option "Revert Changes from Revision x to Revision y". The reversion will only be applied to your local workspace.
By comparing your local workspace with the tagged version (right mouse click on the project – Compare With – Branch/Tag – select tagged version from repository), you can verify if the reversion was successful.
Finally Synchronise and commit all changes.
Now I am still wondering…. Is there an easier way to do it?
(also solutions using Tortoise are welcome)
Nice work guys, thanks very much for this, very useful and much appreciated.Alastair
@Klaas, Hakan
Thanx for your replies. Your answers were actually the answers I was looking for, but couldn’t find Googling!
I consider both your solutions better than my one. I would have gone for solution of Klaas, thus not deleting the trunk but renaming it to a branch.
Unfortunately it’s now too late for this project.
Hopefully others struggling with this problem will now Google this blog and find your solutions!
Since the Subversion directories trunk, tags and branches merely follow a naming convention (there is really nothing special with these dirs) you could delete the trunk directory (but be sure to branch it before) and branch a tagged release back into trunk like:
* make a branch of trunk (for example to branches/deprecated_trunk_20080121)
* delete the trunk-directory
* make a branch of the stable release tag into trunk (for example from tags/1.0 to trunk)
Hello Emiel
In my opinion you try to achieve three different things in one action. Your end result is perhaps workable, the logging history will be a bit confusing. I would do it as follows.
First the customer wants you to create a change on code that is in production (According the conventions of subversion the production code is tagged). In subversion it is not done to change a tag, thus I would create a branch. This is the place where you can adapt the code for the new situation.
Secondly the desired change is already done in the trunk.. With a bit of luck the wanted change can be identified in one or two commit steps. I would merge these steps into the newly created branch. This process is called creating a back-patch. When I commit the back-patch I would note the revision numbers from the trunk, including the comment on the original change.
At last it is decided that the new development will not be done on the trunk anymore. The trunk becomes obsolete. New functionality will be added tot the branch. Because in subversion the trunk is always the latest and greatest code I would rename the trunk to a branch name for example trunk_version_discontinued. I would rename the new branch to trunk.
The end result is the same as with your actions, but the logging history reflects now better what was done. And in case you need more changes that can be found in the former trunk you can easily merge them again.
Success with the remainder of the project
Command line way of doing this found at: http://aralbalkan.com/1381