C. Michael Pilato wrote:
> On 07/11/2012 09:12 AM, Branko Čibej wrote:
>> That is correct. Essentially, not only does the server have to know
>> about and correctly record renames; the rename operations in the update
>> (or merge) editor drive need to happen in the correct order so that they
>>
On 07/11/2012 09:12 AM, Branko Čibej wrote:
> That is correct. Essentially, not only does the server have to know
> about and correctly record renames; the rename operations in the update
> (or merge) editor drive need to happen in the correct order so that they
> can be reflected in the working co
On Wed, Jul 11, 2012 at 7:44 AM, Julian Foad wrote:
> Branko Čibej wrote:
>> On 10.07.2012 23:40, Julian Foad wrote:
>>> I think the essence of this line of thought is:
>
>>>
>>> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
>>> does, and we see what 1.7 'merge --rein
On 11.07.2012 13:43, Johan Corveleyn wrote:
> On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad
> wrote:
> ...
>> I just want to say: I'm not at all demanding we break backward
>> compatibility. Sorry if it sounded like it. I'm just saying that we're
>> proposing to change the behaviour of the plain
On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad wrote:
...
> I just want to say: I'm not at all demanding we break backward
> compatibility. Sorry if it sounded like it. I'm just saying that we're
> proposing to change the behaviour of the plain merge command, and in doing
> that we need to work ou
On 11.07.2012 12:44, Julian Foad wrote:
> Branko Čibej wrote:
>> Am I correct in assuming that most of this discussion is a consequence
>> of the current implementation of mergeinfo inheritance? I.e., that there
>> are a certain number of hoops one needs to jump through in order to
>> determine whi
Johan Corveleyn wrote:
> On Wed, Jul 11, 2012 at 6:19 AM, Branko Čibej wrote:
>> Am I correct in assuming that most of this discussion is a consequence
>> of the current implementation of mergeinfo inheritance? I.e., that there
>> are a certain number of hoops one needs to jump through in order
Branko Čibej wrote:
> On 10.07.2012 23:40, Julian Foad wrote:
>> I think the essence of this line of thought is:
>>
>> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
>> does, and we see what 1.7 'merge --reintegrate' does, and we debate what
>> cases are 'supported' v
On Wed, Jul 11, 2012 at 6:19 AM, Branko Čibej wrote:
> On 10.07.2012 23:40, Julian Foad wrote:
>> I think the essence of this line of thought is:
>>
>> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
>> does, and we see what 1.7 'merge --reintegrate' does, and we debate
On 10.07.2012 23:40, Julian Foad wrote:
> I think the essence of this line of thought is:
>
> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
> does, and we see what 1.7 'merge --reintegrate' does, and we debate what
> cases are 'supported' versus knowingly 'unsupported
-
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
- Original Message -
> From: Julian Foad
> To: Paul Burba
> Cc: Subversion Development ; C. Michael Pilato
> ; Branko Čibej ; Stefan Sperling
>
> Sent: Tuesday, 10
Hi Paul. Thanks for your comments.
Paul Burba wrote:
> On Mon, Jul 9, 2012 at 4:16 PM, Julian Foad wrote:
[...]
>> * The merging history of the root 'R' (the root node of the
>> requested merge source and target trees), and of a subtree 'S' (a
>> single node or subtree
>
> Minor point: I'v
On Mon, Jul 9, 2012 at 4:16 PM, Julian Foad wrote:
> To move forward and decide what behaviour is right, we need to be able to
> compare the 1.7 behaviour with the proposed behaviour in *specific*
> scenarios. So we need to be able to enumerate the specific scenarios that we
> mean by the gene
To move forward and decide what behaviour is right, we need to be able to
compare the 1.7 behaviour with the proposed behaviour in *specific* scenarios.
So we need to be able to enumerate the specific scenarios that we mean by the
general term "merging with subtree mergeinfo". This is what I a
Subversion Development
>; Paul Burba ; Branko Čibej
>
>Sent: Thursday, 21 June 2012, 14:29
>Subject: Re: Subtree mergeinfo -- what I learnt at the Hackathon
>
>On Wed, Jun 20, 2012 at 10:07:18PM -0400, C. Michael Pilato wrote:
>> On 06/20/2012 01:25 PM, Stefan Sperling wrote
On Wed, Jun 20, 2012 at 10:07:18PM -0400, C. Michael Pilato wrote:
> On 06/20/2012 01:25 PM, Stefan Sperling wrote:
> >> (Sorry if the above reads like a cranky old-timer putting the brakes on
> >> progress -- I trust you know that's not my intent.)
> >
> > But it doesn't help much to say somethin
On 06/20/2012 01:25 PM, Stefan Sperling wrote:
>> (Sorry if the above reads like a cranky old-timer putting the brakes on
>> progress -- I trust you know that's not my intent.)
>
> But it doesn't help much to say something like this without also suggesting
> a viable alternative. I would love to s
On Wed, Jun 20, 2012 at 1:25 PM, Stefan Sperling wrote:
> On Wed, Jun 20, 2012 at 11:39:40AM -0400, C. Michael Pilato wrote:
>> But let's back up a bit, though.
>>
>> I'm not convinced that the changes you wish to make to subtree handling are
>> all that desirable, at least when not considered as
On Wed, Jun 20, 2012 at 11:39 AM, C. Michael Pilato wrote:
> On 06/20/2012 10:59 AM, Julian Foad wrote:
>> HOW SHOULD SYMMETRIC MERGE BEHAVE?
>>
>> What does this mean for how the initial implementation of symmetric merge
>> should behave?
>>
>> My intention so far has been to make the 'sync-like'
On Wed, Jun 20, 2012 at 10:59 AM, Julian Foad
wrote:
> Warning: long email. Merge gurus and enthusiasts please comment!
>
> At the Hackathon last week, the biggest single topic I discussed with others
> was the handling of subtree merges: both the current handling (which Paul
> told me a lot ab
On Wed, Jun 20, 2012 at 11:39:40AM -0400, C. Michael Pilato wrote:
> But let's back up a bit, though.
>
> I'm not convinced that the changes you wish to make to subtree handling are
> all that desirable, at least when not considered as part of much, much
> larger rethinking of Subversion's fundame
On 06/20/2012 10:59 AM, Julian Foad wrote:
> HOW SHOULD SYMMETRIC MERGE BEHAVE?
>
> What does this mean for how the initial implementation of symmetric merge
> should behave?
>
> My intention so far has been to make the 'sync-like' direction of
> symmetric merge (that is, same direction as previo
Warning: long email. Merge gurus and enthusiasts please comment!
At the Hackathon last week, the biggest single topic I discussed with others
was the handling of subtree merges: both the current handling (which Paul told
me a lot about), and how we could model them in a more pure/general/consis
23 matches
Mail list logo
