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

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 11 Jul 2012 12:44:26 +0100 (BST)

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' versus knowingly 'unsupported', and we see what an ideal symmetric merge would do.  Then we evaluate the current 'symmetric'[1] implementation against that: does it do "the same as" or "better than" or "worse than" what a user can do with the existing merge (assuming he/she chooses the "reintegrate" option appropriately).
>> It's not easy to set up all of the possible scenarios: reintegrating the root but excluding a subtree, for example, can't be done in a single merge command.  Does that mean that scenario is uninteresting?  No, I don't think so.  What we can do is eliminate the existing merge command from the set-up phases of the test scenarios, and set up the desired mergeinfo directly: "faking it", if you will.  Doing it that way separates the concerns: the question of what the merge command will do, given a certain scenario, is a separate question from how we can use merges to create that scenario.
>> The question I have at the moment is: Does this approach to evaluation make sense to you?
> 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 which, if any, mergeinfo applies to a particular file (or
> subtree)?

No; the inheritance algorithm is simple enough.

This discussion is about how to compare what "works" now (in 1.7) versus what "works the same" or "works better" or "works worse" in a proposed "symmetric" implementation.  It's a matter of devising a way to enumerate all the possible the cases systematically, so that we have a way to answer the question "do all the cases that work in 1.7 still work in the proposed implementation?"

- Julian

> Assuming that retrieving merginfo is expensive (which I gather it is
> right now) and you want to minimize the number of explicit mergeinfo
> lookups, your approach makes sense to me.
>> [1] 'symmetric' -- Urgh! -- we must change the name as the current incarnation is not very symmetric at all.
> You can always try --symmetricer ...
> -- Brane
Received on 2012-07-11 13:45:04 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.