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.
>
Received on 2011-10-20 08:13:20 CEST