Re: Symmetric merge and subtrees

On Thu, Aug 2, 2012 at 10:45 AM, Julian Foad wrote: > Hi Paul. > > Thanks for looking at this and the other ('deleted subtrees') thread. > Replies in line below... > > > Paul Burba wrote: >> Julian Foad wrote: >>> There are some merge scenarios for which it's not clear whether the >>> user shou

Re: Symmetric merge and deleted subtrees

I (Julian Foad) wrote: > I have only had a chance to skim through your reply so far.  I'm glad that > you find it to be an explicable and harmless difference. OK, I follow your explanation and agree; thanks.  I have closed the isse #4217. In investigating this, I tried your suggestion of doing

Re: Symmetric merge and deleted subtrees

Hi Paul. I have only had a chance to skim through your reply so far.  I'm glad that you find it to be an explicable and harmless difference. I have assigned Issue #4217 to track this, as I want to be able to refer to it before having a chance to study your reply properly. - Julian Paul Burb

Re: Symmetric merge and subtrees

Hi Paul. Thanks for looking at this and the other ('deleted subtrees') thread.  Replies in line below... Paul Burba wrote: > Julian Foad wrote: >>  There are some merge scenarios for which it's not clear whether the >> user should specify '--reintegrate' or not.  We need to decide what the >>

Re: Symmetric merge and deleted subtrees

On Tue, Jul 31, 2012 at 1:50 PM, Julian Foad wrote: > I'm investigating a discrepancy that shows up, when 'symmetric merge' is > enabled [1], in the notifications printed by some merges. Merge_tests 78 > fails because the expected notification for the last merge is: > > --- Merging r6 through r

Re: Symmetric merge and subtrees

On Tue, Jul 17, 2012 at 1:28 PM, Julian Foad wrote: > There are some merge scenarios for which it's not clear whether the user > should specify '--reintegrate' or not. We need to decide what the > 'symmetric' (i.e. automatically-choosing) code should do in those cases. > > The following example

Re: Symmetric merge and subtrees

I (Julian Foad) wrote: > Investigating the second of three 'symmetric merge' test failures: > >   merge_reintegrate_tests.py 10 > > There is a definite issue concerning reverse merges from the branches' own > history.  In this test, the merge that behaves unexpectedly is the final > 'reintegrat

Re: Symmetric merge and subtrees

Investigating the second of three 'symmetric merge' test failures:   merge_reintegrate_tests.py 10 There is a definite issue concerning reverse merges from the branches' own history.  In this test, the merge that behaves unexpectedly is the final 'reintegrate' shown in the following graph (whic

Re: Symmetric Merge -- status

(Just finishing an unfinished sentence...) I (Julian Foad) wrote: > I (Julian Foad) wrote: >> This is great.  You're right, the main thing seems to be that >> find_symmetric_merge is currently only fetching and analyzing >> the branch-root mergeinfo.  It needs to fetch and analyze all >> mer

Re: Symmetric Merge -- status

I (Julian Foad) wrote: > This is great.  You're right, the main thing seems to be that > find_symmetric_merge is currently only fetching and analyzing > the branch-root mergeinfo.  It needs to fetch and analyze all > mergeinfo on the branch, finding a merge base for each subtree, > and proceed som

Re: Symmetric Merge -- status

Thanks, Paul! This is great.  You're right, the main thing seems to be that find_symmetric_merge is currently only fetching and analyzing the branch-root mergeinfo.  It needs to fetch and analyze all mergeinfo on the branch, finding a merge base for each subtree, and proceed something like this

Re: Symmetric Merge -- status

On Fri, May 25, 2012 at 12:08 PM, Julian Foad wrote: > Hi, all. > > I want to update you all on the "symmetric merge" [1] status and my plans, > and invite your thoughts and any assistance you can give. > > I'll be presenting this subject at Elego's SvnDay [2] and at WANdisco events > in October,

Re: Symmetric merge -- current test failures when enabled

- Original Message - > From: Branko Čibej > To: dev@subversion.apache.org > Cc: > Sent: Thursday, 10 May 2012, 8:58 > Subject: Re: Symmetric merge -- current test failures when enabled > > On 10.05.2012 09:36, Julian Foad wrote: >> Branko Čibej wrote: >>&g

Re: Symmetric merge -- current test failures when enabled

