Re: [Monotone-devel] Monotone Commit Template (Patches)
On Thu, Sep 27, 2007, Pablo Delgado wrote: > [...] > So I went ahead after a few days of looking around in the code and decided to > hack away at it. > [...] > The behavior is as follows, First it reads the .mtn-message if it exist. If it > is not empty then it inserts the > contents of the file into user_log. Then it continues with the previously > coded > behavior which is it reads and > checks _MTN/log and if not empty it will append it to user_log right after the > .mtn-message file content and the > MAGIC_LINE is perpended at the beginning of the file. This way the user can > still continue to use the _MTN/log file > for recording their work. > [...] What is the current status of this? I personally would like to see out-of-the-box .mtn-message support ASAP -- perhaps even already in Monotone 0.37. Please let this changeset from Pablo be reviewed and decided upon. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
Hi, Nathaniel Smith wrote: If anything, it's probably on the late side to be organizing for January/February, so people probably would want to get on it quick... Yeah, better late than never ;-) Besides, are there any good reasons that it must be Jan/Feb? We could still do in in March or even April, no? I would not be surprised if Google were willing to offer space again, or there are other options like above. I don't know that Google's non-Mountain View campuses are set up for anything like this, but I don't know that they aren't, either (though there'd be no Leslie there, obviously :-)). Whoever decides to make things actually happen would of course get to make final decision on all these things, Europe vs. other continents etc. :-) Looks like somebody just needs to step forward... I've mailed Leslie and asked if Google would be interested in sponsoring again. I'm very enthusiastic about Google's biggest European office in Zurich, sort of my home town. Take a look at [1]! But maybe that's just me being overly excited about Zurich... Anybody else interested in helping to organize? Regards Markus [1]: Working at Google Zurich, a YouTube Video: http://www.youtube.com/watch?v=TPz1Mou-Xxk ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
Markus Schiltknecht writes: > Hi, > > Nathaniel Smith wrote: >> If anything, it's probably on the late side to be organizing for >> January/February, so people probably would want to get on it quick... > > Yeah, better late than never ;-) Besides, are there any good reasons > that it must be Jan/Feb? We could still do in in March or even April, > no? It is not too late to ask for a developers' room at FOSDEM in Brussels (23-24 Feb 2008). See http://fosdem.org. Since I live in Brussels, I will definitely attend and can accommodate one person at no charge. I'm also trying to set up an Ada developers' room with several interesting speeches. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Schiltknecht wrote: > Hello Siegfried, > > Siegfried Herbold wrote: >> Maybe there is a location of the same size like Google with: >> - - - free (firewall/charge) internet >> - - - two projection surfaces, but only one mounted beamer (one >> unmounted beamer to organize) >> - - - one flip chart >> - - - open for us 24/7 >> - - - free of charge > > Can you be a little more specific, i.e. where is that room? Close to an > airport? At least somewhat attractive for visitors? TechnoloieCenter Wuppertal, Germany (www.w-tec.de), 0.5h by car / 1.1h by train from international Airport Duesseldorf (DUS) > >> There is no problem with public transport (200 meters from location) > > In most cities in Europe, that's not much of a problem, I guess. > > Regards > > Markus > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHD24papNh/bw3S9oRAqHYAKCrolYiCOFTTIgog7hpO1smRyHf3gCfUqI6 1RoK3uRv/dtnEZcHsiHXik4= =Onsn -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Summit 2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Keller schrieb: > Is there a general interest of doing another summit next year - maybe > again in January/February? I've created a wiki page to collect more ideas and dates: http://www.venge.net/mtn-wiki/MtnSummit2008 Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHD3Tuaf7NlBYNEJIRAizzAJ4n4MpDSP76OpehIaoKr8Zd/c0tRACgzkJ7 Bgmb9pNwEaNEa49sFGVTvKE= =6F07 -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [BUG] merge_into_workspace fails on second merge attempt
On Fri, Oct 12, 2007, Ralf S. Engelschall wrote:
> On Fri, Oct 12, 2007, Ralf S. Engelschall wrote:
> > On Thu, Sep 27, 2007, Ralf S. Engelschall wrote:
> > [...]
> > | mtn: fatal: std::logic_error: roster.cc:1808: invariant
> > 'I(left_uncommon_ancestors.find(left_rid) !=
> > left_uncommon_ancestors.end())' violated
> > [...]
>
> Ok, with the following small script...
>
> --
> #!/bin/sh -x
> mtn=${1+/u/rse/prj/monotone/src/mtn}
> cd /tmp
> rm -f /tmp/test.db
> $mtn --db=/tmp/test.db db init
> rm -rf test
> mkdir test
> cd test
> $mtn --db=/tmp/test.db setup -b test
> echo "foo" >test.txt
> $mtn add test.txt
> $mtn ci -m "commit 1 (foo)"
> echo "bar" >test.txt
> $mtn ci -m "commit 2 (bar)"
> echo "baz" >test.txt
> $mtn ci -m "commit 3 (baz)" -b test.tmp
> echo "baz2" >test.txt
> $mtn ci -m "commit 4 (baz2)"
> $mtn up -r h:test
> MTN_MERGE=diffutils MTN_MERGE_DIFFUTILS=partial \
> $mtn merge_into_workspace h:test.tmp
> --
And one more related bug: if you comment out the two lines...
$mtn ci -m "commit 2 (bar)"
echo "baz" >test.txt
...in the above script (so that the main branch has just a single
initial revision), another assertion fires:
mtn: fatal: std::logic_error: graph.cc:87: invariant 'I(!next.empty())'
violated
So, we have at least two major problems here which make
"merge_into_workspace" effectively totally broken and hence
unfortunately unusable :-(
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [BUG] merge_into_workspace fails on second merge attempt
On Fri, Oct 12, 2007, Ralf S. Engelschall wrote:
> On Thu, Sep 27, 2007, Ralf S. Engelschall wrote:
> [...]
> | mtn: fatal: std::logic_error: roster.cc:1808: invariant
> 'I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end())'
> violated
> [...]
Ok, with the following small script...
--
#!/bin/sh -x
mtn=${1+/u/rse/prj/monotone/src/mtn}
cd /tmp
rm -f /tmp/test.db
$mtn --db=/tmp/test.db db init
rm -rf test
mkdir test
cd test
$mtn --db=/tmp/test.db setup -b test
echo "foo" >test.txt
$mtn add test.txt
$mtn ci -m "commit 1 (foo)"
echo "bar" >test.txt
$mtn ci -m "commit 2 (bar)"
echo "baz" >test.txt
$mtn ci -m "commit 3 (baz)" -b test.tmp
echo "baz2" >test.txt
$mtn ci -m "commit 4 (baz2)"
$mtn up -r h:test
MTN_MERGE=diffutils MTN_MERGE_DIFFUTILS=partial \
$mtn merge_into_workspace h:test.tmp
--
...one can repeat the problem. After removing the firing assertion in
roster.cc:1808...
--- roster.cc e36b1e83bf7a5a3538f0a882feaccb9f32250118
+++ roster.cc e4338d04a283dc68fdb9ede159aa486f6a92bd1d
@@ -1805,7 +1805,7 @@ namespace {
node_id_source & nis)
{
I(!null_id(left_rid) && !null_id(right_rid));
-I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end());
+// I(left_uncommon_ancestors.find(left_rid) !=
left_uncommon_ancestors.end());
I(left_uncommon_ancestors.find(right_rid) ==
left_uncommon_ancestors.end());
I(right_uncommon_ancestors.find(right_rid) !=
right_uncommon_ancestors.end());
I(right_uncommon_ancestors.find(left_rid) ==
right_uncommon_ancestors.end());
...the "merge_into_workspace" command works just fine. I've reviewed
even the results and everything looks just fine. Unfortunately, I still
do not _understand_ why this assertion exists and why it is false only
for "merge_into_workspace". But I guess this assertion is from times
before "merge_into_workspace" was invented and the workflow in the
implementation of "merge_into_workspace" results in a special case which
triggers the assertion. I don't know whether one can really _safely_
remove the assertion or not. Can somebody shed some light on us here?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Summit 2008
Lapo Luchini <[EMAIL PROTECTED]> writes: > Markus Schiltknecht wrote: >> IMO, for FOSDEM it seems to make more sense to have a more user focused >> event. Or presentations and talks or whatever. > > Or -well- we could have a longer Summit *AND ALSO* some of us (as subset > of the European ones, I'd guess) go to FOSDEM as well ;-) Yes, or we could use FOSDEM for users plus the rest of the week for developers. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
Markus Schiltknecht writes: > Hi, > > Ludovic Brenta wrote: >> It is not too late to ask for a developers' room at FOSDEM in Brussels >> (23-24 Feb 2008). See http://fosdem.org. Since I live in Brussels, I >> will definitely attend and can accommodate one person at no charge. >> I'm also trying to set up an Ada developers' room with several >> interesting speeches. > > That's also a good idea! Do you know the deadline for reserving such a > DevRoom? Their website isn't too informative to me today > (i.e. DevRooms is an empty page from here). >From past experience, the deadline is mid-October. However, this is not set in stone and this year they're having serious problems with the organisation. From yesterday's update on the web site, it seems (some of) the problems have been solved. I would suggest asking for a dev room very soon if enough people are interested. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
Hello Siegfried, Siegfried Herbold wrote: Maybe there is a location of the same size like Google with: - - - free (firewall/charge) internet - - - two projection surfaces, but only one mounted beamer (one unmounted beamer to organize) - - - one flip chart - - - open for us 24/7 - - - free of charge Can you be a little more specific, i.e. where is that room? Close to an airport? At least somewhat attractive for visitors? There is no problem with public transport (200 meters from location) In most cities in Europe, that's not much of a problem, I guess. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathaniel Smith wrote: > > My problem is that I'm probably not up to helping much with the > > organization this time -- I'll certainly be interested in coming, > > though! Sponsorship was very helpful, but it's not a necessary thing. > > The hard and urgent part is finding space and picking dates -- last > > year, of course, Google gave us space and some money towards lodging, > > so that determined the space part of things. (The other options I > > thought about were either borrowing space from a friendly company that > > is less massive than Google, which companies are much easier to find > > but it's much harder to get space during weekdays; or else lodging in > > a hotel that had free wifi and at getting one suite that could serve > > as a work area during the day.) (You also want to think about > > transportation issues -- in Europe I guess there is generally public > > transportation? Basically just making sure that there is some > > sensible way for people to eat during days without requiring elaborate > > load-everyone-in-a-car stuff. Google, of course, made this > > super-easy.) > > > > I would not be surprised if Google were willing to offer space again, > > or there are other options like above. I don't know that Google's > > non-Mountain View campuses are set up for anything like this, but I > > don't know that they aren't, either (though there'd be no Leslie > > there, obviously :-)). Whoever decides to make things actually happen > > would of course get to make final decision on all these things, Europe > > vs. other continents etc. :-) > > > > -- Nathaniel > > Maybe there is a location of the same size like Google with: - - - free (firewall/charge) internet - - - two projection surfaces, but only one mounted beamer (one unmounted beamer to organize) - - - one flip chart - - - open for us 24/7 - - - free of charge There are two possibilities of full service catering in the room and in a neighbour building is a canteen (breakfast and lunch only) There is no problem with public transport (200 meters from location) Regards Siggi -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHD1raapNh/bw3S9oRAnvcAJ9nPJXnGrfH6cbadfIkS7v7TCD14gCgqprY vt+08cbKO4fpt/Q9BrXt4es= =DpRq -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Summit 2008
Markus Schiltknecht wrote: > IMO, for FOSDEM it seems to make more sense to have a more user focused > event. Or presentations and talks or whatever. Or -well- we could have a longer Summit *AND ALSO* some of us (as subset of the European ones, I'd guess) go to FOSDEM as well ;-) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Summit 2008
Hi, Lapo Luchini wrote: It seems real neat, the main "problem" is probably that it is "only" 2 days long... especially and after a flight from around the world it is probably better to have a longer event..? Yeah, that seems troublesome for a summit like last February. Especially because there are also lots of other attractive projects. IMO, for FOSDEM it seems to make more sense to have a more user focused event. Or presentations and talks or whatever. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone speedup by adding additional database indices?
Hi, Lapo Luchini wrote: Taking a better look at indexes of table revision_certs: CREATE TABLE revision_certs ( hash not null unique, -- hash of remaining fields separarated by ":" id not null, -- joins with revisions.id name not null,-- opaque string chosen by user value not null, -- opaque blob keypair not null, -- joins with public_keys.id signature not null, -- RSA/SHA1 signature of "[EMAIL PROTECTED]:val]" unique(name, id, value, keypair, signature) ); CREATE INDEX revision_certs__id_name_value ON revision_certs (id, name, value); CREATE INDEX revision_certs__name_value ON revision_certs (name, value); Those are not two indexes, they are four indeed: UNIQUE(hash) UNIQUE(name, id, value, keypair, signature) KEY (id); KEY (name, value); Question is: is there a reason the "big unique index" has that order? I guess so. If that's not the case, we could simply change it to: UNIQUE(id, name, value, keypair, signature) and avoid both KEY(id) and the proposed KEY(id, name, value). AFAICT, the only difference an ordering change of a unique constraint makes, is the difference in the structure of the underlying index. So we'll have to check which indices we really need. It looks like we mostly need '(id)' and '(name, value)'. I'm going to quickly try these indices, which seem to satisfy most cases: .. UNIQUE(name, value, id, keypair, signature) CREATE INDEX revision_certs__id (id); Side questions: why an UNIQUE on "all data" and an UNIQUE on "hash of all data"? Assuming the hash doesn't casually collide (and we assume it all the time) and the ':' separator is adequate they are a bit redundant. Why do we store that hash in the database at all? Is it so terribly expensive to calculate that we need to cache it in the database? Am I right assuming that we only need that hash during netsync? I tend to agree with Lapo, that we don't need another unique constraint on that hash. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Summit 2008
Ludovic Brenta wrote: > It is not too late to ask for a developers' room at FOSDEM in Brussels > (23-24 Feb 2008). See http://fosdem.org. Since I live in Brussels, I > will definitely attend and can accommodate one person at no charge. It seems real neat, the main "problem" is probably that it is "only" 2 days long... especially and after a flight from around the world it is probably better to have a longer event..? Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone speedup by adding additional database indices?
Hi, Lapo Luchini wrote: Small PHP script to aid in the display of EXPLAIN: Nice thing! 2 OpenRead 1 13 keyinfo(5,BINARY,BINARY) sqlite_autoindex_revision_certs_2 Aha, there are ..autoindex... thingies for the unique constraints! Why doesn't sqlite show those? I don't like these hidden automatisms... However, thank you Lapo for clearing this! Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
On Oct 10, 2007, at 5:49 PM, Zack Weinberg wrote: On 10/10/07, Julio M. Merino Vidal <[EMAIL PROTECTED]> wrote: 1) The trouble of users with external boost libary versions goes away There will most likely be no trouble, I think. If monotone uses no binary libraries from Boost (as is the case now), the user will only need to have an unpacked boost tarball somewhere in his file system and point the compiler to use the include files from there. He does not have to deal with Boost.Build at all (e.g. not build binary libraries nor install anything into his system), which is the thing that uses to cause a lot of trouble. Oh, excellent. Would you be willing to update the installation instructions, since you know how it's done? Done! -- Julio M. Merino Vidal <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] allow Lua registered commands to have a proper parameter description
When using the recently introduced Lua command register_command() one
cannot specify a string describing the _parameters_ a command expects.
On "mtn -h" or "mtn help " the part "Syntax specific
to 'mtn ':" is always just an empty line. The reason simply is
because commands::cmd_lua() calls commands::command() with always an
empty string for the parameter description.
The following patch enhances the situation by introducing an additional
parameter to register_command() which is then passed through to
commands::command() and this way allows Lua registered commands to
show a proper parameter string on the help outputs (in case they have
parameters).
Backward compatibility is not an issue here as register_command() will
be released with Monotone 0.37 the first time. I've also adjusted the
documentation and the sample uses of register_command() in contrib/.
Any objections on the appended patch?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
--- contrib/extra-commands.lua 4ad86255ae43a32fbf1ad67f5328ff78075e322f
+++ contrib/extra-commands.lua b5765df0e7533d406743d254a7038e8e7d876f08
@@ -9,7 +9,7 @@ end
mtn_automate("update")
end
-register_command("pup", "Pull and update a workspace",
+register_command("pup", "", "Pull and update a workspace",
"This command approximates the update command of a centralised revision
control system. " ..
"It first contacts the server to gather new revisions and then it
updates the workspace.", "pup")
@@ -30,7 +30,7 @@ end
end
end
-register_command("cpp", "Commit, pull and push a workspace",
+register_command("cpp", "", "Commit, pull and push a workspace",
"This command approximates the commit command of a centralised revision
control system. " ..
"It first commits your work to the local repository, then contacts the
server to gather " ..
"new revisions. If there is a single head at this point, then the local
changes are pushed " ..
@@ -42,7 +42,7 @@ end
mtn_automate("update")
end
-register_command("mup", "Merge and update a workspace",
+register_command("mup", "", "Merge and update a workspace",
"This command merges multiple heads of a branch, and then updates the
current workspace" ..
"to the resulting revision.", "mup")
--- lua_hooks.cc8db4abc61015882eff57df28d1fa14cdb46ade88
+++ lua_hooks.cc57900637d5588e80197752a936229e320993202f
@@ -969,11 +969,12 @@ namespace commands {
std::string const f_name;
public:
cmd_lua(std::string const & primary_name,
+ std::string const & params,
std::string const & abstract,
std::string const & desc,
lua_State *L_st,
std::string const & func_name) :
- command(primary_name, "", CMD_REF(user), false, "",
+ command(primary_name, "", CMD_REF(user), false, params,
abstract, desc, true, options::options_type() |
options::opts::none, true),
st(L_st), f_name(func_name)
{
@@ -1031,15 +1032,16 @@ LUAEXT(register_command, )
LUAEXT(register_command, )
{
- const char *cmd_name = luaL_checkstring(L, -4);
+ const char *cmd_name = luaL_checkstring(L, -5);
+ const char *cmd_params = luaL_checkstring(L, -4);
const char *cmd_abstract = luaL_checkstring(L, -3);
const char *cmd_desc = luaL_checkstring(L, -2);
const char *cmd_func = luaL_checkstring(L, -1);
- N(cmd_name && cmd_abstract && cmd_desc && cmd_func,
+ N(cmd_name && cmd_params && cmd_abstract && cmd_desc && cmd_func,
F("%s called with an invalid parameter") % "register_command");
- new commands::cmd_lua(cmd_name, cmd_abstract, cmd_desc, L, cmd_func); //
leak this - commands can't be removed anyway
+ new commands::cmd_lua(cmd_name, cmd_params, cmd_abstract, cmd_desc, L,
cmd_func); // leak this - commands can't be removed anyway
lua_pushboolean(L, true);
return 1;
--- monotone.texi 9bdc10fe42bccd03dae526214854bc4d08f863b5
+++ monotone.texi f36f9ea6bc0159051867e484d01421952f71f9ef
@@ -9118,7 +9118,7 @@ @section Additional Lua Functions
Returns true if a match for @var{regexp} is found in @var{str}, return
false otherwise. @xref{Regexps}, for the syntax of @var{regexp}.
[EMAIL PROTECTED] register_command(@var{name}, @var{abstract},
@var{description}, @var{function})
[EMAIL PROTECTED] register_command(@var{name}, @var{params}, @var{abstract},
@var{description}, @var{function})
Add a command named @var{name} to the @var{user} command group in monotone.
This function is
normally called directly from a @file{monotonerc} file rather than a hook.
When the user issues the
__
Re: [Monotone-devel] Monotone Summit 2008
Hi, Ludovic Brenta wrote: It is not too late to ask for a developers' room at FOSDEM in Brussels (23-24 Feb 2008). See http://fosdem.org. Since I live in Brussels, I will definitely attend and can accommodate one person at no charge. I'm also trying to set up an Ada developers' room with several interesting speeches. That's also a good idea! Do you know the deadline for reserving such a DevRoom? Their website isn't too informative to me today (i.e. DevRooms is an empty page from here). Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone speedup by adding additional database indices?
Markus Schiltknecht wrote: > Aha, there are ..autoindex... thingies for the unique constraints! I discovered them myself *after* having written explain.php, all the tests I did from sqlite3 client did use one of the other 2 "normal" indexes =) > Why doesn't sqlite show those? I don't like these hidden automatisms... > > However, thank you Lapo for clearing this! In fact that autoindex on UNIQUE(name, id, value, keypair, signature) should already be ideal for queries on (name, id, value) with no need for an additional index. So I wonder why it was not used in the first place. I'll take a closer look again this evening probably. Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [OT] monotone & ohloh
Lapo Luchini wrote: > Monotone main page: > http://www.ohloh.net/projects/652 ...and if you have an account on ohloh, and use monotone often, please consider adding it to your "stack" of used programs (link "stack it", near the project name), so that it has its proper place in the rank of more used VCSes ;-) Lapo PS: in another thread they wrote they won't probably support new VCSes for many months.. but may probably opensource the code and allow people doing it themself (shouldn't be too hard, even if I never used Ruby...). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [BUG] merge_into_workspace fails on second merge attempt
On Thu, Sep 27, 2007, Ralf S. Engelschall wrote: > With the appended tiny test repository (which contains just two branches > "test" and "test.2"), when I perform a initial "merge_into_workspace" > from test.2 to test everything works fine. But if I repeat this once > "test.2" was already merged to "test" (e.g. even with propagate) the > "merge_into_workspace" aborts because an invariant in roster.cc is > not fulfilled (the ~/prj/monotone/src/mtn is the latest Monotone from > h:n.v.m as of today and the "diffutils" is just used for full batch > operation): > > | $ export MTN_MERGE=diffutils; export MTN_MERGE_DIFFUTILS=partial; \ > | cp test.db.bak test.db; ~/prj/monotone/src/mtn --db=/tmp/test.db \ > | propagate test.2 test; (rm -rf test; ~/prj/monotone/src/mtn \ > | --db=/tmp/test.dbco -b test test; cd test; ~/prj/monotone/src/mtn \ > | merge_into_workspace b:test.2) > | mtn: propagating test.2 -> test > | mtn: [source] fa031b9e25421817806d8388559c9fb430128913 > | mtn: [target] e363b9f348f4e1da9849c1e8b9ed12bbb893f505 > | mtn: help required for 3-way merge > | mtn: [ancestor] test > | mtn: [left] test > | mtn: [ right] test > | mtn: [ merged] test > | executing external 3-way merge command > | performing 3-way merge, adding conflict markers > | mtn: [merged] df773bab0a43d69c1b7f8db06538f3c1cab108f8 > | mtn: expanding selection 'b:test.2' > | mtn: expanded to 'fa031b9e25421817806d8388559c9fb430128913' > | mtn: fatal: std::logic_error: roster.cc:1810: invariant > 'I(right_uncommon_ancestors.find(right_rid) != > right_uncommon_ancestors.end())' violated > | mtn: this is almost certainly a bug in monotone. > | mtn: please send this error message, the output of 'mtn version --full', > | mtn: and a description of what you were doing to [EMAIL PROTECTED] > | mtn: wrote debugging log to /tmp/test/_MTN/debug > | mtn: if reporting a bug, please include this file > > Can anybody with a deeper understanding of the code base help? Ok, I was able to reduce this problem to the following simple test case which allows anybody of us to repeat the bug from scratch: | # use h:n.v.m as of 2007-10-12 12:53 (d4d8e25c9c0b7d47e4d9f4c17876f28f09b00126) | $ mtn=/u/rse/prj/monotone/src/mtn | | # create a fresh test repository and a corresponding workspace | $ $mtn --db=/tmp/test.db db init | $ mkdir test | $ cd test | $ $mtn --db=/tmp/test.db setup -b test | | # commit something | $ echo "foo" >test.txt | $ $mtn add test.txt | mtn: adding test.txt to workspace manifest | $ $mtn ci -m "commit 1 (foo)" | mtn: beginning commit on branch 'test' | mtn: committed revision 7fc72e11b673943cd53a85402c095c9fb00bf91e | | # commit something again | $ echo "bar" >test.txt | $ $mtn ci -m "commit 2 (bar)" | mtn: beginning commit on branch 'test' | mtn: committed revision 3b0093ee368e6e34ca2485dbaacc96eaec6a069b | | # commit something to a temporary branch | $ echo "baz" >test.txt | $ $mtn ci -m "commit 3 (baz)" -b test.tmp | mtn: beginning commit on branch 'test.tmp' | mtn: committed revision a79ce292a282d372a6c6a1266d6baaf35dd86724 | | # switch back the workspace to the main branch | $ $mtn up -r h:test | mtn: expanding selection 'h:test' | mtn: expanded to '3b0093ee368e6e34ca2485dbaacc96eaec6a069b' | mtn: selected update target 3b0093ee368e6e34ca2485dbaacc96eaec6a069b | mtn: target revision is not in current branch | mtn: switching to branch test | mtn: modifying test.txt | mtn: switched branch; next commit will use branch test | mtn: updated to base revision 3b0093ee368e6e34ca2485dbaacc96eaec6a069b | | # try to merge in the temporary branch | $ MTN_MERGE=diffutils MTN_MERGE_DIFFUTILS=partial \ | $mtn merge_into_workspace a79ce292a282d372a6c6a1266d6baaf35dd86724 | mtn: modifying test.txt | mtn: fatal: std::logic_error: roster.cc:1808: invariant 'I(left_uncommon_ancestors.find(left_rid) != left_uncommon_ancestors.end())' violated | mtn: this is almost certainly a bug in monotone. | mtn: please send this error message, the output of 'mtn version --full', | mtn: and a description of what you were doing to [EMAIL PROTECTED] | mtn: wrote debugging log to /tmp/test/_MTN/debug | mtn: if reporting a bug, please include this file The bug is deterministically repeatable. Unfortunately, my current understanding of the Monotone codebase is still not sufficient to fix this bug myself. So, can please somebody help out and let us finally fix the "merge_into_workspace" command? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [BUG] merge_into_workspace fails on second merge attempt
On Fri, Oct 12, 2007 at 02:32:19PM +0200, Ralf S. Engelschall wrote: > -I(left_uncommon_ancestors.find(left_rid) != > left_uncommon_ancestors.end()); [...] > ...the "merge_into_workspace" command works just fine. I've reviewed > even the results and everything looks just fine. Unfortunately, I still > do not _understand_ why this assertion exists and why it is false only > for "merge_into_workspace". But I guess this assertion is from times > before "merge_into_workspace" was invented and the workflow in the > implementation of "merge_into_workspace" results in a special case which > triggers the assertion. I don't know whether one can really _safely_ > remove the assertion or not. Can somebody shed some light on us here? Ah, I see. Here's what's going on: "left_uncommon_ancestors" is the set of all revisions that are ancestors of the left revision being merged, but are not ancestors of the right revision being merged. (Compare to the notion of "common ancestors"; every ancestor of the revisions being merged is exactly one of common, left uncommon, or right uncommon.) Asserting that left_rid is in left_uncommon_ancestors, then, is asserting that left_rid is an ancestor of itself (which it is by definition) and that it is not an ancestor of right_rid (which is the point that's causing the problem). It does not make sense to merge an ancestor with its own descendent -- the descendent *already* contains everything that the ancestor has, plus it creates pointless merge nodes in the graph that prevent branches from converging. The other merge commands with more polished UIs contain special case code to detect this and skip entering the actual merge engine; merge_into_workspace ATM does not. (For instance, check out the code follow "// check for special cases" on line 510 of cmd_merging.cc.) So the short-term workaround for this case would be to just use 'propagate otherbranch thisbranch' or 'cert h:otherbranch branch thisbranch' instead of 'workspace_merge otherbranch thisbranch'. The long term solution is probably: -- if someone tries to do a workspace merge like this, then print a message and just update to the descendent version -- teach commit that if you try to do a commit with no changes, but the branch has changed versus the parent, then put that branch cert on the parent instead of just erroring out. -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone Summit 2008
On Fri, Oct 12, 2007 at 11:12:15AM +0200, Markus Schiltknecht wrote: > Nathaniel Smith wrote: > >If anything, it's probably on the late side to be organizing for > >January/February, so people probably would want to get on it quick... > > Yeah, better late than never ;-) Besides, are there any good reasons > that it must be Jan/Feb? We could still do in in March or even April, no? No, no particular reason -- I think last year it just happened then because by the time we started planning it was too late to do it before Jan/Feb, and there was no reason to hold it off until after that. On further thought, a time after March 22 would be much better for me personally, because I'm a teaching assistant for the winter quarter this year, so that makes it quite tricky for me to get away between January 4 and March 22 (would need to find someone else to take my class, couldn't do it at all during test times, etc.). -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
