Re: [Monotone-devel] Packages for Debian testing
Hi, Zack Weinberg wrote: some time to figure it out. [ I am not certain 0.33-2 will actually go into testing after ten days - grep-excuses seems to think bug 425907 is relevant even though it affects 0.31-8 too, and *may* be confused about which boost libraries it needs... but we don't have to worry about that right now, anyway. ] I'm not sure exactly how the excuses script works, but http://bugs.debian.org/cgi-bin/version.cgi?width=;info=1;height=;found=monotone%2F0.31-8;package=monotone;format=png;collapse=0;ignore_boring=0 seems to indicate that it thinks 0.33-2 isn't a direct descendent of 0.31-8 - maybe this is why it thinks that's a problem? -- Jon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] CHAR_BIT on Mac OS X not in limits
Hi! Building 0.35 on Mac OS X (10.4.10), I found that you're expecting CHAR_BIT to be defined in limits. The file in question is numeric_vocab.hh . Unfortunately, that does not seem to be the case. The C header limits.h does define CHAR_BIT, however. Including both does not seem to cause any conflicts. I'm currently fiddling with the monotone source code to create a new command that allows me to re-sign revisions. At first glance, that seems possible. Why do I want to do that? Let's just say I did stuff when I wasn't fully awake... as a result, I now have a number of revisions in my db that are signed with a key that doesn't exist anymore. What's worse, I have a key with the same ID in the db, so monotone (quite correctly) cries havoc. And, no, I don't have backups. If you have any better idea than regenerating signatures with the new key for each revisions, I'd be glad to hear it. If not, is there any interest for a command like that to go into monotone? Any preferences as to the specifics of this command? Personally, I'd go the simple/stupid way and would want mtn sign key id revision overwriting any previous signatures for that revision in the db. Thanks for any replies, Jens ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
In message [EMAIL PROTECTED] on Fri, 6 Jul 2007 18:17:18 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw On 7/6/07, Ludovic Brenta [EMAIL PROTECTED] wrote: zackw Second, I would indeed encourage you, Richard and Zack, to zackw co-maintain the package. That means, as a prerequisite, that zackw I'd like you to agree on merging your scripts, and on a zackw long-term maintenance strategy. zackw zackw As far as scripts, I don't have any; Me neither. I was wondering what scripts you were talking about, Ludovic. The snapshots I make are a different story, and the script I use there isn't really that interesting for regular releases, as most of it is about propagating from three different monotone branches to a private one. For regular releases, I simply use dpkg-buildpackage (or debuild the last two or three days). zackw I was just taking the official 0.35 release tarball and zackw manually applying relevant bits of the 0.31-8 Debian diff, plus zackw one post-0.35 change. I'd be inclined to track official zackw releases as closely as possible. Richard, what are your zackw thoughts? In complete agreement. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Richard Levitte [EMAIL PROTECTED] writes: Zack Weinberg said: zackw On 7/6/07, Ludovic Brenta [EMAIL PROTECTED] wrote: zackw Second, I would indeed encourage you, Richard and Zack, to zackw co-maintain the package. That means, as a prerequisite, that zackw I'd like you to agree on merging your scripts, and on a zackw long-term maintenance strategy. zackw zackw As far as scripts, I don't have any; Me neither. I was wondering what scripts you were talking about, Ludovic. The snapshots I make are a different story, and the script I use there isn't really that interesting for regular releases, as most of it is about propagating from three different monotone branches to a private one. For regular releases, I simply use dpkg-buildpackage (or debuild the last two or three days). By scripts I simply mean the contents of the debian/ subdirectory. zackw I was just taking the official 0.35 release tarball and zackw manually applying relevant bits of the 0.31-8 Debian diff, plus zackw one post-0.35 change. I'd be inclined to track official zackw releases as closely as possible. Richard, what are your zackw thoughts? In complete agreement. Me too. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] CHAR_BIT on Mac OS X not in limits
In message [EMAIL PROTECTED] on Sat, 7 Jul 2007 12:17:33 +0200, Jens Finkhäuser [EMAIL PROTECTED] said: jens Building 0.35 on Mac OS X (10.4.10), I found that you're jens expecting CHAR_BIT to be defined in limits. The file in jens question is numeric_vocab.hh . That bug has been fixed and the fix will be part of 0.36. The fix is very easy, just add the following line among the includes: #include climits Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Jon Bright [EMAIL PROTECTED] writes: Hi, Zack Weinberg wrote: some time to figure it out. [ I am not certain 0.33-2 will actually go into testing after ten days - grep-excuses seems to think bug 425907 is relevant even though it affects 0.31-8 too, and *may* be confused about which boost libraries it needs... but we don't have to worry about that right now, anyway. ] I'm not sure exactly how the excuses script works, but http://bugs.debian.org/cgi-bin/version.cgi?width=;info=1;height=;found=monotone%2F0.31-8;package=monotone;format=png;collapse=0;ignore_boring=0 seems to indicate that it thinks 0.33-2 isn't a direct descendent of 0.31-8 - maybe this is why it thinks that's a problem? I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. So I closed the two bugs; they will not block monotone from going into testing. However, boost has been blocked for 53 days by 2 RC bugs; one of them is fixed in experimental but the other one (#429533) seems problematic. The 0.33-2 in unstable is built against boost 1.34.0-1, which has both bugs. Also, it was built with g++-4.2 (the new default C++ compiler as of two weeks ago), so watch out for any bugs. I think it is appropriate to allow the package to mature a little more in unstable. Personally I run testing and I am content with 0.31-6 for now. (I do have an unstable chroot for building packages). -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
In message [EMAIL PROTECTED] on Sat, 07 Jul 2007 13:31:40 +0200, Ludovic Brenta [EMAIL PROTECTED] said: ludovic Sure. I'd add myself before uploading in any case :) Now, ludovic you and Richard should decide who will be in the Maintainer: ludovic field :) Zack, how much do you desire being an official maintainer. Or shall we do a virtual rock, scissors, bag? Don't misunderstand me, I have zero problems being a maintainer for monotone, considering I'm already involved to a large enough degree that I think the difference won't be that big. Another thought is, does the maintainer have to be a person, or can it be a group of maintainers? Technically, all we would need is a mailing list (possibly monotone-devel@nongnu.org, but that depends on what the rest of the list thinks of that idea), and it wouldn't look different from a debian/control point of view. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Help request with buildbot for monotone
Hello, I've approximately understood how buildbot is supposed to be set up, and I've starting setting it up (both a master and a slave) on monotone.ca. Trouble is, it seems like my factory isn't quite working as I expected... it literally seems to do nothing. You can view the result for yourself on http://monotone.ca:8010/ if you're amused by a slave doing nothing ;-). So, I'm trying to read the monotone part of all the python code, but python not being the language I know the best (far from it), I'm a little lost. How the hell is the factory supposed to be set up? Right now, the factory I use looks like this: f_unix_general = factory.BuildFactory() f_unix_general.addStep(Monotone, server_addr=monotone.ca, branch=net.venge.monotone, monotone=mtn) f_unix_general.addStep(ShellCommand, command=[autoreconf, -i]) f_unix_general.addStep(Configure) f_unix_general.addStep(Compile) f_unix_general.addStep(Test, command=[make, check]) If someone (njs! *wink* *wink* *nudge* *nudge*) could point out what I'm doing wrong, I'd be quite happy. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: By scripts I simply mean the contents of the debian/ subdirectory. Ah, well, I'd be using the stuff currently in debian/ on net.venge.monotone. The way I see it working under ideal conditions is that the -1 release for any given upstream release has an empty (but present) Debian diff, and subsequent Debian releases accumulate changes in the diff. We can also bring forward Debian-specific changes in the diff if necessary (e.g. the current removal of -DBOOST_SP_DISABLE_THREADS). I am not inclined to use a patch system, as I don't expect divergence from upstream sufficient to warrant it. We are currently using cdbs; I wouldn't object to switching to a pure debhelper arrangement. I don't mind it myself but I know there are lots of people who don't like cdbs. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. Argh. So I closed the two bugs; they will not block monotone from going into testing. Was that really the right thing to do? Those bugs are real and present in 0.33-2; it's just that they're in 0.31-8 as well... However, boost has been blocked for 53 days by 2 RC bugs; one of them is fixed in experimental but the other one (#429533) seems problematic. The 0.33-2 in unstable is built against boost 1.34.0-1, which has both bugs. Double argh, and IMO entirely destroys the point of doing 0.33-2 at all; it was supposed to be built against 1.33.1, to avoid those problems and the known bugs in monotone =0.35 when boost 1.34 is in use! ... however, I have just installed the 0.33-2 package from unstable, and it sure *looks* like it's built against boost 1.33; are you sure? Also, it was built with g++-4.2 (the new default C++ compiler as of two weeks ago), so watch out for any bugs. ... according to mtn --full-version, this is not true either. I think it is appropriate to allow the package to mature a little more in unstable. I'm not proposing to push it in ahead of the 10-day window, but I'd like to see it go in as soon as possible after that. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
On 7/7/07, Richard Levitte [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Sat, 07 Jul 2007 13:31:40 +0200, Ludovic Brenta [EMAIL PROTECTED] said: ludovic Sure. I'd add myself before uploading in any case :) Now, ludovic you and Richard should decide who will be in the Maintainer: ludovic field :) Zack, how much do you desire being an official maintainer. Or shall we do a virtual rock, scissors, bag? Don't misunderstand me, I have zero problems being a maintainer for monotone, considering I'm already involved to a large enough degree that I think the difference won't be that big. I am indifferent, truly. I kinda like the mailing list idea. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtn sign
On 07/07/2007, at 9:00 AM, [EMAIL PROTECTED] wrote: I'm currently fiddling with the monotone source code to create a new command that allows me to re-sign revisions. At first glance, that seems possible. Sounds very possible, and a great idea... Why do I want to do that? Let's just say I did stuff when I wasn't fully awake... as a result, I now have a number of revisions in my db that are signed with a key that doesn't exist anymore. What's worse, I have a key with the same ID in the db, so monotone (quite correctly) cries havoc. And, no, I don't have backups. I ended up with the same problem after a new user did the same thing (two keys, one ID) in my DB earlier this year. My solution was to pull to a new DB, and change epochs to stop the bad revs being pushed in again. That was far too extreme for normal use, and I expect this to be a not uncommon problem with new users. It is made worse if you use ssh based syncing. Then ssh does the auth, which means the signatures aren't checked before revs are sent around, and it is really easy to propagate the bad certs. If you have any better idea than regenerating signatures with the new key for each revisions, I'd be glad to hear it. If not, is there any interest for a command like that to go into monotone? Any preferences as to the specifics of this command? Personally, I'd go the simple/stupid way and would want mtn sign key id revision overwriting any previous signatures for that revision in the db. Looks like a reasonable solution. You could probably already do this pretty easily at the moment - use automate to get the old certs, then re-sign with the new key. That will add duplicate certs signed by the new key. Then you sync the db to a new db, removing the old, bad certs. Adding a new command to do it cleanly seems useful though. This isn't the only approach however. Graydon mentioned recently that he considered forcing all keys to have unique ID's to be a bug. If keys were referenced by hash instead then you could have multiple keys with the same ID. That would seem to be a better long term fix for the problem (although I think the short term fix is also useful...). Be well, Will :-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
On 7/7/07, Zack Weinberg [EMAIL PROTECTED] wrote: On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. Argh. Okay. So maybe it's not as simple as uploading the version from experimental to unstable. I forgot to include the translations added in -7 and -8. Double argh, and IMO entirely destroys the point of doing 0.33-2 at all; it was supposed to be built against 1.33.1, to avoid those problems and the known bugs in monotone =0.35 when boost 1.34 is in use! ... however, I have just installed the 0.33-2 package from unstable, and it sure *looks* like it's built against boost 1.33; are you sure? My Deb-fu was lacking. I built the i386 binary to use boost 1.33.1 from testing. However, all the buildd architecture binaries will be built from unstable using boost 1.34. If monotone 0.33 is buggy with boost 1.34, this is an RC bug and 0.33 will not migrate to testing. If that's the case, you may as well upload 0.35. In the mean time, i386 users can use the 0.33 binary in unstable. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
In message [EMAIL PROTECTED] on Sat, 7 Jul 2007 09:46:25 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw I kinda like the mailing list idea. Seems like a good option, doesn't it? It would allow for maintainers to help each other easily, or to switch with minimal hassle. What does the Debian community think of such a setup, incidently? Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
On 7/7/07, Richard Levitte [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] on Sat, 7 Jul 2007 09:46:25 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw I kinda like the mailing list idea. Seems like a good option, doesn't it? It would allow for maintainers to help each other easily, or to switch with minimal hassle. What does the Debian community think of such a setup, incidently? A team of maintainers is great. In fact, it's done quite regularly. Just search google for 'debian maintainer team'. If the team's well coordinated, it can work much better than a single maintainer. Cheers, Shaun ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
On 7/7/07, Shaun Jackman [EMAIL PROTECTED] wrote: On 7/7/07, Zack Weinberg [EMAIL PROTECTED] wrote: On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. Argh. Okay. So maybe it's not as simple as uploading the version from experimental to unstable. I forgot to include the translations added in -7 and -8. I've uploaded 0.33-3 which includes the forgotten -7 and -8 changes. Cheers, Shaun monotone (0.33-3) unstable; urgency=low * Include the Japanese and Portuguese translations from 0.31-7 and 0.31-8, which were accidentally omitted in 0.33-2. -- Shaun Jackman [EMAIL PROTECTED] Sat, 7 Jul 2007 11:09:04 -0600 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
In message [EMAIL PROTECTED] on Sat, 7 Jul 2007 09:39:25 -0700, Zack Weinberg [EMAIL PROTECTED] said: zackw On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: zackw By scripts I simply mean the contents of the debian/ subdirectory. zackw zackw Ah, well, I'd be using the stuff currently in debian/ on zackw net.venge.monotone. Yup, that's what I would expect to use as well. There's really only one little difference between debian/control in n.v.m and the one in my snapshot branch: Build-Depends: cdbs (= 0.4.28), debhelper (= 4.0.0), autotools-dev, - libboost-filesystem-dev, libboost-regex-dev, libboost-dev, libz-dev + libboost-filesystem-dev, libboost-regex-dev, libboost-dev, libz-dev, + po-debconf Is po-debconf something we actually need? I've never really checked, but it was there in the n.v.m.debian branch once upon a time... zackw The way I see it working under ideal conditions is that the -1 zackw release for any given upstream release has an empty (but zackw present) Debian diff, and subsequent Debian releases accumulate zackw changes in the diff. We can also bring forward Debian-specific zackw changes in the diff if necessary (e.g. the current removal of zackw -DBOOST_SP_DISABLE_THREADS). I agree with that. zackw I am not inclined to use a patch system, as I don't expect zackw divergence from upstream sufficient to warrant it. Completely agree. zackw We are currently using cdbs; I wouldn't object to switching to zackw a pure debhelper arrangement. I don't mind it myself but I zackw know there are lots of people who don't like cdbs. I don't have enough knowledge for that part, so I'll happily leave that entirely in your hands and will just be a willing tester ;-). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtn sign
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William Uther schreef: Personally, I'd go the simple/stupid way and would want mtn sign key id revision overwriting any previous signatures for that revision in the db. If it overwrites any previous signatures the command should be 'resign', since I would assume 'sign' would just *add* my signature. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGj9piMkyGM64RGpERAmGGAKCXzf69VplBEUL/8NWZ6LoSnQmfKQCdHRGV LFddBLtrOTT89JSB99ZTt6c= =8ONN -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] RFC: 'suspend' certs
Hi all, I'm busy scratching mtn itches. Another on my list is that I tend to refrain from using branches as very lightweight objects because they never go away. Now, the mythical policy branches were touted as a solution to this, but I must admit I don't have a clear idea of how they're supposed to work... (BTW, I'm in the Bay area at the moment. If someone is around who understands policy branches and wants to chat about them, drop me an email.) Anyway, I have another proposed solution. It is a 'suspend' cert. It looks the same as a 'branch' cert in that it contains the name of a branch. The effect of a 'suspend' cert is to remove that revision from any list of heads for that branch. If all the heads of a branch are suspended, then the branch no longer appears in mtn ls branches. The meaning of suspend is not this is a bad revision: we already have test failure for that. The meaning is I don't want mtn to bother me with this revision. We could use other synonyms for suspend: discontinue, terminate, cease, close, yield, shelve, end, finish, conclude, abandon, vanish, obviate, debar, inactivate, desist... but I'll go with suspend unless there is an outcry. ( http://en.wikipedia.org/wiki/Color_of_the_bikeshed ) Notes: - A suspend cert does not stop anyone from making descendants of the revision, and they'll appear on lists of heads just as normal. - A suspend cert does stop merge from trying to merge the revision by default. (I'm looking at putting the filter in project_t::get_branch_list(), project_t::get_branch_heads() and pick_update_candidates()) - A suspend cert and update interact in a somewhat complex manner. If all update candidates are suspended then they're all considered. If some update candidates are not suspended, then all the suspended candidates are removed. Thoughts, comments? Will :-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: 'suspend' certs
On 07/07/2007, at 20:53, William Uther wrote: The meaning of suspend is not this is a bad revision: we already have test failure for that. The meaning is I don't want mtn to bother me with this revision. Or I don't want other users to bother with this revision because it's dead, obsolete, abandoned, whatever, isn't it? We could use other synonyms for suspend: discontinue, terminate, cease, close, yield, shelve, end, finish, conclude, abandon, vanish, obviate, debar, inactivate, desist... but I'll go with suspend unless there is an outcry. ( http://en.wikipedia.org/wiki/Color_of_the_bikeshed ) Shouldn't it then be suspended instead of suspend? Anyway, it seems to me that this is a good idea (but I don't know anything about policy branches). -- Julio M. Merino Vidal [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: 'suspend' certs
In message [EMAIL PROTECTED] on Sat, 7 Jul 2007 11:53:35 -0700, William Uther [EMAIL PROTECTED] said: willu.mailingListsAnyway, I have another proposed solution. It willu.mailingLists is a 'suspend' cert. It looks the same as a willu.mailingLists 'branch' cert in that it contains the name of a willu.mailingLists branch. The effect of a 'suspend' cert is to willu.mailingLists remove that revision from any list of heads for willu.mailingLists that branch. If all the heads of a branch are willu.mailingLists suspended, then the branch no longer appears in willu.mailingLists mtn ls branches. I like the idea! willu.mailingLists ( http://en.wikipedia.org/wiki/Color_of_the_bikeshed ) It should be clear by now that the bikeshed must be colored violet with pink dots. willu.mailingListsNotes: willu.mailingLists - A suspend cert does not stop anyone from willu.mailingLists making descendants of the revision, and they'll willu.mailingLists appear on lists of heads just as normal. willu.mailingLists - A suspend cert does stop merge from trying willu.mailingLists to merge the revision by default. (I'm looking at willu.mailingLists putting the filter in project_t::get_branch_list(), willu.mailingLists project_t::get_branch_heads() and willu.mailingLists pick_update_candidates()) willu.mailingLists - A suspend cert and update interact in a willu.mailingLists somewhat complex manner. If all update candidates willu.mailingLists are suspended then they're all considered. If willu.mailingLists some update candidates are not suspended, then all willu.mailingLists the suspended candidates are removed. willu.mailingLists willu.mailingLists Thoughts, comments? Only one, really: how do we handle irresponsable usage of that cert. I would normally expect developers to be responsable (and I'm sure there are a few laughing at this point ;-)), but I can also imagine cases when developers become childish over issues and could go into a suspend war. Should we care? Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: 'suspend' certs
On 07/07/2007, at 12:10 PM, Richard Levitte wrote: willu.mailingLists ( http://en.wikipedia.org/wiki/ Color_of_the_bikeshed ) It should be clear by now that the bikeshed must be colored violet with pink dots. Green! On 07/07/2007, at 12:02 PM, Julio M. Merino Vidal wrote: Shouldn't it then be suspended instead of suspend? The name of the cert is irrelevant as the user never sees it. The name of the command should be suspend because it is a command, not a description of the state of the branch. On 07/07/2007, at 12:10 PM, Richard Levitte wrote: Only one, really: how do we handle irresponsable usage of that cert. I would normally expect developers to be responsable (and I'm sure there are a few laughing at this point ;-)), but I can also imagine cases when developers become childish over issues and could go into a suspend war. Should we care? Normal mechanisms apply. In particular, you can personally choose not to trust certs by a particular developer. Will:-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: 'suspend' certs
William Uther [EMAIL PROTECTED] writes: [...] Anyway, I have another proposed solution. It is a 'suspend' cert. It looks the same as a 'branch' cert in that it contains the name of a branch. The effect of a 'suspend' cert is to remove that revision from any list of heads for that branch. If all the heads of a branch are suspended, then the branch no longer appears in mtn ls branches. That seems not unrelated to http://thread.gmane.org/gmane.comp.version-control.monotone.devel/5660. (Which doesn't seem surprising: there are a few problems that seem almost solvable with what monotone's already got, so it's natural to look at smallish changes that might smooth some of the rough edges, and such changes are likely to overlap quite a bit.) [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: 'suspend' certs
In message [EMAIL PROTECTED] on Sat, 7 Jul 2007 13:35:07 -0700, William Uther [EMAIL PROTECTED] said: willu.mailingLists On 07/07/2007, at 12:10 PM, Richard Levitte wrote: willu.mailingLists willu.mailingLists Only one, really: how do we handle irresponsable willu.mailingLists usage of that cert. [...] willu.mailingLists willu.mailingLists Normal mechanisms apply. In particular, you can willu.mailingLists personally choose not to trust certs by a willu.mailingLists particular developer. Good point. (especially for someone having no taste in bikeshed color ;-)) Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Packages for Debian testing
Zack Weinberg writes: On 7/7/07, Ludovic Brenta [EMAIL PROTECTED] wrote: I looked at the changelog, and indeed it has branches. For example the current changelog (0.33-2) does not list 0.31-8 (or -7) at all. Argh. So I closed the two bugs; they will not block monotone from going into testing. Was that really the right thing to do? Those bugs are real and present in 0.33-2; it's just that they're in 0.31-8 as well... The bugs said FTBFS but 0.33-2 built just fine on all architectures, so the bugs are gone. That's why I closed them. However, boost has been blocked for 53 days by 2 RC bugs; one of them is fixed in experimental but the other one (#429533) seems problematic. The 0.33-2 in unstable is built against boost 1.34.0-1, which has both bugs. Double argh, and IMO entirely destroys the point of doing 0.33-2 at all; it was supposed to be built against 1.33.1, to avoid those problems and the known bugs in monotone =0.35 when boost 1.34 is in use! Yes. If you want a recent version of monotone on an older version of libraries, the only solution right now is www.backports.org, i.e. the latest version of monotone running on Etch, i.e. using g++-4.1 and boost 1.33.1-10. ... however, I have just installed the 0.33-2 package from unstable, and it sure *looks* like it's built against boost 1.33; are you sure? It is a coincidence that you use the same architecture as Shaun (i386). I'm on amd64, and I would use the version just built against boost 1.34 on the buildds. Also, it was built with g++-4.2 (the new default C++ compiler as of two weeks ago), so watch out for any bugs. ... according to mtn --full-version, this is not true either. Ditto. I think it is appropriate to allow the package to mature a little more in unstable. I'm not proposing to push it in ahead of the 10-day window, but I'd like to see it go in as soon as possible after that. Me too, but as soon as possible really depends on boost. I suggest you contact the boost maintainers, chip in on monotone using the single-threaded version of boost (see the last comment in #429533), and ask what the boost maintainers' plans are regarding the two RC bugs. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: 'suspend' certs
On Sat, Jul 07, 2007 at 11:53:35AM -0700, William Uther wrote: I'm busy scratching mtn itches. Excellent. Anyway, I have another proposed solution. It is a 'suspend' cert. It looks the same as a 'branch' cert in that it contains the name of a branch. The effect of a 'suspend' cert is to remove that revision from any list of heads for that branch. If all the heads of a branch are suspended, then the branch no longer appears in mtn ls branches. I like the idea, but it seems specific to a particular usage - that's not necessarily a bad thing, but I'd like to consider the generalised problem for a moment, because there's a mechanism here that may be useful elsewhere too (without trying to reinvent policy branches). Just a little thought excursion/exploration, nothing concrete in terms of real requirements.. For starters, it might be nice to generalise the cert form to something like a branch-status:suspended branch.name cert, leaving room for other statuses too (needs-testing, ready-for-integration, finished, merged, abandoned, and a list of other possible bikeshed colours). As a general rule from that, the branch status descriptor becomes the union of the (trusted) status certs on all the (otherwise valid) heads. This is something that's created centrally and available wherever needed, listed with a new ls variant, etc. Then there's the interpretation and resulting behaviour for particular values - such as hiding the branch name in 'ls branches' as you propose for 'suspended'. This interpretation may include combined statuses (does foo trump bar, are they independent, etc). Perhaps this interpretation also includes looking at some of the other status values that were on some (but not all) of the heads (a subsidiary descriptor for partial statuses). This seems like something to leave entirely up to user hooks, if at all, other than providing the raw descriptors. This reminds me of an earlier discussion about branch statuses. I think at that time we posited that the status value would be inherited down the ancestry tree until overridden by another cert on a descendant, leading to a kind of graph-colouring status. That got very quickly into looking like merging behaviour (though with the difference of being able to add certs to existing revs), and from there into certifying across to policy branches where merging is well defined. The all heads rule seems simple enough not to step into that territory and be useful in the meantime. Notes: - A suspend cert does not stop anyone from making descendants of the revision, and they'll appear on lists of heads just as normal. This seems fine, perhaps add some UI as a variant: - if all heads of a branch are suspended, we could discourage (but not forbid) the creation of new branch certs on that branch, eg via commit, propagate, approve. This means you need to do something explicit to create the descendants (to prevent accidents), but you can fork off a new branch name from here as normal. There c/should be a switch (--no-ignore-suspended, or something like --no-status more suitable to the generalised status form above?) that makes the status behaviour ineffective (so you can see the branch again in ls, so you can commit descendants, etc.) - A suspend cert does stop merge from trying to merge the revision by default. (I'm looking at putting the filter in project_t::get_branch_list(), project_t::get_branch_heads() and pick_update_candidates()) - A suspend cert and update interact in a somewhat complex manner. If all update candidates are suspended then they're all considered. If some update candidates are not suspended, then all the suspended candidates are removed. I'm less sure about these; they seem to cross from don't worry about this branch to don't use this revision which you rightly stated was better done with testresult or other certs. I think the right behaviour falls out naturally from the 'all heads or nothing' rule, which applies to the use of the branch as a whole, not individual revs. For merge, perhaps don't try and merge a branch where all heads are suspended (unless the same --no-whatever switch is given). Maybe it's known they can't easily be merged, and that's why the branch was abandoned. Or perhaps don't try and merge pairs of heads where both are suspended - but if there's a non-suspended (maybe new) head, that could merge with a suspended head, as would the also not suspended descendant be with the next suspended head. But really, I'm not sure any special behaviour is needed here. For update, the only special behaviour might be a this branch is suspended warning. If there's a single head, we should just update to it. If there are multiple heads (all suspended), the pick one or please try a merge warning gets changed a little as above; it's probably an old workspace and the most likely user action is to abandon the workspace too (or switch it to a new
[Monotone-devel] Re: RFC: 'suspend' certs
Bruce Stephens wrote: That seems not unrelated to http://thread.gmane.org/gmane.comp.version-control.monotone.devel/ 5660. (Which doesn't seem surprising: there are a few problems that seem almost solvable with what monotone's already got, so it's natural to look at smallish changes that might smooth some of the rough edges, and such changes are likely to overlap quite a bit.) Yeah, except my version is green. Did you even commit your version to a branch? Will:-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] CHAR_BIT on Mac OS X not in limits
Jens Finkhäuser wrote: I'm currently fiddling with the monotone source code to create a new command that allows me to re-sign revisions. At first glance, that seems possible. Doesn't the cert command already do this? You will have to issue 4 certs for each revision (branch, author, date, changelog). Or are you thinking of a macro command that issues these 4 certs with a new key? Why do I want to do that? Let's just say I did stuff when I wasn't fully awake... as a result, I now have a number of revisions in my db that are signed with a key that doesn't exist anymore. What's worse, I have a key with the same ID in the db, so monotone (quite correctly) cries havoc. And, no, I don't have backups. A large number or a small one? ;) - make a backup db! - delete all the bad certs from the bad revisions - issue new certs on each revision using values from the old db This is possibly easier with a small number of bad revs but I'm sure you it can be scripted for a large number. If you have any better idea than regenerating signatures with the new key for each revisions, I'd be glad to hear it. If not, is there any interest for a command like that to go into monotone? Any preferences as to the specifics of this command? Personally, I'd go the simple/stupid way and would want mtn sign key id revision mtn cert revision branch '...' mtn cert revision date '...' mtn cert revision author '...' mtn cert revision changelog '...' Yeah, this is a little verbose and will require a lot more typing that simply saying please resign all of the certs on some revision with a new key I guess. overwriting any previous signatures for that revision in the db. You can really only issue new certs with the new key. Overwriting doesn't work so well because if you've pushed the bad certs to any other database they'll simply come back the next time you sync. Thanks for any replies, Hope this helps. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: partial pull #2 - gaps instead of a single horizon
Thomas Moschny wrote: If *every* string representing a path in the database started with foo, that prefix could also be omitted, because it would be redundant. If however only some paths started with foo and the others did not, the prefix could obviously not be omitted. That's all I wanted to say. Ok, that makes more sense. In your proposal, all paths in the db would start with './', and I was trying to imagine (or asking you if you could imagine) an extension to your proposal in which some paths don't have that prefix. If we can't find such a use case, then there's no point in having that prefix *in the db* at all. Yeah, so there's a potential 2 byte per path optimization. I agree that it probably doesn't make much sense to put these into the database though. If for no other reason that the change to existing revision hashes. (Note that I'm not saying it wouldn't be useful in the GUI, i.e. presented to or accepted from the user.) Yeah, I wonder whether listing paths in the UI with such prefixes would be a good idea or not. It would at least allow for displaying the root dir with a somewhat sensible name. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] trac-like systems for monotone
Hi, So in going down my list of itches, I came to I want something Trac-like. Being initially thwarted by the fact that the monotone- Trac plugin website seems to have gone down (I know, it's committed as a branch to the main repo, but I didn't remember that at the time), I went looking for other options. This then is a rambling email about what I found and what the problems were. It is a rough state of things email. The first things that I came across this: http://twiki.org/cgi- bin/view/Plugins/MercurialContrib Simply put, TWiki normally stores all its data in plain text files. It handles versioning using rcs. The above plugin replaces rcs with mercurial. The result is that you can run TWiki in multiple places and synchronise them all. It doesn't look that hard to convert the plugin to use monotone instead. There are also things like bug-tracker plugins for twiki. So there's at least one round-about way to get a distributed bug tracker. There are some issues with going this route though: - twiki is fairly heavyweight, and although it can be made distributed, it is designed to be run on a central server, not by each user. - twiki needs a web server. Jetty works, but this adds to the weight. - The end result is missing branch/revision/diff browsing and log browsing One could take something like ViewMTN and integrate it with TWiki (one of the features I like about Trac is that you can use wiki markup in commit messages and it works). That isn't going to make the whole system lighter weight... Or you could take something like Guitone and add a simple hypertext system to it, using mtn as the backing store. That would be well-suited to running on the end-user's system. It would mean implementing yet another hypertext system and bug tracking system, and you'd lose the easy way to have them web accessible. So then I looked at what others do: - Monotone development itself doesn't use a bug tracking system (although there seems to be some tests that are there solely as bug markers). - Pidgin uses Trac for the wiki and bug tracking, and ViewMTN for the source view. They are able to close tickets in commit messages, but the text in ViewMTN doesn't link to the tickets or other wiki entries. - OpenEmbedded use BugZilla, a generic wiki, ViewMTN, and a generic file browser pointed at a monotone working copy. Has anyone tried making twiki distributed? Did it work? e.g. http://article.gmane.org/gmane.comp.version- control.monotone.devel/6044 Cheers, Will :-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
