[Monotone-devel] RFC: Improved mtn logo
Hi all! Do you like to see the following as main logo? http://thomaskeller.biz/monotone/guitone.png I'm already using it as Dock icon for guitone on OSX and I think Thomas Moschny will probably adapt his TracMonotone logo as well. Thomas. -- - "I know that I don't know." (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] RFC: TracMonotone test setup
Hi! As most of you already know I have a test setup of TracMonotone (thanks to Thomas Moschny who set it up with me): http://tracmtn.thomaskeller.biz I'd like to collect ideas there what else is missing to actually use this kind of setup for monotone's development. A few things are already stated on the front page, but you're free to add more. Thanks, Thomas. -- - "I know that I don't know." (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!
Hi Larry, Great. This is the functionality that I was looking for some time ago, to automate building automake packages for my software. I wrote a small perl script some time ago, that upon execution, tagged the current revision with a monotonically incrementing version number, next builds an automake package (using 'make dist'), whose name depends on the package name, and on the current version number and the current branch name. This works using ako keyword expansion on selected files. Fi. a package with name 'heccer' can have branches 'passive' and 'active', and the consequent releases would be called heccer-passive-1.tar.gz heccer-passive-2.tar.gz heccer-passive-3.tar.gz and heccer-active-1.tar.gz heccer-active-2.tar.gz heccer-active-3.tar.gz and so on. This automates building releases, and avoids human errors. The release number is saved in a small database, currently included in the project, such that a next release number can be generated from the database. The downside is that this database is committed with the project and that a tag is set on the previous revision, after incrementing the version number. Both these operations can possibly fail and leave the system in an inconsistent state, because the repository is kind of ahead of the released package. This is just a minor issue, but it makes me feel uncomfortable. So far the script works without problems. I am just wondering about the relationship between what you have done and what I have done ? Can I use your versioning method in combination with my keyword expander and build automake packages for heccer and neurospaces automatically ? Can I use m7 and monotone interchangebly for monotone functions ? I.e. I only have to call m7 to get the version number ? Hugo On 11/6/06, Larry Hastings <[EMAIL PROTECTED]> wrote: Howdy folks! Today I announce a new version of m7. In case you forgot, m7 is a proof-of-concept Python script that adds simple "local revision numbers" to monotone. These local revision numbers are simple monotonically increasing numbers affixed to revisions, and you can use them anywhere you specify a revision on the command-line. To ensure it's unambiguous, you need to prefix the revision number with a colon. So, if revision "818b9c9604efad446e5729d82a707714fea92cde" was local revision number 5, these commands are equivalent: mtn cat --revision=818b9c9604efad446e5729d82a707714fea92cde foo.cpp m7 cat --revision=:5 foo.cpp When I announced m7 over a year ago I didn't know what to expect. Reactions were mixed, from negative like "I would never use this, and I hope no one else does either", to positive like "I would never use this, but it's kind of neat"*. The original objection to m7 was its use of tags to track local revision numbers. Later I changed to custom certs, but that was little improvement. Since these tags & certs become part of your database, they would be sync'd to external users, even though they were primarily intended for local use. Correspondents on the monotone mailing list felt these certs would clutter up their databases and network traffic. However! Some senior monotone fella, surely either Graydon or Nathaniel, suggested an approach that doesn't need these certs―and is both faster and less error-prone to boot. It relies on a slightly-obscure feature of SQLite: every table has an indexed unique auto-incrementing integer column, whether or not it specifies one explicitly in its schema (see http://www.sqlite.org/autoinc.html ). So each entry in the revision table already has a locally-unique "revision number", ready-made and just waiting to be exposed to the monotone user. This even works, automatically, for external revisions you get from a network sync―a feature the old m7 never had, and never would! The only downside to this approach is a descent into "mtn db execute" territory, but it's a quick trip. I am therefore pleased to announce m7 version 0.8, which does not create extra tags or certs. Its only overhead is three "database variables" for local configuration which do not get propogated via netsync. You should feel free to download it and play around with it, secure in the knowledge that it will not "infect" your repositories with extraneous certs. m7 is written in Python, and requires version 2.3 or higher. Apart from the exposed local revision numbers, m7's other main feature is a more readable form of annotate. I tinkered with this a little too; now by default it prints a legend of the relevant revisions at the top before the annotated source. In case you're an existing m7 user, you can remove all the old m7 cruft by running "m7 unpopulate" from your work directory. (And you could give me the shock of my life by letting me know you were actually using m7.) You can read more about m7, and download a copy, here: http://www.midwinter.com/~lch/programming/m7/ Cheers, larry * This is exaggerated for comedic effect, though I do believe I have z
[Monotone-devel] New TracMonotone site
Hi all, Just wanted to let you know that TracMonotone now has a new home: http://tracmtn.1erlei.de/ . Please use the new site if you want to file a bug report or request new features. TracMonotone is a plugin for Trac (see http://www.edgewall.com/trac/) that allows a Trac installation to use a Monotone instead of a Subversion repository. The plugin enables you to browse your project's sourcecode, view changesets, etc., like in any other Trac project. Revisions can be linked to from wiki pages, tickets, and any other place that contains wiki text, e.g. commit messages, and they can be specified either using their hex-id, or via a tag or branch name, and later via Monotone selectors, too. Regards, Thomas Moschny ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] spanish po files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Attached you would find the spanish po files, and updated po/LINGUAS. cheers nicolás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFUJPJmjsZS9ZBxv8RAtlnAJ4omscc+lZYWRdMsC9xNhBeDQrjewCeI+q6 PAf7M7MLUK5ZyuVpmCaBQDI= =E0Ra -END PGP SIGNATURE- spanish_po.patch.gz Description: application/gzip ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] log's date timezone
Hi, monotone log's date timezone seems to be UTC. This is not easy to read but UTC may be useful. Why not display the date in local timezone and have --utc switch to display dates in UTC. In both case, the timezone may be displayed in the date field. Thanks & Regards, -- Benoît Dejean GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html signature.asc Description: Ceci est une partie de message numériquement signée ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: zsh completion annoyance: mtn add
Thomas Moschny <[EMAIL PROTECTED]> writes: > Can you please try the attached (trivial) patch and see whether that > behaves the way you expect? I haven't responded sooner because I'm trying to clear up some confusion. My computer at work is the one having trouble with completion. Applying this patch doesn't change its current behavior. But my computer at home, running the same version of zsh and monotone, behaved as desired even /before/ applying your patch. In other words, had I been trying my "mtn add" examples at home, I never would have reported a problem in the first place. This suggests that something else is wrong with my zsh installation on my computer at work. I had recently updated zsh using Cygwin's setup program, and have not rebooted the computer since. Once I get a chance to reboot and restore my lost "context", I'll try the "mtn add" scenario again and report back on my findings. In the meantime, thank you for providing the patch so quickly. -- Steven E. Harris ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!
Hugo Cornelis wrote: heccer-passive-1.tar.gz heccer-passive-2.tar.gz heccer-passive-3.tar.gz and heccer-active-1.tar.gz heccer-active-2.tar.gz heccer-active-3.tar.gz and so on. This automates building releases, and avoids human errors. The release number is saved in a small database, currently included in the project, such that a next release number can be generated from the database. The downside is that this database is committed with the project and that a tag is set on the previous revision, after incrementing the version number. Both these operations can possibly fail and leave the system in an inconsistent state, because the repository is kind of ahead of the released package. This is just a minor issue, but it makes me feel uncomfortable. So far the script works without problems. I am just wondering about the relationship between what you have done and what I have done ? Can I use your versioning method in combination with my keyword expander and build automake packages for heccer and neurospaces automatically ? Can I use m7 and monotone interchangebly for monotone functions ? I.e. I only have to call m7 to get the version number ? The problem with local revision numbers, AFAICT, is that they are, indeed, local. You can't ever make a release from a different machine. You can't even move to a different machine yourself*. And when monotone changes its internal storage, all kinds of things can go haywire. In short: Don't use local revision numbers to construct (apparently) globally unique revision numbers. It doesn't work. In general, you can't guarantee monotonely (a pun?) increasing revision numbers in a distributed system. Ever. What might work for you is some combination of 1) allowing only a single person to make releases (other people making releases are punished by ignorance) 2) using a file in the repository that contains the current release number 3) I'm sure there are other ways, and someone will hopefully be so nice as to point them out. If you happen to want releases with local revision numbers, go ahead and use Larry's script. Just don't complain if something breaks because of the above. You have been warned. Cheers, -- Ulf PS: This post is not meant as a thrashing, just well-intended advice. * Except if you make an bitwise exact copy of your archive. smime.p7s Description: S/MIME Cryptographic Signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] spanish po files
Here is a patch with spanish po file po/es.po and po/LINGUAS cheers nicolás spanish_po.patch.gz Description: application/gzip ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] spanish po files
Nicolas Ruiz schrieb: Attached you would find the spanish po files, and updated po/LINGUAS. Thanks a lot for that! I've added this on your behalf. For future commits just send your public key to Nathaniel (njs at pobox dot com) and he'll give you write access to venge.net. Thanks again, Thomas. -- - "I know that I don't know." (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
RE: [Monotone-devel] [drlvm][icl] Fix for the gc_gen compilation problem with Intel Compiler, windows
On Fri, Nov 03, 2006 at 07:31:08PM +0300, Salikh Zakirov wrote: > Hi, > ... Nathaniel Smith wrote: > I think maybe this went to the wrong list? Exactly. I am very sorry for that. I've attached a yellow paper with the reminder to check the list address for the future %-) Sorry for the noise. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!
Ulf Ochsenfahrt <[EMAIL PROTECTED]> wrote: > 2) using a file in the repository that contains the current release number autoconf does this nicely, actually. Why not bump your release version script into a shell checkin wrapper script that you use instead of mtn commit and tag. Then, continue to use your commit hook to build the dist after the commit? -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!
> "Larry" == Larry Hastings <[EMAIL PROTECTED]> writes: Larry> Apart from the exposed local revision numbers, m7's other Larry> main feature is a more readable form of annotate. I Larry> tinkered with this a little too; now by default it prints a Larry> legend of the relevant revisions at the top before the Larry> annotated source. I think this could be a good thing. While I have not used annotate for any real-life use yet, I imagine that the default behaviour of displaying revision ids could be very unhelpful (Yes, I know, you can get it to output date and time too - but then you have to trust the clock of the person who committed the change...). -- Brian May <[EMAIL PROTECTED]> ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
annotate (was Re: [Monotone-devel] m7 rises from the dead... reborn with new non-irritating behavior!)
On Wed, Nov 08, 2006 at 10:06:16AM +1100, Brian May wrote: > While I have not used annotate for any real-life use yet, I imagine > that the default behaviour of displaying revision ids could be very > unhelpful (Yes, I know, you can get it to output date and time too - > but then you have to trust the clock of the person who committed the > change...). The default now is to put the date/time in -- but really, nothing in the annotate UI is particularly set in stone, improvements very welcome. (We should have 'automate annotate' that does the same thing as plain old annotate used to do, too. Needs a volunteer to do some refactoring) -- Nathaniel -- "Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics." -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] patch serieses
There was a discussion on IRC today about quilt/mq/stgit style workflows: http://colabti.de/irclogger//irclogger_log/monotone?date=2006-11-08,Wed&sel=5#l9 I suggested that one possible approach to providing such functionality would be to map quilt "patches" to monotone "branches" (_not_ monotone "revisions", which is the kind of approach that stgit and perhaps mq take). For more details, see the chat log above. Then I worked out how one would do the most complicated sort of operation with this representation -- reordering "patches" -- and stuck it in a pastebin, but pastebins expire, so the main point of this email message is to reproduce this text that I pastebinned in a place that is well-archived: Patch series: A -> B -> C. I assume the series order itself is stored somewhere else; this is just the revision graph that goes along with that. (Or perhaps the series is not stored at all, but implicit in the ancestry relationships between the branch heads.): |\| | | |\| A | | \| | B | \| C To make the patch series order be A -> C -> B instead, we must: - remove the "B" changes from C - apply the "C" changes to B I.e., we want a revision that has only "A" changes in branch A, we want a revision that has only "A" and "C" changes in branch C, and we want a revision that has "A", "B" and "C" changes in branch B. (Interestingly, the current head of C actually has this property already.) Also, we want the head of B to be a descendent of the head of C. (The current head of "C" does not have this property.) The way to do this is: |\| | | |\| A | | \| | B | \| C | <-- this edge is an inversion of the A->B edge merged into C newC | newB <-- this revision is a copy of the old C head The newC revision is created by merging C and A, using B as a common ancestor. (To do this with current mtn, just 'co -r h:C; pluck -r h:B -r h:A; commit'.) Then the newB revision is created by taking the old C head's roster, re-committing it as a child of newC, and putting the resulting revision into branch B instead. -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
