Re: Subtree mergeinfo -- what I learnt at the Hackathon

Thank you all for your feedback on this.  I'm presently on leave, moving house, and am not able to give it my full attention until Monday 2 July. 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 out what the details of the new behaviour will be, and this thread is helping us to do just that.  I ended up with a bias towards trying to move toward a more rename-friendly approach, but I recognise we can't get there yet so the "follow each node's own ancestry" idea is just an idea for the future.  We need a simpler approach for now. - Julian >________________________________ > From: Stefan Sperling <stsp_at_elego.de> >To: C. Michael Pilato <cmpilato_at_collab.net> >Cc: Julian Foad <julianfoad_at_btopenworld.com>; Subversion Development <dev_at_subversion.apache.org>; Paul Burba <ptburba_at_gmail.com>; Branko Čibej <brane_at_apache.org> >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: >> >> (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 see Julian move forward with this >> > work and am looking forward to learning how far it could get us. >> >> I agree that it doesn't help as much as you or I would like.  Still, I'd >> like to think that you'd appreciate my pointing out that the petroleum I see >> dripping from beneath your car might be a reason to avoid driving it, even >> when I lack the mechanical know-how to prescribe a more specific solution.  :-) > >Yes, I should have phrased this differently. Sorry. > >I didn't mean to say that you weren't allowed to raise your concerns. >I meant to say that I think we shouldn't discourage Julian from >following down this path. I must have read a subtext in your comment >that wasn't actually there. Your comments are actually very valuable since >they prevent us from being mislead into a situation where subtree merging >stops working for users who are relying on it. > >> I too would love to see Julian move forward with this work, and I don't want >> to be a voice of discouragement for that effort.  It's just the moving >> backward that bothers me.  Error messages communicate to users that they're >> doing something wrong, but they aren't.  Support for subtree mergeinfo and >> cherry picking are a documented part of Subversion's merge tracking feature. > >Agreed. Ideally, the symmetric merge will support all currently supported >use cases, without throwing errors at users or requiring new command-line >switches. > >I haven't yet made up my mind about interim measures for 1.8 though. >I suppose if symmetric merge won't support all currently supported use cases >in 1.8, we could keep the --symmetric option in place for 1.8, and drop it >in 1.9 or later once the symmetric merge code can handle all use cases? > > >
Received on 2012-06-24 15:52:27 CEST