You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by James Hanley <jh...@dgtlrift.com> on 2013/02/22 20:15:06 UTC
Merge, reintegrate, and merge with tree conflicts
We are seeing merge tree conflicts where I believe svn is not working
as expected. I'm not entirely sure if this is due to a lack of
understanding for proper use on our part, but it was my understanding
that reintegrate was to be used when pulling changes from a branch and
pushing them into the copied from branch.
The problem can be reproduced by creating a branch, add and committing
a new directory within the branch, reintegrating the changes to the
originating branch, then merging any new changes from the originating
branch into the branch with the changes.
I've included the following script to regenerate the issue two
different ways - the first is the most simple way I can think of the
reproduce it, and the later is a simulated structure of how we are
using svn and how I found it.
Any advice?
-Jim
Re: Merge, reintegrate, and merge with tree conflicts
Posted by James Hanley <jh...@dgtlrift.com>.
Okay - I read through and understand the use of reintegrate - but that
is what we are using and the script provided in the original post
uses. The issue is that even with its use, I'm getting a tree
conflict. Please read and test the script from the original post.
On Feb 24, 2013, at 7:59 AM, Stefan Sperling <st...@elego.de> wrote:
> On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote:
>> Is this a use case that was taken into consideration, and will it be
>> "fixed" or the functionality/logic added to allow this use case?
>
> See my other reply for more details, but yes, this is being addressed:
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
Re: Merge, reintegrate, and merge with tree conflicts
Posted by James Hanley <jh...@dgtlrift.com>.
Okay - I read through and understand the use of reintegrate - but that
is what we are using and the script provided in the original post
uses. The issue is that even with its use, I'm getting a tree
conflict. Please read and test the script from the original post.
Meant to reply all (twice)
On Feb 24, 2013, at 7:59 AM, Stefan Sperling <st...@elego.de> wrote:
> On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote:
>> Is this a use case that was taken into consideration, and will it be
>> "fixed" or the functionality/logic added to allow this use case?
>
> See my other reply for more details, but yes, this is being addressed:
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
Re: Merge, reintegrate, and merge with tree conflicts
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Feb 24, 2013 at 07:55:41AM -0500, James Hanley wrote:
> Is this a use case that was taken into consideration, and will it be
> "fixed" or the functionality/logic added to allow this use case?
See my other reply for more details, but yes, this is being addressed:
http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
Re: Merge, reintegrate, and merge with tree conflicts
Posted by James Hanley <jh...@dgtlrift.com>.
Yes I have used git, etc - in the past, but we are forced to use svn
for the time being.
What I would like to quantify is if this shortcoming of subversion is
by design or if its a bug. From your description, it seems like the
former, and if so, what is the architectural reasoning?
I understand the concept that the merge to WC records the merge
information, and the merged from has no knowledge of the merge or even
branch for that matter.
Is this a use case that was taken into consideration, and will it be
"fixed" or the functionality/logic added to allow this use case? Is
there a tracker item or roadmap item describing such use, and what
dependancies are blocking the implementation for this?
On Feb 24, 2013, at 7:14 AM, Andreas Tscharner
<An...@metromec.ch> wrote:
>> So what is the proper way to continuously perform the workflow we're
>> trying to do - that is pull changes from origin path into branch, push
>> changes to origin branch from branch, and repeat.
>>
>> Using bidirectional merge (without reintegrate) seems create severe
>> merge conflicts.
>
> Short answer: There is none (with SVN)
>
> Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk).
> At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course)
>
> If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right?
>
> Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try.
>
> Best regards
> WENZEL Metromec AG
> Andreas Tscharner
> --
> Andreas Tscharner, Development
> WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland
> phone: +41 (0)81 257 07 00
> fax: +41 (0)81 257 07 01
> e-mail: mailto:andreas.tscharner@metromec.ch
> www: http://www.metromec.ch
Re: Merge, reintegrate, and merge with tree conflicts
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Feb 25, 2013 at 11:11:19AM -0500, James Hanley wrote:
> 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
Yes, it is very prone to accident, which is why it's not documented,
as Julian himself pointed out in his post.
The feature will officially be available in 1.8. Until then, you can
use this trick or just ignore the fact that it exists if it confuses
your users too much. It will be much easier once Subversion can figure
out the correct merge direction on its own.
I just mentioned it because of the claim that doing this was impossible
with SVN, which isn't true. It's inconvenient at the moment, but not
impossible. The inconvenience will be addressed in the next release.
> 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
I believe a sync merge would do here.
The last direction in a merge from T to B1 was T->B1. That's what
counts. B2 has nothing to do with it.
> 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
Again, "sync" should be alright. The last merge involving B2 and T
was in the B2->T direction.
> 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?
I've already mentioned this briefly here:
http://svn.haxx.se/users/archive-2013-02/0238.shtml
Generally I would recommend to cherry-pick only to or from branches
which never merge in their entirety with another branch.
Say you have a release branch for all your 1.0.x releases. This branch
will live as long as 1.0.x releases are shipping (1.0.0, 1.0.1, etc.),
and then it will simply become uninteresting. You'd never attempt to merge
this branch into a branch representing a different release (i.e. merge two
code bases meant for different releases with one another in their entirety),
and hence such a branch is suitable to be cherry-picked from and to.
In particular, you want to avoid situations where cherry-picked changes
end up being merged in a circular fashion, such as:
initial commit on B1 -> cherry-pick from B1 to B2 -> merge B2 into T
-> merge T into B1 # initial change is applied again to B1
In this kind of situation, assuming both B1 and B2 are over time kept in
sync with T, it is more appropriate to commit the change to T initially.
It's a good idea to design your branching/merging strategy in a way
that avoids cycles. There are many ways of doing so, so I cannot
elaborate further without more information about your current strategy.
> 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...
When it's done. The community is already discussing the 1.8 release and
is very eager to get it done. We're currently still applying some stability
fixes for the new local-move-tracking feature. Follow the dev@ list if
you're curious.
If you'd like to help testing 1.8 once alpha and beta releases come out,
that would be highly appreciated! Just watch this list or the announce@
list which receives much less traffic than the users@ list does.
I believe there will be binary packages available for easy installation.
> 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?
Sure. Here's a transcript of a run of your script when run with 1.8
and all --reintegrate options removed.
$ bash -x enduceTreeConflict.sh
+ svn --version
svn, version 1.8.0-dev (under development)
compiled Feb 25 2013, 10:54:05 on x86_64-unknown-openbsd5.3
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
+ svnadmin --version
svnadmin, version 1.8.0-dev (under development)
compiled Feb 25 2013, 10:54:05 on x86_64-unknown-openbsd5.3
Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository back-end (FS) modules are available:
* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_base : Module for working with a Berkeley DB repository.
+ echo '###########################################'
###########################################
+ echo '### Attempting most simple reproduction ###'
### Attempting most simple reproduction ###
+ echo '###########################################'
###########################################
+ mkdir simple
+ pushd simple
/tmp/simple /tmp
+ svnadmin create repo
++ pwd
+ svn checkout file:///tmp/simple/repo wc
Checked out revision 0.
+ echo 'Create basic repo structure'
Create basic repo structure
+ cd wc
+ mkdir branches tags trunk
+ svn add branches tags trunk
A branches
A tags
A trunk
+ svn commit -m 'basic repo structure'
Adding branches
Adding tags
Adding trunk
Committed revision 1.
+ echo 'Navigate to trunk'
Navigate to trunk
+ cd trunk
+ echo 'Create initial project layout'
Create initial project layout
+ mkdir -p Program
+ svn add Program
A Program
+ svn commit -m 'Initial project layout'
Adding Program
Committed revision 2.
+ echo 'Create branch'
Create branch
+ cd ..
+ cd branches
+ svn cp '^/trunk/Program' Program_rc1
Checked out revision 2.
A Program_rc1
+ svn commit -m 'initialize integration branch'
Adding Program_rc1
Committed revision 3.
+ echo 'add new feature'
add new feature
+ cd Program_rc1
+ mkdir -p treeconflict
+ svn add treeconflict
A treeconflict
+ svn commit -m 'add new feature'
Adding treeconflict
Committed revision 4.
+ echo 'Reintegrating feature to trunk'
Reintegrating feature to trunk
+ cd ../../trunk/Program
+ svn up
Updating '.':
At revision 4.
+ svn merge '^/branches/Program_rc1' .
--- Merging r3 through r4 into '.':
A treeconflict
--- Recording mergeinfo for merge of r3 through r4 into '.':
U .
+ svn commit -m 'Reintegrating feature to trunk'
Sending .
Adding treeconflict
Committed revision 5.
+ echo 'Rebaselining feature from trunk'
Rebaselining feature from trunk
+ cd ../../branches/Program_rc1
+ svn up
Updating '.':
At revision 5.
+ svn merge '^/trunk/Program' .
--- Recording mergeinfo for merge between repository URLs into '.':
U .
+ echo 'We have a tree conflict!!!'
We have a tree conflict!!!
+ popd
/tmp
+ echo '################################################'
################################################
+ echo '### Attempting to show real world use issue. ###'
### Attempting to show real world use issue. ###
+ echo '################################################'
################################################
+ mkdir someWhatRealWorldApplication
+ pushd someWhatRealWorldApplication
/tmp/someWhatRealWorldApplication /tmp
+ svnadmin create repo
++ pwd
+ svn checkout file:///tmp/someWhatRealWorldApplication/repo wc
Checked out revision 0.
+ echo 'Create basic repo structure'
Create basic repo structure
+ cd wc
+ mkdir branches tags trunk
+ svn add branches tags trunk
A branches
A tags
A trunk
+ svn commit -m 'basic repo structure'
Adding branches
Adding tags
Adding trunk
Committed revision 1.
+ echo 'Navigate to trunk'
Navigate to trunk
+ cd trunk
+ echo 'Create initial project layout'
Create initial project layout
+ mkdir -p Program/foo Program/bar Program/bla
+ svn add Program
A Program
A Program/foo
A Program/bar
A Program/bla
+ svn commit -m 'Initial project layout'
Adding Program
Adding Program/bar
Adding Program/bla
Adding Program/foo
Committed revision 2.
+ echo 'Create integration/team branch structure'
Create integration/team branch structure
+ cd ..
+ cd branches
+ mkdir -p int usr/andy usr/bob usr/charlie usr/david
+ svn add int usr
A int
A usr
A usr/andy
A usr/bob
A usr/charlie
A usr/david
+ svn commit -m 'create integration/team branch structure'
Adding int
Adding usr
Adding usr/andy
Adding usr/bob
Adding usr/charlie
Adding usr/david
Committed revision 3.
+ echo 'initialize integration branch'
initialize integration branch
+ cd int
+ svn cp '^/trunk/Program' Program_rc1
A Program_rc1/foo
A Program_rc1/bar
A Program_rc1/bla
Checked out revision 3.
A Program_rc1
+ svn commit -m 'initialize integration branch'
Adding Program_rc1
Committed revision 4.
+ echo 'create usr branch main line & branch'
create usr branch main line & branch
+ cd ../usr/andy
+ svn cp '^/branches/int/Program_rc1' Program_rc1_main_line
A Program_rc1_main_line/bla
A Program_rc1_main_line/foo
A Program_rc1_main_line/bar
Checked out revision 4.
A Program_rc1_main_line
+ svn cp Program_rc1_main_line Program_rc1_new_feature
A Program_rc1_new_feature
+ svn commit -m 'create usr branch main line & branch'
Adding Program_rc1_main_line
Adding Program_rc1_new_feature
Committed revision 5.
+ echo 'add new feature'
add new feature
+ cd Program_rc1_new_feature
+ mkdir -p treeconflict/burr treeconflict/snburr treeconflict/snurr
+ svn add treeconflict
A treeconflict
A treeconflict/burr
A treeconflict/snburr
A treeconflict/snurr
+ svn commit -m 'add new feature'
Adding treeconflict
Adding treeconflict/burr
Adding treeconflict/snburr
Adding treeconflict/snurr
Committed revision 6.
+ echo 'Perform downstream merging'
Perform downstream merging
+ cd ../Program_rc1_main_line
+ svn up
Updating '.':
At revision 6.
+ svn merge '^/branches/int/Program_rc1' .
--- Recording mergeinfo for merge of r5 through r6 into '.':
U .
+ svn commit -m 'Rebaselining usr/andy main line from integration main line'
Sending .
Committed revision 7.
+ cd ../Program_rc1_new_feature
+ svn up
Updating '.':
At revision 7.
+ svn merge '^/branches/usr/andy/Program_rc1_main_line' .
--- Merging r5 through r7 into '.':
U .
--- Recording mergeinfo for merge of r5 through r7 into '.':
G .
+ svn commit -m 'Rebaselining usr/andy feature from andy'\''s main line'
Sending .
Committed revision 8.
+ cd ../Program_rc1_main_line
+ svn up
Updating '.':
At revision 8.
+ svn merge '^/branches/usr/andy/Program_rc1_new_feature' .
--- Merging differences between repository URLs into '.':
A treeconflict
A treeconflict/snurr
A treeconflict/burr
A treeconflict/snburr
U .
--- Recording mergeinfo for merge between repository URLs into '.':
U .
+ svn commit -m 'Reintegrating usr/andy feature to andy'\''s main line'
Sending .
Adding treeconflict
Committed revision 9.
+ cd ../../../int/Program_rc1
+ svn up
Updating '.':
At revision 9.
+ svn merge '^/branches/usr/andy/Program_rc1_main_line' .
--- Merging differences between repository URLs into '.':
A treeconflict
A treeconflict/snurr
A treeconflict/burr
A treeconflict/snburr
U .
--- Recording mergeinfo for merge between repository URLs into '.':
G .
+ svn commit -m 'Reintegrating usr/andy main line to integration main line'
Sending .
Adding treeconflict
Committed revision 10.
+ echo 'Perform additional downstream merging'
Perform additional downstream merging
+ cd ../../usr/andy/Program_rc1_main_line
+ svn up
Updating '.':
At revision 10.
+ svn merge '^/branches/int/Program_rc1' .
--- Merging differences between repository URLs into '.':
U .
--- Recording mergeinfo for merge between repository URLs into '.':
G .
+ echo 'We have a tree conflict!!!'
We have a tree conflict!!!
+ svn status
M .
$
Re: Merge, reintegrate, and merge with tree conflicts
Posted by James Hanley <jh...@dgtlrift.com>.
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 <st...@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.
Re: Merge, reintegrate, and merge with tree conflicts
Posted by Stefan Sperling <st...@elego.de>.
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.
Re: Merge, reintegrate, and merge with tree conflicts
Posted by James Hanley <jh...@dgtlrift.com>.
I guess I should have read the next response in the thread before replying...
On Feb 24, 2013, at 7:52 AM, Stefan Sperling <st...@elego.de> wrote:
> On Sun, Feb 24, 2013 at 12:14:04PM +0000, Andreas Tscharner wrote:
>>> So what is the proper way to continuously perform the workflow we're
>>> trying to do - that is pull changes from origin path into branch, push
>>> changes to origin branch from branch, and repeat.
>>>
>>> Using bidirectional merge (without reintegrate) seems create severe
>>> merge conflicts.
>>
>> Short answer: There is none (with SVN)
>
> Sorry, not true :) Bidirectional merge is possible with SVN.
>
> Subversion 1.8 will ship with an enhanced 'automatic' merge that
> will make this very easy to do, see
> http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
>
> But it is also possible with 1.7 -- it's just not widely documented
> because the trick for doing it was discovered fairly recently during
> 1.8 development, while the "automatic merge" feature was being developed.
>
> Quoting Julian Foad in http://svn.haxx.se/dev/archive-2012-05/0474.shtml
>
> * To merge again in the same direction as the previous merge
> => the existing "sync" merge will work.
>
> * To merge again in the opposite direction to the previous merge
> => the existing "reintegrate" merge will work.
>
> So whenever switching directions use --reintegrate, and then keep using
> plain 'svn merge' until you change directions again.
> See the rest of Julian's post for details.
>
> If you want to merge in this fashion, you should avoid subtree merges
> (e.g. merging ^/trunk/foo to ^/branches/branch/foo), but always merge all
> changes from the source branch (e.g. from ^/trunk to ^/branches/branch).
>
> You should also avoid cherry-picking merges, i.e. never specify a
> particular revision range to be merged, instead relying on merge-tracking
> to merge all outstanding changes.
>
> Note that both of the above restrictions exist in DVCS by design. So if you
> are already considering DVCS as an alternative these restrictions should
> not be an issue.
>
> Please let us know if this approach works well for you.
>
>> Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk).
>> At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course)
>>
>> If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right?
>>
>> Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try.
>>
>> Best regards
>> WENZEL Metromec AG
>> Andreas Tscharner
>> --
>> Andreas Tscharner, Development
>> WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland
>> phone: +41 (0)81 257 07 00
>> fax: +41 (0)81 257 07 01
>> e-mail: mailto:andreas.tscharner@metromec.ch
>> www: http://www.metromec.ch
Re: Merge, reintegrate, and merge with tree conflicts
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Feb 24, 2013 at 12:14:04PM +0000, Andreas Tscharner wrote:
> > So what is the proper way to continuously perform the workflow we're
> > trying to do - that is pull changes from origin path into branch, push
> > changes to origin branch from branch, and repeat.
> >
> > Using bidirectional merge (without reintegrate) seems create severe
> > merge conflicts.
>
> Short answer: There is none (with SVN)
Sorry, not true :) Bidirectional merge is possible with SVN.
Subversion 1.8 will ship with an enhanced 'automatic' merge that
will make this very easy to do, see
http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
But it is also possible with 1.7 -- it's just not widely documented
because the trick for doing it was discovered fairly recently during
1.8 development, while the "automatic merge" feature was being developed.
Quoting Julian Foad in http://svn.haxx.se/dev/archive-2012-05/0474.shtml
* To merge again in the same direction as the previous merge
=> the existing "sync" merge will work.
* To merge again in the opposite direction to the previous merge
=> the existing "reintegrate" merge will work.
So whenever switching directions use --reintegrate, and then keep using
plain 'svn merge' until you change directions again.
See the rest of Julian's post for details.
If you want to merge in this fashion, you should avoid subtree merges
(e.g. merging ^/trunk/foo to ^/branches/branch/foo), but always merge all
changes from the source branch (e.g. from ^/trunk to ^/branches/branch).
You should also avoid cherry-picking merges, i.e. never specify a
particular revision range to be merged, instead relying on merge-tracking
to merge all outstanding changes.
Note that both of the above restrictions exist in DVCS by design. So if you
are already considering DVCS as an alternative these restrictions should
not be an issue.
Please let us know if this approach works well for you.
> Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk).
> At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course)
>
> If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right?
>
> Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try.
>
> Best regards
> WENZEL Metromec AG
> Andreas Tscharner
> --
> Andreas Tscharner, Development
> WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland
> phone: +41 (0)81 257 07 00
> fax: +41 (0)81 257 07 01
> e-mail: mailto:andreas.tscharner@metromec.ch
> www: http://www.metromec.ch
RE: Merge, reintegrate, and merge with tree conflicts
Posted by Andreas Tscharner <An...@metromec.ch>.
> So what is the proper way to continuously perform the workflow we're
> trying to do - that is pull changes from origin path into branch, push
> changes to origin branch from branch, and repeat.
>
> Using bidirectional merge (without reintegrate) seems create severe
> merge conflicts.
Short answer: There is none (with SVN)
Long(er) answer: We were seeing the same problems here with a similar workflow. We ended up with some rules that actually changed the desired workflow (no merges from trunk to feature branch during development) and caused other problems (big changes when reintegrating the feature branch back to trunk).
At the moment we are evaluating a DVCS (Mercurial in our case) which pretty much solves these problems (we have others of course)
If I had to guess by the words you use (pull, push), I'd say you have already used a DVCS, right?
Our evaluation lasts until the 7th of March, so I cannot say what our results are, but I think a DVCS is worth a try.
Best regards
WENZEL Metromec AG
Andreas Tscharner
--
Andreas Tscharner, Development
WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland
phone: +41 (0)81 257 07 00
fax: +41 (0)81 257 07 01
e-mail: mailto:andreas.tscharner@metromec.ch
www: http://www.metromec.ch
RE: Merge, reintegrate, and merge with tree conflicts
Posted by Bob Archer <Bo...@amsi.com>.
> > So what is the proper way to continuously perform the workflow we're
> > trying to do - that is pull changes from origin path into branch, push
> > changes to origin branch from branch, and repeat.
> >
> > Using bidirectional merge (without reintegrate) seems create severe
> > merge conflicts.
>
>
> You can keep the feature branch alive by doing a record only merge on the
> trunk of the revision which your integrate merge was committed as.
Sorry, this should say:
You can keep the feature branch alive by doing a record only merge on the branch from trunk of the revision which your integrate merge was committed as.
BOb
>
>
>
> BOb
>
>
>
> >
> > On Feb 22, 2013, at 7:22 PM, Matthew Pounsett <ma...@conundrum.com>
> > wrote:
> >
> > >
> > > On 2013/02/22, at 14:15, James Hanley wrote:
> > >
> > >> We are seeing merge tree conflicts where I believe svn is not
> > >> working as expected. I'm not entirely sure if this is due to a
> > >> lack of understanding for proper use on our part, but it was my
> > >> understanding that reintegrate was to be used when pulling changes
> > >> from a branch and pushing them into the copied from branch.
> > >
> > > I asked about this a couple of weeks ago[1] as well. The
> > > explanation I got[2]
> > was that once you've done a --reintegrate, the source of that merge is
> > a dead branch, and cannot be used again. You can demonstrate this
> > much simpler this
> > way:
> > >
> > > cd branches
> > > svn cp ^/trunk ./mybranch
> > > cd mybranch
> > > mkdir foo
> > > svn add foo
> > > svn commit -m "added foo to mybranch"
> > > cd ../../trunk
> > > svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch
> > > svn merge ^/trunk
> > >
> > > As soon as the --reintegrate is done, ^/branches/mybranch is dead.
> > >
> > >
> > > [1]
> > > <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb
> > > ox /%3C01A9EBD6-CE2D-4565-833D-
> 2252CE2E5B71%40conundrum.com%3E>
> > > [2]
> > > <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mb
> > > ox /%3C20130207150922.GC28403%40ted.stsp.name%3E>
RE: Merge, reintegrate, and merge with tree conflicts
Posted by Bob Archer <Bo...@amsi.com>.
> So what is the proper way to continuously perform the workflow we're trying to
> do - that is pull changes from origin path into branch, push changes to origin
> branch from branch, and repeat.
>
> Using bidirectional merge (without reintegrate) seems create severe merge
> conflicts.
You can keep the feature branch alive by doing a record only merge on the trunk of the revision which your integrate merge was committed as.
BOb
>
> On Feb 22, 2013, at 7:22 PM, Matthew Pounsett <ma...@conundrum.com>
> wrote:
>
> >
> > On 2013/02/22, at 14:15, James Hanley wrote:
> >
> >> We are seeing merge tree conflicts where I believe svn is not working
> >> as expected. I'm not entirely sure if this is due to a lack of
> >> understanding for proper use on our part, but it was my understanding
> >> that reintegrate was to be used when pulling changes from a branch
> >> and pushing them into the copied from branch.
> >
> > I asked about this a couple of weeks ago[1] as well. The explanation I got[2]
> was that once you've done a --reintegrate, the source of that merge is a dead
> branch, and cannot be used again. You can demonstrate this much simpler this
> way:
> >
> > cd branches
> > svn cp ^/trunk ./mybranch
> > cd mybranch
> > mkdir foo
> > svn add foo
> > svn commit -m "added foo to mybranch"
> > cd ../../trunk
> > svn merge --reintegrate ^/branches/mybranch cd ../branches/mybranch
> > svn merge ^/trunk
> >
> > As soon as the --reintegrate is done, ^/branches/mybranch is dead.
> >
> >
> > [1]
> > <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox
> > /%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E>
> > [2]
> > <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox
> > /%3C20130207150922.GC28403%40ted.stsp.name%3E>
Re: Merge, reintegrate, and merge with tree conflicts
Posted by James Hanley <jh...@dgtlrift.com>.
So what is the proper way to continuously perform the workflow we're
trying to do - that is pull changes from origin path into branch, push
changes to origin branch from branch, and repeat.
Using bidirectional merge (without reintegrate) seems create severe
merge conflicts.
On Feb 22, 2013, at 7:22 PM, Matthew Pounsett <ma...@conundrum.com> wrote:
>
> On 2013/02/22, at 14:15, James Hanley wrote:
>
>> We are seeing merge tree conflicts where I believe svn is not working
>> as expected. I'm not entirely sure if this is due to a lack of
>> understanding for proper use on our part, but it was my understanding
>> that reintegrate was to be used when pulling changes from a branch and
>> pushing them into the copied from branch.
>
> I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way:
>
> cd branches
> svn cp ^/trunk ./mybranch
> cd mybranch
> mkdir foo
> svn add foo
> svn commit -m "added foo to mybranch"
> cd ../../trunk
> svn merge --reintegrate ^/branches/mybranch
> cd ../branches/mybranch
> svn merge ^/trunk
>
> As soon as the --reintegrate is done, ^/branches/mybranch is dead.
>
>
> [1] <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E>
> [2] <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C20130207150922.GC28403%40ted.stsp.name%3E>
Re: Merge, reintegrate, and merge with tree conflicts
Posted by Matthew Pounsett <ma...@conundrum.com>.
On 2013/02/22, at 14:15, James Hanley wrote:
> We are seeing merge tree conflicts where I believe svn is not working
> as expected. I'm not entirely sure if this is due to a lack of
> understanding for proper use on our part, but it was my understanding
> that reintegrate was to be used when pulling changes from a branch and
> pushing them into the copied from branch.
I asked about this a couple of weeks ago[1] as well. The explanation I got[2] was that once you've done a --reintegrate, the source of that merge is a dead branch, and cannot be used again. You can demonstrate this much simpler this way:
cd branches
svn cp ^/trunk ./mybranch
cd mybranch
mkdir foo
svn add foo
svn commit -m "added foo to mybranch"
cd ../../trunk
svn merge --reintegrate ^/branches/mybranch
cd ../branches/mybranch
svn merge ^/trunk
As soon as the --reintegrate is done, ^/branches/mybranch is dead.
[1] <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C01A9EBD6-CE2D-4565-833D-2252CE2E5B71%40conundrum.com%3E>
[2] <http://mail-archives.apache.org/mod_mbox/subversion-users/201302.mbox/%3C20130207150922.GC28403%40ted.stsp.name%3E>