Re: [Monotone-devel] 3rd party libraries
On Fri, Oct 24, 2008 at 3:51 AM, Matthew Nicholson <[EMAIL PROTECTED]> wrote: > Markus Wanner wrote: > >> In the archive I've read that boost::program_options didn't do what we >> want. Looking at the boots documentation, I also see boost::asio - could >> that perhaps be a better replacement for the (unmaintained) netxx? >> Anybody used boost::asio before? >> > > I use boost::asio in my astxx library. I have not had any problems with it, > seems well designed. Also there is a non-boost version of it for the anti > boost crowd (I happen to be pro-boost). The description of the differences might be of interest: http://think-async.blogspot.com/2008/05/boostasio-vs-asio.html Particularly > — Asio is header-file-only and for most uses does not require linking against > any Boost library. Boost.Asio always requires that you link against the > Boost.System library, and also against Boost.Thread if you want to launch > threads using boost::thread. Zbynek -- http://robotika.cz/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Markus Wanner wrote: In the archive I've read that boost::program_options didn't do what we want. Looking at the boots documentation, I also see boost::asio - could that perhaps be a better replacement for the (unmaintained) netxx? Anybody used boost::asio before? I use boost::asio in my astxx library. I have not had any problems with it, seems well designed. Also there is a non-boost version of it for the anti boost crowd (I happen to be pro-boost). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
Zack Weinberg wrote: On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: * lua: pretty similar to sqlite, except the source inclusion variant is a bit more complicated. I'm all for dynamic linking and don't see much of a reason for source inclusion. I think I mentioned this before, but if we're going to stop bundling lua we have to overhaul the error-handling interface between lua and our code, because we're currently relying on lua's ability to be compiled as C++ and use C++ exceptions to report errors. Of course we need to overhaul it *anyway* because right now lots of errors just silently get lost, but remember that this is on the critical path for unbundling it. Yeah, I recently noticed the same issue. To properly unwind the stack on error in a c++ app, lua needs to be compiled with a c++ compiler. It uses setjmp and longjmp for error handling when compiled as C and exceptions when compiled as C++. If we don't require stack unwinding on error (I have not looked at the code), then dynamic linking is fine, but I think this is a candidate for bundling. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: > * libz: dynamic linking hasn't posed any problems and the library seems > to be available on pretty much any system. libz is a shining example of how to do library stability. (It helps that it hasn't needed to change in years and years except for the occasional bugfix. :-) > * botan: source inclusion *has* posed problems in the past, namely that > we couldn't use asm optimizations due running our own build harness for > botan. Additionally, maintaining the build harness was a hassle and > something I'm glad to get rid of. The library is still pretty new and > not available on all systems. We are currently using a development > branch (1.7), which is a bit unfortunate. However, I've adjusted > nvm.stripped, so that it compiles against 1.6.x as well. I'm all for > dynamic linking of that library. I'm all for dynamic linking of botan, too, and being able to use the accelerated engines. > * sqlite: source inclusion worked fine so far, but it hasn't really > been updated for quite awhile. nvm.stripped provides dynamic linking, > but SQLite also offers a pretty simple amalgamation release, which we > could use as well. Offering choice between system library and bundled > one should be simple enough to maintain, IMO. So I believe this is the one that started graydon on the "bundle everything" path, with specific point revs of sqlite 2.x working for us and others not, and over at my day job we've been having similar problems with more recent releases of it. So it may well be worth continuing to bundle a "known good" version of the amalgamation. If we do, though, we should be much more proactive about testing newer releases so we don't wind up where we are now (i.e. stuck multiple feature releases behind the curve) again. > * lua: pretty similar to sqlite, except the source inclusion variant is > a bit more complicated. I'm all for dynamic linking and don't see much > of a reason for source inclusion. I think I mentioned this before, but if we're going to stop bundling lua we have to overhaul the error-handling interface between lua and our code, because we're currently relying on lua's ability to be compiled as C++ and use C++ exceptions to report errors. Of course we need to overhaul it *anyway* because right now lots of errors just silently get lost, but remember that this is on the critical path for unbundling it. > * pcre, idna: I'm not too sure about these, but dynamic linking seems > to make more sense. I didn't hit any stumbling block so far in nvm.stripped. Concur. API/ABI stability shouldn't be an issue with these. > * boost: we've done quite a lot of work to get rid of boost and > replaced it with our own code. Discussed in other message. I'd forgotten about boost::test, but it was another case of the wrong abstraction for our needs; in particular it was really painful integrating it with our I(), E(), etc macros. > If not, we need to decide if we want to re-add boost::date_time to > replace our own date handling code. mtn-dates.o from nvm.dates is > currently 89 KiB on my 64bit machine, while the boost::date_time .so > file weights only 60 KiB (presumably lots of header only stuff). From a > quick glance at the docu, it does much more than what's currently > covered by nvm.dates. But improved date parsing would be nice to have. > Not sure if it provides the same independence from the system's epoch as > we currently do. As I said in my other message, I recall its having specific portability bugs that hurt us. Regarding file size, are you sure you're not counting debug information? On my (also 64-bit - amd64) machine, the file is 129KB, but 'size' says it's only got about 7KB of actual code in it. That's a n.v.m build; I haven't built your .dates branch but I don't see anything in there that would bulk it up that much. Improved date parsing certainly would be nice to have but I think if we're going to do anything there, it oughta be that we figure out how to use gnulib's getdate.y, which is the gold standard as far as user-supplied date parsing. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3rd party libraries
On Thu, Oct 23, 2008 at 3:38 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> On IRC we recently had a discussion about using boost::date_time instead
> of rolling our own in dates.{cc,hh} - as I've been doing in nvm.dates.
> I've been under the impression, that we do not want to rely on boost
> libraries. But in nvm.stripped I'm working on linking monotone against
> other libraries as well, so it seems we need to revisit the question of
> how to work with 3rd party modules in general.
In this message I just want to address the boost situation. I feel
very strongly that we shouldn't use any boost module that isn't
"header-only" ever again, and that we should maybe even stop using the
header-only modules as well. This is an extreme position but I think
it's justified:
The boost modules with link libraries do not present a stable ABI.
The number one cause of segmentation faults in monotone used to be
that the binary was being dynamically linked with boost libraries that
weren't an *exact match* for the headers it was compiled with. Since
we stopped using those, I can't remember the last time we had a
segfault reported. By me that's sufficient reason not to use them,
all by itself. We could bundle them, I suppose, but we never did that
in the first place because - as you mentioned yourself - the boost
build system is nonstandard and difficult to work with. It becomes
significantly less troublesome if you only want header-only libraries,
but it's still fiddly enough that it's not worth it IMO.
It's true that boost::regex was bloated (or rather, in many distro
builds it dragged in the bloated ICU libraries, whose functionality we
weren't even using) but that was secondary to the ABI problems in my
estimation.
Also, all of the boost modules (header-only or not) are code we do not
control that is written right at the bleeding edge of the C++
standard, and therefore has caused trouble with new-and-pickier or
old-and-buggy compilers in the past, on several occasions.
Finally, it has been my experience that many of the boost modules
present abstractions that are a poor fit for what we need in this
project. boost::fs was a good example -- it wasn't just slow, it was
causing impedance mismatches *everywhere* we had to convert from
boost::fs objects to internal path objects or vice versa, and there is
still a lot of code in the current tree that's slower than it should
be because I never finished cleaning it up after we got rid of
boost::fs. And you know how we've never done non-ASCII file names
correctly? That's because boost::fs made it impossible. We could do
it now, it would just involve a lot of code auditing.
boost::date_time was inflexible and not portable enough (it got time
zones wrong on Windows, if I remember correctly). I wasn't paying
close attention to the brief use of boost::program_options, but I am
not surprised it was trouble, either.
Of the boost modules we still use, though, I really only have a
problem with boost::format. It's big, slow, and its authors refuse to
implement the numeric format specifiers correctly, which means ugly
casts are required in a few places. The smart pointers, the random
number generator, the tokenizer, lexical_cast, etc. those I'm fine
with, API-wise. I mainly think we might want to consider not using
them because of the compiler trouble they have caused in the past, and
I'm not sure it would be worth the programmer trouble of coming up
with replacements.
Also, I've read the boost::asio docs and I actually think that would
be a good thing to be using. The abstractions look sane, the author
appears to understand what you need to do to get a stable C++ ABI, and
it would certainly be an improvement over the unmaintained 'netxx'
thing we have now. But I'd much rather we used it in its standalone
"libasio" incarnation, that doesn't pull in any other boost modules.
I'm going to send another message that responds to the rest of your
points, including the dates stuff.
zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: mtn & GPG signatures [Was: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL]
Lapo Luchini wrote: (yes I know, it's not easy to check it's the *same* mtn key that's in your DB as "[EMAIL PROTECTED]" and you received using netsync… and that part of the UI must be improved to show some unique hash at least when keyids It would be most useful if the UI would display the key hash when displaying signatures. That way you can be sure that the key that signed the revision really is the same key you are looking at. Brian May ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Brian May wrote: Markus Wanner wrote: Huh? How should that be possible? Isn't it sufficient exchanging known public keys during netsync? Only if you trust the database you are syncing from. Especially for the initial sync from an exmpty database. Err. I got distracted as I was double checking my email. I meant to say: Only if you trust the database you are syncing from. Especially for the initial sync *to* an empty database. of course... Brian May ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Markus Wanner wrote: Huh? How should that be possible? Isn't it sufficient exchanging known public keys during netsync? Only if you trust the database you are syncing from. Especially for the initial sync from an exmpty database. Brian May ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Daniel Carrera wrote: I don't agree. What I propose would be no worse than naming the key '[EMAIL PROTECTED]' which is the current system. I'm just making the existing system more convenient. Getting back on topic (not that the diversion wasn't interesting), you can't authorize somebody to have access unless you can authenticate them first. In my version of monotone: [EMAIL PROTECTED]:~/tree/ikiwiki/public/wiki$ mtn ls keys [public keys] e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 [EMAIL PROTECTED] d22a65c6ed5d212ec319acbbb3a9012123928899 [EMAIL PROTECTED] a7c3deef8f1005230be3e216acc052d473fea994 [EMAIL PROTECTED] 1c5099967954a7acebebd2ee7bbf4abd2f35e01f [EMAIL PROTECTED] ... The hash on the left side is secure, it can't change. Key e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 will always be key e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6. If it changes then it isn't key e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 any more, but another key. As such using e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 is secure, as it is also not feasible for somebody else to come up with a e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 that pretends to be my key. Unfortunately, e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 means nothing to most people. If you added e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 to ~/./monotone///read/-/permissions or /~/./monotone//write-/permissions it means nothing. Just who is allowed access? Maybe you know when you added the entry, but maybe several years later./ If you see e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 signed a certificate, just what does that mean? Nothing. // /So you need to identify the user associated with key /e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6. Monotone does this, I believe (I haven't looked at the details), by storing the key alongside an identifier in the database. This identifier is used in ~/./monotone///read/-/permissions and ///~/./monotone//write-/permissions. It is also used in the output of "mtn ls certs " where you can find out who signed a particular revision. ///The problem is there is no security in mapping the key to the keyid. If I look at the output of / "ls certs " and see that it was signed by "/[EMAIL PROTECTED]" how do I know it was signed by keyid e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6? I don't. More importantly, how do I know it really was signed by /"/[EMAIL PROTECTED]"? I don't. As far as I am aware, there is nothing to stop an attacker changing the mappings in the database, to look like, maybe: [public keys] e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 [EMAIL PROTECTED] d22a65c6ed5d212ec319acbbb3a9012123928899 [EMAIL PROTECTED] a7c3deef8f1005230be3e216acc052d473fea994 [EMAIL PROTECTED] 1c5099967954a7acebebd2ee7bbf4abd2f35e01f [EMAIL PROTECTED] 44af5cdd1394964a2adc4de086234c1a76f94a18 [EMAIL PROTECTED] Now everything that was signed by key e17e2bdd1721ad25f2c439a6e7df12d8b6f141b6 will look like it was signed by [EMAIL PROTECTED], and everything that appears to be signed by "[EMAIL PROTECTED]" is actually signed by a key that only the attacker was the corresponding private key. This isn't a problem so far - the attacker has only stuffed up his database - however the attacker can trick other people into synchronising from his database... Now lets try this in practice: I think the way to carry out this attack would be to directly modify the values within the public_keys table: sqlite> .dump public_keys BEGIN TRANSACTION; CREATE TABLE public_keys ( hash not null unique, -- hash of remaining fields separated by ":" id primary key, -- key identifier chosen by user keydata not null-- RSA public params ); INSERT INTO "public_keys" VALUES(X'1C5099967954A7ACEBEBD2EE7BBF4ABD2F35E01F', '[EMAIL PROTECTED]', X'30819F300D06092A864886F70D010101050003818D00308189028181009A26A7E43E0E3218DE6FC1AA48FCD22F31928695449B4D712E5EAC420248AF374143A9F27D6406F758E7B103DBE5D40232D91ACFF8FC72C719B4E03D010410017931F7F915D4AADDFC220FE8844D3BDE2108D58B5D5ECBF3CE555B36517B7B5C3B92BC859BED0A64C13F554838A5D8FC34B7F89F02AC7CE2280F2B6749251EE90203010001'); INSERT INTO "public_keys" VALUES(X'D22A65C6ED5D212EC319ACBBB3A9012123928899', '[EMAIL PROTECTED]', X'30819F300D06092A864886F70D010101050003818D0030818902818100C65679E8F852BA66226C66BA2A87DA25761AC18129815174B34DE14FA5E93D951F51950A8335BA2A314308414E1129E58E92EBF826B049CD602A83EE55CAF8C9EEF2C95B4C2AED5FD41329315859DDE8142474491346C3A759C23C0FCEF73DD4745F62A189BA375578E5B373195358E14744F8DEBE6CD81FBA13401F3B6CC7C30203010001'); INSERT INTO "public_keys" VALUES(X'E17E2BDD1721AD25F2C439A6E7DF12D8B6F141B6', '[EMAIL PROTECTED]', X'30819F300D06092A864886F70D010101050003818D0030818902818100A1B79A84D5FFC20B3ECF19D756C991D0614618C748FA9AA5D423CE73B80D184FD9FE033005BC9B7E6A3110B5D38F3CFABEA3D8A34192820D1D5481465755BB93E65F9A932C119480B8E519B472B4716DEA35719F96B56C75A4DAAAD8EE7357919D1A88A204B2B773F5C341E9246D73E5955DDAA1D55DCB799D22957B26ACDCBB0203010001'); INSERT INTO "
Re: [Monotone-devel] date certs on net.venge.monotone
On Thu, Oct 23, 2008 at 5:12 AM, Markus Wanner <[EMAIL PROTECTED]> wrote: > Thomas Moschny wrote: >> So, I don't think we should warn there. > > Even make hints about clock skews. Why is that so unwanted for monotone? Make warns about clock skew (between your local host and its NFS server) because such clock skew breaks Make. Right now, clock skew (between all the hosts used by everyone in a distributed development project) does not break monotone; it continues to provide its basic functionality of managing revisions just fine. Your proposal would compromise this core functionality (either by causing revisions to disappear, or just printing annoying warning messages), so as to better provide the functionality of letting people know that someone else's clock that they can't fix is broken. I understand the impulse, but I don't see how this is the right place for it -- if I really want to know about clock skew, there are better ways to find out, and if don't have access to those better ways, I can just run that script you wrote over my monotone history anyway. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] date certs on net.venge.monotone
Hi, Thomas Moschny wrote: > Monotone stores timestamps in the date certs in UTC, of course. Nevertheless, > clocks for each developer might differ a bit such that commits appear to be > made in non-chronological order. That's theoretically possible, though pretty rare in practice. > So, I don't think we should warn there. Even make hints about clock skews. Why is that so unwanted for monotone? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Thomas Moschny wrote: >> Why would you want to warn about that? > > So, I don't think we should warn there. My opinion regarding that warning depends on the offset: of course something up to a few minutes delta means nothing (simply the user didn't care use NTP), a delta up to one day means little (the user didn't configure the timezone), but a delta over one day is wrong for sure… I'm sure a warning would be nice to have in that last case, but probably also in the middle one. For me, I'd like a warning also in the first case (I'm an NTP-freak), but I would never suggest an "option" to change its behaviour, clutters the UI more that acceptable for what it gives, IMHO… -- Lapo Luchini - http://lapo.it/ “I do engineering, not religion.” (Daniel J. Bernstein) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] date certs on net.venge.monotone
Hi, Stephen Leake wrote: > If there is no global shared clock, then developers working in > different time zones can easily commit revisions to a shared server > that have timestamps using local times that appear to be "out of > order" with respect to each other. Any sane OS today knows the difference between local time and UTC. Measurement shows that this is not an issue (except maybe for Xaraya, which needs further investigation) > On the other hand, there are such things as global clocks; we use them > all the time at NASA. If each developer on a team commits to > configuring their computer such that the functions "local_to_UTC" and > "UTC_to_local" work properly, My assumption is that most clocks are close enough to "the" global clock to be useful for mtns purpose. Looking at the dates in nvm, this assumption holds true for the vast majority of committed revisions. > monotone could support an option to use > UTC times for timestamps. Monotone currently uses UTC dates for its certs, which might not be overly user friendly. However, we do not take leap seconds into account within our own date calculation routines. > TAI might be a better global time choice, > since it doesn't do leap seconds, and hence is monotonic. Conversion between UTC and local time is pretty simple on most systems, where as UTC to TAI and back is not as common. IMO the user shouldn't need to care about anything except local time. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Stephen Leake wrote: > TAI might be a better global time choice, > since it doesn't do leap seconds, and hence is monotonic. Duh! Isn't UTC monotonic as well, even if it sometimes "changes speed"? AFAIR leap seconds mean a minute with either 59 or 61 seconds, nothing never "jumps" ahead or behind… but I should probably refresh my UTC a bit. OTOH TAI seems nice and good and has an "official" 64 bit representation; DJB wrote a (now public-domain) library for it too: http://cr.yp.to/libtai.html -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] date certs on net.venge.monotone
Stephen Leake wrote: > Markus Wanner <[EMAIL PROTECTED]> writes: > > I'm just proposing to check the date and warn the user if it obviously > > doesn't match. It would help making that meta-information more reliable, > > nothing more, nothing less. > > If there is no global shared clock, then developers working in > different time zones can easily commit revisions to a shared server > that have timestamps using local times that appear to be "out of > order" with respect to each other. Monotone stores timestamps in the date certs in UTC, of course. Nevertheless, clocks for each developer might differ a bit such that commits appear to be made in non-chronological order. > Why would you want to warn about that? So, I don't think we should warn there. - Thomas -- Thomas Moschny <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] date certs on net.venge.monotone
Markus Wanner <[EMAIL PROTECTED]> writes: > I'm just proposing to check the date and warn the user if it obviously > doesn't match. It would help making that meta-information more reliable, > nothing more, nothing less. If there is no global shared clock, then developers working in different time zones can easily commit revisions to a shared server that have timestamps using local times that appear to be "out of order" with respect to each other. Why would you want to warn about that? On the other hand, there are such things as global clocks; we use them all the time at NASA. If each developer on a team commits to configuring their computer such that the functions "local_to_UTC" and "UTC_to_local" work properly, monotone could support an option to use UTC times for timestamps. TAI might be a better global time choice, since it doesn't do leap seconds, and hence is monotonic. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] date certs on net.venge.monotone
Hi, Ethan Blanton wrote: > That is correct. It actually caused problems for us at some point, > when something related to monotone started rejecting those fractional > second values. The oldest revisions in that Pidgin data started out > as CVS, were migrated to SVN, and then subsequently migrated to > Monotone. There's plenty of weird and wonderful-ness in there. ;-) Aha, thanks for confirmation. > Which brings me to a (yet another) reason that I don't think this > mucking about with date certs is a good idea -- there are almost > certainly *correct* date certs in the Pidgin repository which are out > of order. I'm not sure what you mean be *correct* dates certs being out of order. I've counted exactly 36 discrepancies in the pidgin repository, see my mail starting this thread: > pidgin: 36 of 28349 (0.13%) > During our migration, there were a number of revisions > which, for one reason or another, had problems which made them > difficult to migrate (svn is capable of creating revisions under > normal circumstances which it cannot subsequently handle gracefully). Yeah, svn is capable of doing lots of nasty things... > There are sequences of such revisions which were collapsed to one > "patch-up" revision in the migration; the date stamp on the patch-up > revision is the date of its creation, not the date of the original > changes. This causes one date in the middle of a sequence of valid > revisions to be months or even years newer than its ancestors or > descendants. Agreed. > Generally speaking, date information in monotone is very much > meta-information. Introducing the idea of global clocks in this > manner takes it from being meta-information to being revision > information. I'm just proposing to check the date and warn the user if it obviously doesn't match. It would help making that meta-information more reliable, nothing more, nothing less. > I think this is a bad idea. If I've had a patch sitting > on my disk for 2 months, and I just now get around to committing it, > it may be a reasonable and correct thing for me to want to do to use a > --date argument to the commit of the creation of the patch, not the > commit of the patch. In that case you should certainly also commit against the parent revision you've created the patch against. So that would not result in timestamp inconsistencies. > I guess, basically, I'm not a fan of validating anything for > consistency which does not have a clear definition of consistency. In > the absence of global clocks, dates do not have consistency. The fact > that monotone currently recognizes and ignores this information is a > feature, not a bug. Monotone does not ignore the information, but create date certs from it. Ignoring it would mean dropping date certs entirely. Please keep in mind that for us human beings there *is* a global clock and we like to express ourselves in terms of date and time. Of course, monotone cannot rely on the system clock being in sync with the global clock. But as pointed out, the assumption is good enough to provide that convenience feature called "date cert". To help the user making that convenience feature more reliable, it would help if monotone checked date certs, IMO, without hurting anything else. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] 3rd party libraries
Hi,
On IRC we recently had a discussion about using boost::date_time instead
of rolling our own in dates.{cc,hh} - as I've been doing in nvm.dates.
I've been under the impression, that we do not want to rely on boost
libraries. But in nvm.stripped I'm working on linking monotone against
other libraries as well, so it seems we need to revisit the question of
how to work with 3rd party modules in general.
There are three major options, all of which we've already used:
* Dynamic linking to external libraries. We've always linked against
libz, for example. Pros: low maintenance cost for us, enjoy newer
versions by replacing the lib - Cons: dependencies on other libs, mtn
needs to (dynamically) cope with various versions of the lib.
* Source inclusion: we've done that for botan, sqlite, lua, pcre and
others. Pros: need to support only one version, independence of upstream
(i.e. netxx is dead) - Cons: high maintenance cost for us, packagers
don't like it.
* Avoid the library: we are currently doing that with boost, for
example. Pros: no dependency, no license issues, code exactly what we
need - Cons: hight maintenance and development costs for us.
I think pros and cons are pretty clear, sure you can still add some
general ones here and there. Just wanting to make sure we speak about
the same things.
Now, let's get to the single libraries we use:
* libz: dynamic linking hasn't posed any problems and the library seems
to be available on pretty much any system.
* botan: source inclusion *has* posed problems in the past, namely that
we couldn't use asm optimizations due running our own build harness for
botan. Additionally, maintaining the build harness was a hassle and
something I'm glad to get rid of. The library is still pretty new and
not available on all systems. We are currently using a development
branch (1.7), which is a bit unfortunate. However, I've adjusted
nvm.stripped, so that it compiles against 1.6.x as well. I'm all for
dynamic linking of that library.
* sqlite: source inclusion worked fine so far, but it hasn't really
been updated for quite awhile. nvm.stripped provides dynamic linking,
but SQLite also offers a pretty simple amalgamation release, which we
could use as well. Offering choice between system library and bundled
one should be simple enough to maintain, IMO.
* lua: pretty similar to sqlite, except the source inclusion variant is
a bit more complicated. I'm all for dynamic linking and don't see much
of a reason for source inclusion.
* pcre, idna: I'm not too sure about these, but dynamic linking seems
to make more sense. I didn't hit any stumbling block so far in nvm.stripped.
* boost: we've done quite a lot of work to get rid of boost and
replaced it with our own code. It began with boost::fs (see [1]) and
continued with test, regex, date_time and probably others. Now we only
rely on some boost header files, but we don't "source include" these
ATM. Reading the ML-archive, there are several complaints about
difficulties building boost, it's bjam based build harness is a bit
uncommon. Botan also provides it's own (perl based) configure script.
And autoconf is far from being everybody's friend. Boost is old enough
to be shipped with most major distributions.
The reason for removing boost::regexp were, that it's bloated. pcre is
much smaller. I'm unsure about boost::test and boost::date_time.
If we really decide to not want any boost library, I'd like to
a) be clearer about the reasons and
b) "source include" the required boost header files, so as to really be
independent of boost.
If not, we need to decide if we want to re-add boost::date_time to
replace our own date handling code. mtn-dates.o from nvm.dates is
currently 89 KiB on my 64bit machine, while the boost::date_time .so
file weights only 60 KiB (presumably lots of header only stuff). From a
quick glance at the docu, it does much more than what's currently
covered by nvm.dates. But improved date parsing would be nice to have.
Not sure if it provides the same independence from the system's epoch as
we currently do.
I've dropped boost::graph from nvm.cvsimport-branch-reconstruction and
coded my own graph stuff (i.e. a dijkstra search algo) for better
performance and flexibility (different in-memory representation from
boost's).
In the archive I've read that boost::program_options didn't do what we
want. Looking at the boots documentation, I also see boost::asio - could
that perhaps be a better replacement for the (unmaintained) netxx?
Anybody used boost::asio before?
Thoughts? Comments?
Regards
Markus Wanner
[1]: Nathaniel: boost::fs is slow:
http://article.gmane.org/gmane.comp.version-control.monotone.devel/4262
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
