This is /really/ confusing as with the script I'm using reintegrate
the first time to go from branch to trunk, but you're saying I also
have to use it from trunk to branch - that is from origin to copied
branch. I've read through Julian's post (repeatedly) and if I
understand right, the "reintegrate" option will "flip" the perspective
of the current merge and "sync" merges from then on... This seems
/really/ accident prone as I'm still unclear as to with Julian's post
what are the implications if there multiple branches off the
originator involved, and multiple branch generations (branch of
branch) involved - so refactoring what Julian wrote:
Copy T->B1.
Merge T->B1 -- use a "sync" merge
Merge T->B1 -- use a "sync" merge
Merge B1->T -- use a "reintegrate" merge
Merge B1->T -- use a "sync" merge
Merge B1->T -- use a "sync" merge
Merge T->B1 -- use a "reintegrate" merge
Merge T->B1 -- use a "sync" merge
Copy T->B2
Merge T->B1 -- use a "sync" merge
Merge T->B2 -- use a "sync" merge
Merge B2->T -- use a "reintegrate" merge
Merge T->B1 -- use a ???? merge
Copy B2->B2.1
Merge B2->B2.1 -- use a "sync" merge?
Merge B2.1->B2 -- use a "reintegrate" merge?
Merge B2->T -- use a ??? merge
More merge shenanigans
What about cherry picking such that a bug is fixed in the trunk and
needs to be back-ported to a point release?
If it's only available with automatic handling in 1.8, when will that
be released (as http://subversion.apache.org/roadmap.html says Q4 2012
- /unconfirmed/) and we are over halfway through Q1 2013...
For completeness sake, can you test if the reintegrate option is
removed completely from the script, how does it perform against 1.8 -
as I don't have a sandbox to test?
On Sun, Feb 24, 2013 at 9:19 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sun, Feb 24, 2013 at 07:57:14AM -0500, James Hanley wrote:
>> I guess I should have read the next response in the thread before replying...
>
> So, to be clear (since you asked off-list):
>
> The following changes to your script prevent the tree conflict with 1.7.
>
> --- enduceTreeConflict.sh.orig Sun Feb 24 15:08:17 2013
> +++ enduceTreeConflict.sh Sun Feb 24 15:08:29 2013
> @@ -48,7 +48,7 @@
> echo "Rebaselining feature from trunk"
> cd ../../branches/Program_rc1
> svn up
> -svn merge ^/trunk/Program .
> +svn merge --reintegrate ^/trunk/Program .
> echo "We have a tree conflict!!!"
> #svn commit -m "Rebaselining feature from trunk"
>
> @@ -127,7 +127,7 @@
> echo "Perform additional downstream merging"
> cd ../../usr/andy/Program_rc1_main_line
> svn up
> -svn merge ^/branches/int/Program_rc1 .
> +svn merge --reintegrate ^/branches/int/Program_rc1 .
> echo "We have a tree conflict!!!"
> svn status
> #svn commit -m "Rebaselining usr/andy main line from integration main line"
>
> Remember to use --reintegrate whenever you switch merge direction.
> The first time your script uses --reintegrate direction switches from
> trunk->branch to branch->trunk. The tree conflict happens when you switch
> direction again (to trunk->branch) but don't use --reintegrate.
>
> Having to keep track of which direction the prior merge was using is
> rather cumbersome, which is another reason why this "feature" is not
> widely advertised in existing documentation (besides the fact that
> is was discovered after 1.7 was released).
>
> Subversion 1.8 will fix this issue in a much nicer way.
> I've tried running your script with Subversion 1.8-to-be (i.e. trunk).
> There is no tree conflict at all, even without the above modifications,
> because Subversion 1.8 detects the changes of direction automatically.
Received on 2013-02-25 17:12:04 CET