Ok - Well now I am confused... I did: svn rm /repos/branches/releases/1 cd /repos/branches/releases svn copy http://myServer/repos/branches/releases/1@1000
Which gave me a new copy of the release branch - as it stood at r1000. Which subsequently the revision used to create ^/tags/1.0 Now we want to release 1.1 - but am back to having my original issue of "everything" being in conflict. cd /repos/branches/releases svn merge ^/trunk --dry-run and everything is reported as a tree-conflict. I assumed that creating the release branch via svn mechanics and then doing a merge into that branch would work seamlessly - but it obviously isn't the case. Firstly I don't understand why it is in conflict in the first place. Secondly, when in a feature branch; cd /repos/branches/feature1 svn merge ^/trunk works as expected - and updates my feature branch with all changes made in trunk - since the last trunk->feature branch merge operation. Why is it not working for me in the other directory / branch? As always - thanks in advance! Gavin. On 19/10/2011, at 10:56 PM, Gavin Baumanis wrote: > Hi There everyone, > > I have trunk, branches and tags. > (the "default" repo setup) > > VERY recently we swapped from continuous deployment to having a scheduled > release strategy. > We used to simply cherry-pick or even just OS copy the required changes from > trunk to a "special"(to us) branch any change that needed to go to production. > This special branch was ten simply copied to production. > > Now, we are trying to start the "standard" release strategy, > Develop on trunk, > Merge to a release branch, > Create a tag. > > I genuinely cannot recall how we created the release branch; > all I know is the symptoms of what I now face - and hope to "correct". > > I did this; > cd /repos/branches/releases/1 > svn merge ^/trunk --dry-run > > And subsequently got a status report that everything was going to be a > conflict. > So I think it's safe to say that the releases branch was created by an OS > copy and not an SVN aware operation. > > is there a pain-free way that I correct my repository to allow for successful > trunk -> release branch merging? > I am thinking of; > * Deleting the release branch; > * Recreating the release branch at the revision that the release branch was > originally created. > * Re-merging the single trunk change that was merged to > ^/branches/releases/1.0 > > Which should bring it to its current state - and match the 1.01 release tag. > > And hopefully now allow me to merge ^/trunk -> ^/branches/releases - which > should allow a more pain-free merge for the next release. > > Do I have that right? > Is there something else I can do that would negate the requirement to > recreate the release branch? > > As always - thanks for your assistance. > > > Gavin 'Beau' Baumanis. >
