[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Move tracking -- concept demo

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 26 Nov 2014 19:09:59 +0000

Stefan Sperling wrote:
> On Wed, Nov 26, 2014 at 04:53:00PM +0000, Julian Foad wrote:
>> I recognize that this all seems a big change, but I think it's the most
>> important thing Subversion needs, and I think we can do it. If you care about
>> move tracking, please have a play with it and tell me what do you think.
> I'd really like to look at this but there is something at a higher
> level that worries me and discourages me from diving into technical
> details just now.

Hi Stefan, and thanks for saying this.

> I remember Branko telling me last summer he had a vision of how moves
> would work and that it was different to yours and that merging moves
> were not going to work as you envisage. (That's not exactly what he
> said, I'm just paraphrasing what I took away from the conversation.)
> Since then I haven't heard much from Branko on this topic, I have put
> off work on a more user-friendly tree-conflict resolution script I've
> been meaning to write (other projects have just been so much more exciting),
> and you've been hacking away on this branch which is great but...
> ... are we still a project run by a community of collaborators with a
> shared focus, or is everyone of us working isolated in their own corner?
> In the latter case, what do we do to fix the situation and find
> project-wide consensus on how to proceed?

That's exactly why I'm trying to open up communication, because I feel we've been working in silence too much. Me in particular: I'm not a naturally talkative person and no-one has been asking me, so I have to force myself to start putting something out there, both code and words.

Philip pointed out (and I'm paraphrasing too) that it was all very well to have theoretical ideas, but we couldn't evaluate their usefulness without trying them out in some kind of real way. Hence me writing this demo code.

Also it is pretty near impossible to understand someone else's ideas when they are quite a long way from current state and not extremely well articulated. Discussion isn't very productive between people who only share a very vague common understanding. When I did post my theoretical notes, I didn't get much response. Something that you can touch, and where you can see real results, should be much easier to engage with.

So now I'm trying to invite everyone to join in with running some scenarios involving moving and merging, and see what we like and what we dislike about how it works. That will give us some new ideas and expectations as to what might be possible, whatever direction we choose to pursue, and in doing so will help us decide what directions are best.

To get the whole community involved and come to a shared goal, we need to share these ideas in public and discuss them and see where they lead. When the ideas are too abstract, we need to play with a demo and see what we can learn from it, positive and negative.

To reiterate, at this point the aim is to share the *ideas*, so that we can then have informed discussions.

> What's the grand vision that unites this design with other (as of
> yet mostly vocally relayed) design proposals? I've never seen the
> discussion about competing move-tracking designs that took place
> in Berlin earlier this year being concluded.

There is no conclusion, yet, nor a grand vision other than what I said about wanting move tracking to be "solidly supported".

I could characterize this design as taking quite a rigid approach, with the objective of arriving at quite simple "mathematical" definitions of the difference between two branch-revisions, and the calculation of a 3-way merge, and so on. In order to do this it mandates declaring branches in advance, and having a 1:1 mapping between the elements in different branches for merging, among other things.

- Julian
Received on 2014-11-26 20:10:33 CET

This is an archived mail posted to the Subversion Dev mailing list.