Re: [Monotone-devel] interface version / command matrix
Thomas Keller <[EMAIL PROTECTED]> writes: >> Unless the tool uses _only_ automate commands, it _must_ check the mtn >> version number. I don't think automate is powerful enough for that. >> Nor do I think it needs to be. > > That is the contract interface_version guarantees. guitone _solely_ > depends on automate currently (ok, despite one very little use case > where I use mtn pubkey - but this is on my TODO list, i.e. I plan to > implement mtn automate get_public_key some time). > >>> No code changes would need to be done on the client's side to >>> support a new monotone release which does no or just a minor changes >>> to the interface. >> I define "the interface" to include the mtn commands, as well as the >> mtn automate commands. > > For me its the other way around. I program the tool against the > automation interface by purpose, because this interface is the only > one which guarantees me at least some kind of stability. Sure, there > are still a lot of missing commands and functionality, the problem of > mediocre error (plain string) reporting, no ticker support, aso. - but > this is nothing which cannot be addressed in the future. > > The "big" plan for me certainly is making automate feature-complete > (with the exclusion of some rarely needed commands like mtn crash ;), > because only when its feature-complete it can actually be useful for > everybody. And people can start using it for even more obscure things, > like providing new command line frontends which has already been done > in the past (see the mtn_automate lua function). That makes sense. However, the more features the automate interface supports, the more likely it is that some individual feature will suffer an incompatible change, and the major version will increase, incorrectly labeling all features as incompatible. So a keyword list is the right way to go. > In the development version of guitone I do the following to "commit": > > * query automate get_option branch and automate keys (the latter for > finding out the private keys which can be used to sign the certs later > on), optionally allow the user to override these values. the date cert > will be later hard-coded to the current datetime, the author can be > explicitely overwritten, otherwise I'll just use the value I got from > mtn automate keys. > * call automate get_current_revision to receive an (optionally > restricted) changeset on the current workspace > * parse this revision text and look for file patches and file adds > * iterate over these findings and call automate put_file on each of > them while reading the contents of the files from disk) > * writing the revision text to the database via automate put_revision > * write the supplied certs to the database via automate cert > * after the revision was committed successfully, I write any new > options to _MTN/options and also write out a clean (empty) revision to > _MTN/revision Thanks. > The only thing what is missing currently (but this also applies to the > usage of mtn commit) is a sane way to ask the user for passphrase > input. But again, this is also something which is on my longish TODO > list - > finding a sane way to supply the passphrase to automate. For me and Emacs DVC, I think ssh-agent is the best solution to that. That's on my todo list (ssh-agent doesn't work with mtn on Win32, at least not generally). > Feel free to add this into the monotone documentation - your English > is probably better anyways ;) Ok. I'll add the similar list for merge once I figure it out. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Hi, Thomas Moschny wrote: There is not something like a REST standard, but as far as I understood, URLs for a restful service should start with a noun denoting what is returned by that URL, and followed by some id (or, in the case of returning a set, some other arguments to further confine that set). So in my scheme, /revisions/... (plural) returns a list of revisions, /revision/... (singular) the contents of a single revision, /manifest/... returns a manifest, and so on. Hm.. I looked at the revision in a more object oriented fashion, thinking of "get ancestors", "get descendants" or "get manifest" as methods of the revision. That's where the hierarchy came from. I personally don't like having to distinguish between plural and singular. However, I don't mind much either way. Instead of returning basic_io, my service returns json for everything besides file contents (and raw output in case of the "backdoor" /cmd/...). Ah, so you were only speaking of the wire format. Yeah, that's fine with me. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Markus Schiltknecht wrote: > Very nice. Really similar to what I have in mind. With the revisions, I > remember doing something more like: > > /revision/$REVID/manifest > /revision/$REVID/ancestors There is not something like a REST standard, but as far as I understood, URLs for a restful service should start with a noun denoting what is returned by that URL, and followed by some id (or, in the case of returning a set, some other arguments to further confine that set). So in my scheme, /revisions/... (plural) returns a list of revisions, /revision/... (singular) the contents of a single revision, /manifest/... returns a manifest, and so on. > And I started with: > > /branch/$BRANCHNAME/heads That in fact can be done with a selector, so I didn't provide an URL for it. > > Note that while the urls are easy changeable, actually thoughts also have > > to be put in the design of the json responses > > Right. > > > that replace the basic_io output > > of mtn (for revisions, manifests, certs, etc.). > > Replace? You mean you would completely replace the basic_io format with > a json based one? Or are you speaking of the format for transmission > exclusively? Instead of returning basic_io, my service returns json for everything besides file contents (and raw output in case of the "backdoor" /cmd/...). Regards, 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] Monotone upgrade policy for the SQLite copy?
On Sat, Mar 29, 2008, Markus Schiltknecht wrote: > Ralf S. Engelschall wrote: >> As Monotone is already using its own build-environment > > ..which is a bad thing(tm), which we want to get rid of, IMO... The alternative is to place a full SQLite build-environment 1:1 into sqlite/ and also run its own "configure" step during Monotone's "configure" step. Certainly more complex, but as for SQLite 3.5 I now at least had to extend the m4/sqlite.m4 a little bit, it would prevent that Monotone configure SQLite differently than the SQLite upstream vendor intended. >> for building the >> sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to >> just the sqlite3.[ch] files from the SQLite "amalgamation" distribution. > > As far as I understand, the point of amalgamation is, that there's only one > preprocessed C file. No, the amalgamation "sqlite3.c" file is not really pre-processed in the meaning of the C pre-processor. But it is pre-processed in the meaning of the Lemon parsor generator, etc. It is more or less just a concatenation of the *.c source files (where parse.c is also used instead of parse.y, etc). >> Fully backward compatible on-disk format will be not possible in the >> long-term, so as long as a dump/restore is still possible everything >> should be fine. > > This is an SQL database - they cannot drop dump/restore upgrading > possibility without loosing most users ;-) Sure. Sorry for not being clear enough: I just meant "fully backward compatibility _without_ dump/restore requirements" (= just by upgrading to a newer SQLite version). >> Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x > > Very cool, thanks! And good luck! Ok, I've it running. I dropped sqlite/*, added sqlite3.[ch] and adjusted the Monotone build-environment for this. I'm now checking the functionality under run-time (especially via the test suite)... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Personal/Project/MtnSummit Introduction
Greetings! The subject is 'Introduction' and after crashing into the mailing list a few days ago I think that wouldn't hurt. **Personal** I have been following the list and the development of monotone for a few months now, and since the beginning of this year, me and a colleague are using monotone actively, mainly for concurrent development, storing source codes, project workspaces and the like. In the past I have been using CVS and was often disappointed at its missing features and circumstantial administration. After comparing a few version control systems and relatively early considering monotone, I was impressed by its ease of use, setup and the modern approaches. **Project** After not having even the slightest clue of Python and a very long night of unsuccessfully muddling around with Lighttpd, Apache and various plugins for getting ViewMTN running, I thought that a small viewing application based on PHP couldn't be that much of a problem. That thought lasted exactly to the point at which I had to understand the database structure of monotone, which I obviously didn't. The recent discussions on the new URL features have made it rather exciting for me to follow the further development, since that one would be of great help for reaching the goals of my little project rather early. And also without messing around directly with the database, thus avoiding problems like locking. Perhaps such a project isn't even desired because ViewMTN is considered to be enough of a web viewer. But if it is, maybe the work on this could be brought forward on the summit, which leads us to the next chapter: **MtnSummit** I had a little chat with Thomas Keller, wiping out my last doubts about the summit in Wuppertal, and now I am looking forward to meeting some of the people behind this great project and possibly learning more about it, mostly the advanced ranges of application. Maybe you have already seen my note in the Wiki. For your information: most of my time I am coding with Java or PHP, so the parts where I can help seem to be the Eclipse plugin, my own web viewer (if that one is welcome, see above) or the more general areas like documentation etc. Just to let you know in advance. That's about it! Now I could use a snack ;-) I am staying on IRC this evening, so if there are questions or suggestions, feel free to contact me. Last remark, since I am not a native speaker, it could take some time to get an answer from me. Now a snack, really! Best wishes, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Ralf S. Engelschall wrote: As Monotone is already using its own build-environment ..which is a bad thing(tm), which we want to get rid of, IMO... for building the sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to just the sqlite3.[ch] files from the SQLite "amalgamation" distribution. As far as I understand, the point of amalgamation is, that there's only one preprocessed C file. Fully backward compatible on-disk format will be not possible in the long-term, so as long as a dump/restore is still possible everything should be fine. This is an SQL database - they cannot drop dump/restore upgrading possibility without loosing most users ;-) Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x Very cool, thanks! And good luck! Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sat, Mar 29, 2008, Markus Schiltknecht wrote: > Ralf S. Engelschall wrote: > [...] > > For the bundled sqlite variant, we should IMO switch to the amalgamation > distribution. As Monotone is already using its own build-environment for building the sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to just the sqlite3.[ch] files from the SQLite "amalgamation" distribution. >> If there is still no such policy I personally recommend a policy like >> this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone >> should can be upgraded to the latest version of SQLite as long as (1) >> this SQLite version it is fully backward compatible to the old on disk >> format (= is able to read it) and at maximum a dump/restore of the >> database is necessary, > > What minimum requirement are you proposing here? Fully backward compatible > (on disk format) *or* dump/restore? Fully backward compatible on-disk format will be not possible in the long-term, so as long as a dump/restore is still possible everything should be fine. At least as long as Monotone is in heavy "development mode" (versions 0.xx) a dump/restore is fully acceptable IMHO. But once Monotone reached something like a version above 1.0, a full dump/restore is IMHO only acceptable any longer for a jump between N.M.x and N.(M+1).0 but not between N.M.x and M.M.(x+k). But we are still not at this point in time... > Especially when we allow linking against system libraries, we have to be > careful and check multiple versions. Maybe even provide a "downgrade" > feature, i.e. if a user first uses a newish system provided sqlite, then > downgrades to the monotone provided one by building mtn from source. > However, dump/restore should do the trick. Yes, for those scenarious a dump/restore will be necessary. > [...] > Yes, there are pretty obvious, IMO. I don't think we are lacking a policy. > We need someone to just *do* it. Are you volunteering to test monotone > against sqlite 3.5.x? Or try integrating the amalgamation distribution? Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x 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] url schemes
Hi, Thomas Moschny wrote: Of course. However, I retain the right to change them if they turn out to be not as useful as I thought :) Hehe.. :-) /revision/REV_ID /manifest/REV_ID /certs/REV_ID /file/FILE_ID (raw) /branches /tags /revisions/leaves /revisions/roots /revisions/parents/REV_ID /revisions/children/REV_ID /revisions/ancestors/REV_ID /revisions/descendants/REV_ID /revisions/select/SELECTOR /ancestry /version /cmd/COMMAND/ARG1/ARG2/... (raw) Everything not marked with "(raw)" is served using a json response. Slashes in the SELECTOR (and the ARGs) have to be url-escaped (%2F). Very nice. Really similar to what I have in mind. With the revisions, I remember doing something more like: /revision/$REVID/manifest /revision/$REVID/ancestors ... And I started with: /branch/$BRANCHNAME/heads ... Note that while the urls are easy changeable, actually thoughts also have to be put in the design of the json responses Right. that replace the basic_io output of mtn (for revisions, manifests, certs, etc.). Replace? You mean you would completely replace the basic_io format with a json based one? Or are you speaking of the format for transmission exclusively? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: url schemes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Schiltknecht schreef:
| Hi,
|
| Koen Kooi wrote:
|> Since it's read-only, is it possible to cache the state and allow
|> multiple connections?
|
| Hm.. if it uses mtn automate behind the scenes, as I did in my
| experiments, I fear that makes not much difference. (Except nuskool
| being faster than netsync anyway.)
|
|> At OpenEmbedded we have at any given moment >10
|> simultanous connections to mtn serve, which each take a few seconds to
|> 'initialize'[1] (incrementing rev and cert counters) and seem to block
|> other transfers ("Why do I have to wait 3 hours before I an allowed to
|> push a rev?!?" as one developer put it).
|
| Maybe http caching could help here? By reducing locking contention to
| the database, only requests which really need to write the database need
| to block each other.
|
| This is another good reason to keep the URL scheme simple. If you stuff
| too much information into a single request, caching it gets harder or
| useless.
Last week we had a maximum 173 simultanious[1] connections which put mtn
in such a state it needed to be killed to get traffic flowing again. So
having some form of relatively lock-free read-only serving option would
be a good thing.
regards,
Koen
[1] probably a lot of 'duplicate' connections where people ctrl-c and
try again and the server hasn't noticed the disconnect yet.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFH7pLJMkyGM64RGpERAulRAJ0Qx3x0AaXFUl2ScGNaGi6fQfVP3ACfcwO9
xnhltT5QflGoxrGAC7oZUrI=
=wOcv
-END PGP SIGNATURE-
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Markus Schiltknecht wrote: > Hm.. sounds very similar to what I've been trying... nice to hear you > also like twisted as much :-) > > Do you mind enclosing the URL scheme you are using here? I would very > much like to get something together, which would serve many use cases > (i.e. dumb servers, an automate API, nuskool, maybe even xmpp..). Of course. However, I retain the right to change them if they turn out to be not as useful as I thought :) This is what is currently working (modulo bugs, of course). /revision/REV_ID /manifest/REV_ID /certs/REV_ID /file/FILE_ID (raw) /branches /tags /revisions/leaves /revisions/roots /revisions/parents/REV_ID /revisions/children/REV_ID /revisions/ancestors/REV_ID /revisions/descendants/REV_ID /revisions/select/SELECTOR /ancestry /version /cmd/COMMAND/ARG1/ARG2/... (raw) Everything not marked with "(raw)" is served using a json response. Slashes in the SELECTOR (and the ARGs) have to be url-escaped (%2F). The /cmd/COMMAND url simply passes through automate commands, mainly for debugging and easy access to mtn content using a browser. It cannot handle options, and is likely to disappear again. Note that while the urls are easy changeable, actually thoughts also have to be put in the design of the json responses that replace the basic_io output of mtn (for revisions, manifests, certs, etc.). Regards, 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] Re: url schemes
Hi,
Koen Kooi wrote:
Since it's read-only, is it possible to cache the state and allow
multiple connections?
Hm.. if it uses mtn automate behind the scenes, as I did in my
experiments, I fear that makes not much difference. (Except nuskool
being faster than netsync anyway.)
At OpenEmbedded we have at any given moment >10
simultanous connections to mtn serve, which each take a few seconds to
'initialize'[1] (incrementing rev and cert counters) and seem to block
other transfers ("Why do I have to wait 3 hours before I an allowed to
push a rev?!?" as one developer put it).
Maybe http caching could help here? By reducing locking contention to
the database, only requests which really need to write the database need
to block each other.
This is another good reason to keep the URL scheme simple. If you stuff
too much information into a single request, caching it gets harder or
useless.
Regards
Markus
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: url schemes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Moschny schreef:
| Meanwhile, I wrote a (quick'n'dirty) twisted plugin. It serves mtn
content
| (read-only, for now) via http and json, over a tcp or a unix domain
socket.
Since it's read-only, is it possible to cache the state and allow
multiple connections? At OpenEmbedded we have at any given moment >10
simultanous connections to mtn serve, which each take a few seconds to
'initialize'[1] (incrementing rev and cert counters) and seem to block
other transfers ("Why do I have to wait 3 hours before I an allowed to
push a rev?!?" as one developer put it).
regards,
Koen
[1] Which means one cpu (Xeon [EMAIL PROTECTED]) is constantly at 100% load
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFH7ooFMkyGM64RGpERAgcTAJ9bSjMWrCbJqcQ1L3T2umjYYOlcMgCgiKD5
wFBbYID53oZPmEB+1SGPCmU=
=kUUI
-END PGP SIGNATURE-
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Markus Schiltknecht wrote: Do you mind enclosing the URL scheme you are using here? Uh.. s/enclosing/disclosing/ :-) Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.db-compaction
Hi, Zack Weinberg wrote: On Sat, Mar 29, 2008 at 11:16 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: Anybody opposed to landing that branch before releasing 0.40? If nobody speaks up I'm going to merge it back to mainline on Monday, okay? No objection from me. I've checked in a few more tests of the migration logic. Cool, thanks for reviewing and cleaning up the encode_hexenc() calls spread all over the place. I've reviewed the diff against mainlien and applied some more polishing. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Hi, Thomas Moschny wrote: Meanwhile, I wrote a (quick'n'dirty) twisted plugin. It serves mtn content (read-only, for now) via http and json, over a tcp or a unix domain socket. Here, the requests are not coded as post-data in json, but directly in the url, very similar to those mentioned in the thread. I think I'll use that for tracmtn, so it will show up in a branch soon. Hm.. sounds very similar to what I've been trying... nice to hear you also like twisted as much :-) Do you mind enclosing the URL scheme you are using here? I would very much like to get something together, which would serve many use cases (i.e. dumb servers, an automate API, nuskool, maybe even xmpp..). Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.db-compaction
On Sat, Mar 29, 2008 at 11:16 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > Anybody opposed to landing that branch before releasing 0.40? If nobody > speaks up I'm going to merge it back to mainline on Monday, okay? No objection from me. I've checked in a few more tests of the migration logic. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
Hi, Philipp Gröschler wrote: When it comes to simplicity, I personally would prefer that in the matter of usability over coding complexity. Not every programmer has that attitude, which is why we have lots of ugly user interfaces out there. But if I got you right (at least this time) then we seem to share that opinion. Cool. :-) To become more technical again: when in some distant future these URL features become available, would it then be possible for just any application to connect to a running 'mtn serve' process via network, issue one or more HTTP requests and get the relevant answers, without the need for this application to speak netsync? That's part of what I like so much about nuskool: it's very simple and easy to understand. FWIW, I certainly envision providing some of the automate interface to the outside via HTTP, yes. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] url schemes
On Saturday 29 March 2008 Philipp Gröschler wrote: > To become more technical again: when in some distant future these URL > features become available, would it then be possible for just any > application to connect to a running 'mtn serve' process via network, > issue one or more HTTP requests and get the relevant answers, without > the need for this application to speak netsync? The (experimental) nvm.nuskool branch already provides something similar: You can, via scgi, connect a mtn process to a webserver and it will serve json-over-http requests. This is bidirectional: you can query for revisions, files and file deltas, and you can send new ones back. The new gsync command (also in this branch) syncs a local database against such a server. Meanwhile, I wrote a (quick'n'dirty) twisted plugin. It serves mtn content (read-only, for now) via http and json, over a tcp or a unix domain socket. Here, the requests are not coded as post-data in json, but directly in the url, very similar to those mentioned in the thread. I think I'll use that for tracmtn, so it will show up in a branch soon. Regards, 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] url schemes
Markus Schiltknecht schrob: Hm.. I see. But.. looking at the command line only, we could use whatever URL we want. We wouldn't have to use a URL at all. From a CLI users point of view, I'd even favor the current syntax for netsync. So what do you want a mtn:// url at all? I just began to think alot about the feature when Timothy started the discussion on the "mtn:// sync" thread a few days ago. As it is with new features, they are likely to replace old behavior (though it is clear that the old syntax will be kept long enough to ensure backwards compatibility). Since I am rather new into actually using monotone (and not only following its development progress) I wanted to adopt the new possibilities correctly. The old syntax is working for me as well, but learning only one (newer) syntax to the full could save valuable "brain capacity". Allright. So far. *cough* Being able to use the same URL for the web interface, for monotone and for clever as well as dumb servers seems much more important to me, than sticking to "?" as a separator for no reason, except simplicity of coding it. Or put it another way: why should "/branch/" not be a better and more descriptive separator? This is true of course, as long as there will always be only one specific /keyword/ between the host name and the rest of the path. And this even only for the argument of human readbility. When it comes to simplicity, I personally would prefer that in the matter of usability over coding complexity. Not every programmer has that attitude, which is why we have lots of ugly user interfaces out there. But if I got you right (at least this time) then we seem to share that opinion. But probably I'm just too focused on nuskool, having URLs like these in mind: http://www.xyz.org/revision/d558f906d0d597ac7ac01f891fe46f994dc0946c https://www.xyz.org/file/a5a5ce3a1ed7c9dead79c526e382237697d54c04 maybe even: ftp://www.xyz.org/branch/net.venge.monotone/botan/sha160.cpp Any kind of separator other than '/' would just be disturbing there. Or do you really expect people to remember where to put the '?', before or after the 'branch' or 'revision'. The more I look at this notation, the more I like it. Don't know what I had on mind when I started arguing for question marks and that other stuff. Let's forget about that! I full heartedly agree. But I fail to see how multiple separators and intuition fit together. ;-) Here again we're in the area of personal taste. As I do a lot of coding on web applications, I often think alot about how to hide the structure of a particular app. The common user really does not care much about how URLs look like, you're right, but some folks do. But that is going too far by now, and I don't want to earn the "Offtopic Award" in my first active week on the list ;-) To become more technical again: when in some distant future these URL features become available, would it then be possible for just any application to connect to a running 'mtn serve' process via network, issue one or more HTTP requests and get the relevant answers, without the need for this application to speak netsync? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Schiltknecht schreef: | Hi, | | Koen Kooi wrote: |> And what about mtn resolving NCCs for people, instead of erroring out |> with a nicer message? "bogus invariant" or "nice error message" still |> don't get me a solution to the problem, it just makes me throw a smaller |> object out of the window ;) | | Well said ;-) | | We certainly have that on the radar, however, it's not such a walk in | the park as the OP's bug fix was. :-) And the OP's bug is harder to 'automagically' solve than the NCCs OpenEmbedded encounters, which go like: ~ * file gets added in vendor branch (can't be merged to mainline) ~ * file gets copied to mainline and committed ~ * vendor propagates mainline to vendor branch ~ *boom* And in this case the proposed solution to drop the 'youngest' node is not always the correct one. You could offer a dialog: - --- conflict: duplicate node 'x' ~ added in org.foo.mainline on 20080312 ~ added in com.vendor.branch on 20071228 ~ 1) drop org.foo.mainline node ~ 2) drop com.vendor.branch node ~ 3) abort merge Enter choice [default: 3] : - --- or have an extra param to propagate like - --preferred-branch=org.foo.mainline. Bonus points for (re)creating revisions to keep history from both sides. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH7nMFMkyGM64RGpERAtVFAJwMHVQS+zpFu8Xz9IJG9hOibyXQzQCdF7RR wCmn6DllvjO+xLW2wCfych0= =J0JU -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated
Hi, Koen Kooi wrote: And what about mtn resolving NCCs for people, instead of erroring out with a nicer message? "bogus invariant" or "nice error message" still don't get me a solution to the problem, it just makes me throw a smaller object out of the window ;) Well said ;-) We certainly have that on the radar, however, it's not such a walk in the park as the OP's bug fix was. :-) Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Schiltknecht schreef: | Hi, | | IMO, a good bug report deserves an equally good fix. In revision | d779238b.. I hope to have achieved that. The error message now looks like: | | conflict: duplicate name 'x' for the directory 'foo/bar' | | ..in the normal case. If you rename a parent directory as well, as in | your case, it says: | | conflict: duplicate name 'x' for the directory | named 'foo/bar' on the left and | named 'foo/baz' on the right. | | That's certainly better than failing on a bogus invariant. | | (The fix will not appear before monotone 0.40). And what about mtn resolving NCCs for people, instead of erroring out with a nicer message? "bogus invariant" or "nice error message" still don't get me a solution to the problem, it just makes me throw a smaller object out of the window ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFH7mrzMkyGM64RGpERAksQAJwLeYZLfaDYqz+/HmUycLhy/33SUgCdHwpg MU0CGG2YdyagoXAYGDgKN3I= =Kgmw -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.experiment.db-compaction
Hi, Markus Schiltknecht wrote: during this easter hack, I've managed to get further with nvm.e.db-compaction. Rememder? The branch turning all database and in-memory ids into binary representation. Anybody opposed to landing that branch before releasing 0.40? If nobody speaks up I'm going to merge it back to mainline on Monday, okay? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi, Stephen Leake wrote: Logically, those are not "branches"; they are now part of mainline. So it would be more correct to say : I don't quite follow your reasoning here. Even if they got merged later on, those are still "branches of development". > You will get revisions that used to be on a branch but are now on > mainline. Their branch cert didn't change. Even after a merge, most revisions of the branch will still carry only *one* branch cert - that of the branch. Thus I fail to see how those should now "be on mainline". You'd only save sync'ing 'new' development branches. Which is a good thing. Really? If I'm interested enough in a project to want to fetch it's development history (!), I'm at least as interested in all current branches, as I am interested in history. I've never taken the effort to strip away branches I might not be interested in (heck, how should I even know?). But that's just me. Let's hear other people's preferences here! Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fatal: std::logic_error: roster_merge.cc:528: invariant 'I(left_name == right_name)' violated
Hi, Derek Scherger wrote: I also think that "in the directory" is much better than the earlier "for the directory" myself. The latter hints that the directory is in conflict, rather than the thing in the directory. Yeah, right. That's one of the nitty gritty details only a native speaker can really get right, I think... One minor nit. I did make a rather painstaking effort in the improved messages to issue them one per line, rather than the multi-line message (with embedded newlines) below. I haven't given this one much thought yet and I'm not overly attached to the current formatting but if you look over all of the other messages in the roster_merge.cc conflict stuff you'll hopefully pick up on the general theme. I'll have a look myself too and see if I can come up with an improvement. In general I would really like to keep all of the conflict messaging consistent, if possible. Oh, I didn't know that. But yeah, consistent messaging would be very nice. I was just concerned about the invariant and didn't think too much about the error messages. Feel free to improve it! Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Ralf S. Engelschall wrote: While looking at compile-time warnings of Monotone, I've just stumpled over the fact that we are still using SQLite 3.4.2 in Monotone while at sqlite.org we already have SQLite 3.5.7 released recently. My simple question is: what is the "official" Monotone upgrade policy with respect to the embedded copy of SQLite? I guess simply because noone has taken care, recently. Matthew did the last update to 3.4.2 on 2007-08-14. Please also note, that 3.4.2 is the latest 3.4 release and 3.5.0 features some incompatibilities with older versions, see: http://www.sqlite.org/34to35.html > Who takes care of the SQLite upgrades for Monotone? I've started picking up the nvm.library-build branch, where we strive for accepting system libraries as well. IMO that includes the ability to ling against a system provided sqlite library. For the bundled sqlite variant, we should IMO switch to the amalgamation distribution. If there is still no such policy I personally recommend a policy like this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone should can be upgraded to the latest version of SQLite as long as (1) this SQLite version it is fully backward compatible to the old on disk format (= is able to read it) and at maximum a dump/restore of the database is necessary, What minimum requirement are you proposing here? Fully backward compatible (on disk format) *or* dump/restore? Especially when we allow linking against system libraries, we have to be careful and check multiple versions. Maybe even provide a "downgrade" feature, i.e. if a user first uses a newish system provided sqlite, then downgrades to the monotone provided one by building mtn from source. However, dump/restore should do the trick. (2) it's API is backward compatible or Monotone's use of the SQLite API is at least simultaneous adjusted during the upgrade; (3) Monotone after the upgrade still passes its test suite and (4) in case of a required non-automated upgrade step hints about this are added to file UPGRADING". Yes, there are pretty obvious, IMO. I don't think we are lacking a policy. We need someone to just *do* it. Are you volunteering to test monotone against sqlite 3.5.x? Or try integrating the amalgamation distribution? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] interface version / command matrix
On Saturday 29 March 2008 Thomas Keller wrote: > Whether or not we're doing the cap.-bits thing it would surely be useful > to define once and for all what should actually be an "incompatible > change". I haven't heard much of the other voices yet on this issue. One criterion could be, whether there exists (or could exist) any client using that part of the interface in the "normal" way (as intended by the interface's developers), that needs to be fixed to continue using that part. This is - of course - very vague. - 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] interface version / command matrix
Thomas Keller schrieb: That is the contract interface_version guarantees. guitone _solely_ depends on automate currently (ok, despite one very little use case where I use mtn pubkey - but this is on my TODO list, i.e. I plan to implement mtn automate get_public_key some time). I probably should just name it packet_for_pubkey to match the naming of the other packet_for_* commands. Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en 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] interface version / command matrix
Stephen Leake schrieb:
Thomas Keller <[EMAIL PROTECTED]> writes:
Stephen Leake schrieb:
Which means we probably should use two digits for the minor number;
we'll probably have more than 10 backward-compatible changes before
the next incompatible change.
Ok, this is another thing which should be ruled: in my opinion what
follows on x.9 is x.10 aso. In guitone I split up on "." and compare the
major and the minor numbers separately.
Well, that works, but it's clearer if we go from x.09 to x.10.
I don't like the idea of padding zeros to these numbers. The thing is
that it merely serves the interface developer in whose environment it is
rather hard to do "7.2".split(".")[1].toInt() (pseudo code) and compare
that value then further.
Actually, I don't like the idea of changing anything wrt interface
numbering - if people really have a problem with it, then I'm on Thomas
Moschny's side and would rather vote for stripping any versioning number
off the code and replace it by magic capabilities strings (though this
will have its very own set of problems I believe).
Another nit: you have a C for inventory for 7.0. That change was the
addition of --no-ignored, --no-unknown, --no-unchanged,
--no-corresponding-renames. That was backward-compatible, so it should
be B.
This is, like the --depth thing, debateable. I fully agree that the new
options are backwards-compatible, however, the change that it no longer
recurses into ignored directories which happened in the same release was
for me backwards-incompatible, because for a given fixed input the
output, i.e. the amount of nodes returned, changed significantly.
Ok. I just viewed that as fixing a bug. Not a big deal.
Whether or not we're doing the cap.-bits thing it would surely be useful
to define once and for all what should actually be an "incompatible
change". I haven't heard much of the other voices yet on this issue.
In practice, you can just check the mtn version, since the automate
interface version changes in sync with that.
Not always. In the past there have been quite a few releases where
nothing had been changed, so interface_version kept constant. This is
also wanted; if you develop a tool that relies on a certain interface
version like 8.3, you should be able to safely deploy that with any
monotone release with an interface version 8.3 <= x < 9.0.
Hmm. I guess you are implying that this tool should complain that it
might not work on a version that is 9.0 or greater. Ok, that makes
sense. But it is quite likely overconservative. For example, how many
tools actually _relied_ on inventory recursing into ignored
directories?
I have no idea if any other tools beside DVC and guitone actually use
inventory nowadays heavily, so I have no idea if they used this
"feature" or not. But certainly, other incompatible changes in the past
would made this exact version parsing needed.
guitone is coded very conservative in this case. I rather throw an
"unsupported version" message at the user beforehand than letting him
find some obscure bug / crash because a format change triggered an
invariant in my code, f.e.
But you have ignored my point that it is just as likely that a tool
that works on mtn 0.38 might not work on mtn version 0.40.
Unless the tool uses _only_ automate commands, it _must_ check the mtn
version number. I don't think automate is powerful enough for that.
Nor do I think it needs to be.
That is the contract interface_version guarantees. guitone _solely_
depends on automate currently (ok, despite one very little use case
where I use mtn pubkey - but this is on my TODO list, i.e. I plan to
implement mtn automate get_public_key some time).
No code changes would need to be done on the client's side to
support a new monotone release which does no or just a minor changes
to the interface.
I define "the interface" to include the mtn commands, as well as the
mtn automate commands.
For me its the other way around. I program the tool against the
automation interface by purpose, because this interface is the only one
which guarantees me at least some kind of stability. Sure, there are
still a lot of missing commands and functionality, the problem of
mediocre error (plain string) reporting, no ticker support, aso. - but
this is nothing which cannot be addressed in the future.
The "big" plan for me certainly is making automate feature-complete
(with the exclusion of some rarely needed commands like mtn crash ;),
because only when its feature-complete it can actually be useful for
everybody. And people can start using it for even more obscure things,
like providing new command line frontends which has already been done in
the past (see the mtn_automate lua function).
Although it may be that there are ways to effect some of the
non-automate commands via automate. You have mentioned that your tool
does not use 'mtn commit', but rather some combination of automate
commands. It would be useful to doc
[Monotone-devel] Monotone upgrade policy for the SQLite copy?
While looking at compile-time warnings of Monotone, I've just stumpled over the fact that we are still using SQLite 3.4.2 in Monotone while at sqlite.org we already have SQLite 3.5.7 released recently. My simple question is: what is the "official" Monotone upgrade policy with respect to the embedded copy of SQLite? Who takes care of the SQLite upgrades for Monotone? If there is still no such policy I personally recommend a policy like this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone should can be upgraded to the latest version of SQLite as long as (1) this SQLite version it is fully backward compatible to the old on disk format (= is able to read it) and at maximum a dump/restore of the database is necessary, (2) it's API is backward compatible or Monotone's use of the SQLite API is at least simultaneous adjusted during the upgrade; (3) Monotone after the upgrade still passes its test suite and (4) in case of a required non-automated upgrade step hints about this are added to file UPGRADING". Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
