Mark Rogers wrote:

...

After an hour or so of reading tutorials and trawling Google I'm still stuck on something.

I find the best place to start is the on line official book. Here's chapter 4 on branches (and merging):

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html

...

Suppose I want to call my current software tree "v1", and create a copy to become "v2". The software is a PHP web library and basically the purpose of v2 is to start removing all the old PHP3/PHP4 compatibility code, and tidy things up, thus breaking backwards compatibility.

I think I start with something like: svn copy -m "v2" <svnrepo> <svnrepo>/tags/v1 svn copy -m "v2" <svnrepo> <svnrepo>/tags/v2

My current code is already in a directory ~/mylib/v1, and I want to keep that as it is (several apps on the server are using it), and checkout v2 directory ~/mylib/v2; new apps will start to use that version.

AIUI, you should be able to create a branch for v2 development without affecting the v1 tree, just by doing this: svn copy -m 'making v2 branch' <repo>/mylib/v1 <repo>/mylib/v2

...

So far so good. Where I'm stuck is how to make sure that ~/mylib/v1 stays on the v1 branch so I can continue to fix bugs and add features (unlikely but possible) to it if I need to, and ~/mylib/v2 similarly stays on the v2 branch. Both will have regular commits to their respective branches, and I may want to merge fixes from v1 into v2 (and vice versa). In other words v1 will become v1.0.1, v1.0.2, ... and v2 will independently become v2.0.1, v2.0.2, ... whilst sharing common history and allowing me to migrate some changes between branches.

According to the book, you can now check out your v2 branch to a separate working area: svn checkout <repo>/mylib/v2

..where you can continue development of v2 separate from the v1 working area. These two work areas will initially be the same of course, however changes checked into v2 will not appear in v1 and vice versa.

If you want to 'tag' specific releases of anything, you simply copy the relevant tree again, but give it a tag name eg: svn copy <repo>/mylib/v1 <repo>/mylib/v1.0.3

..this is the same as creating a branch, thus the *humans* have to understand that this directory should not have changes committed (you can also use the paranoid access control mentioned in the book to prevent this happening).

Merging is covered in the next page of the book (after branching):

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html

..where you will want to merge specific changes (that fix specific bugs) from one branch to the other. This works well as long as the humans don't commit bug fixes with other work, preventing the selection of changes by a changeset number (read the part on cherrypicking).

HTH, Phil