[Monotone-devel] Re: current multiple heads (was Re: write access to my public server)

[graydon hoare]

Derek Scherger wrote:

> I like it!

yes, it's a good change. I like it too.

> > - CVS import honors visibility of files
> > - monotone log [ID] [file] to see the changes to a specific file only
> > - make --without-bundled-sqlite work (but not default)
> > - monotone heads shows date and author

I have merged your head with joel's and implemented a slightly more 
useful -- though still questionable -- form of evaluating disapproval 
when calculating "heads". it still has cases where it fails.

there is an interesting problem which arises from this: disapproval 
isn't quite as "final" as I had initially hoped. in particular, consider 
this scenario:

  A->B contains badness
  A->C is OK

  - I review A->B and disapprove of it
  - njs, working independently, merges B and C automatically into D
  - njs proceeds to hack on D a bit, making a new (good) edge D->E
  - njs finally receives my disapproval, but it has no affect; E still
    contains the badness that I disapproved (maybe)

this problem (in general) comes from disapproval adhering to "changes" 
but monotone dealing primarily in "versions". there is no "intrinsic" 
aspect of E which indicates that it contains the changes in A->B.

so we have a few options, as I see it:

 - ignore this problem and tell people who do code review to go through
   a central server. this is a bad solution.

 - calculate a synthetic "set of disapproving ancestor edges" for any
   version. this is only a half solution because it fails to note when
   a disapproved edge is "solved" by a correction patch, and also fails
   to transmit the information to users without complete history.

 - totally overhaul monotone's internal storage structure to represent
   versions primarily as sets of changes (a la darcs and arch). this is
   the most expensive solution, but I've done expensive things here in
   the past and I'm not completely adverse to the concept. my major
   concern with this is that set-like representations grow forever,
   which penalizes users for having successful, large-scale and
   long-lived projects. nonetheless, it is an option; arch has its
   "cached versions" and darcs has its "checkpoint patches". maybe that
   makes more sense.

 - rework the concept of disapproval to "do something else". for
   example, when dealing with persistent attributes of files we found
   that a versionned .mt-attrs file made more sense than trying to
   calculate cascading sets of file certificates. maybe a file called
   .mt-disapproved which holds the set of "live" disapprovals in a
   version. then the command "disapprove A B" makes a new edge A->K
   which contains nothing more than an addition of "A B" to the
   .mt-disapproved file. this would then cause future mergers of your
   branch to carry this disapproval forwards, and give a means for
   users to mark a disapproval as "fixed" (by removing the entry).

in general, the more I've discussed monotone with others in recent days, 
the more clear it has become that we need a slightly (or massively) 
enhanced ability to denote, select, search, split, combine etc. edges 
("changes") in addition to versions ("states"). it is possible that this 
can be done synthetically (as we currently do) from the ancestry graph, 
but it remains to me an open question.

indeed, my feeling increasingly is that the *central* problem in VC is 
dealing with the change / version duality in a seamless manner. by 
seamless I mean both from a UI perspective, and from the perspective of 
"equally efficient supporting data structures". all systems I know of 
focus on one view or the other. can we make a system which does both 
equally well?

I'd welcome further thoughts on the matter.

-graydon