I hate it how it is only after you have sent the email to the mailing list - you realise the error you have made!
The issue lies in the creation of the branch. In the original email it was created via an OS copy and not a svn command. In the most recent email, I explained how I did this; > svn copy http://myServer/repos/branches/releases/1@1000 Which effectively is the same thing that I had when I did the OS copy. The issue being there is no ancestry between ^/trunk and the release branch. Everything is now working correctly as I have created the release branch with; svn copy http://myServer/repos/trunk@1000 a subsequent; cd /repos/branches/releases svn merge ^/trunk --dry-run Now shows only the changes performed on trunk since r1000. Gavin. On 20/10/2011, at 5:12 PM, Gavin Beau Baumanis wrote: > 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. >>
