Re: inconsistency between mergeinfo records

On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett <stefan_at_egosoft.com> wrote:

> Hi Stefan,
>
> thanks for taking the time to write that tool.
> I've scheduled a time-slot to check this out/test on our side.
> Unfortunately, our current project plan doesn't provide enough free time to
> check this out in the next 2-4 weeks. I'll get back to you immediately once
> I got the time to work on this task.
>

No worries. The tool is intended to be released with 1.10,
so there is no rush.

> If you have any time requirements/considerations on your side which would
> require/benefit from earlier feedback, pls let me know.
>

Right now, we are all working towards the 1.9 RC. Feedback
in May or June would be nice.

The key question that I like to see answered is "Does the
tool do something useful?" For instance, it might become
ineffective in complex setups, we might need to add detection
of "mismatched" branches etc. We might also end up with
mergeinfo that is technically smaller but neither faster to
process nor easier to understand.

So, there are the things that I'd love to get some feedback on:

* Does the tool work at all (no crashes, nothing obviously stupid)?
* Is the result of each reduction stage correct (as far as one can tell)?
* Is the tool feedback intelligible? How could that be improved?

* How effective is each stage / mergeinfo reduction command?
* How often does it completely elide sub-tree mergeinfo?
* What typical scenarios prevented sub-tree mergeinfo elision?

Up to here, you don't need to commit anything. If you are
convinced that the tool works correctly, you may commit
the results into some toy copy of your repository. Then the
following would be interesting:

* Are merges based on the reduced mergeinfo faster?
* Do merges based on the reduced mergeinfo use less memory?
* Any anomalies?

-- Stefan^2.
Received on 2015-03-28 15:05:29 CET