Re: [Monotone-devel] Re: SPKI/SDSI
On Wed, Feb 08, 2006 at 03:35:25PM +, Bruce Stephens wrote: Nathaniel Smith [EMAIL PROTECTED] writes: I've been reading RFC 2693 [ftp://ftp.isi.edu/in-notes/rfc2693.txt] to prepare for CodeCon, so I can talk about plans for trust management without seeming totally ignorant of relevant literature :-). It's an interesting read; I think there are enough differences in problem domain to make it non-ideal for monotone, but it's a good basis for discussion. So, good thing to read (or at least skim) at some point if people are interested in this stuff. Also http://www.crypto.com/trustmgt/kn.html is interesting. I must admit all these things feel like nifty technical solutions in search of too few actual problems. In theory I think there's lots of things you could do in a uniform way if everyone would just agree on one framework to use, but in reality almost all specific problems seem adequately (if not completely) solvable using simpler (if specific) solutions. (And so long as there's no obvious winner, it's not worth anyone going with a system that really could do everything.) I'm not sure what has held back SPKI uptake in practice. The web site actually suggests that nothing has, it's just that it's a set of principles rather than a single spec that everyone has to implement, so all the people working on SPKI are now just writing systems that do what they need to, instead of trumpeting their adherence to SPKI canon. This seems like a feature; if you read that RFC, they lay out how to interpret PGP keys, X.509 keys, etc., as instances of SPKI certs. They seem very aware that any solution that requires universal adoption is no solution at all, and to have at least attempted to target their design to make this irrelevant. Regardless, though, _this_ part is all irrelevant to monotone :-). My guess is that'll be so for whatever problems there are for monotone: it'll be not too bad to add one or two features, and now and again add an epicycle or two, and the immediate requirements can be satisfied. As a specific example, get_revision_cert_trust would probably be more useful if it had access to all the certs for a revision. I could imagine wanting to ignore tags other than my own on my own branches, and probably there are other examples. Maybe similarly for accept_testresult_change. Personally, I'm pretty darn convinced that get_revision_cert_trust is a dead end. Especially it just doesn't provide any way to get one of the most basic things you expect out of a VCS: some way for a core group of developers can manage commit access (really cert trust and perhaps push access). _Everyone_ has policy on who can change what how, and in practice telling every user to work out their own rules, while flexible, is completely... well, just way too clunky to work :-). (If anyone disagrees, then could I ask you to volunteer to go around and get everyone on a project to manually update their hooks the next time someone joins the project? Thanks ;-).) We know how to solve this; the full design of SPKI/SDSI is way overkill and not appropriate, but some of the basic principles are useful to think about. We basically think we know how to solve monotone's problem (the trust branch idea, for those who remember it), and it's basically just the technique in 7.7 of the above RFC (though we came up with it independently), plus some monotone specific gunk to make it fit in nicely. The really nice thing about this chunk of extra architecture is that it also gives you natural solutions for such things as: * key lifecycle (including retiring old keys and making new ones with the same name as the old one) * branch naming (and renaming) * a natural place for a project to store project-general data. say, for instance, darcs's famous email-address-in-the-repo, so one could in principle say monotone email-changes and have local changes magically bundled off to the appropriate list. and so on :-) -- Nathaniel -- But in Middle-earth, the distinct accusative case disappeared from the speech of the Noldor (such things happen when you are busy fighting Orcs, Balrogs, and Dragons). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] validation hook documentation
Nathaniel asked me to document the commit message validation hook that
I added, so here's a patch to do that. It also changes the lua to
reflect what really gets passed in. I'll implement the rest of his
suggestions in another patch soon.
--
Blake Kaplan
#
# old_revision [40f0799799e84361c24e9f0d23d271fb4308f7f8]
#
# patch monotone.texi
# from [200d3e76ba97251314502d5e9dd0bdb1215289cb]
#to [355d07f84caee318dd69f37ff6274842ca2d2c70]
#
# patch std_hooks.lua
# from [259f2956124c69bd0f616943ad64663f67213cd6]
#to [8f01e338e8056c62de500694210fd22dacac6122]
#
--- monotone.texi 200d3e76ba97251314502d5e9dd0bdb1215289cb
+++ monotone.texi 355d07f84caee318dd69f37ff6274842ca2d2c70
@@ -6690,6 +6690,25 @@
@end ftable
[EMAIL PROTECTED] Validation Hooks
+
+If there is a policy decision to make, Monotone defines certain hooks to
+allow a client to validate or reject certain behaviors.
+
[EMAIL PROTECTED] @code
[EMAIL PROTECTED] validate_commit_message (@var{message}, @var{changeset_text})
+
+This hook is called after the user has entered his/her commit message.
[EMAIL PROTECTED] is the commit message that the user has entered and
[EMAIL PROTECTED] is the full text of the changes for this revision,
+which can be parsed with the parse_basic_io function. If the hook finds the
+commit message satisfactory, it can return @code{true, }. If it finds
+fault, then it can return @code{false, reason} where @var{reason} is the
+reason the message was rejected. By default, this hook rejects empty log
+messages.
+
[EMAIL PROTECTED] ftable
+
@page
@node Additional Lua Functions
@section Additional Lua Functions
--- std_hooks.lua 259f2956124c69bd0f616943ad64663f67213cd6
+++ std_hooks.lua 8f01e338e8056c62de500694210fd22dacac6122
@@ -706,7 +706,7 @@
return matches
end
-function validate_commit_message(message, new_manifest_id)
+function validate_commit_message(message, changeset_text)
if (message == ) then
return false, empty messages aren't allowed
end
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [sqlite] disk locality (and delta storage)
On Fri, Feb 10, 2006 at 07:06:27PM -0500, [EMAIL PROTECTED] wrote: Daniel Carosone [EMAIL PROTECTED] wrote: It seems a little odd to me to build a centralised, online information system for tracking state and documenting activity around and about source code in a distributed and disconnected VCS. Ah yes, you're right. But in the system I envision, the wiki and bug-tracking are also decentralized, disconnected, and distributed. Now I'm *very* interested :) Wiki pages doesn't seem so hard, they're pretty much text documents stored in a VCS anyway. There are some complications. Each wiki page acts if it where its own independent project or branch. Hm. I'm not sure I see that as the case; if I update several pages together and change the linkage between them, I could well want a single commit revision across the several topic pages. But I've not given it much thought.. it probably does work close to that way (a commit per page update) when the editing is being done via html forms. The wiki I'm most familiar with, in implementation, is Twiki (and even then, only vaguely). It's a web front-end onto RCS files that hold the wiki text. If you have access to the server, there's nothing stopping you doing your own checkout/edit/checkin, for example if you find the browser editing panel restrictive for what you need to do. So I just figured wiki content in monotone might as well work pretty much the same way, with the webserver as one committer. And then you probably want some way see all current leaves and to do merges from the web interface. Yes. A nice web-based merge UI is one thing you'd want, but it needn't be there in the first instance. You're going to need some rules and mechanisms for when the webserver will update as new content arrives in the database via netsync; in the first instance you could rely on developers to merge and provide the webserver with a unique head. Until that's resolved, the webserver and its users could just keep committing along the line they started with. If you start running multiple web servers as semi-independent mirrors (not counting 'personal' ones, as below), then you get to the point of needing to provide web users with more UI to deal with choosing and merging heads. Much of that UI is probably very much like the UI you need to give them to navigate source content, viewmtn-style. If you intend your system to be publically accessible, then you will also need some mechanism to delete (or at least permanently hide from public view) the spam that miscreants occasionally post on wiki pages and sometimes also on tickets. Some kind of death cert perhaps. Yes, but I think this applies for monotone projects that accept anonymous revisions, regardless of whether the content is a wiki page or anything else. Bug tracking state would require a little more smarts, with suitable text formats stored in the VCS and code/hooks to assist in making sane merges between multiple heads of a given ticket, but even that doesn't seem terribly hard. My thinking about tickets is that each change to a ticket is just a small, signed, immutable record (like a cert) that contains a variable number of name/value pairs. The names are things like title, description, status, assigned-to, etc. To reconstruct the current state of a ticket, you sort all the pieces by their creation time (their actual creation time, not the time they happened to arrive at your database) and read through them one by one. Values overwrite prior values with the same name. So in the end, you have one value for each field name - and that is the current state of your ticket. I wouldn't use creation time, datestamps are unreliable; even without someone issuing malicious timestamps, there are sometimes good uses for dating a revision in the past, or even possibly in the future. (Ok, I can't think of a good case for future dates right now, but I have quite valid ones for past-dating certs, as well as the cvs_import case). Instead, I'd evisaged using the revision DAG to let one state replace a previous one (ie, topological sort in your algorithm above). When merging paths that have conflicting values, it's probably best for the user to choose the correct one, and place that value on the merge node. By which time, you might as well just store the ticket as structured content, perhaps with a commit-hook to validate well-formedness and other constraints. This approach gives you automatic merging and a complete change history/audit trail. It does give you simpler merging, but perhaps too simple? Overwiting values like this mightn't be the best thing in some cases.. and it means people can go back and change history. Using the DAG means that a bug can be closed on one branch, (or even one divergent head/path within a branch) but still open on another. Which seems exactly correct, to me. In any case, just like for actual code, there will be some kinds of
Re: [Monotone-devel] mtsh, monotree, monotone.el, etc.
Bruce Stephens [Wednesday 8 February 2006] : I notice contrib/monotone-nav.el hasn't seen much modification, so am I right to guess that it's not being used much? Nevers used it myself, I don't even know what i's supposed to do :) contrib/monotone.el seems to work fine, and I've been using it recently now and again. Are there things missing from it? I feel there probably are things it could usefully do, but I find it hard to imagine specific things I could add. So maybe that's a sign that it's sufficient. I initially wrote monotone.el, then someone (Harley Gorrell [EMAIL PROTECTED]) far more knowledgeable than me about elisp development started rewriting this file and added monotone-nav.el. Unfortunately he hasn't contributed since April. Personally, I prefer my version of monotone.el, I just have feeling it works better :) Anyway, having a close look at monotone.el and cleaning it up is on my list of things to do. I'm interested if you have remarks/comments/opinions on monotone.el. I need to have a look at this too: http://wiki.gnuarch.org/xtla#DVC I *do* use contrib/monotone.zsh_completion all the time. I'll send a patch updating it once rosters is more officially stable. Right, monotone.bash_completion needs to be updated too. -- Olivier ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [sqlite] disk locality (and delta storage)
Thanks for this detailed email! I've been a bit crazy with codecon the last week, and most of what I have to say is hmm, lots to think about here, so, yeah :-). I did want to reply to your VCS system comments, though: On Tue, Feb 07, 2006 at 10:17:54AM -0500, [EMAIL PROTECTED] wrote: What I'm looking for is a VCS + bug-tracker + wiki that I can just drop into a cgi-bin of some low cost web hosting site (like Hurricane Electric, which I notice we both use) and have a ready-to-roll project management system with no setup or other details to worry about. Kind of a sourceforge-in-a-box, only a lot better than sourceforge. I'm That sounds awesome. I'm _really_ interested in this area myself, actually, though the stuff I've been playing with is somewhat orthogonal. (Nothing really working yet, but playing with ways to improve data integration -- by folding in even more, like IRC logs and mailing list archives. These kinds of things require a much heavier server architecture, though, so sort of exploring different parts of the design space.) looking for something like monotone with CVSTrac enhancements that works over HTTP. Nothing like that currently exists, I'm afraid, so I've been working on my own. Yes, it is a big job, though perhaps not any bigger than writing an SQL database engine ;-) I can't say monotone works with CVSTrac, but then, I assume your system doesn't either off the bat :-). And, monotone can work over HTTP -- or at least, _I_ say it can :-). There is a branch where I worked out a proof-of-concept implementation of this: http://viewmtn.angrygoats.net/branch.psp?branch=net.venge.monotone.dumb It's as a python script that does some rather Clever Things. I don't have time to explain the algorithm in detail now, but it basically supports monotone's full push/pull/sync semantics, you can talk to one friend's repo and then talk to another's, etc., that all just works; and it should be transactional (except that in some rare cases someone has to rollback by hand; in the dumb remove filesystem case, readers can't in general do a rollback, and renames can't in general be atomic, so if you're extremely unlikely you might get wedged). And it should be really speedy on top of some well done network backends (you really want things like pipelining). If you do take a look at it, there's basically dumb.py doing monotone glue, fs.py giving the generic filesystem interface that needs to be implemented for each transport, and merkle_dir.py in between, where all the magic lives. I haven't actually convinced anyone yet to take care of it and polish it up, though (or rewrite more sanely, or whatever), so it's just sort of been sitting there, waiting forlornly for someone who will give it love... Monotone is my favorite of the current crop of VCSes by the way. It has 80% of what I am looking for. What I'm really after is a better monotone. I have been greatly inspired by your work, as have others, I notice. Thank you very much! I would be interested in hearing what you think of as the last 20%, beyond HTTP support. I also innocently observe that if what you want is a better monotone, the quickest route may be to... make monotone better ;-). While size is definitely not everything -- I doubt anyone notices 10% here or there -- a factor of 2-3x is probably going to be hard to sell. Unfortunately, since it's a nice scheme. The CVS repository for SQLite is 15MiB. Under a baseline+delta schema it would grow to (perhaps) 45MiB. The cheapest account on Hurricane Electric includes 1GiB of storage. Why should I care about the extra 30MiB? Well, because there are enough people out there with gig-sized source checkouts. (Yeah, not even history, but... checkouts.) Or hundreds and hundreds of thousands of commits (gcc, mozilla, linux kernel...). While there's definitely value to a tool that works well for the 95% of projects that are not that big, we really would like to have a single tool that 100% of projects can viably use. The extraordinarily intense competition in the VCS field is also a factor; note that mercurial scales to those projects just fine, without excessive space usage, and is experiencing great uptake on small projects too -- so since we think we offer some other compelling advantages, we really would like to compete directly across the whole range :-). -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: SPKI/SDSI
Nathaniel Smith [EMAIL PROTECTED] writes: [...] The really nice thing about this chunk of extra architecture is that it also gives you natural solutions for such things as: * key lifecycle (including retiring old keys and making new ones with the same name as the old one) * branch naming (and renaming) * a natural place for a project to store project-general data. say, for instance, darcs's famous email-address-in-the-repo, so one could in principle say monotone email-changes and have local changes magically bundled off to the appropriate list. and so on :-) Yes indeed. And you didn't mention another big one, which is that other people have already designed it. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
On 2/11/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Fri, Feb 10, 2006 at 05:25:36PM +0100, Richard Levitte - VMS Whacker wrote:
I'm taking a look at the current revision approval possibilities, and
there are things I don't quite understand. Also, it looks like this
hasn't been looked at for ages.
It hasn't. It was sort of stuck in as a statement of intention,
before anyone realized _quite_ how long it would take to get a solid
VCS foundation so we could get back to the actual _workflow_ stuff
that was the original goal...
I don't know that there's a lot of point in trying to patch this up
piecemeal; we don't have any coherent model for how review would work
right now, and fiddling with the trust hook (which is also one of
these vestigial has-been-there-forever, never-really-designed things)
doesn't seem like it will really get us there?
Personally, I think the functionality of 'disapprove' should move to
'revert' ('revert -r REV [RESTRICTION]; commit'), and 'approve' could
just go away, or stay on until we have a real story, or whatever.
The name 'revert' of course makes sense for this, but this will also
clash with the 'revert' used to revert a change in a working copy
The real answer is the trust branch stuff, which is actually getting
much closer now that we have rosters in and are starting to get handle
on how we can get over the speed problems we've been facing forever.
It will be nice if we can stop fighting fires for a bit... *knocks on
wood*
--
Justin Patrin
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [sqlite] disk locality (and delta storage)
On Fri, Feb 10, 2006 at 07:06:27PM -0500, [EMAIL PROTECTED] wrote: Daniel Carosone [EMAIL PROTECTED] wrote: Wiki pages doesn't seem so hard, they're pretty much text documents stored in a VCS anyway. There are some complications. Each wiki page acts if it where its own independent project or branch. And then you probably want some way see all current leaves and to do merges from the web interface. If you intend your system to be publically accessible, then you will also need some mechanism to delete (or at least permanently hide from public view) the spam that miscreants occasionally post on wiki pages and sometimes also on tickets. Some kind of death cert perhaps. These all seem reasonably straightforward; basically just UI issues. The trickiest bit is the making each page independent bit... but you can just do that by having each page be a single file named page.txt in its own branch. Alternatively, sometimes it is very nice to allow renaming in a wiki. (I have definitely wanted this feature, when I realized that the spec I have been working out on a wiki page actually should be called something different than what it currently is.) You can allow this pretty straightforwardly even in the distributed wiki case if you just use monotone's rename support... Bug tracking state would require a little more smarts, with suitable text formats stored in the VCS and code/hooks to assist in making sane merges between multiple heads of a given ticket, but even that doesn't seem terribly hard. My thinking about tickets is that each change to a ticket is just a small, signed, immutable record (like a cert) that contains a variable number of name/value pairs. The names are things like title, description, status, assigned-to, etc. To reconstruct the current state of a ticket, you sort all the pieces by their creation time (their actual creation time, not the time they happened to arrive at your database) and read through them one by one. Values overwrite prior values with the same name. So in the end, you have one value for each field name - and that is the current state of your ticket. You seem to be reinventing history tracking with certs. It seems a lot simpler to just make tickets, like, a text file, and then use the existing history tracking tools. They're quite tuned and involve some non-obvious bits. In particular, compared to this scheme, they're insensitive to clock skew, they provide real merging (in your scheme, if I change a field locally, and you change the same field locally, then whichever of us has our clock set later at that time will silently clobber the other person), and users can investigate the history of a ticket using normal history browsing tools... It is also very useful to have certs that record a link between a revision and a ticket. In this way you can record that a bug was introduced by, or fixed by, a particular revision. The linkage between tickets and revisions has proven to be particularly valuable in CVSTrac. Indeed! Enabling this kind of workflow integration is _exactly_ why we have this generic cert thing built in. No-one's done much with it yet, though, so really we don't even know how far the possibilities go -- so I get all excited when someone does :-). Once you have cross linking between revisions and tickets, if you add a google-like search you then have a very powerful system for doing source tree archeological work. This comes up a lot in maintaining SQLite. Somebody on the web reports a problem. I have some vague memory of fixing a similar problem 9 months ago, but do not recall where it was or how I fixed it. By using the search feature of CVSTrac together with the links between tickets and check-in comments, I can quickly find the historical problem and pinpoint exactly when and how the problem was fixed. Then post a URL to the specific ticket that described the problem and the specific revision that fixed it. Yep! Monotone has much more structured information than CVS, and it's much easier to get at; one can get at all sorts of things. You can track not just the list of commits, but things like branches, figure out whether they're merged or not yet, see which branches work is occurring on... Or how about another cool use of certs: http://mt.xaraya.com/com.xaraya.core/index.psp I think the move from CVS to systems with simpler, saner data models opens up huge opportunities for better visualization, data mining, data navigation, community awareness, workflow management... sadly, I never get to work on this, because I end up spending my time trying to make the basic pieces just work :-). But I can't wait to see what other people come up with, and can cheer loudly while they do... -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be
Re: [Monotone-devel] [sqlite] disk locality (and delta storage)
Daniel Carosone [EMAIL PROTECTED] wrote: Just type (for example): monotone httpserver and then point your webbrowser at 127.0.0.1. My personal favourite is jetty in Java for this kind of thing; I'm not sure monotone itself should grow a http server :) The built-in webserver need not have all the features or performance of apache. Something very simple will suffice. CVSTrac has the ability to act as its own web server, or to let inetd be the server that calls CVSTrac on each request. Both features combined are implemented in less than 150 lines of C code. To see the code visit http://www.cvstrac.org/cvstrac/getfile/cvstrac/cgi.c Search for cgi_http_server and cgi_handle_http_request. -- D. Richard Hipp [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] validation hook documentation
In message [EMAIL PROTECTED] on Sat, 11 Feb 2006 03:07:02 -0800, Blake Kaplan [EMAIL PROTECTED] said: mrbkap Nathaniel asked me to document the commit message validation mrbkap hook that I added, so here's a patch to do that. It also mrbkap changes the lua to reflect what really gets passed in. I'll mrbkap implement the rest of his suggestions in another patch soon. Applied, committed and pushed. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote:
Personally, I think the functionality of 'disapprove' should move to
'revert' ('revert -r REV [RESTRICTION]; commit'), and 'approve' could
just go away, or stay on until we have a real story, or whatever.
The name 'revert' of course makes sense for this, but this will also
clash with the 'revert' used to revert a change in a working copy
This is exactly the same command. Notice the -r REV, which means to
revert the [RESTRICTION] files to as they were in REV (as opposed to
the BASE rev as default), and a commit after. Thus a revert is just
like an update that doesn't change MT/revision, so diffs and commits
are still relative to the original BASE.
This works fine if your BASE is the revision where the 'bad' change
was first made, or at least some near descendent before other changes
have been made in the relevant files too. If intervening changes have
been made, the current functionality of 'disapprove' is to apply a
reverse patch against the current head.
That's handy and convenient, but I actually think the more appropriate
way to achieve this is to actually go back up the graph and checkout
the original damaged BASE rev, revert and commit as above, and then
merge the new head with the anti-change with the current head.
The resulting graph just makes more sense: it connects the bad change
with the repair, and shows you the alternate path in between that's
affected by the bad code.
So, yes please.
--
Dan.
pgp7ojUvMs3r0.pgp
Description: PGP signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Approval revisited...
In message [EMAIL PROTECTED] on Sun, 12 Feb 2006 09:41:14 +1100, Daniel
Carosone [EMAIL PROTECTED] said:
dan On Sat, Feb 11, 2006 at 03:37:01AM -0800, Justin Patrin wrote:
dan Personally, I think the functionality of 'disapprove' should
dan move to 'revert' ('revert -r REV [RESTRICTION]; commit'), and
dan 'approve' could just go away, or stay on until we have a real
dan story, or whatever.
dan
dan The name 'revert' of course makes sense for this, but this will
dan also clash with the 'revert' used to revert a change in a
dan working copy
dan
dan This is exactly the same command.
No.
dan Notice the -r REV, which means to revert the [RESTRICTION] files
dan to as they were in REV (as opposed to the BASE rev as default),
dan and a commit after. Thus a revert is just like an update that
dan doesn't change MT/revision, so diffs and commits are still
dan relative to the original BASE.
dan
dan This works fine if your BASE is the revision where the 'bad'
dan change was first made, or at least some near descendent before
dan other changes have been made in the relevant files too. If
dan intervening changes have been made, the current functionality of
dan 'disapprove' is to apply a reverse patch against the current
dan head.
Incorrect. disapprove does what you describe it should do, as
follows, except for the merge that you have to do separately:
dan That's handy and convenient, but I actually think the more
dan appropriate way to achieve this is to actually go back up the
dan graph and checkout the original damaged BASE rev, revert and
dan commit as above, and then merge the new head with the anti-change
dan with the current head.
dan
dan The resulting graph just makes more sense: it connects the bad
dan change with the repair, and shows you the alternate path in
dan between that's affected by the bad code.
I entirely agree with that last remark, and since that's what
disapprove does (well, except for the merge), why should we change it,
and even more, why should we mix it up with another command that does
something different altogether?
dan So, yes please.
My vote goes to no! pretty please, no!
Cheers,
Richard
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/
When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up.
-- C.S. Lewis
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
