Re: [Monotone-devel] Re: Is this the right mailing list? [Was: upgrading 0.36-0.37: "mtn: fatal: std::logic_error: roster.cc:186: invariant 'fetching nonexistent entry from children' violated"]

[Thomas Keller]

Lapo Luchini schrieb:
> I wonder what's best:
> 1. don't allow commits with names that are caseless-equals to existing
> ones (or allow only it with a switch that clearly states "use this only
> if this project won 't EVER be used on Windows or Mac")

Not useful in a distributed system. Upon the next pull you could get a
revision with such files anyways and have a trauma after merge && update ...

> 2. allow them perfectly at commit phase, but fail graciously on checkout
> ("this system is not case sensitive, and this procontains both 'a' and
> 'A', please rename one of the two"... and that would imply that a
> "rename without checkout" would be needed, so that people can actually
> "solve" the problem by themselves.... maybe considering
> caseless-name-clashes a real node conflict and create a "node conflicts
> editor" that interactively asks: A and B wants the same name, which one
> wins, which one gets deleted? Aa and AA want to be saved, do you like to
> drop/renam Aa? drop/rename AA?... and at the end of this interactive
> session it just commits a merge when those choices were automatically
> done, with no need to check out separately ther past revisions, fixing
> them, and re-doing the now-clean merge)

While the ad-hoc, interactive error resolution might have its very own
charme, I think its a bit harsh for many of those conflicting names.

What I just thought about is the following: Lets warn the user if there
are conflicting files on checkout/update but continue to process the
command. Put all conflicting files into some .mtn-update.REVID (or
.mtn-checkout.REVID) directory and add the appropriate renames for it to
the working revision. Finally build a UI to guide the user to resolve
the issues like you said above.

This way the user can decide when he resolves the issue(s) and can still
update his workspace in the meantime. The revert action then has to be
rethought, though, since it is supposed to revert the last update
(effectivly updating to the parent revision) and not just to revert the
local changes in the workspace. Then we need to decide what to do with
commit: either block commits or let them go. If we do the latter we
should ensure that a conflict resolution is possible later on as well.
(To cope with these stuff I originally added the REVID param to the
directory name above to avoid clashes in several of those updates.)


Thomas.

-- 
only dead fish swim with the stream: http://thomaskeller.biz/blog
Für Freiheit und gegen staatliche Überwachungsmaßnahmen:
http://leipzig.vorratsdatenspeicherung.de

signature.asc
Description: OpenPGP digital signature