Re: [Monotone-devel] Workspace merge?

[Nathaniel Smith]

On Sat, Jul 14, 2007 at 05:23:32AM -0400, Stephen Leake wrote:
> "Zack Weinberg" <address@hidden> writes:
> > Tangentially, I want conflict marker generation to be left to a lua
> > hook.
> 
> Yes, with a default to the CVS style.

It will probably be with a default to "call merge(1), like CVS does"
or even "don't do them at all" in the first version, because that lets
us get the functionality out the door without rewriting our text
conflict stuff to know how to generate conflicts... (right now it just
aborts when it sees the first conflict).

> > Manifests are older, and I believe now used only in the netsync
> > protocol; they did the same job as rosters, but did not carry all of
> > the same information.
> 
> Ah. So in the info manual in general, we should talk about "rosters",
> not "manifests"? I just rewrote the section for 'automate inventory'
> in nvm.basic_io.inventory, using the term 'manifests'.

No, the manual should always (?) talk about manifests, because the
manual is directed at users, not people hacking on monotone internals.
Rosters are an detail of our optimized implementation; manifests are a
stable textual format, part of our fundamental history representation.
Manifests get signed, for instance (indirectly).

(Actually, manifests are not even sent over netsync, at this point we
don't even have code to parse a manifest in mtn proper...)

> > I would be very reluctant to put the conflict marker in the roster.
> > That data structure is complicated enough.  I'd rather see a separate
> > serialization of the conflict list in the roster_merge_result,
> > indicating which changes to the workspace roster have been faked up to
> > remove conflicts.
> 
> I'm not clear how that would interact with 'automate inventory'; that
> code gets all of it's information from rosters (I think).

It could get some information from _MTN/conflicts too, though, easy
enough.

-- Nathaniel

-- 
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield