Re: [Monotone-devel] MonotoneOnDebian
Zack Weinberg za...@panix.com writes: On Wed, Feb 25, 2009 at 6:12 PM, hend...@topoi.pooq.com wrote: In http://monotone.ca/wiki/MonotoneOnDebian/ it says, Monotone packages can currently be found in the Debian repositories. Monotone changes very rapidly and versions in sarge and etch may be slightly dated. It is recommend that you use the monotone package from the monotone website or the version that is in sid/unstable which is generally kept up to date. But going to the monotone website, I find no .deb packages for etch. There are packages for Suse, but that's not the same. Hm, perhaps that should be reworded. The .deb on the website is generally built against sid, and I doubt it will work on etch myself. We generally haven't bothered doing backports but if you grab the source package from sid (0.40-7) it should build fine against etch's libraries. I agree that the paragraph should be removed. It is no longer true that monotone changes very rapidly; in fact, it has an amazing track record of backwards compatibility (at the netsync level) since 0.26. The changes in database schema are more frequent but not generally a problem since migration is painless. The user interface has remained clear, simple and consistent all along despite the new features. That's one of the reasons I like monotone so much and I'm happy using whatever version of monotone is in Debian (currently 0.40-7), even if it is not the latest. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Documentation Texinfo XML to Wiki converter
Zack Weinberg schrieb: On Wed, Feb 25, 2009 at 3:09 PM, Philipp Gröschler monot...@plasma.cx wrote: Philipp Gröschler schrieb: In the course of the current Mini Summit I spent the afternoon hacking on a (yet still) small XSLT file whose purpose will be the conversion of Monotone's Texinfo Documentation to a set of multiple files which can be used for the Wiki. I just committed the first release of this thing, in a very *pre-alpha* state. But better than nothing ;-) For further informations please check out nvm.plasma.doc-wiki-xslt and have a look the documentation provided there. Please let me know your suggestions and if this thing could have a real purpose by someday. Just so that I can keep working on it - or not. What is *your* vision for this thing? I don't really understand what you have in mind so it's hard for me to evaluate. I think we would prefer to keep the master copy of the manual as part of the main sources rather than opening it up to wiki-based editing, but that doesn't mean support for more different rendering formats is uninteresting -- far from it. The main reason behind it was that we wanted to chain the information in the wiki and in the manual closer together, i.e. have a common layout, a common search functionality, a common markup, easier linkage, and so on. The whole xslt thing is basically a test balloon how well we can convert the current texinfo source to wiki markup and if this works out well if we use this instead of plain HTML files for the website (or even switch completly to a wiki manual, if people agree). The reason for this step is because makeinfo is rather limited when it comes to HTML output, you cannot rearrange things or add certain needed header / footer parts easily to it, _but_ there is an XML output available which theoretically could be transformed to anything we want. And exactly this is Philipp's work. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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] Documentation Texinfo XML to Wiki converter
Thomas Keller schrieb: The whole xslt thing is basically a test balloon how well we can convert the current texinfo source to wiki markup and if this works out well if we use this instead of plain HTML files for the website (or even switch completly to a wiki manual, if people agree). The reason for this step is because makeinfo is rather limited when it comes to HTML output, you cannot rearrange things or add certain needed header / footer parts easily to it, _but_ there is an XML output available which theoretically could be transformed to anything we want. And exactly this is Philipp's work. Thanks for clearing this out ;-) My last mail wasn't really what one would call creative or informational. Again, if there are questions, please first take a look at the README file in the branch I committed. There I tried to sum up my intentions. Well, at least the important ones. Zack Weinberg schrob: What is *your* vision for this thing? I don't really understand what you have in mind so it's hard for me to evaluate. I think we would prefer to keep the master copy of the manual as part of the main sources rather than opening it up to wiki-based editing, but that doesn't mean support for more different rendering formats is uninteresting -- far from it. My vision is to get involved in the project in a way that I can help within my limited spare time/abilities. The current state of the package is very experimental, just to show a way how it *could* be done. Besides the possibility of completely switching over from the Techinfo Manual to Wiki at some day, I rather thought of a continous one-way process. The documentation would still be maintained with Techinfo and new versions would be converted to Wiki format. The respective resulting parts of the Wiki should then be read only to prevent concurrent modifications which could not easily be brought back into the Techinfo part. But that is not my decision. I wanted to show a way how it could be done, and if there's reasonable demand then I will keep working on it. So much for the vision part ;-) Daniel Carosone schrieb: The great thing about this work is it (begins to) breaks the coupling between purpose and style, which means content can be used for multiple purposes regardless of style, in turn meaning that unification doesn't get confused with markup conversion. So, really, yay, and yay again. I carefully consider this as a positive response ;-) Yes, XSLT is a nice way to break the border between plain markup and presentation. I learned to use it about five years ago and I was astounded by its possibilities. For quite a while I used it for a self written XML-based servlet engine. But besides the magic one could do with XSLT there are also a lot of limitations. The way a stylesheet works and is processed could drive you easily into madness. At least it has done so a few times with me. And some things just do not work. Example: I wanted to give the user the possibility to choose the output format converter at runtime. The first intended way was to get a command line parameter into a XSLT variable, which then contains the complete file name of the converter stylesheet and then use this variable with an include instruction. So to speak, for dynamically chosing the included converter stylesheet. That one went wrong. XSLT stylesheets are first compiled completely and then interpreted. There's no way for such dynamic and runtime dependent behaviour without external programed logic. Ah, so much text. I think I should stop here. Greetings! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Documentation Texinfo XML to Wiki converter
On Thu, Feb 26, 2009 at 02:45:03PM +0100, Philipp Gröschler wrote: Thomas Keller schrieb: The whole xslt thing is basically a test balloon how well we can convert the current texinfo source to wiki markup and if this works out well if we use this instead of plain HTML files for the website (or even switch completly to a wiki manual, if people agree). The reason for this step is because makeinfo is rather limited when it comes to HTML output, you cannot rearrange things or add certain needed header / footer parts easily to it, _but_ there is an XML output available which theoretically could be transformed to anything we want. And exactly this is Philipp's work. Thanks for clearing this out ;-) My last mail wasn't really what one would call creative or informational. Again, if there are questions, please first take a look at the README file in the branch I committed. There I tried to sum up my intentions. Well, at least the important ones. Zack Weinberg schrob: What is *your* vision for this thing? I don't really understand what you have in mind so it's hard for me to evaluate. I think we would prefer to keep the master copy of the manual as part of the main sources rather than opening it up to wiki-based editing, but that doesn't mean support for more different rendering formats is uninteresting -- far from it. My vision is to get involved in the project in a way that I can help within my limited spare time/abilities. The current state of the package is very experimental, just to show a way how it *could* be done. Besides the possibility of completely switching over from the Techinfo Manual to Wiki at some day, I rather thought of a continous one-way process. The documentation would still be maintained with Techinfo and new versions would be converted to Wiki format. The respective resulting parts of the Wiki should then be read only to prevent concurrent modifications which could not easily be brought back into the Techinfo part. If text can be modified both on wiki and on original sources, conversion has to be a two-way process, probably moderated. But that is not my decision. I wanted to show a way how it could be done, and if there's reasonable demand then I will keep working on it. So much for the vision part ;-) Daniel Carosone schrieb: The great thing about this work is it (begins to) breaks the coupling between purpose and style, which means content can be used for multiple purposes regardless of style, in turn meaning that unification doesn't get confused with markup conversion. So, really, yay, and yay again. I carefully consider this as a positive response ;-) I first encountered this distinction way back in the days that SGML was an experiment by the American Associatin of Publishers (AAP). Separating the author's job from the book designer's job was the whole point. Since then there's been an explosion of variations on the original design, most of them completely contrary to the original purpose. XML is one of the few that *is* in the right direction, though overly complex. By the way, AAP is the Dutch word for monkey or ape, yielding much mirth in Amsterdam, wher I was at the time. Yes, XSLT is a nice way to break the border between plain markup and presentation. I learned to use it about five years ago and I was astounded by its possibilities. For quite a while I used it for a self written XML-based servlet engine. But besides the magic one could do with XSLT there are also a lot of limitations. The way a stylesheet works and is processed could drive you easily into madness. At least it has done so a few times with me. And some things just do not work. Example: I wanted to give the user the possibility to choose the output format converter at runtime. The first intended way was to get a command line parameter into a XSLT variable, which then contains the complete file name of the converter stylesheet and then use this variable with an include instruction. So to speak, for dynamically chosing the included converter stylesheet. That one went wrong. XSLT stylesheets are first compiled completely and then interpreted. There's no way for such dynamic and runtime dependent behaviour without external programed logic. I forget. Is XSLT the one that has a syntax resembling Scheme? -- hendrik Ah, so much text. I think I should stop here. Greetings! Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Documentation Texinfo XML to Wiki converter
On Wed, Feb 25, 2009 at 07:06:50PM -0500, hend...@topoi.pooq.com wrote: On Thu, Feb 26, 2009 at 12:09:45AM +0100, Philipp Gröschler wrote: Philipp Gröschler schrieb: In the course of the current Mini Summit I spent the afternoon hacking on a (yet still) small XSLT file whose purpose will be the conversion of Monotone's Texinfo Documentation to a set of multiple files which can be used for the Wiki. The Lumiera group is struggling with this proboem too -- manageing text under distributed revision control and making it editable with ordinary check-in and check-out as well as by wiki. They seem to be in the process of developing a new wiki (which they are calling uwiki) for this purpose. They refuse to base it on ikiwiki because they consider perl unmaintainable. And, by the way, I thing they're using git instead of monotone. Specifically, their discussion in in the Tidying up the docs threads on http://lists.lumiera.org/pipermail/lumiera/2009-February/thread.html But the problem is a common one. Yes, indeed it is. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] git fast-export
On Wed, Feb 25, 2009 at 12:37 PM, Felipe Contreras felipe.contre...@gmail.com wrote: I think it should be an option. Otherwise the people that want a single message would have trouble running a git filter-branch command to strip the message out. It would be much easier to do that in the mtn export. Looking through the pidgin repo that I have here, there are several commits with multiple changelog's some of which consist of a single 'a' character. Selecting one of these arbitrarily is going to select the 'a' changelogs sometimes which I suspect is also not what you want, unless you're thinking of a different option that I am. As I recall what you wanted was an option to just grab one changelog and use that right? Maybe the longest changelog would be the best one to use? I see several other revisions with multiple distinct changelogs that seem like they would be good to preserve as well. I'm somewhat reluctant to add an option that does this because it does not seem like a general thing that anyone else will want and it seems like it will just move your problem around a bit. Instead of getting changelogs you don't want you'll be missing changelogs you do want. The other options here are to (1) filter the exported data and remove the messages you don't want or (2) delete the unwanted changelog certs from a copy of your monotone database and export from that. Both of these should be scriptable without too much trouble although Identifying the specific changelogs to drop will probably be rather tedious. I don't know the exact commit id in the Pidgin repo, but I can assure you, it's there. Oh I beleive you, but it still might be useful to see the actual real data and do something based on that. So, if you do come across the revision id, I'd still like to see it. no author cert: 'unknown' user_id not mapped: 'user_id' user_id mapped: obvious The current code works mostly like this. In the unmapped case it only adds '' and '' when neither is present. There are monotone users who have their keys named like User Name u...@foobar.com and adding another set of '' and '' around these wouldn't make much sense. Anyway, I've been able to reach a little further and now I've finally found a difference in the trees between your and my method. In Pidigin's repo there's a commit '3f1b3854a77850131531d1d6f19c44a0b9174107' that in my method some files have exec flag off, and with your method it has the exec flag on. Can you take a look? Good catch. The monotone checkout of this revision has execute bits on some files that the git checkout does not. I'll have to do some digging to see what's going wrong here. Now I'm using a bit different method so I'll be able to test faster. The latest monotone git_export code runs quite a bit faster as well. I can export the pidgin repo I have here in a little over an hour instead of the 5 hours it was taking previously. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Build failure on MacOS X
Hi all, I notice that the current head fails to build the documentation on MacOS X if you're using the fink package manager for your dependencies. The problem is that the fink package manager has an ancient version of gettext (0.14) and its version of xgettext doesn't handle the '--package-name' option. The error is below. I don't know when they'll get around to using a current version of gettext. I'm currently trying to use the updated packages described here: http://www.mail-archive.com/fink-de...@lists.sourceforge.net/msg17761.html but that might not be an option for everyone (and I don't know if it works yet). It seems that the MacPorts packaging system has a newer version of gettext that works, so that might also be an option for some. Be well, Will :-} /sw/bin/xgettext -omonotone.pot -D. -cTRANSLATORS: \ --package-name=monotone --package-version=0.43dev \ --copyright-holder='Graydon Hoare gray...@pobox.com' \ --msgid-bugs-address='monotone-devel@nongnu.org' \ --keyword=F --keyword=FP:1,2 --keyword=_ --keyword=N_ --flag=F:1:c- format --flag=FP:1:c-format --flag=FP:2:c-format \ sanity.cc [snip] monotone.cc std_hooks.lua /sw/bin/xgettext: unrecognized option `--package-name=monotone' ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
