the inventory must be updated as merge proceeds, not at the end

[Denys Duchier]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> Denys Duchier wrote:
>> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>> 
>>>I see the surgical operations as something that is only necessary for
>>>performing tree transforms on a filesystem (or possibly the inventory).
>>> I don't think they're necessary to calculate a merge.
>> 
>> That's true, but you then still have to apply the computed transform
>> and that's when you need to come up with an appropriate sequence of
>> surgical operations.
>
> That is true, but I don't understand your point.

My point is that the necessity to perform surgical operations has not
gone away.  With the 2-phase (limbo-in, limbo-out) algorithm, what
surgical operations are needed is trivially determined by each
changeset entry.  With the shadow FS approach, these operations are
applied on the shadow and recorded so that they can simply be played
back at commit-time.  With your approach, you need to somehow
rediscover a sequence of surgical operations that will do the trick.
At first sight, that seems harder.

> Conflicts are the big dragon I'm trying to slay.  Conflict resolution
> can itself cause conflicts, and that is very hard to handle in the
> current model.

I have only started to look into conflict resolution, so I am not very
confident in my intuitions, but I don't think you're right.  If you
keep the (virtualized) tree and the inventory (object) in synch, it
seems pretty straightforward.

> Filesystem conflicts can be quite nasty, too, and I'd like to localize
> all the conflict checking in one place, in the hope of covering all the
> nasty little corner cases properly.

Me too, but I may not see the entire "big picture".

>>  We seem to be trading off "une usine à gaz" for very
>> little added convenience.
>
> Desole, je ne parle pas le francais courament.

Perhaps you would say "a Rube Goldberg contraption" - something very
complicated to achieve a trivial result ;-)  Not that I think this is
trivial, of course.

>> And this minor simplification comes
>> at what cost?: an entirely new bunch of code to implement tree
>> transforms
>
> If you like, I can base it on the work I did on the bzr-changeset
> plugin.  Then it will be mostly-old code.

I meant that this would be more code in bzr.  I side with
Saint-Exupery in the pursuit of perfection, if you know what I mean ;-)

> This email is the first time I have heard that you were unconvinced of
> the practical benefits.

well... The presumption is still that you have more of a clue than I
do.  So I was waiting to see what you'd come up with.

>> My "shadow FS" proposal is considerably simpler
>
> The benefits are limited to
> 1. prediction
> 2. rollback
>
> right?

I don't know if "rollback" is the right term, since there's nothing to
undo: the filesystem is not modified until "commit", but otherwise,
yes.  It's basically like operating on a copy of your actual FS.

> that layer to be the WorkingTree.  So yes, it is "designed for the
> working tree proper".

The shadow FS idea would make it possible to virtualize what's under
.bzr and trivially obtain --dry-run support and transactional
semantics for that too.  I don't know if that's useful though.

Cheers,

--Denys