Hi, > No, it is an option on the command=line as well as described further down in > the article I posted a couple of replies back. And as I said with this large a code base looking through history via the command line is hardly ideal.
> If I understood Bertrand, the results of the poll will be binding, so you > have to work within whichever plan wins. Despite you only putting 2 options of all those that have been discussed? And only one of the 3 options I actually put forward. > I hope the develop branch will hardly every match trunk completely because > it will be containing changes not yet ready for primetime. That fine and no issues with that. But I'm taking about changes made to trunk that are not in the unstable branch. > I am not an expert, but my undertanding is that cherrypicking doesn't cause > merge conflicts although it could result in something being broken if you > miss an important revision. But that should be found in testing of the > release branch before it gets merged to trunk. Hopefully yes. However in fixing anything that is broken in this way you'll need to check into trunk. How do you then sync the unstable branch with that change that has just been made in trunk? All merge of of trunk from unstable can cause conflicts if for example someone deleted or renamed a file in one changeset and someone else modified the same file in another changeset. Other issues can also cause conflicts see: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.mergeconflicts We would also need to block any SVN client that use 1.5 or below: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients Justin