On 10.05.2012 09:36, Julian Foad wrote: > Branko Čibej wrote: >> On 09.05.2012 18:54, Julian Foad wrote: >>> The second group concerns merging changes into a file from its own (past >>> or >> future) history; this kind of merge isn't a 'sync' so shouldn't >> be handled by this code path. >> >>

Re: Symmetric merge -- current test failures when enabled

Branko Čibej wrote: > On 09.05.2012 18:54, Julian Foad wrote: >> The second group concerns merging changes into a file from its own (past or > future) history; this kind of merge isn't a 'sync' so shouldn't > be handled by this code path. > > We keep coming back to this ... I still don't unders

Re: Symmetric merge -- current test failures when enabled

On 09.05.2012 18:54, Julian Foad wrote: > The second group concerns merging changes into a file from its own (past or > future) history; this kind of merge isn't a 'sync' so shouldn't be handled by > this code path. We keep coming back to this ... I still don't understand /why/ we would need mor

Re: Symmetric merge -- tests

> Heads-up: I've added a test suite file, 'merge_symmetric_tests.py'.  Stefan^2, Cristian, Oleksiy... maybe you'd like to help out with this? This test file starts with depictions of the scenarios we're aiming to address.  So far, this is what I've come up with: #   Merge once # # A (--?-

Re: Symmetric Merge -- switched subtrees [was: no local mods or switched subtrees by default]

On Fri, Apr 20, 2012 at 1:12 PM, Julian Foad wrote: > Hi Paul, just one clarification request on a very brief skimmed reading: > >>     * If the incoming change deletes the path SS, then it is interpreted as >> deleting the entry SS from SSP's list of children. >> >> Correct, SS@BASE is deleted, *

Re: Symmetric Merge -- switched subtrees [was: no local mods or switched subtrees by default]

Hi Paul, just one clarification request on a very brief skimmed reading: >    * If the incoming change deletes the path SS, then it is interpreted as > deleting the entry SS from SSP's list of children. > > Correct, SS@BASE is deleted, *but* the repository location represented > by the switched

Re: Symmetric Merge -- Algorithm

Cristian Amarie wrote: >> [...] You are talking about any graph consisting of a sequence >> of 'complete' merges[1] between the >> two branches A and B.  Is this a concrete example, where n=2 and m=3? >> >>     / -- p q - A1 -- s - A2 >>   O       \      \  /      \      / >>

Re: Symmetric Merge -- switched subtrees [was: no local mods or switched subtrees by default]

On Fri, Apr 20, 2012 at 5:36 AM, Julian Foad wrote: > Paul Burba wrote on 27 March 2012: >> Julian Foad wrote: >>>  The check for switched subtrees:  I think we should enable this by default. >>> >>>  I suppose the issue here must be that we don't have a compelling use >>> case for supporting such

Re: Symmetric Merge -- Algorithm

> Hi Cristian.  First, let me see if I understand you.  You are talking about > any graph consisting of a sequence of 'complete' merges[1] between the > two branches A and B.  Is this a > concrete example, where n=2 and m=3? > >     / -- p q - A1 -- s - A2 >   O       \      \  /  

Re: Symmetric Merge -- Algorithm

