Re: [Monotone-devel] Re: Deterministic *-merge
On Fri, 2007-01-12 at 18:14 -0800, Nathaniel J. Smith wrote: Anyway, the answer to your question is that I'm not proposing anything at all change in monotone -- that's why I said at the beginning of the writeup that my note had no practical consequences :-). I think that merge behavior is one of the most crucial pieces of how a VCS behaves. Darcs is an example of this approach taken to extreme, and demonstrates how a solid theoretical basis for the merge can be viewed as the core design choice of a VCS. Having something equivalent for more traditional version control systems would be a real breakthrough IMVHO. As for practical implications - cherry picking can be defined in terms of a merge operation, as long as you *really* trust your merge :-) We've generally taken the line that the history graph should attempt to model as closely as possible the user's intrinsic understanding of versioning a bunch of files, because this is the both the most user-friendly and the most future-proof approach. (Sucks to build a particular merge algorithm's assumptions into your hash-chained history graph, and thus be stuck with that merge algorithm for a few decades...) That's true. On the other hand, there's immense power to be gained from picking a powerful merge abstraction and running with it (again Darcs is a good example). That said, I dunno, maybe someone will figure out how to use this kind of stuff to improve VCS UI -- it's just some ideas, who knows what will happen to them once they start wandering around in people's heads... For starters, annotating the '#' with the list of candidate values immediately suggests an interface for conflict resolution. Also presumably the cases where conflict actually occurs would (hopefully) be more in line with user expectations. And then there are the advanced features you could build on top of this (like cherry-picking). These all require that the chosen merge abstraction be really solid, which translates to trying to poke theoretical holes in it, and then trying it in practice for a while, until sufficient confidence is reached. Most VCS don't trust their merge method (for good reason). On the down side, this restrict their power; on the up side, they allow plugging in different merge algorithms, so it would be possible to implement and test deterministic *-merge in them to see how well it works in practice. Monotone is a particularly good platform for this because it is based on solid abstractions in other areas (what is a version, what is a branch, etc.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] project_t , and preparing for projects / policy branches
I've been reorganizing things somewhat to try to prepare for
implementing a concept of a project that we'll need for the policy
work.
So far, this mostly means that I've added a project.{cc,hh} with a
project_t class, and that things that make / query certs (and this
includes things that ask about branches) have to go through this.
Anything dealing with keys should also end up going through here, but I
haven't done that part yet.
There is currently a single project, accessed by app.get_project(). I'm
thinking that later this will become the default project, which is
whatever is specified either in _MTN/options or on the command line. We
can also have app.get_project(string) for operations like netsync or
automate (stdio) that want to be able to look at multiple projects.
The database class had several get_revision_certs() functions. Most uses
of these (the exception being some code that looked like it was for
migration) now go through project_t. The functions in project_t aren't
(all) just wrappers, they have names based more on how the functions the
wrap were used, and are changed to fit those uses better. (For example,
the get all certs of type foo variant became project_t::get_tags(),
because that's all it was used for.)
Also, the mentioned get_tags() returns a set of new tag objects. The
code that used it wanted to know the key used for signing the tag, but I
don't think it's at all certain that tags will remain implemented as
certs (putting them in the policy branch should allow them to become
more interesting). So, just returning a set of certs probably wouldn't
be good.
One other change is that there's an outdated_indicator.{cc,hh} that's
used by the database cert query functions to let their users find out
when the returned info might be outdated. Currently, this is only really
used by project_t::get_branch_heads(), with the result that calling
'heads' repeatedly for the same branch (say, through automate stdio) is
very fast after the first time. I don't really know if we want to keep
this, it's mostly there just because it occurred to me while I was
messing around trying to figure out how to get started on this
(re)organize things to prepare for having a 'project' concept thing.
--
Timothy
Free (experimental) public monotone hosting: http://mtn-host.prjek.net
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] FYI: (en|de)code_hexenc now use botan
I just pushed a change that removes transforms.cc's bespoke implementation of hex encoding in favor of Botan's. I believe this to have been a historical accident, but if it turns out to cause performance issues (which I doubt it will) we can certainly go back to the way it was. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Summit update -- 1 month to go!
On Fri, Jan 12, 2007 at 09:49:30AM +0100, Lapo Luchini wrote: Nathaniel J. Smith wrote: If you don't have a room to sleep in yet (has _anyone_ booked a hotel room yet?), then now is also really the time! That, I'll probably do this evening, as soon as we decide the logistics for the few days before the summit starts (anyway has suggestion what is at a reasonable distance and can't really be missed? we have 4 full days available for the trip before the summit starts). Well, I'm fond of recommending the Exploratorium to people :-). (It's up in SF, just under the Golden Gate bridge.) Alcatraz is touristy, but actually pretty darn cool, too. And speaking of transportation, we need 2-3 (or more) people to drive everyone back and forth from the hotel everyday, and if you can be one of these people, i.e., are: -- age 25 or older -- legal to drive in the US (IIUC if you are legal to drive at home you are probably legal to drive in the US) then you should let me know, so we can figure out the rental stuff. Me and Gabriele were thinking about renting a car anyway, in order to take a better look around the area in the first 4 days, so there would be no problem in doing this. How should we move in that direction? Will it be a centralized booking like the hotel or not? Oh, good -- I was starting to get worried that we might not have any drivers there for the whole week after all :-). (Might still be a bit complicated with your leaving on Sunday, but we can figure something out.) We needed to do the hotel bit centralized because we all wanted to be at the same place, and because we could get better rates -- for the cars I don't know if it matters either way. (We _might_ be able to negotiate for better rates, but I don't really know how rental car companies work.) The main thing is making sure we have enough seats to get everyone around... AFAICT the most cost-effective thing to get are minivans, each of which seats 7. (You might not want to rent one just for the two of you beforehand, though, since they're more expensive than a car.) So we need somewhere between 2 minivans and 3 minivans, it looks like from the current wiki page... it would be helpful if people with question marks next to their names figured out what they were doing soonish, so we can figure this part out :-). -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] project_t , and preparing for projects / policy branches
On Sat, Jan 13, 2007 at 01:58:05PM -0600, Timothy Brownawell wrote:
I've been reorganizing things somewhat to try to prepare for
implementing a concept of a project that we'll need for the policy
work.
Huzzah.
It's going to be weird at the summit, trying to seriously sit down and
hack this stuff out, without you there. Think you'll be around on IRC
at least or so?
So far, this mostly means that I've added a project.{cc,hh} with a
project_t class, and that things that make / query certs (and this
includes things that ask about branches) have to go through this.
Anything dealing with keys should also end up going through here, but I
haven't done that part yet.
Better factoring? Shocking! :-)
There is currently a single project, accessed by app.get_project(). I'm
thinking that later this will become the default project, which is
whatever is specified either in _MTN/options or on the command line. We
can also have app.get_project(string) for operations like netsync or
automate (stdio) that want to be able to look at multiple projects.
Makes sense. We might want to consider making the project something
that gets passed around directly, as well, instead of being global
state, if we want one process to be able to work with multiple
projects. I guess this would fit into the general trend of trying to
split things out of the app_state blob, and might or might not be
sensible to mix in with other changes now.
The database class had several get_revision_certs() functions. Most uses
of these (the exception being some code that looked like it was for
migration) now go through project_t. The functions in project_t aren't
(all) just wrappers, they have names based more on how the functions the
wrap were used, and are changed to fit those uses better. (For example,
the get all certs of type foo variant became project_t::get_tags(),
because that's all it was used for.)
Huh, didn't we also have get all branch certs? And I guess the
selector stuff is all inside database.cc, so never mind that...
Also, the mentioned get_tags() returns a set of new tag objects. The
code that used it wanted to know the key used for signing the tag, but I
don't think it's at all certain that tags will remain implemented as
certs (putting them in the policy branch should allow them to become
more interesting). So, just returning a set of certs probably wouldn't
be good.
Yeah, tags are an interesting question. We should probably even
consider simply throwing them out altogether -- the only thing I can
think that's actually different between tags and (what monotone calls)
branches is that if you do
mtn co -rt:foo
you don't want monotone to guess that the workspace should have its
default branch set to foo, but rather to whatever real branch the
revision is in (if there is one).
One other change is that there's an outdated_indicator.{cc,hh} that's
used by the database cert query functions to let their users find out
when the returned info might be outdated. Currently, this is only really
used by project_t::get_branch_heads(), with the result that calling
'heads' repeatedly for the same branch (say, through automate stdio) is
very fast after the first time. I don't really know if we want to keep
this, it's mostly there just because it occurred to me while I was
messing around trying to figure out how to get started on this
(re)organize things to prepare for having a 'project' concept thing.
This is technically sort-of incorrect, isn't it, because in principle
the trust hooks might return different values the first and second
time they are called? Not that anyone is likely to complain within a
single monotone instance, though in the long run one of the things
that having more control over trust will give us is the ability to
cache such decisions on _disk_. We will almost certainly need to
eventually cache head sets on disk in order to scale.
-- Nathaniel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
