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