I (Julian Foad) wrote: > Cristian Amarie wrote: > >>>   1. Find the latest rev of A synced to B and of B synced to A. >>>   2. Choose a base. >> For me 2 this is an important point regarding obtaining of the same >> result. >> >> Having >>   / A1 ... Ax ... An-1  -> An  (merge B into A pro

Re: Symmetric Merge -- Algorithm

Cristian Amarie wrote: >>   1. Find the latest rev of A synced to B and of B synced to A. >>   2. Choose a base. > For me 2 this is an important point regarding obtaining of the same > result. > > Having >   / A1 ... Ax ... An-1  -> An  (merge B into A produces An) > O >   \ B1 ... By ... Bm-1 ->

Re: Symmetric Merge -- switched subtrees [was: no local mods or switched subtrees by default]

Paul Burba wrote on 27 March 2012: > Julian Foad wrote: >> The check for switched subtrees:  I think we should enable this by default. >> >> I suppose the issue here must be that we don't have a compelling use >> case for supporting such a merge, and so we haven't defined and don't >> want to

Re: Symmetric Merge -- Algorithm

I've been splitting between been a svn baby/trying to swim into svn code and reading the wiki plus mails regarding symmetric merge. (Please be patient if I'll bump into some inherent beginner stupidities, I'm still into the crash course phase). > 1. Find the latest rev of A synced to B and of B s

Re: Symmetric Merge -- Algorithm

Paul Burba wrote: > Julian Foad wrote: >> I have written out how I think a large part of the symmetric merge >> algorithm should go, in more detail.  Review and other feedback would >> be welcome. [...] >> At this point I haven't included processing of subtree mergeinfo in >> the algorithm de

Re: Symmetric Merge -- Algorithm

My motive is not PR. My motive is very specifically, this: I would like to have a subversion merge that supports a modern code review workflow. You commit to a branch, someone else reviews the commit, and merges it into a shared build. If I can add that to my app, it helps all of my svn us

Re: Symmetric Merge -- Algorithm

On 04/17/2012 02:29 PM, Branko Čibej wrote: > On 17.04.2012 18:40, Andy Singleton wrote: >> It sounds like there is a clear choice for the first release of >> Julian's Symmetric Merge project: >> 1) Add "symmerge" as a new command and leave the existing merge in place, >> 2) or try to replace the

Re: Symmetric Merge -- Algorithm

On 17.04.2012 18:40, Andy Singleton wrote: > It sounds like there is a clear choice for the first release of > Julian's Symmetric Merge project: > 1) Add "symmerge" as a new command and leave the existing merge in place, > 2) or try to replace the existing merge in one shot for all existing > user

Re: Symmetric Merge -- Algorithm

It sounds like there is a clear choice for the first release of Julian's Symmetric Merge project: 1) Add "symmerge" as a new command and leave the existing merge in place, 2) or try to replace the existing merge in one shot for all existing users. If you asked me to try to replace all of the op

Re: Symmetric Merge -- Algorithm

On Tue, Apr 17, 2012 at 11:52 AM, Andy Singleton wrote: >  On 4/17/2012 11:38 AM, Paul Burba wrote: >> >> On Mon, Apr 16, 2012 at 12:25 PM, Julian Foad >>  wrote: >>> >>> I have written out how I think a large part of the symmetric merge >>> algorithm should go, in more detail.  Review and other f

Re: Symmetric Merge -- Algorithm

On 4/17/2012 11:38 AM, Paul Burba wrote: On Mon, Apr 16, 2012 at 12:25 PM, Julian Foad wrote: I have written out how I think a large part of the symmetric merge algorithm should go, in more detail. Review and other feedback would be welcome. We need to write out the algorithm in this level o

Re: Symmetric Merge -- Algorithm

On Mon, Apr 16, 2012 at 12:25 PM, Julian Foad wrote: > I have written out how I think a large part of the symmetric merge > algorithm should go, in more detail.  Review and other feedback would > be welcome. > > We need to write out the algorithm in this level of detail and a > little more detail,

Re: Symmetric Merge - status

>> Julian Foad wrote: >>>   I'm pleased to be able to say that as of this weekend we can welcome >>>   three more people -- Stefan Fuhrmann and Cristian Camerin and Oleksiy >>>   Suschuk [...] >> >> Welcome aboard! > > Correction: it's "Cristian Amarie" (IRC name: camerin). Correction 2: it's

Re: Symmetric Merge - status

C. Michael Pilato wrote: > Julian Foad wrote: >> I'm pleased to be able to say that as of this weekend we can welcome >> three more people -- Stefan Fuhrmann and Cristian Camerin and Oleksiy >> Suschuk [...] > > Welcome aboard! Correction: it's "Cristian Amarie" (IRC name: camerin). - Julian

Re: Symmetric Merge - status

On 04/02/2012 11:02 AM, Julian Foad wrote: > I'm pleased to be able to say that as of this weekend we can welcome > three more people -- Stefan Fuhrmann and Cristian Camerin and Oleksiy > Suschuk -- who are all now getting involved with this work. They are all > working for Assembla and have just

Re: Symmetric Merge - status

On Mon, Apr 02, 2012 at 04:02:03PM +0100, Julian Foad wrote: > New People > > > I'm pleased to be able to say that as of this weekend we can welcome three > more people -- Stefan Fuhrmann and Cristian Camerin and Oleksiy Suschuk -- > who are all now getting involved with this work.  They are al

Re: Symmetric Merge

On Mon, Mar 26, 2012 at 1:52 PM, Julian Foad wrote: > Mark Phippard wrote: > >> I have been doing some simple playing around merging back and forth >> between a simulated branch and trunk.  Overall, it seems to work >> pretty nicely. > > Thanks for trying it and reporting back, Mark! > >> One thin

Re: Symmetric Merge

On Wed, Mar 28, 2012 at 3:40 AM, Julian Foad wrote: > Paul Burba wrote: > >> I tweaked run_and_verify_svn2 in a manner similar to what you did to >> run_and_verify_merge.  This picks up a lot of other 'svn merge' uses >> and several test failures.  These failures fall into 4 basic >> categories as

Re: Symmetric Merge

Paul Burba wrote: > I tweaked run_and_verify_svn2 in a manner similar to what you did to > run_and_verify_merge.  This picks up a lot of other 'svn merge' uses > and several test failures.  These failures fall into 4 basic > categories as detailed below.  I'll be trying some ad hoc testing > tomor

Re: Symmetric Merge

On Thu, Mar 22, 2012 at 5:36 AM, Julian Foad wrote: > If anyone wants to try the new symmetric merge code, it's basically in > place.  It's not finished.  It's enabled with '--symmetric' command-line > option.  I've just tried running it in place of 'reintegrate, using the > following patch to

Re: Symmetric Merge -- no local mods or switched subtrees by default

On Tue, Mar 27, 2012 at 5:14 AM, Julian Foad wrote: > Branko Čibej wrote: >> Perhaps we had a bit of a misunderstanding here ... My point was, the >> checks you mention have to always happen, not just optionally happen if >> one uses the (by now quite misnamed) --reintegrate option. I'm not >> arg

Re: Symmetric Merge -- no local mods or switched subtrees by default

On Tue, Mar 27, 2012 at 10:14:31AM +0100, Julian Foad wrote: > Oh, OK, at least we're clear now!  So, my views... [...] > Thoughts? I agree.

Re: Symmetric Merge -- no local mods or switched subtrees by default

Branko Čibej wrote: > Perhaps we had a bit of a misunderstanding here ... My point was, the > checks you mention have to always happen, not just optionally happen if > one uses the (by now quite misnamed) --reintegrate option. I'm not > arguing against sanity checks, quite the opposite, I'm arguing

Re: Symmetric Merge

On 26.03.2012 13:11, Julian Foad wrote: > Mike Dixon wrote: > >> It's nice that svn will be able to handle more complicated merges >> in the future, but please don't remove the existing checks on standard >> operations that protect me from my own ignorance. >> >> I'm also the svn administrator at

Re: Symmetric Merge

Mark Phippard wrote: > I have been doing some simple playing around merging back and forth > between a simulated branch and trunk.  Overall, it seems to work > pretty nicely. Thanks for trying it and reporting back, Mark! > One thing I noticed (not sure if I would call this a problem but maybe >

Re: Symmetric Merge

On Thu, Mar 22, 2012 at 5:36 AM, Julian Foad wrote: > If anyone wants to try the new symmetric merge code, it's basically in > place.  It's not finished.  It's enabled > with '--symmetric' command-line option. I have been doing some simple playing around merging back and forth between a simulat

Re: Symmetric Merge

Mike Dixon wrote: > On 3/22/2012 10:19 PM, Branko Čibej wrote: >> On 22.03.2012 22:33, Julian Foad wrote: >>> Branko Čibej wrote: I'm confused. What additional checks would --reintegrate do that your common or garden merge would skip? What kind of check do you think you can saf

Re: Symmetric Merge

On Fri, Mar 23, 2012 at 10:55:45AM -0700, Mike Dixon wrote: > On 3/22/2012 10:19 PM, Branko Čibej wrote: > >On 22.03.2012 22:33, Julian Foad wrote: > >>Branko Čibej wrote: > >>>I'm confused. What additional checks would --reintegrate do that your > >>>common or garden merge would skip? What kind of

Re: Symmetric Merge

On 3/22/2012 10:19 PM, Branko Čibej wrote: On 22.03.2012 22:33, Julian Foad wrote: Branko Čibej wrote: I'm confused. What additional checks would --reintegrate do that your common or garden merge would skip? What kind of check do you think you can safely skip without throwing all the effort you

Re: Symmetric Merge

On 22.03.2012 22:33, Julian Foad wrote: > Branko Čibej wrote: >> I'm confused. What additional checks would --reintegrate do that your >> common or garden merge would skip? What kind of check do you think you >> can safely skip without throwing all the effort you're putting into >> fixing the merge

Re: Symmetric Merge

>> Julian Foad wrote: >>> I suggest we should leave the --reintegrate option available, >>> meaning "do stricter checks", and after doing the checks >>> it will run the symmetric merge code.  Currently the checks >>> are "no local mods" and "no switched subtrees" >>> and "no cherry picks"[

Re: Symmetric Merge

On 22.03.2012 17:16, Mark Phippard wrote: > On Thu, Mar 22, 2012 at 12:12 PM, Julian Foad > wrote: >> I suggest we should leave the --reintegrate option available, meaning "do >> stricter checks", and after doing the checks >> it will run the symmetric merge code. Currently the checks are "no lo

Re: Symmetric Merge

On Thu, Mar 22, 2012 at 12:12 PM, Julian Foad wrote: > I suggest we should leave the --reintegrate option available, meaning "do > stricter checks", and after doing the checks > it will run the symmetric merge code.  Currently the checks are "no local > mods" and "no switched subtrees" > and "no

Re: Symmetric Merge

Mark Phippard wrote: > Julian Foad wrote: >> By the way, my intent is to remove the '--symmetric' option and >> have the code just run inside the original 'sync' and >> 'reintegrate' code paths.  There's no reason, other than for >> testing, to expose this at the UI. > > I assume the plan is

Re: Symmetric Merge

On Thu, Mar 22, 2012 at 6:05 AM, Julian Foad wrote: > By the way, my intent is to remove the '--symmetric' option and have the code > just run inside the original 'sync' and > 'reintegrate' code paths.  There's no reason, other than for testing, to > expose this at the UI. I assume the plan is

Re: Symmetric Merge

I'll use it for the merges I run myself --- but I don't use 'svn merge' very often. Julian Foad wrote on Thu, Mar 22, 2012 at 09:36:44 +: > If anyone wants to try the new symmetric merge code, it's basically in > place.  It's not finished.  It's enabled with '--symmetric' command-line > opti

Re: Symmetric Merge

I (Julian Foad) wrote: > By the way, my intent is to remove the '--symmetric' option and have the > code just run inside the original 'sync' and 'reintegrate' code > paths.  There's no reason, other than for testing, to expose this at the UI. >> >> If anyone wants to try the new symmetric merg

Re: Symmetric Merge

By the way, my intent is to remove the '--symmetric' option and have the code just run inside the original 'sync' and 'reintegrate' code paths.  There's no reason, other than for testing, to expose this at the UI. - Julian - Original Message - > From: Julian Foad > To: SubversionDeve

Re: Symmetric Merge -- Wiki page

On 02.03.2012 09:45, Justin Erenkrantz wrote: > For branches that tend to be reintegrate targets - feature work on a > short or long-lived branch - I tend to see it's a different pattern > and doesn't usually involve cherry-picks - it's more the > sync/reintegrate model with complete merges you've

Re: Symmetric Merge -- Wiki page

On 27.02.2012 14:15, Julian Foad wrote: > As many of you are aware I've been looking at improving merge in various > ways. I'd like to ask for feedback at this stage on the Wiki page > (renamed from > SvnMergeTheory). The essential point is th

Re: Symmetric Merge -- Wiki page

On Mon, Feb 27, 2012 at 5:15 AM, Julian Foad wrote: > As many of you are aware I've been looking at improving merge in various > ways.  I'd like to ask for feedback at this stage on the Wiki page > (renamed from > SvnMergeTheory).  The essentia

Re: Symmetric Merge -- Wiki page

Stefan Sperling wrote: > Julian Foad wrote: >> >> >> How much of what I've written makes sense?  I know it could do with >> much more detailed worked examples, with concrete Subversion commands >> and output to prove the connection between th

Re: Symmetric Merge -- Wiki page

On Mon, Feb 27, 2012 at 01:15:30PM +, Julian Foad wrote: > As many of you are aware I've been looking at improving merge in > various ways.  I'd like to ask for feedback at this stage on the Wiki > page (renamed from > SvnMergeTheory).  The ess