This week I had the situation where I was asked to come to another office (in Groningen) and do some testing and fixing of the software. The revision running there was revision 590, while I was in the middle of an integration effort, going up to release 605. I couldn't bring the current broken code, but some work needed to be done at the Groningen office, with revision 590.
(Note: we usually install a revision including source and build it on the spot, so the revision 590 source was present in Groningen office).
So, I went there and did some testing, fixing problems, etc. When I came back, bringing the source with me, I had the situation where you started to hack and decided afterwards that creating a new branch would've been a good idea. To do this, first you'll want to create a patch of all your changes:
$ cd your/current/project/directory $ svn diff > ~/hackwork.patch
Then find out what revision you are hacking:
$ svnversion . 590M
Now create a separate branch of the original version:
$ svn copy http://subversion.company.com/svn/telis/tuce \ http://subversion.company.com/svn/telis/tuce-branch-gron \ -m "Creating separate branch for work outside integration efforts" Committed revision 606.
Go to another directory, in my case ~/workspace
$ cd ~/workspace $ svn co http://subversion/svn/telis/tuce-branch-gron $ cd tuce-branch-gron
And now integrate your changes again, and commit them in the branch:
$ patch -p 0 < ~/gron.patch patching file tdb/mysql-telis.sql patching file client/python/plotffo.py ... lines removed ... $ svn commit -m "Fixes made on colors in FFO plot, conversion housekeeping \ macro different, conversion FFO plot corrected" Sending client/perl/lib/FFO_sweep_macro.pm Sending client/perl/lib/PLL_sweep_macro.pm ... lines removed ... Sending tdb/mysql-telis.sql Transmitting file data ............... Committed revision 609.
VoilĂ , a separate branch is created.