Re: Implicit keep-alive after reintegrate merge

On 31.01.2012 12:08, Julian Foad wrote: > (I'm assuming that your b@r2 in this example is a simple copy with no diff, > otherwise the first part of 'merge 3' should use a@r1 instead of b@r2 for > its base.) > > But no, merge 3 should be even simpler than that. We don't have to go and > fetch th

Re: Implicit keep-alive after reintegrate merge

I agree that a symmetric merge algorithm would suffice for both 'sync' and 'reintegrate' merges. I'm starting to write this up here: . Subversion's current merge implementation makes assumptions in both the 'sync' and 'reintegrate' cases.  (Th

Re: Implicit keep-alive after reintegrate merge

On 30.01.2012 22:19, Stefan Sperling wrote: > On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote: >> No, AFAIU, Brane's suggestion was not that we shouldn't use the >> "reintegrate-way" for 3.2, but rather that we should *always* use the >> "reintegrate-way", also for sync merges. So t

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 11:16 PM, Stefan Sperling wrote: > On Mon, Jan 30, 2012 at 10:37:51PM +0100, Johan Corveleyn wrote: >> On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling wrote: >> > But you cannot use the last-synced revision as left anchor either: >> >  svn co b >> >  svn merge b@r4 a@r6

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 10:37:51PM +0100, Johan Corveleyn wrote: > On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling wrote: > > But you cannot use the last-synced revision as left anchor either: > >  svn co b > >  svn merge b@r4 a@r6 b > > Because applying this delta reverts b@r5 (this change appe

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling wrote: > On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote: >> No, AFAIU, Brane's suggestion was not that we shouldn't use the >> "reintegrate-way" for 3.2, but rather that we should *always* use the >> "reintegrate-way", also for syn

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote: > No, AFAIU, Brane's suggestion was not that we shouldn't use the > "reintegrate-way" for 3.2, but rather that we should *always* use the > "reintegrate-way", also for sync merges. So that a sync merge picks > its arguments for the 2-

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 2:23 PM, Stefan Sperling wrote: > On Tue, Jan 24, 2012 at 01:12:39AM +0100, Branko Čibej wrote: >> By the way, I read Stefan's description of why --reintegrate is >> necessary, and after slogging through the unfortunate terminology (2-URL >> merge doesn't mean a thing in CM

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 10:01:23AM -0500, Mark Mielke wrote: > No merge is perfect. The situation is either complex, or it is not > complex - and moving resolution to the private branch is a matter of > process - not a matter of algorithm. Where did you get the idea that conflict resolution must h

Re: Implicit keep-alive after reintegrate merge

Stefan: I believe you are agreeing that the merge in either direction is the same complexity, and describing how --reintegrate moves the responsibility for the complexity to the owner of the private branch, and requires resolution before submission. I think you are saying this is a good thing b

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 02:23:46PM +0100, Stefan Sperling wrote: > What we use during --reintegrate is (3.2 b). And here I'm catching myself spreading misinformation again. There is another tweak we use during reintegrate. Consider the graph again (fixed version): (3) +-b@

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 02:23:46PM +0100, Stefan Sperling wrote: > (3) > +-b@r2--+ b@r3--b@r4-b@r5 > (branch) /^ | (merge 2) > / | (merge 1) v > --- a@r1 --a@r2---+- a@r6 > > Merge 1 brings a@r2 in

Re: Implicit keep-alive after reintegrate merge

On Tue, Jan 24, 2012 at 01:12:39AM +0100, Branko Čibej wrote: > By the way, I read Stefan's description of why --reintegrate is > necessary, and after slogging through the unfortunate terminology (2-URL > merge doesn't mean a thing in CM theory :) and one little bit caught my > attention: > > > A

Re: Implicit keep-alive after reintegrate merge

On 23.01.2012 18:53, Julian Foad wrote: > I've committed my latest version of this work to the new > 'reintegrate-keep-alive' branch in r1234919. > > I'm working on explaining how this stuff relates to ClearCase's model and the > need or non-need for a difference between "reintegrate" and "normal

Re: Implicit keep-alive after reintegrate merge

I've committed my latest version of this work to the new 'reintegrate-keep-alive' branch in r1234919. I'm working on explaining how this stuff relates to ClearCase's model and the need or non-need for a difference between "reintegrate" and "normal" merges in Subversion. - Julian

Re: Implicit keep-alive after reintegrate merge

On 20.01.2012 12:20, Mark Mielke wrote: > I know that Subversion has these limitations compared to ClearCase: > > 1) Merge tracking is done at a commit level rather than at a per file > or directory level. This means more complex analysis as the per commit > information is "lossy" compared to what

Re: Implicit keep-alive after reintegrate merge

On 01/20/2012 05:40 AM, Daniel Shahaf wrote: Sure, here it is: 12:37:24 @danielsh | wayita: reintegrate? .. 12:37:25wayita | danielsh: If you want to know why --reintegrate is necessary, see http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3c20110720124721.ga7...@ted.st

Re: Implicit keep-alive after reintegrate merge

Branko Čibej wrote on Fri, Jan 20, 2012 at 09:52:34 +0100: > On 20.01.2012 03:23, Daniel Shahaf wrote: > > To rule out the common case: are you familiar with Stefan's post giving > > a reasons for this? > > Nope. > > > His argument is that 'cd trunk-wc && svn merge ^/branches/feature-branch' > >

Re: Implicit keep-alive after reintegrate merge

On 20.01.2012 03:23, Daniel Shahaf wrote: > To rule out the common case: are you familiar with Stefan's post giving > a reasons for this? Nope. > His argument is that 'cd trunk-wc && svn merge ^/branches/feature-branch' > and 'cd 1.7.x-wc && svn merge ^/trunk' are syntactically indistinguishable

Re: Implicit keep-alive after reintegrate merge

Branko Čibej wrote on Thu, Jan 19, 2012 at 20:11:25 +0100: > On 19.01.2012 15:38, Julian Foad wrote: > > Branko Čibej wrote: > > > >> Instead of trying to invent ways to not make current reintegrate suck > >> rocks, I'd suggest taking a look at how other tools handle such repeated > >> merges betwe

Re: Implicit keep-alive after reintegrate merge

On 19.01.2012 15:38, Julian Foad wrote: > Branko Čibej wrote: > >> Instead of trying to invent ways to not make current reintegrate suck >> rocks, I'd suggest taking a look at how other tools handle such repeated >> merges between branches. Specifically, since git afficionados have so >> much to sa

Re: Implicit keep-alive after reintegrate merge

Branko Čibej wrote: > On 18.01.2012 23:37, Julian Foad wrote: >> [...] there are certain simple >> changes that the three-way text merge function will detect as "looks >> like that change has already been made here" and auto-resolve it as a >> no-op, but that's beside the point. > > I don't th

Re: Implicit keep-alive after reintegrate merge

Paul Burba wrote on 2012-01-11: > A random thought about your patch: The skip/stop logic kicks in when > performing a cherry pick merge.  It might be better if it only applies > when doing sync merges.  Reasoning: If a user explicitly states the > revisions she wants to merge, I think we should as

Re: Implicit keep-alive after reintegrate merge

On 18.01.2012 23:37, Julian Foad wrote: > Branko Čibej wrote: > >> On 18.01.2012 14:45, Julian Foad wrote: A@1---r4---r5---r6---r7r11---> |\ ^ | | \ | | | \

Re: Implicit keep-alive after reintegrate merge

Branko Čibej wrote: > On 18.01.2012 14:45, Julian Foad wrote: >>> A@1---r4---r5---r6---r7r11---> >>>   |\                                    ^          | >>>   | \                                   |          | >>>   |  \                              reintegrate    |

Re: Implicit keep-alive after reintegrate merge

On 18.01.2012 14:45, Julian Foad wrote: >> A@1---r4---r5---r6---r7r11---> >> |\ ^ | >> | \| | >> | \ reintegrate | >> | V

Re: Implicit keep-alive after reintegrate merge

Paul Burba wrote: > Julian Foad wrote: >> I describe the idea of "logical changes" in >> . > > Most of the ideas there make sense, though I'm a bit foggy as to how > the mergeinfo format will change and how we'll migrate existing > repositor

Re: Implicit keep-alive after reintegrate merge

On Wed, Jan 18, 2012 at 8:45 AM, Julian Foad wrote: > Hi Paul. > > Paul Burba wrote: > >> Julian Foad wrote: >>> I (Julian Foad) wrote: >> I think I understand now.  Your patch works fine when the only cyclic >> merges are done via reintegrate (i.e. r24). > > [...] > >> I thought you were going to

Re: Implicit keep-alive after reintegrate merge

I (Julian Foad) wrote: [] > What do we want in this case?  The options are basically: > >   (1) try to merge (as we do now), despite knowing it will conflict; >   (2) skip r11 (not usually good in this kind of case); Two clarifications: The options I'm listing are all the options that I thi

Re: Implicit keep-alive after reintegrate merge

Hi Paul. Paul Burba wrote: > Julian Foad wrote: >> I (Julian Foad) wrote: > I think I understand now.  Your patch works fine when the only cyclic > merges are done via reintegrate (i.e. r24). [...] > I thought you were going to tackle more complex reflective merge > cases, such as this example:

Re: Implicit keep-alive after reintegrate merge

On Tue, Jan 17, 2012 at 10:12 AM, Julian Foad wrote: > I (Julian Foad) wrote: >> I think merge_reintegrate_tests.py 19 demonstrates it better than 1000 words >> so >> I'll leave it at that for today. > > For people who'd like to follow along without having to apply and run the > patch, that test

Re: Implicit keep-alive after reintegrate merge

I (Julian Foad) wrote: > I think merge_reintegrate_tests.py 19 demonstrates it better than 1000 words > so > I'll leave it at that for today. For people who'd like to follow along without having to apply and run the patch, that test does: Rev  A A_COPY | 02   |--cp-->X # every X i

Re: Implicit keep-alive after reintegrate merge

I'll leave it at that for today. I'll respond to your last response (below) maybe tomorrow. - Julian - Original Message - > From: Paul Burba > To: Julian Foad > Cc: "dev@subversion.apache.org" > Sent: Wednesday, 11 January 2012, 19:57 > Subject: R

Re: Implicit keep-alive after reintegrate merge

On Wed, Jan 11, 2012 at 7:43 AM, Julian Foad wrote: > Hi Paul.  Thanks for your thoughts. > > Paul Burba wrote: > >> Julian Foad wrote: >>>  We can say for sure that when we reintegrated B to A (in A:40), that >>> will have added new mergeinfo on A describing merges from B.  However, >>> if change

Re: Implicit keep-alive after reintegrate merge

Hi Paul.  Thanks for your thoughts. Paul Burba wrote: > Julian Foad wrote: >> We can say for sure that when we reintegrated B to A (in A:40), that >> will have added new mergeinfo on A describing merges from B.  However, >> if change A:40 had instead been a different merge into A, let's say >

Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 9, 2012 at 6:14 AM, Julian Foad wrote: > Merging would be simpler if the user didn't have to think about doing the > "keep-alive dance" after a reintegrate [1]. > > I'm trying to teach the sync merge to detect when a reintegrate has been > done, so that we could avoid the need for r4