Re: [Monotone-devel] Future of monotone
[EMAIL PROTECTED] schrieb: There's the libssl package in Debian. aptitude tells me Description: SSL shared libraries libssl and libcrypto shared libraries needed by programs like apache-ssl, telnet and openssh It is part of the OpenSSL implementation of SSL. Is that at all relevant? Take a hard look at licensing. libssl was (last time I looked) 4-clause bsd licensed (bsd + advertising), and thus triggered the license incompatibility mode of the GPL. There might be some GNU/GPL rewrite of it - at least something along that lines was planned. But given that other libssl-using GPL sources aren't build against such a replacement in the Debian repository (eg. netatalk), I might be mistaken on it (or that project just isn't far enough yet) Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
On Tuesday 29 January 2008 Nathaniel Smith wrote: My current feeling is that separating out signer from author is a bad idea. The cost of having them is paid all the time different identities to worry about every time you print a log message, First, we already have this situation with the commit messages. With the proposal in its last form, there will only be additional author fields in the tag, suspend, and test-result certs, of which we don't have that many. Second, we should probably ask our users what they really want. And if I remember correctly there were voices (from the Pidgin devs?) asking even for being able to store several authors. We also should have a look at what other VCSs do here - does e.g. git discriminate between author and signer? Also, I don't think that printing the signer for log etc. is appropriate at all. The combination of signer and correct signature determines whether I'm actually accepting a cert, and does not necessarily count as the actual payload of the cert. The cost of not having them is this annoyance with database rebuilds, which are *very* rare, and for them ad hoc techniques suffice. (For instance: just munge a note about the original author into the commit message programmatically.) Uh. This means that e.g. front ends would have to parse that again? And how do you know whether it was munged in programmatically or by hand? - Thomas 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] Future of monotone
Hi, Sebastian wrote: ...like - just put a mtn binary in your $PATH and use your online-Repo over ssh (couldn't find any other RCS doing this). Thanks for joining the pro-voices. I'd also like to add: straight and clear separation between the copy of the repository history and your working directories. There are drawbacks on all the others too. I like monotone the best. Yeah, me too. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
On Jan 29, 2008, at 5:45 AM, Nathaniel Smith wrote: On Mon, Jan 28, 2008 at 08:51:03PM -0700, Derek Scherger wrote: One reason for separating out the author from the signer is that, in the event of a database rebuild, all certs will be re-signed by whoever does the rebuild and the original author is lost. This has happened a few times in the monotone history and while not a huge problem does leave rebuild a little more lossy than it could be. My current feeling is that separating out signer from author is a bad idea. The cost of having them is paid all the time -- you have two different identities to worry about every time you print a log message, there are security concerns (people who are confused about identity can cause a mess), etc. The cost of not having them is this annoyance with database rebuilds, which are *very* rare, and for them ad hoc techniques suffice. (For instance: just munge a note about the original author into the commit message programmatically.) Another situation where the signer/author diference is useful is when committing patches on behalf of other people. Git has this feature and I have found it useful under some situations. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
Hi, Zbigniew Zagórski wrote: Ha... I think it's Graydon leave effect ... everybody is now on steroids ;) See releases ? ViewMtn, Guitone, mtteam is also preparing a demo ... Hope this enthusiasm will last for long... I certainly hope so, yes. ;-) Unfortunately I've recompiled head, ran tests and times are the same as with 0.38, so your code is slower. I didn't wanted to bring bad news ... :( No problem, thanks for the performance tests. BTW: please don't drop the mailing list and reply to all. Or can the list admin make the mailing list set a reply-to header, or something? Hmm, it's my common mistake to hit Reply only but this time I'm innocent. I've noticed later on, sorry. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Future of monotone
Thomas Moschny [EMAIL PROTECTED] writes: [...] We also should have a look at what other VCSs do here - does e.g. git discriminate between author and signer? Signing is much less significant in git. Having one person commit something that someone else authored is routine (it's the way that most public git projects operate), and yes, git distinguishes committer and author. Ordinarily the tools show the author of commits. Quite separately, it's conventional to put lines in commit messages like Signed-off-by:, Acked-by:, Reviewed-by: to indicate various kinds of approval of a commit. (In git, the commits (including the log messages) invoke the history DAG.) I'm not exactly sure quite how this might connect to monotone. A normal way of using git is for someone to commit something to their local repository, then email it upstream (using git format-patch, git send-email). Then the person upstream commits it to their repository (git am), perhaps modifying it slightly (and quite often modifying it by adding Signed-off-by:). Monotone doesn't really have commands facilitating that. Rather, it would be normal either for someone to be granted write access, or for them to offer access to their server. (Those are also possible in git, and in those cases the committer and author are the same.) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
Hi, Nathaniel Smith wrote: If you need clean roundtripping, author fields are hardly your worst problem. Sure, but that's no reason for dropping differentiation between signer and author. You're going to need to add extra system-specific metadata regardless, and hey, look at these nice user-extensible cert things... :-). Sure, but to show the correct author in 'mtn log' or 'mtn annotate' et al, that would then have to parse *all* possible third-party VCS source metadata certs. And no, dropping that information isn't an option, IMO. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
Hi, Kelly F. Hickel wrote: Hmm, doesn't that suggest that *every* cert needs an original signer in addition to the signer? Uh.. yeah, sort of. We were referencing to that person as the author, I think. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Tue, Jan 29, 2008 at 10:41:21AM +0100, Patrick Georgi wrote: There might be some GNU/GPL rewrite of it - at least something along that lines was planned. But given that other libssl-using GPL sources aren't build against such a replacement in the Debian repository (eg. netatalk), I might be mistaken on it (or that project just isn't far enough yet) You're thinking of GnuTLS, which AFAIK is mature. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
On Tue, Jan 29, 2008 at 12:40:56PM +0100, Markus Schiltknecht wrote: Yeah, and that argument gets even stronger if you take imports or pulling from foreign VCSes into account: you will have to pull in commits, tags and branches, and certainly can't recycle the cert from the source VCS (if here even is such a thing). Having distinct signer and authors for tags and branches makes sense in those cases, IMO. Deferring that complexity to commit messages, which then have to be parsed by third party tools strikes me as a rather bad idea, taking flexibility from monotone. If you need clean roundtripping, author fields are hardly your worst problem. You're going to need to add extra system-specific metadata regardless, and hey, look at these nice user-extensible cert things... :-). -- Nathaniel -- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
Hi, Derek Scherger wrote: One reason for separating out the author from the signer is that, in the event of a database rebuild, all certs will be re-signed by whoever does the rebuild and the original author is lost. This has happened a few times in the monotone history and while not a huge problem does leave rebuild a little more lossy than it could be. Yeah, and that argument gets even stronger if you take imports or pulling from foreign VCSes into account: you will have to pull in commits, tags and branches, and certainly can't recycle the cert from the source VCS (if here even is such a thing). Having distinct signer and authors for tags and branches makes sense in those cases, IMO. Deferring that complexity to commit messages, which then have to be parsed by third party tools strikes me as a rather bad idea, taking flexibility from monotone. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
Hi, Zack Weinberg wrote: 2) On .experiment.encapsulation, selector completion is done totally differently. I'm not sure what prefix_matching_constraint() needs to turn into, but I'm sure it won't work in its present form after .e.e lands. Okay, I've just propagated and fixed everything from n.v.m.e.e to that unhexification branch. For convenience, I've also suspended the other revision, so there's just one un-suspended head now in n.v.m.experiment.db-compaction (44f34ded75a62aceb6eb42b69d3704ede8a69707). All tests succeed on my box again. The prefix_matching_constraint() function prepares an WHERE clause, which imitates the sqlite'ism named 'GLOB'. Instead of using a clause like WHERE id GLOB 'deadbe*' It now prepares a where clause more similar to: WHERE id = 'deadbe' AND id = 'deadbf' In a way, this is a work around for the missing support of GLOBing binary fields in SQLite. On the other hand, I like the above boundary think better, because it's more SQL compliant, IIRC. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Jan 29, 2008 9:41 AM, Patrick Georgi [EMAIL PROTECTED] wrote: Take a hard look at licensing. libssl was (last time I looked) 4-clause bsd licensed (bsd + advertising), and thus triggered the license incompatibility mode of the GPL. There might be some GNU/GPL rewrite of it - at least something along that lines was planned. But given that other libssl-using GPL sources aren't build against such a replacement in the Debian repository (eg. netatalk), I might be mistaken on it (or that project just isn't far enough yet) Could dropbear (a lightweight SSH2 server and client) be of help here? I have no experience handling various licenses, but a brief look into it's LICENSES file seem to indicate it's not incompatible with the GPL (didn't see any advertising clause). Regards, ~Nuno Lucas Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
RE: [Monotone-devel] Re: Future of monotone
One reason for separating out the author from the signer is that, in the event of a database rebuild, all certs will be re-signed by whoever does the rebuild and the original author is lost. This has happened a few times in the monotone history and while not a huge problem does leave rebuild a little more lossy than it could be. Cheers, Derek Hmm, doesn't that suggest that *every* cert needs an original signer in addition to the signer? -Kelly ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Future of monotone
Julio M. Merino Vidal [EMAIL PROTECTED] writes: On Jan 29, 2008, at 12:22 PM, Bruce Stephens wrote: [...] Having one person commit something that someone else authored is routine (it's the way that most public git projects operate), and yes, git distinguishes committer and author. Ordinarily the tools show the author of commits. Quite separately, it's conventional to put lines in commit messages like Signed-off-by:, Acked-by:, Reviewed-by: to indicate various kinds of approval of a commit. (In git, the commits (including the log messages) invoke the history DAG.) Which to me is wrong because you are then putting meta-data inside a free-form (commit message) field. We'd easily handle those with separate certs, being signer and author just a subset of them. Sure, I'm not necessarily recommending it as an approach for monotone. If git had something like certs, doubtless they'd be used for this kind of information. In practice it seems to work fine, though. commits aren't free-form, there are headers which specify the tree (the manifest, I guess), the parents, the author (and timestamp) and committer (and timestamp). I guess those are the things that need to be accessed most often. As far as I know there are no tools which do anything much programmatically with Signed-off-by:, etc. Those things are intended for occasional human use. (There are exceptions which do syntax highlighting and so on.) If monotone had a bundled cert containing the usual things (branch, date, author, log message), then perhaps it would be sufficient for *that* cert to have the extra author field, but for other more special-case certs not to. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Future of monotone
On Jan 29, 2008, at 12:22 PM, Bruce Stephens wrote: Thomas Moschny [EMAIL PROTECTED] writes: [...] We also should have a look at what other VCSs do here - does e.g. git discriminate between author and signer? Signing is much less significant in git. Having one person commit something that someone else authored is routine (it's the way that most public git projects operate), and yes, git distinguishes committer and author. Ordinarily the tools show the author of commits. Quite separately, it's conventional to put lines in commit messages like Signed-off-by:, Acked-by:, Reviewed-by: to indicate various kinds of approval of a commit. (In git, the commits (including the log messages) invoke the history DAG.) Which to me is wrong because you are then putting meta-data inside a free-form (commit message) field. We'd easily handle those with separate certs, being signer and author just a subset of them. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Mon, Jan 28, 2008 at 05:04:33PM +0100, Markus Schiltknecht wrote: Thomas Keller wrote: So where lacks monotone the most? While this list of *lacking* features is very appreciated, I feel it's also important to point out where monotone is shining. What comes to my mind: - very strong integrity checking - compiled C++ code, not interpreted - pretty thought-through and flexible certification concept (IMO) - database backend (SQL compliance) - dedicated multi-branch netsync protocol - ease of extensibility by lua hooks - ease of setting up a netsync server - I can write bots to apply test-result certs, and use monotone-viz to look at the status of the tree over time - the database is a single file that can easily be shared with multiple workspaces - clean conceptual model: certs, attributes - a tag doesn't create a new revision - monotone will find bad drive controllers - supports strong partitioning of projects (via merge_into_dir) - simple to automate with the list goes on. I've got ~1100 branches with ~100k revisions, ~780k of files, with 20GiB of databases spread out over 2 clusters of 3 machines each. --Jack -- Jack (John) Cummings http://mudshark.org/ PGP fingerprint: F18B 13A3 6D06 D48A 598D 42EA 3D53 BDC8 7917 F802 pgpVkkt8rVRE8.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Tue, Jan 29, 2008 at 09:30:24AM -0800, [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 05:04:33PM +0100, Markus Schiltknecht wrote: Thomas Keller wrote: So where lacks monotone the most? Lets make an entry in the dream-on category: I miss the ability to merge revisions to tree-structured files while guaranteeing that tree structure remains properly nested. (what kinds of tree structures? Well, XML comes to mind because it's standard; indented text comes to mind because there's so much of it. Things with brackets also, but maybe I'm getting greedy here :-) This could be done with syntax plugins for various file types. There might be other uses for such plugins) I don't expect anyone to provide this this anytime soon, and as far as I know, no revision management system does this. (but would it be useful if monotone were to be able to merge C files without violating statement nesting? Or considering it a merge conflict if it were inevitable?) -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Tue, Jan 29, 2008 at 09:30:24AM -0800, [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 05:04:33PM +0100, Markus Schiltknecht wrote: Thomas Keller wrote: So where lacks monotone the most? Just wondering -- can monotone sync between mounted file systems (instead of over a network cinnection? I have a Linux hand-held. The easiest way to communicate with a desktop machine is to connect it with a USB cable, wherupon the hand-held acts like a USB disk drive. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
[EMAIL PROTECTED] writes: I've got ~1100 branches with ~100k revisions, ~780k of files, with 20GiB of databases spread out over 2 clusters of 3 machines each. Oh please, give us some numbers on http://venge.net/monotone/wiki/ProjectsUsingMonotone ! -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
Hi, Ludovic Brenta wrote: Sorry to interrupt but in standard SQL there is WHERE id LIKE 'deadbe%' and I happen to use it occasionally on the command line. I'm worried that that won't be possible anymore after the unhexification. Agreed. Unfortunately the '%' doesn't work that well for binary values, so yes, you would loose the ability to query directly via LIKE. The following supposedly still works, provided you use a monotone enhanced sqlite, which provides an unhex() function: WHERE unhex(id) LIKE 'deadbe%' Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] unhexification of revision hashes
Markus Schiltknecht writes: The prefix_matching_constraint() function prepares an WHERE clause, which imitates the sqlite'ism named 'GLOB'. Instead of using a clause like WHERE id GLOB 'deadbe*' It now prepares a where clause more similar to: WHERE id = 'deadbe' AND id = 'deadbf' Sorry to interrupt but in standard SQL there is WHERE id LIKE 'deadbe%' and I happen to use it occasionally on the command line. I'm worried that that won't be possible anymore after the unhexification. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Future of monotone
Graydon Hoare wrote: My plan here was to rip out netsync, packets, basic_io, netio, and the old cert system. Put in the new cert system and the new sync system, and replace the automate commands with json-speaking equivalents. Do away with all the legacy i/o stuff, and provide one that's actually easy to speak. The idea was that this would both make hosting and deploying much easier -- HTTP is more friendly Oh, I also forgot to add: HTTP has a well-defined mechanism for vhosting or placing multiple mtn scgi slaves serving different databases under the same external-facing HTTP port. I think this is a better solution than the hand-built usher system we have. And doing SSL. And lots of stuff. But the main point was just to make it easy to talk to without any intermediaries. JSON+HTTP is very appealing to frontend authors. There's a very large body of people who program browser-resident UIs exclusively now, and they are most comfortable with something they can XHR to get JSON blobs from. If you integrate the database sync service and general public data browsing interfaces, your frontends can develop 100% on the client side, without any special setup effort. -Graydon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Future of monotone
Thomas Moschny wrote: On Monday 28 January 2008, Graydon Hoare wrote: I think it's a good branch as they go in this sort of thing. I just ran out of interest. Sorry to hear that, but that's life, it seems. It contains a variety of interrelated new code. Anyone else is welcome to pick it up of course. The changes are, primarily: [...] - a sketch of the long-planned upgrade to certificates Can you explain that a bit? Is this related to the idea of creating combined certs consisting of a author/date/msg/branch tuple? Yes, though there was a huge following thread in which most of the issues were probed by others here :) Pretty much my reasoning was: - We need a new sort of 'branch' cert that points to a symbolic branch ID rather than a string branch name. - The 'branch' cert is really a 'commit' or 'approve' cert, so we might as well gain some semantic clarity and cut down the amount of crypto overhead (signatures are not small) by bundling the commit/approve date, author(s), and comment fields. Of course these would be separate from signing key ID and signing date. Authors don't even need to be formally identified by keys. They can be strings. - It'd be good to shove a version number and/or algorithm ID in there for vague hand-wavey future proofing. Not that one can ever be safe from the future. Perhaps this is embarrassing, but I thought 'suspend' certs had to do with shutting down branches, and all the possible policy-branch designs (even the most minimal) have a concept of a branch lifecycle, with a revivable 'dormant'/'active' state and a sticky 'revoked' state. -Graydon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
On Jan 29, 2008 6:18 PM, Sebastian [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: Just wondering -- can monotone sync between mounted file systems (instead of over a network cinnection? I use mtn sync ssh://[EMAIL PROTECTED]/media/usbdisk/monotone/xy.mtn '*' mtn sync file:///media/usbdisk/monotone/xy.mtn '*' will probably be faster and not require a password :-) (We should make mtn sync /media/usbdisk/monotone/xy.mtn do the Right Thing, if it doesn't already.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Future of monotone
[EMAIL PROTECTED] schrieb: Just wondering -- can monotone sync between mounted file systems (instead of over a network cinnection? I use mtn sync ssh://[EMAIL PROTECTED]/media/usbdisk/monotone/xy.mtn '*' Enter my password and everything is fine :-) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
