Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/22/2010 10:48 PM, Hendrik Boom wrote: On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote: On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: On 11/22/2010 09:43 AM, Hendrik Boom wrote: This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. Yep, that would be ideal except it looks like rpm-based distros don't support it. Maybe we should log a bug against rpm itself. Maybe we should first find out what the actual specifications are for version numbers in rpm. http://rpm.org/gitweb?p=rpm.git;a=blob_plain;f=lib/rpmvercmp.c;hb=HEAD Numeric segments are newer then alpha segments, anything other than an alnum is a separator and is otherwise ignored. So "abc123.de-~f8g" has segments "abc" (alpha), "123" (numeric), "de" (alpha), "f" (alpha), "8" (numeric), "g" (alpha). I also found a perl module earlier today that claimed to have copied an earlier rpm version; that had alpha vs. numeric segments in the same position as arbitrary/undefined but was otherwise the same. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote: > On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: > > On 11/22/2010 09:43 AM, Hendrik Boom wrote: > >> This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, > >> which will sort before version 1.1 > >> > >> This sounds like the numbering system we're looking for. > >> > >> Of course, this isn't the *entire* comparison alrorithm. There's also > >> an epoch and a Debian-specific attachment to the verison number. Check > >> the link above for further details. > > > > Yep, that would be ideal except it looks like rpm-based distros don't > > support it. > > Maybe we should log a bug against rpm itself. Maybe we should first find out what the actual specifications are for version numbers in rpm. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: > On 11/22/2010 09:43 AM, Hendrik Boom wrote: >> This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, >> which will sort before version 1.1 >> >> This sounds like the numbering system we're looking for. >> >> Of course, this isn't the *entire* comparison alrorithm. There's also >> an epoch and a Debian-specific attachment to the verison number. Check >> the link above for further details. > > Yep, that would be ideal except it looks like rpm-based distros don't > support it. Maybe we should log a bug against rpm itself. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone bombs on privkey?
Am 22.11.10 16:51, schrieb Aaron W. Hsu: > I was attempting to use privkey, but apparently it isn't working the way > I thought it was: > > > 782 arcfide$ mtn privkey arcf...@sacrideo.us > mtn: misuse: there is no key named 'arcf...@sacrideo.us' This has been fixed in a69b014519d54982daf0ea0ab54999b3a4e292d3. > 783 arcfide$ mtn privkey 0 > mtn: fatal: error: project.cc:599: I(!info.id.inner()().empty()) > mtn: this is almost certainly a bug in monotone. > mtn: please send this error message, the output of 'mtn version --full', > mtn: and a description of what you were doing to monotone-de...@nongnu.org. > mtn: wrote debugging log to /home/arcfide/.monotone/dump > mtn: if reporting a bug, please include this file > 784 arcfide$ This is a general problem with a couple of related key commands. Will look into it later on. 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: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/22/2010 09:43 AM, Hendrik Boom wrote: This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. Yep, that would be ideal except it looks like rpm-based distros don't support it. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone bombs on privkey?
If you do the following, you'll get a list of available keys: mtn ls keys However, what you have hit upon is a bug in the key identifier reader, which seems to be triggered by one-character arguments. Also, when I'm trying, it's also telling me that keys that are there can't be found: mtn privkey rich...@levitte.org mtn: misuse: there is no key named 'rich...@levitte.org' (that's the key I use for commits, so I know for a fact it exists ;-)) Cheers, Richard In message on Mon, 22 Nov 2010 10:51:12 -0500, "Aaron W. Hsu" said: arcfide> I was attempting to use privkey, but apparently it isn't working the arcfide> way I thought it was: arcfide> arcfide> arcfide> 782 arcfide$ mtn privkey arcf...@sacrideo.us arcfide> mtn: misuse: there is no key named 'arcf...@sacrideo.us' arcfide> 783 arcfide$ mtn privkey 0 arcfide> mtn: fatal: error: project.cc:599: I(!info.id.inner()().empty()) arcfide> mtn: this is almost certainly a bug in monotone. arcfide> mtn: please send this error message, the output of 'mtn version arcfide> --full', arcfide> mtn: and a description of what you were doing to arcfide> monotone-de...@nongnu.org. arcfide> mtn: wrote debugging log to /home/arcfide/.monotone/dump arcfide> mtn: if reporting a bug, please include this file arcfide> 784 arcfide$ arcfide> arcfide> The output of mtn version --full follows: arcfide> arcfide> monotone 0.99.1 (base revision: arcfide> 8973482283db7c36780dce2b54721ccc0f5b7388) arcfide> Running on : Linux 2.6.33.4 #2 SMP Tue Sep 21 17:28:38 CDT 2010 x86_64 arcfide> C++ compiler: GNU C++ version 4.4.4 arcfide> C++ standard library: GNU libstdc++ version 20100429 arcfide> Boost version : 1_42 arcfide> SQLite version : 3.6.23.1 (compiled against 3.6.23.1) arcfide> Lua version : Lua 5.1 arcfide> PCRE version: 8.02 2010-03-19 (compiled against 8.2) arcfide> Botan version : 1.8.10 (compiled against 1.8.10) arcfide> Changes since base revision: arcfide> format_version "1" arcfide> arcfide> new_manifest [c1270158b7fa91abf8235ad129b0476943bde1ed] arcfide> arcfide> old_revision [8973482283db7c36780dce2b54721ccc0f5b7388] arcfide> arcfide> Generated from data cached in the distribution; arcfide> further changes may have been made. arcfide> arcfide> And a dump that was in .monotone/dump: arcfide> arcfide> Encountered an error while musing upon the following: arcfide> project.cc:599: detected internal error, arcfide> 'I(!info.id.inner()().empty())' violated arcfide> Current work set: 7 items arcfide> - begin 'system_flavour' (in virtual void sanity::initialize(int, arcfide> - char**, const char*), at sanity.cc:117) arcfide> Linux 2.6.33.4 #2 SMP Tue Sep 21 17:28:38 CDT 2010 x86_64 arcfide> - end 'system_flavour' (in virtual void sanity::initialize(int, char**, arcfide> - const char*), at sanity.cc:117) arcfide> - begin 'cmdline_string' (in virtual void sanity::initialize(int, arcfide> - char**, const char*), at sanity.cc:131) arcfide> 'mtn', 'privkey', '0' arcfide> - end 'cmdline_string' (in virtual void sanity::initialize(int, char**, arcfide> - const char*), at sanity.cc:131) arcfide> - begin 'string(lc_all)' (in virtual void sanity::initialize(int, arcfide> - char**, const char*), at sanity.cc:136) arcfide> LC_CTYPE=en_US;LC_NUMERIC=en_US;LC_TIME=en_US;LC_COLLATE=C;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=en_US;LC_ADDRESS=en_US;LC_TELEPHONE=en_US;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=en_US arcfide> - end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, arcfide> - const char*), at sanity.cc:136) arcfide> - begin 'full_version_string' (in virtual void arcfide> - mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:32) arcfide> monotone 0.99.1 (base revision: arcfide> 8973482283db7c36780dce2b54721ccc0f5b7388) arcfide> Running on : Linux 2.6.33.4 #2 SMP Tue Sep 21 17:28:38 CDT 2010 x86_64 arcfide> C++ compiler: GNU C++ version 4.4.4 arcfide> C++ standard library: GNU libstdc++ version 20100429 arcfide> Boost version : 1_42 arcfide> SQLite version : 3.6.23.1 (compiled against 3.6.23.1) arcfide> Lua version : Lua 5.1 arcfide> PCRE version: 8.02 2010-03-19 (compiled against 8.2) arcfide> Botan version : 1.8.10 (compiled against 1.8.10) arcfide> Changes since base revision: arcfide> format_version "1" arcfide> arcfide> new_manifest [c1270158b7fa91abf8235ad129b0476943bde1ed] arcfide> arcfide> old_revision [8973482283db7c36780dce2b54721ccc0f5b7388] arcfide> arcfide> Generated from data cached in the distribution; arcfide> further changes may have been made. arcfide> - end 'full_version_string' (in virtual void mtn_sanity::initialize(int, arcfide> - char**, const char*), at mtn-sanity.cc:32) arcfide> - begin 'info.id' (in void arcfide> - project_t::complete_key_identity_from_id(key_store*, lua_hooks&, arcfide> - key_identity_info&
[Monotone-devel] Monotone bombs on privkey?
I was attempting to use privkey, but apparently it isn't working the way I thought it was: 782 arcfide$ mtn privkey arcf...@sacrideo.us mtn: misuse: there is no key named 'arcf...@sacrideo.us' 783 arcfide$ mtn privkey 0 mtn: fatal: error: project.cc:599: I(!info.id.inner()().empty()) mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to monotone-de...@nongnu.org. mtn: wrote debugging log to /home/arcfide/.monotone/dump mtn: if reporting a bug, please include this file 784 arcfide$ The output of mtn version --full follows: monotone 0.99.1 (base revision: 8973482283db7c36780dce2b54721ccc0f5b7388) Running on : Linux 2.6.33.4 #2 SMP Tue Sep 21 17:28:38 CDT 2010 x86_64 C++ compiler: GNU C++ version 4.4.4 C++ standard library: GNU libstdc++ version 20100429 Boost version : 1_42 SQLite version : 3.6.23.1 (compiled against 3.6.23.1) Lua version : Lua 5.1 PCRE version: 8.02 2010-03-19 (compiled against 8.2) Botan version : 1.8.10 (compiled against 1.8.10) Changes since base revision: format_version "1" new_manifest [c1270158b7fa91abf8235ad129b0476943bde1ed] old_revision [8973482283db7c36780dce2b54721ccc0f5b7388] Generated from data cached in the distribution; further changes may have been made. And a dump that was in .monotone/dump: Encountered an error while musing upon the following: project.cc:599: detected internal error, 'I(!info.id.inner()().empty())' violated Current work set: 7 items - begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:117) Linux 2.6.33.4 #2 SMP Tue Sep 21 17:28:38 CDT 2010 x86_64 - end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:117) - begin 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:131) 'mtn', 'privkey', '0' - end 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:131) - begin 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:136) LC_CTYPE=en_US;LC_NUMERIC=en_US;LC_TIME=en_US;LC_COLLATE=C;LC_MONETARY=en_US;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=en_US;LC_ADDRESS=en_US;LC_TELEPHONE=en_US;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=en_US - end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:136) - begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:32) monotone 0.99.1 (base revision: 8973482283db7c36780dce2b54721ccc0f5b7388) Running on : Linux 2.6.33.4 #2 SMP Tue Sep 21 17:28:38 CDT 2010 x86_64 C++ compiler: GNU C++ version 4.4.4 C++ standard library: GNU libstdc++ version 20100429 Boost version : 1_42 SQLite version : 3.6.23.1 (compiled against 3.6.23.1) Lua version : Lua 5.1 PCRE version: 8.02 2010-03-19 (compiled against 8.2) Botan version : 1.8.10 (compiled against 1.8.10) Changes since base revision: format_version "1" new_manifest [c1270158b7fa91abf8235ad129b0476943bde1ed] old_revision [8973482283db7c36780dce2b54721ccc0f5b7388] Generated from data cached in the distribution; further changes may have been made. - end 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:32) - begin 'info.id' (in void project_t::complete_key_identity_from_id(key_store*, lua_hooks&, key_identity_info&) const, at project.cc:596) - end 'info.id' (in void project_t::complete_key_identity_from_id(key_store*, lua_hooks&, key_identity_info&) const, at project.cc:596) - begin 'info.official_name' (in void project_t::complete_key_identity_from_id(key_store*, lua_hooks&, key_identity_info&) const, at project.cc:597) - end 'info.official_name' (in void project_t::complete_key_identity_from_id(key_store*, lua_hooks&, key_identity_info&) const, at project.cc:597) - begin 'info.given_name' (in void project_t::complete_key_identity_from_id(key_store*, lua_hooks&, key_identity_info&) const, at project.cc:598) - end 'info.given_name' (in void project_t::complete_key_identity_from_id(key_store*, lua_hooks&, key_identity_info&) const, at project.cc:598) If I may ask, what's going on? How is privkey supposed to work? Aaron W. Hsu -- Programming is just another word for the lost art of thinking. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 10:18:47AM -0500, Hendrik Boom wrote: > On Mon, Nov 22, 2010 at 08:17:38AM -0600, Timothy Brownawell wrote: > > > > So I think basically rpm requires X.Y.Z even/odd scheme in order to > > distinguish release/dev. Which is annoying. > > The colon classification system had a scheme where some symbols would > collate before end-od-string. They used lower-case letters for this, so > 75a came before 75 > 75 came before 75A > Are there any such characters for use with the well-known package > managers? Yes, there is one -- the tilde. Here's a part of the DEbian specification for how upstream version numbers (i.e., ours) are to be sorted.I quote from http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version === First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order from earliest to latest: ~~, ~~a, ~, the empty part, a.[ Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. === This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 08:17:38AM -0600, Timothy Brownawell wrote: > > So I think basically rpm requires X.Y.Z even/odd scheme in order to > distinguish release/dev. Which is annoying. The colon classification system had a scheme where some symbols would collate before end-od-string. They used lower-case letters for this, so 75a came before 75 75 came before 75A Are there any such characters for use with the well-known package managers? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/22/2010 07:23 AM, Thomas Keller wrote: We already append a suffix "dev" to development snapshots (i.e. "1.0dev") which get created on build farms like openSUSE's build service. Thomas Moschny said that this is suboptimal because of rpm's version comparison algorithms which would consider "1.0dev" newer than "1.0", so whatever we come up for the release numbering (which must have widespread support for rpm, dpkg and friends), should be applied in a similar way to this. Personally I don't care much whether we use numbers or appended strings, as long as the algorithms are smart enough to find "1.0-dev" (or whatever) older than "1.0-alpha1" (or whatever). It looks like what rpm does is: split into all-alpha and all-numeric items, and then sort on string/numeric comparisons of each item, or sort on rand() if an item is numeric on one side and alpha on the other. So if we go with appending strings we'd also have to append one for actual releases which I think has issues, "1.0-dev", "1.0-pre", "1.0-release" would sort properly... but then explodes horribly when we want to release a 1.0.1. Using "1.0-release-1" would work, but looks icky. So I think basically rpm requires X.Y.Z even/odd scheme in order to distinguish release/dev. Which is annoying. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Am 22.11.2010 07:36, schrieb Martin Dvorak: > Thomas Keller wrote: >> We'll have regular minor releases just like before after 1.0 - we only >> want to assert to support 1.0 with patch releases a little longer than >> the usual minor releases. I remember we talked about some rules on the >> list, but never actually jotted them down. I did that now on the RoadMap >> page [0] - feel free to post corrections and / or updates there. >> >> Thomas. >> >> [0] http://wiki.monotone.ca/RoadMap/ > > Hi, > > I never was fan of the x.99.x/x.9x/etc. version numbering for betas of > new major versions. I've been thinking about stable/development version > numbering recently (and also in the past) and I think it's better to > call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using > the target major version but appending a suffix that marks it's not the > final release. We already append a suffix "dev" to development snapshots (i.e. "1.0dev") which get created on build farms like openSUSE's build service. Thomas Moschny said that this is suboptimal because of rpm's version comparison algorithms which would consider "1.0dev" newer than "1.0", so whatever we come up for the release numbering (which must have widespread support for rpm, dpkg and friends), should be applied in a similar way to this. Personally I don't care much whether we use numbers or appended strings, as long as the algorithms are smart enough to find "1.0-dev" (or whatever) older than "1.0-alpha1" (or whatever). 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
Fwd: Re: [Monotone-devel] Updated Issue 109 - mtn au get_extended_manifest_of Should Default To Current Workspace Like get_manifest_of Does (monotone)
Forwarding this to the list... Original-Nachricht Betreff: Re: [Monotone-devel] Updated Issue 109 - mtn au get_extended_manifest_of Should Default To Current Workspace Like get_manifest_of Does (monotone) Datum: Sun, 21 Nov 2010 13:27:17 -0500 Von: Stephen Leake An: c...@monotone.ca > 109 - mtn au get_extended_manifest_of Should Default To Current > Workspace Like get_manifest_of Does > # By Thomas Keller, Nov 20, 2010: > The result is a compromise - have one (extended) format for committed > changesets and use inventory for uncommitted / workspace changesets. > We can easily add more fields to inventory from the roster if needed > (right now the most prominent "recent" addition was the birth revision > stanza), but I'd do that on individual request. > # By Stephen Leake, Nov 20, 2010: > In general, automate commands don't have default arguments. The design > is that automate commands are used by front-end tools, which can > easily provide all the required parameters. Given the above, I think we can mark this issue "won't fix"? - Lets wait for the feedback from Tony and then act accordingly. "won't fix" sounds reasonable. Thomas. signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Martin Dvorak wrote: > I never was fan of the x.99.x/x.9x/etc. version numbering for betas of > new major versions. I've been thinking about stable/development version > numbering recently (and also in the past) and I think it's better to > call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using > the target major version but appending a suffix that marks it's not the > final release. > > What do you think? Are there any issues with this scheme for users > and/or automatic tools, such as package managers in Linux? Debian supports this using a tilde to separate the "target major version" and the "suffix", e.g. 1.1~alpha5, 1.1~beta3, 2.0~rc2. I don't know about other distros. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
