RE: Tortoise gets confused when branches are renamed

> Yes, this all said I guess I would say... A better way for the OP to have handled this would have been to TAG the bugfix branch and continue on with more fixes.

That was not practical. Let me explain...

The boss has a policy that there will be one branch called bugfix, containing bug fixes to trunk.

Ages ago, I created a bugfix branch from trunk, and committed some bug fixes.

Now much time and many revisions have passed. Trunk is now a copy of a completely different branch (the development branch, which has many differences, additions, deletions, renames, and was based on an earlier trunk).

I need to make a bugfix to the new trunk. I have two choices:

1) Rename the old bugfix branch to something else, and make a new copy of trunk called bugfix. Easy, and involves two operations on the repository.

2) Merge all the changes made to trunk since the last time the bugfix was branched from it. As it happens, this will give rise to 100s of conflicts (the development branch made changes to the same lines of code I fixed in the original bugfix branch, for completely different reasons).

For a command-line driven SVN client, 1 is the obvious, simple, and correct solution. I don't even have to get involved in peg revisions, as the default peg revision works fine to look at changes in either bugfix branch.

For Tortoise, if I do 1, then I (and, more importantly, everyone else who works on the project) must always remember that I can't access any of the changes in the original (now renamed) bugfix branch without using the workround Stefan suggested.

Nikki

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2195947

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-11 21:28:28 CEST