[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: current multiple heads (was Re: write access to my
From: |
graydon hoare |
Subject: |
[Monotone-devel] Re: current multiple heads (was Re: write access to my public server) |
Date: |
Thu, 29 Apr 2004 12:27:58 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040208) |
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
- [Monotone-devel] write access to my public server (was Re: [PATCH] add xemacs ...), (continued)
- [Monotone-devel] write access to my public server (was Re: [PATCH] add xemacs ...), graydon hoare, 2004/04/20
- [Monotone-devel] Re: write access to my public server, Christof Petig, 2004/04/22
- [Monotone-devel] current multiple heads (was Re: write access to my public server), Christof Petig, 2004/04/28
- Re: [Monotone-devel] current multiple heads (was Re: write access to my public server), Derek Scherger, 2004/04/28
- Re: [Monotone-devel] current multiple heads (was Re: write access to my public server), Christof Petig, 2004/04/29
- Re: [Monotone-devel] current multiple heads (was Re: write access to my public server), Jon Bright, 2004/04/29
- [Monotone-devel] Re: current multiple heads (was Re: write access to my public server),
graydon hoare <=
- [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), graydon hoare, 2004/04/29
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Jon Bright, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), graydon hoare, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Jon Bright, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), graydon hoare, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Nathaniel Smith, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Derek Scherger, 2004/04/29
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Nathaniel Smith, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Jon Bright, 2004/04/30
- Re: [Monotone-devel] Re: current multiple heads (was Re: write access to my public server), Asger Ottar Alstrup, 2004/04/30