[Monotone-devel] PCRE landed
Since Richard is in favor and Nathaniel hasn't said anything, I went ahead and landed the PCRE branch. It's my hope that this has no visible effects at all, beyond not needing boost.regex anymore; let me know if there are problems. I updated the Debian dependencies; it does not appear that the rpm .spec file has dependencies that granular. It is possible to use an external PCRE library by giving --with-system-pcre to configure, but this is not the default. My impression is that, while external Boost libraries are now not needed, to get the header-only libraries that we still use, people building from source will still have to go through the trouble of building the whole of Boost. I looked briefly into the possibility of bundling the remaining Boost components that we use; in principle it would be easy (boost even includes a utility to do this). However, the sheer number of files it would involve is rather daunting. $ bcp --list --scan --boost=/usr/include *.cc *.hh | grep '^boost/' | wc -l 1271 Individual Boost headers (I checked format.hpp and shared_ptr.hpp) seem to expand to about 300 sub-headers a pop, with not much overlap. Thoughts? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
On Wed, Oct 10, 2007 at 12:06:28AM -0700, Zack Weinberg wrote: Since Richard is in favor and Nathaniel hasn't said anything, I went ahead and landed the PCRE branch. Yay! My impression is that, while external Boost libraries are now not needed, to get the header-only libraries that we still use, people building from source will still have to go through the trouble of building the whole of Boost. Depends how their packaging is set up: for comparison and an estimation of the number of files involved: [EMAIL PROTECTED] [17:08][347]/usr/pkgsrc/devel wc -l boost-*/PLIST* 510 boost-build/PLIST 4480 boost-docs/PLIST 3573 boost-headers/PLIST 2 boost-jam/PLIST 32 boost-libs/PLIST 4 boost-python/PLIST 8601 total So, I'm assuming we should now be able to get away with a dep on just boost-headers, which will save a chunk of space and time. Thankyou. -- Dan. pgpoemDGBPXA3.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
On Wed, Oct 10, 2007 at 05:13:48PM +1000, Daniel Carosone wrote: So, I'm assuming we should now be able to get away with a dep on just boost-headers, which will save a chunk of space and time. Thankyou. Well, time at least, if space not so much after all... [EMAIL PROTECTED] [17:16][358]/usr/pkgsrc/devel pkg_info -s 'boost-*' Information for boost-headers-1.33.1: Size of this package in bytes: 20164592 Information for boost-libs-1.33.1: Size of this package in bytes: 6355598 Information for boost-build-1.33.1nb2: Size of this package in bytes: 1510287 pgpJovnlWztSH.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
On 10/10/07, Daniel Carosone [EMAIL PROTECTED] wrote: My impression is that, while external Boost libraries are now not needed, to get the header-only libraries that we still use, people building from source will still have to go through the trouble of building the whole of Boost. Depends how their packaging is set up: for comparison and an estimation of the number of files involved: [...] So, I'm assuming we should now be able to get away with a dep on just boost-headers, which will save a chunk of space and time. Thankyou. Yes, that should work. (I made effectively the same change for the Debian packaging.) I was referring to people who start from scratch with no prepackaged boost. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
Zack Weinberg schrieb: $ bcp --list --scan --boost=/usr/include *.cc *.hh | grep '^boost/' | wc -l 1271 Individual Boost headers (I checked format.hpp and shared_ptr.hpp) seem to expand to about 300 sub-headers a pop, with not much overlap. Are there still objections against including those remaining headers in the monotone source? This has two advantages: 1) The trouble of users with external boost libary versions goes away 2) We're in control of what boost version we're using and can remove more and more of its actual dependencies from the monotone core. Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
In message [EMAIL PROTECTED] on Wed, 10 Oct 2007 09:17:03 +0200, Thomas Keller [EMAIL PROTECTED] said: me Zack Weinberg schrieb: me $ bcp --list --scan --boost=/usr/include *.cc *.hh | grep '^boost/' | wc -l me 1271 me me Individual Boost headers (I checked format.hpp and shared_ptr.hpp) me seem to expand to about 300 sub-headers a pop, with not much overlap. me me Are there still objections against including those remaining headers in me the monotone source? This has two advantages: me me 1) The trouble of users with external boost libary versions goes away me me 2) We're in control of what boost version we're using and can remove me more and more of its actual dependencies from the monotone core. The flip side of the coin is that it becomes yet one more thing for us to maintain. The question to ask every time we make a decision to bundle an external source is, what happens when the current maintainer of that source (on the monotone side) leaves? Who will take over and make sure it keeps on working? There's never an easy answer to that question, and there will always be a balance to strike between ease and pain... 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] PCRE landed
In message [EMAIL PROTECTED] on Wed, 10 Oct 2007 00:06:28 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw Since Richard is in favor and Nathaniel hasn't said anything, I went zackw ahead and landed the PCRE branch. It's my hope that this has no zackw visible effects at all, beyond not needing boost.regex anymore; let me zackw know if there are problems. I updated the Debian dependencies; it zackw does not appear that the rpm .spec file has dependencies that zackw granular. I just hit a whoopsie that I hadn't noticed before; it seems the syntax checking test doesn't quite work because the first line in stderr doesn't necessarely match the first line in stderr-ref. 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
[Monotone-devel] [PATCH] fix test syntax_errors_in_.mtn-ignore
A make check on h:n.v.m currently results in one failed test: syntax_errors_in_.mtn-ignore. The reasons is because the test performs a mtn ls unknown command and checks the stderr output. Unfortunately, it doesn't seem to be deterministic in what order the files are checked against the Lua function ignore_file() and hence the first line (mtn: warning: while matching file '':) of the stderr output of mtn ls unknown contains an abitrary filename and hence lets the test fail. There are multiple possibilities to fix this. I propose to simply skip the first line of stderr during output comparisons: Index: tests/syntax_errors_in_.mtn-ignore/__driver__.lua --- tests/syntax_errors_in_.mtn-ignore/__driver__.lua 40ae692978a4b62a47ad35468cc2e52656a68643 +++ tests/syntax_errors_in_.mtn-ignore/__driver__.lua b055aa0291460500b8f1520f3b18ef7a3c6445c3 @@ -13,4 +13,5 @@ check(samefile(stdout, stdout-ref)) check(get(stderr-ref)) check(samefile(stdout, stdout-ref)) +check(string.gsub(readfile(stderr), [^\r\n]*\r?\n, 1) == + string.gsub(readfile(stderr-ref), [^\r\n]*\r?\n, 1)) -check(samefile(stderr, stderr-ref)) Any objections? 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] PCRE landed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 10, 2007, at 9:19 AM, Daniel Carosone wrote: On Wed, Oct 10, 2007 at 05:13:48PM +1000, Daniel Carosone wrote: So, I'm assuming we should now be able to get away with a dep on just boost-headers, which will save a chunk of space and time. Thankyou. Well, time at least, if space not so much after all... Well, space... you'd save all the space of boost libraries, _including_ boost-headers (which is the biggest package according to the numbers you showed). The binary packages will not need to rely on boost at all, as the header-only libraries provided by boost will be bundled into the binary. Seems good news to me :-) - -- Julio M. Merino Vidal [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHDOrbuIm9UEGtViURAjRaAJ9zSzeVIz4fS/4KEVjpGLtNqyLKjQCglLCF bsOrjiNeE0OYMzimESg0gmk= =eq2E -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 10, 2007, at 9:17 AM, Thomas Keller wrote: Zack Weinberg schrieb: $ bcp --list --scan --boost=/usr/include *.cc *.hh | grep '^boost/' | wc -l 1271 Individual Boost headers (I checked format.hpp and shared_ptr.hpp) seem to expand to about 300 sub-headers a pop, with not much overlap. Are there still objections against including those remaining headers in the monotone source? This has two advantages: 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. - -- Julio M. Merino Vidal [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHDOw+uIm9UEGtViURApesAKDRpHSr8Wz+W/6rK7alT2v4R7X1fwCgn81E D+ug23VJr2zuvKBmmKXAkFA= =NcP8 -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
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? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] fix test syntax_errors_in_.mtn-ignore
On 10/10/07, Ralf S. Engelschall [EMAIL PROTECTED] wrote: A make check on h:n.v.m currently results in one failed test: syntax_errors_in_.mtn-ignore. The reasons is because the test performs a mtn ls unknown command and checks the stderr output. Unfortunately, it doesn't seem to be deterministic in what order the files are checked against the Lua function ignore_file() and hence the first line (mtn: warning: while matching file '':) of the stderr output of mtn ls unknown contains an abitrary filename and hence lets the test fail. There are multiple possibilities to fix this. I propose to simply skip the first line of stderr during output comparisons: That's the right fix in principle but I think there is a more elegant way to implement it. Stay tuned... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] parent selector 'p:xxx'
On Sat, Oct 06, 2007, Ralf S. Engelschall wrote:
This afternoon I finally got really nerved having to type
$ mtn diff -r `mtn automate parent rev` -r rev
or the rather ugly, unhandy and partly unrecognizeable
$ mtn log --diffs --no-graph --brief --from rev --to rev
just to get the diff output which has lead to a particular revision
rev (which in turn I usually figure out via mtn annotate
beforehand).
I don't know whether it is just me, but I rather often need the _parent_
of a revision (if more parents exists, I'm out of luck doing an easy
diff anyway) and especially -- even if a command can figure it out --
want to avoid even having to copy paste it more revision ids than
necessary.
So, find appended a small patch against h:n.v.m which implements a
p:rev selector. With this I now can finally use short commands like:
$ mtn diff -r p:rev -r rev
The rev here can be an appreviated revision, too.
In case others find this additional selector also handy, are there any
objections if I commit this to n.v.m? Else I will include this stuff
just into the patchset I maintain for OpenPKG's monotone package...
[...]
Ok, here is the final patch which includes the documentation update
and a little corresponding test for make check. Any objections for
comitting this?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
===
Index: selectors.hh
--- selectors.hha580067010375b01e72094ebc255e26da4894384
+++ selectors.hh04a1e8390e95624c89c100fd14de9157f5309dc1
@@ -30,6 +30,7 @@ namespace selectors
sel_cert,
sel_earlier,
sel_later,
+ sel_parent,
sel_unknown
}
selector_type;
===
Index: selectors.cc
--- selectors.cc87df1393159bdc637059d9dfa9dfc52d50236326
+++ selectors.cc1f5468137482871fb0c6b418357caa93eed01201
@@ -79,6 +79,9 @@ namespace selectors
case 'e':
type = sel_earlier;
break;
+ case 'p':
+type = sel_parent;
+break;
default:
W(F(unknown selector type: %c) % sel[0]);
break;
===
Index: database.cc
--- database.cc 4ae4c79a2a7fba4f39b072de6edc52625e1f69c0
+++ database.cc b37f89c9d264b674728fda144360e30d5d3b6397
@@ -2874,6 +2874,7 @@ static void selector_to_certname(selecto
case selectors::sel_ident:
case selectors::sel_cert:
case selectors::sel_unknown:
+case selectors::sel_parent:
I(false); // don't do this.
break;
}
@@ -2914,6 +2915,11 @@ void database::complete(selector_type ty
lim.sql_cmd += SELECT id FROM revision_certs WHERE id GLOB ?;
lim % text(i-second + *);
}
+ else if (i-first == selectors::sel_parent)
+{
+ lim.sql_cmd += SELECT parent AS id FROM revision_ancestry WHERE
child GLOB ?;
+ lim % text(i-second + *);
+}
else if (i-first == selectors::sel_cert)
{
if (i-second.length() 0)
@@ -3033,7 +3039,7 @@ void database::complete(selector_type ty
// will complete either some idents, or cert values, or unknown
// which generally means author, tag or branch
- if (ty == selectors::sel_ident)
+ if (ty == selectors::sel_ident || ty == selectors::sel_parent)
{
lim.sql_cmd = SELECT id FROM + lim.sql_cmd;
}
===
Index: monotone.texi
--- monotone.texi ba3e94933926c735fe99c81024701beaaef7203a
+++ monotone.texi 9bdc10fe42bccd03dae526214854bc4d08f863b5
@@ -2765,6 +2765,10 @@ @heading Selectors in detail
@item Identifier selection
Uses selector type @code{i}. For example, @code{i:0f3a} matches
revision IDs which begin with @code{0f3a}.
[EMAIL PROTECTED] Parent selection
+Uses selector type @code{p}. For example, @code{p:0f3a} matches the
+revision IDs which are the parent of the revision ID which begins with
[EMAIL PROTECTED]
@item Tag selection
Uses selector type @code{t}. For example, @code{t:monotone-0.11} matches
@code{tag} certs where the cert value begins with @code{monotone-0.11}.
===
Index: tests/parent_revision_selector/__driver__.lua
--- tests/parent_revision_selector/__driver__.lua
9b3fb350caf11956ba9ee62f74e967d83bbd2dc1
+++ tests/parent_revision_selector/__driver__.lua
9b3fb350caf11956ba9ee62f74e967d83bbd2dc1
@@ -0,0 +1,36 @@
+
+-- setup workspace
+mtn_setup()
+revs = {}
+
+-- commit a revision #1
+addfile(testfile, this is just a test file)
+commit()
+revs[1] = base_revision()
+
+-- commit a revision #2
+writefile(testfile, now
Re: [Monotone-devel] PCRE landed
On 10/10/07, Richard Levitte [EMAIL PROTECTED] wrote: I just hit a whoopsie that I hadn't noticed before; it seems the syntax checking test doesn't quite work because the first line in stderr doesn't necessarely match the first line in stderr-ref. This should be fixed as of rev 459fe7f043ab002873c2d68e35b6550c7e9bfe81. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] fix test syntax_errors_in_.mtn-ignore
On 10/10/07, Ralf S. Engelschall [EMAIL PROTECTED] wrote: I propose to simply skip the first line of stderr during output comparisons: That's the right fix in principle but I think there is a more elegant way to implement it. Stay tuned... Yes, that's what I expected. Feel free to fix in a more elegant way, please. Done in rev 459fe7f043ab002873c2d68e35b6550c7e9bfe81. It's the same concept but done with a new tailfile() helper function in testlib.lua, and the problem line removed altogether from stderr-ref. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone speedup by adding additional database indices?
Indexes speed up read operations but slow down writes. Which do we do more of? I'd optimize for the case that would benefit most. I suspect we do a fair amount of both. In this case, maybe adding indexes for mostly-read tables would be the way to go. -Ben On 10/10/07, Ralf S. Engelschall [EMAIL PROTECTED] wrote: Some Monotone operations really operate slower than what one would expect in the first spot. Hence, I've today looked at the run-time of a simple mtn update in a workspace which *is already* at h:n.v.m. This no-operation command internally performs a dozend times the following SQL queries: SELECT id, name, value, keypair, signature FROM revision_certs WHERE id = ? AND name = ? AND value = ? SELECT keydata FROM public_keys WHERE id = ? SELECT id FROM public_keys WHERE id = ? The problem is that revision_certs and public_keys have not the proper indices for those queries and hence full-table scans seem to be performed. I did a quick test and added the following to indices manually: CREATE INDEX revision_certs__id_name_value ON revision_certs (id, name, value); CREATE INDEX public_keys__id ON public_keys (id); This dropped down the total execution time of the mentioned mtn update command by over 80%! A time mtn update showed 0.450s on average before and 0.080s on average afterwards. And this was really not any type of in-depth analysis of the situation. I just created two obvious indices for the most prominent queries which mtn --debug update showed me. What do we think? Should we investigate further and especially add additional indices like the above to the Monotone database schema? Or is there consensus that this type of speed optimization is just the root of furthcoming evil and at least at this time should be still ignored at all... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- --- Ben Walton [EMAIL PROTECTED] When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Religion. Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone speedup by adding additional database indices?
Some Monotone operations really operate slower than what one would expect in the first spot. Hence, I've today looked at the run-time of a simple mtn update in a workspace which *is already* at h:n.v.m. This no-operation command internally performs a dozend times the following SQL queries: SELECT id, name, value, keypair, signature FROM revision_certs WHERE id = ? AND name = ? AND value = ? SELECT keydata FROM public_keys WHERE id = ? SELECT id FROM public_keys WHERE id = ? The problem is that revision_certs and public_keys have not the proper indices for those queries and hence full-table scans seem to be performed. I did a quick test and added the following to indices manually: CREATE INDEX revision_certs__id_name_value ON revision_certs (id, name, value); CREATE INDEX public_keys__id ON public_keys (id); This dropped down the total execution time of the mentioned mtn update command by over 80%! A time mtn update showed 0.450s on average before and 0.080s on average afterwards. And this was really not any type of in-depth analysis of the situation. I just created two obvious indices for the most prominent queries which mtn --debug update showed me. What do we think? Should we investigate further and especially add additional indices like the above to the Monotone database schema? Or is there consensus that this type of speed optimization is just the root of furthcoming evil and at least at this time should be still ignored at all... 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 speedup by adding additional database indices?
On 10/10/07, Ben Walton [EMAIL PROTECTED] wrote: Indexes speed up read operations but slow down writes. Which do we do more of? I'd optimize for the case that would benefit most. I suspect we do a fair amount of both. In this case, maybe adding indexes for mostly-read tables would be the way to go. The size increase on the DB should also be investigated here. How much did your DB increase in size when the indexes were added? -Ben On 10/10/07, Ralf S. Engelschall [EMAIL PROTECTED] wrote: Some Monotone operations really operate slower than what one would expect in the first spot. Hence, I've today looked at the run-time of a simple mtn update in a workspace which *is already* at h:n.v.m. This no-operation command internally performs a dozend times the following SQL queries: SELECT id, name, value, keypair, signature FROM revision_certs WHERE id = ? AND name = ? AND value = ? SELECT keydata FROM public_keys WHERE id = ? SELECT id FROM public_keys WHERE id = ? The problem is that revision_certs and public_keys have not the proper indices for those queries and hence full-table scans seem to be performed. I did a quick test and added the following to indices manually: CREATE INDEX revision_certs__id_name_value ON revision_certs (id, name, value); CREATE INDEX public_keys__id ON public_keys (id); This dropped down the total execution time of the mentioned mtn update command by over 80%! A time mtn update showed 0.450s on average before and 0.080s on average afterwards. And this was really not any type of in-depth analysis of the situation. I just created two obvious indices for the most prominent queries which mtn --debug update showed me. What do we think? Should we investigate further and especially add additional indices like the above to the Monotone database schema? Or is there consensus that this type of speed optimization is just the root of furthcoming evil and at least at this time should be still ignored at all... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- --- Ben Walton [EMAIL PROTECTED] When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Religion. Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone speedup by adding additional database indices?
Ralph wrote: CREATE INDEX revision_certs__id_name_value ON revision_certs (id, name, value); CREATE INDEX public_keys__id ON public_keys (id); This dropped down the total execution time of the mentioned mtn update command by over 80%! Ben wrote: Indexes speed up read operations but slow down writes. I can't imagine a lot of writes happening to public_keys. ;-) revision_certs would get four or more inserts per commit, and obviously sync operations would add a bunch. Commits have generally been pretty fast for me. Would there be a way to tell sqlite to ignore indices for given operations, such as pulls? Chad ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone speedup by adding additional database indices?
Chad Walstrom [EMAIL PROTECTED] writes: [...] Would there be a way to tell sqlite to ignore indices for given operations, such as pulls? That strikes me as a low-level question that should be ignored (at least unless it causes some measurable problem). One would hope that SQLite will only (or mostly, anyway) use indexes when they'll be beneficial. Index updates strike me as more likely to be a problem, but I doubt it makes sense to suggest sometimes not updating indexes. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone Summit 2008
Hi folks! Is there a general interest of doing another summit next year - maybe again in January/February? We should have more than enough topics for it, a lot of things still nag my personal feeling about monotone (automate interface, selectors, policy *cough* branches, partial pull, ...) and I think it would be a great opportunity for us all to bring monotone just another big step foward. You know I couldn't attend to the last / first one this year, but I'd really like to make it this time. But since I'm even more broken than last year all I could afford is something in Europe. Opinions? Thomas. -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] PCRE landed
On Wed, Oct 10, 2007 at 05:08:11PM +0200, Julio M. Merino Vidal wrote: Well, time at least, if space not so much after all... Well, space... you'd save all the space of boost libraries, _including_ boost-headers (which is the biggest package according to the numbers you showed). The binary packages will not need to rely on boost at all, as the header-only libraries provided by boost will be bundled into the binary. Yeah, ok - they're build deps only. In practice that doesn't make much difference for me; since I don't use binpkgs much I'll wind up with the build deps installed ~everywhere, but it's a good point nonetheless. -- Dan. pgpiZTS1I5W4f.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Monotone Summit 2008
Thomas Keller wrote: Is there a general interest of doing another summit next year - maybe again in January/February? You know I couldn't attend to the last / first one this year, but I'd really like to make it this time. But since I'm even more broken than last year all I could afford is something in Europe. Opinions? I would love to take part of it and, well, if it's in Europe it's certainly a big plus... I don't know if I could manage a 2-week leave from work-life-and-everything two years in a row =) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
