Re: [Monotone-devel] Botan2 support?
Hi, On 10.08.19 10:58, Thomas Moschny wrote: as Botan 1.10 has gone EOL 2018-12-31 [1], has anybody already looked into porting Monotone to Botan 2.x? I did, a few months ago. I'd have to check how far I got, but it seemed doable. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone fails to build with PCRE 8.42
Hello Petr, On 07.05.2018 14:24, Petr Pisar wrote: > monotone-1.1 fails to build with PCRE 8.42: > By the way, PCRE is obsoleted by PCRE2. thanks a lot for these hints. I'll eventually take a look. A monotone 1.2 release is way overdue. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone has disappeared from testing.
On 04/16/2018 01:02 AM, Hendrik Boom wrote: > Just noticed that monotone is no longer available in Debian testing: Yes, I'm sorry, I'm lagging behind with my Debian duties... Then again, monotone also needs a release, as the latest 1.1 isn't compatible with newer Botan versions available in Debian testing. So it looks like we'll have to bundle 1.2, first. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone on Github?
Hi, On 04/10/2018 09:17 AM, grarpamp wrote: > Not really thinking of non self hosting. > Just a simple commit mirror with project page pointing to > wherever is authoritative, github ticketing need not be enabled. I somewhat recently published an export here: https://github.com/mwanner/monotone Graydon has an older snapshot here: https://github.com/graydon/monotone both have been exported via the git export feature. The problem with that is: incremental updates are not supported. > Mostly to satisfy searches made on github, let people play > readonly with it via local git clones till they get serious and > go mtn, attracting more devs / debugs / users, gain some > global search index rank via github, etc. > The meta benefits of doing so. That's why I tried the export. However, I think all of that requires incremental updates. Otherwise you're annoying your users by having to throw away and re-fetch the entire repository. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz
On 02/28/2018 07:24 PM, Hendrik Boom wrote: > When I use monotone-viz I get the message > Could not parse dot output IIRC I have similar issues with monotone-viz (Debian stable). I'm not aware of any replacements. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to compile against Botan 2.x
On 11/11/2017 11:24 AM, Markus Wanner wrote: > With that last fix all functional tests now pass and nvm.botan is ready > to be merged on mainline. Anybody up for a quick review? I count the lack of objections as a frantic "Hell, yes, go merge!" and did so. The main branch should now compile against all of the Botan 2.x series. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to compile against Botan 2.x
On 11/11/2017 11:24 AM, Markus Wanner wrote: > I corrected the PKCS #5 key writing by specifying "SHA-160" instead of> > "SHA-1" for Botan versions 2.0 and newer. I figured I forgot to actually commit this (had the commit log prepared and everything, but...). Done now: 6e44856c. Kind Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to compile against Botan 2.x
On 11/08/2017 10:39 PM, Markus Wanner wrote: > All of the unit tests now pass with the following Botan versions I'm > currently testing against: 1.8.15, 1.10.17, 2.0.1, 2.1.0, 2.2.0, and > 2.3.0. However, I'm still facing Botan-version dependent failures on > various functional tests. I'll investigate on those, next. I corrected the PKCS #5 key writing by specifying "SHA-160" instead of "SHA-1" for Botan versions 2.0 and newer. With that last fix all functional tests now pass and nvm.botan is ready to be merged on mainline. Anybody up for a quick review? Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to compile against Botan 2.x
Hi, I finally made some progress on the nvm.botan branch. I figured two important things: First, the CRC32 calculation was broken due to comparing it with the entire 8 bytes of the footer (which couldn't ever match). That was easy to fix. Second, our custom gzip filter sets the timestamp in the gzip header to all all zeroes. More importantly, the parser *requires* it to be all zeroes. This does not work with more standard gzip behaviour (like the one implemented with Botan's (De)Compression_Filter that's available since 2.0 and newer). I already made the parser more tolerant (in nvm.botan). However, we cannot simply start writing non-zero timestamps without breaking backwards-compatibility. Therefore, I left the custom gzip code in place and in use, even when compiled against newer Botan versions. It's also worth mentioning that I've already dropped support for Botan 1.6.x and 1.7.x. However, the 1.8.x still works, so I kept it for now. I'm tempted to drop it as soon as it poses problems, though. (I haven't even tested Botan 1.6, so the decision is pretty arbitrary.) All of the unit tests now pass with the following Botan versions I'm currently testing against: 1.8.15, 1.10.17, 2.0.1, 2.1.0, 2.2.0, and 2.3.0. However, I'm still facing Botan-version dependent failures on various functional tests. I'll investigate on those, next. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to compile against Botan 2.x
Jack, On 15.10.2017 20:49, Jack Lloyd wrote: > Ah sorry about that, I will take another look at the patch and see > what happened. it might have been caused by my changes, as I've applied your patch onto some different base revision, IIRC. Anyways, I've now merged our work in net.venge.monotone.botan and at least mtn now compiles (for me, too) against Botan 2.0. Not the test suite, though. And with simply invoking `mtn status`, I already get some CRC-32 error (presumably the gzip stuff, which I'd love to get rid of...). 2751100d is the newest revision. I fear I'll have to defer further work on that branch to next week. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to compile against Botan 2.x
Hello Jack, On 09/26/2017 09:47 PM, Jack Lloyd wrote: > I've attached a patch for building Monotone against Botan 2.x thanks again and sorry for not getting back to you earlier, as promised. I committed your patch to net.venge.monotone.botan and continued from there on. Unfortunately, it didn't quite compile against any newer Botan version, so I continued to work on it. Plus, I too started some Botan 1.11 compatibility efforts back some time.. so now I'm facing two heads on that branch and I'm still in the process of merging those. > This isn't quite complete for 2.2, because a lot of Monotone assumes > Botan::SecureVector is a type, and that botan.h includes more than it > does in 2.0-2.2. I added a new header file (src/botan.hh) to deduplicate some of the conditional imports. > I made a change upstream > https://github.com/randombit/botan/commit/3f7dba2c4455bf53dae89d088bd56cdf9b2c94fe > to make some changes to botan.h to make this patch simpler, and in the > thought it will likely ease transition for other projects. This will > be included in 2.3 which is coming out next week. Cool, thanks. Given this won't appear before 2.3, I think monotone still needs dedicated includes for e.g. botan/filters.h to support 2.0 - 2.2, right? Another unrelated question: You changed a couple of (not necessarily secure) byte vectors to DataSource_Memory. Whereas I figured I might simply use a vector. What's the difference? > Two other relevant pieces of information: > > - All support for Botan 1.10 ends at the end of this year I don't known about other distros, but it's what Debian stable currently ships. And given it's just been released, I fear that statement will hold true for another roughly 2 years. I think it would make sense to require at least 1.10 from now on and drop everything older than that. I'm hesitant dropping 1.10 just yet. What do others think about dropping support for older Botan versions? > - Botan now uses semantic versioning, so all Botan 2.x releases should > be forward compatible. It is anticipated 2.x will be supported until > at least 2021. +1, I welcome that simplification. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone botan-stable AUR
Hi, On 29.01.2017 09:46, CooSoft Support wrote: > Oh it's more serious then. For sometime monotone hasn't work with the > version of Botan that ships with Ubuntu 14.04, I had to regress the > botan version back to get it to work. that surprises me and doesn't quite match the dates I have in mind. Current monotone releases (certainly 1.0 and 1.1) are compatible with botan 1.8 and 1.10. Botan 2.0 was released just a few days ago (Friday, 13th, to be precise) and certainly isn't part of Ubuntu 14.04 (or any Ubuntu or Debian release, yet). If you have a specific issue with monotone 14.04, please file a specific bug report. Otherwise I'd assume monotone to work just fine on Ubunut 14.04. (And yes, I have used monotone on *that* Ubuntu release.) Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone botan-stable AUR
Hi, I don't really know what's going on in Arch, but... On 01/16/2017 12:08 AM, Evgeny Pokhilko wrote: > https://aur.archlinux.org/packages/botan-stable/ .. this one works for me. > https://aur.archlinux.org/packages/monotone This doesn't, but it's not like monotone is anywhere nearly as active as Botan. Notably, it won't compile with the newest Botan version. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] sockets are a showstopper for many commands
On 09.09.2016 17:56, Lapo Luchini wrote: > Works for me. :) > > monotone 1.2dev (base revision: ad1a31e0c32511a094308eb6b9c03089e4b66b83) Thanks for your confirmation. Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] where is the repository for monotone nowadays?
On 28.06.2016 17:22, Hendrik Boom wrote:
> On Tue, Jun 28, 2016 at 05:14:44PM +0200, Markus Wanner wrote:
>> On 06/28/2016 04:55 PM, Hendrik Boom wrote:
>>> I tried to update my repository for monotone that I had downloaded
>>> a few years ago, and it seems not to be able to find the main repository.
>>> Where is inowadays?
>>
>> Hm.. the website seems down. I'll take care soon-ish.
Looks like that was just my mobile internet connection was to blame,
here. At home, things work just fine.
Have a look at the fine manual:
http://wiki.monotone.ca/MonotoneProjectServer/
I usually use something like (which is pretty selective):
mtn pull
"mtn://monotone.ca/monotone?net.venge.monotone{,.*};-net.venge.monotone.{contrib,guitone,viewmtn,web,web.,trac-plugin}*"
Kind Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] where is the repository for monotone nowadays?
On 06/28/2016 04:55 PM, Hendrik Boom wrote: > I tried to update my repository for monotone that I had downloaded > a few years ago, and it seems not to be able to find the main repository. > Where is inowadays? Hm.. the website seems down. I'll take care soon-ish. >From the top of my head: "monotone.ca/monotone?net.venge.monotone" Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz problem
On 06/28/2016 04:53 PM, Hendrik Boom wrote: > Sorry. I wasn't clear. I was referring to the problem with > monotone-viz being unable to parse dot output. Well, for that it would be better to file a bug for that specific project. > Or should I invesigate the problem myself? If so, where do I find the > upstream repository for monotone-viz? Presumably there's a monotone > repository for it somewhere. http://oandrieu.nerim.net/monotone-viz/ and branch net.venge.monotone-viz on code.monotone.ca, i.e. here: https://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone-viz/ Kind Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz problem
On 06/28/2016 03:49 PM, Hendrik Boom wrote: > Should I file an official bug report? Or is my note on the monotone > devel mailing list sufficient? It's sufficient for me to write the package. It helps in the package getting accepted in Debian, if there's a third-party RFP. So, yes, please file the "official" RFP. Thanks. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-viz problem
On 06/26/2016 09:22 PM, Anthony Edward Cooper wrote: > I wrote mtn-browse but haven't got involved in the packaging. There's only so > much free time... Others have fine excellent work on packaging it for redhat, > but that doesn't help you. > > One can easily install mtn-browse under /opt and the installer will highlight > missing dependencies. Mind filing a RFP (request for packaging)? I already maintain monotone and monotone-viz for Debian. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Fwd: node blocked by blocked parent
On 06/01/2016 06:46 PM, J Decker wrote: > I have a repository that is tracked in git and in monotone. I was > updating monotone and added two trees; three.js(187 files) and some > data in src/voxels/VOxelInfo_[1-250].txt (okay it's only 437 some > files not thousands) > > all the conflicts are exactly the same; directories are directories, > files are files, and the content of files is the same. Well, monotone tracks files and directories. Two directories added on two different revisions (possibly even by two different persons) are two different directories. If the two happen to claim the same name, that's a conflict, in monotone. As I said before, there's no good solution to support "stitching". That's something that seems to work just fine for other VCSes (which do not track files and directories directly). I'm still convinced that monotone's approach has its benefits and it would be worth implementing proper stitching, but... as a matter of fact nobody implemented it so far. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] node blocked by blocked parent
On 06/01/2016 02:45 AM, J Decker wrote: > mtn.EXE: warning: attach node 2147484550 blocked by blocked parent > 'Voxelarium.2/src/voxels' > mtn.EXE: warning: attach node 2147484551 blocked by blocked parent > 'Voxelarium.2/src/voxels' > mtn.EXE: warning: attach node 2147484552 blocked by blocked parent > 'Voxelarium.2/src/voxels' Well, what's blocking the parent? These are just subsequent errors (which the UI could and probably should better collect and combine into one, but...) > why not an option 'merge into existing' or 'do nothing if already the same' We had discussions about merging nodes or "stitching". But merge semantics for things like that are far from trivial... I agree this is not an optimal solution. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] replace netxx with asio
Hi, in the last couple of days I finally managed to get nvm.asio to a state that doesn't just compile, but pass most tests. Yay! There still are a couple lose ends (see NEWS, where I maintain a temporary todo list for that branch). I'd appreciate feedback as well as help with testing. If someone could take care of the Windows side of things, I'd certainly appreciate that... To reiterate the reasons for this move: netxx is unmaintained; up until now, we even had a full copy in our sources, which in itself is bad enough from a maintenance and security perspective. Furthermore, I think netxx started to show its age. I don't quite recall what exact issues I had with it, though. (A variant of) ASIO is part of boost and it currently is a viable candidate for inclusion in a future C++ standard (N4588, [1]). Packages for Debian [0] and RedHat exist. And in the non-boost variant, it's a headers-only library, so it's trivial to "install" as well. I'd appreciate your feedback and comments. Regards Markus Wanner [0]: To be fair, I should probably mention that I myself am the maintainer of the asio standalone package for Debain, see: https://tracker.debian.org/pkg/asio [1]: N4588, Working Draft, C ++ extensions for Networking: www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4588.pdf signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mtn-Browse Version 1.20 And AutomateStdio 1.10
On 05/10/2016 11:47 AM, Anthony Edward Cooper wrote: > Are I'd assumed that since historically the versions were to 2 > decimal places There was a 0.9 before 0.10 in 2004, and most numbers following just happen to have decimal places... ;-) > The changes for AutomateStdio centred around erase_descendants() and > the extra rev arg to get_attributes(). Mtn-Browse's changes were simply > the inclusion of the min() and not() selector functions. The main work > in mtn-browse was fixing breakage introduced by Ubuntu/later Linux > versions etc. I'll have to give it a spin on the latest Ubuntu LTS that > has just come out (tested on 14.04 KDE 4.x and Unity as well as Debian 6 > and RHEL 4). Okay, thanks for elaborating. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mtn-Browse Version 1.20 And AutomateStdio 1.10
On 05/08/2016 01:57 PM, Anthony Edward Cooper wrote: > Just a quick announcement to say that new versions of mtn-browse and > AutomateStdio have been released. Cool, thanks for the heads up. > The latter now provides support for > Monotone version 1.10 I think you rather mean version 1.1. Out of interest: what changes were necessary to support 1.1 (versus 1.0)? Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
On 04/08/2016 06:34 AM, J Decker wrote:
> 1) Hashes... once they're serliazed, can't 90% of the time they just
> be compared as strings? (The output of which fits in utf-8 as ascii
> subset esp if you're using 58)
Monotone did that, but migrated to using binary representation for
efficiency. Note that we do hash calculations quite frequently, so we
need to serialize pretty frequently, too.
I rather think we need to migrate to binary all the way and encode the
hash just before displaying it to the user. That doesn't need to scale,
because the user hardly wants to see millions of hashes at once.
> 2) hashes fed through as utf-8 codpoints (because any value from
> 0-4,000,000 is encodable in a general algorithm, regardless of
> arbitrary restrictions) would yes more often be outside of the 94
> characters, and be encoded characters... but since the output is just
> characters anyway...
So you could come up with some kind of base400 encoding, where every
code point would cost 1-4 bytes in utf-8 encoding, i.e. we're speaking
about encoding twice. And loose all of the benefits of using a subset of
ASCII I don't see the point.
> Yuck, YAML has keywords?
>
> {"cert":"1249123840182028934801az","Idunno":"blah"}
Something like that may be a canonical format, but without any newline,
I don't consider it human readable. I'd rather use something like:
{
cert: "1249123840182028934801az"
Idunno: "blah"
}
> and that itself is in utf-8... which emans any value is storable in a
> rune (to borrow a type name from Go)
Well, yes, we're already using utf-8 for commit messages and such. So
any human-readable, textual format is very likely using Unicode and be
encoded as UTF-8.
Regards
Markus Wanner
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
On 04/07/2016 11:37 PM, Stephen Leake wrote: > There's a version number in the internal format, so we don't need a flag > day (or maybe that was on a branch; anyway, we can add one). We do need > to maintain both formats for compatibility with old databases. There's a version identifier for things like certs, revs, etc.., yes. However, in any case, there's a point in time where monotone stops using the old format and starts to use the new one. We can soften the migration by prolonging the time between the first release that supports a feature until we activate it. (Not that past flag days had a pretty narrow window...) I even thought about a mtn:features attribute (on the root node), allowing users to switch on features per branch, as they see fit. For example, I still want atomic certs. That feature will require at least a new version, if not a new format, for certificates. Certainly something that monotone-1.1 doesn't understand. So 1.2 might still need to write the old format/version, at least by default. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
On 04/06/2016 02:56 PM, Hendrik Boom wrote: > And if you want it to be human-readable you'd also want to avoid > visually confusing characters. No using both 0 and O. Or using 1, l, > and I. Even , and . can be hard to distinguish in soe fonts. Exactly. Did I already mention base58... ;-) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
On 04/06/2016 05:44 AM, J Decker wrote: > encode into utf8 codepoints maybe? which would expand 0x80-0xFF by 1 > character each... and you could violate utf rules and encode a F880 > that's a 0 codepoint... You mean for hashes? Hm.. that's an interesting idea, which might get us a whole new encoding. However, I don't quite think we can use Unicode there, but should really stick to ASCII. Even base64 is a bad idea, because it contains '/' and '+' chars, which are usually treated as separators. But you don't want revision ids to word-wrap. With these restrictions, base58 is about as space efficient as you can get. Kind Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
On 04/06/2016 05:26 AM, J Decker wrote: > If the structures might mutate with time something like json is pretty brief. > if you have high reliability, sqlite for instance will store a blob > with only \0 for the 0 and \\ for \ ... JSON doesn't handle binary welll, it's a text format. Usually, base64 is used for binary data inside JSON - which is neither human readable nor space efficient. > which results in a copy or shift of data but only a simple comparison > if '\\' kinda like base 254 sorta :) > depending on what character happens least you could replace for > or something ... That's nonsense, according to http://stackoverflow.com/a/1443240, the JSON spec supports only 94 Unicode characters that can be represented as one byte (in UTF-8). Nor is there any canonical *and* human readable variant. If human readable, I'd currently prefer to try something canonical that's still valid YAML. Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
thin the top 25 as well). The CPU time that's used for the actual hex encoding and decoding is vanishingly small, below 0.1%. Now, I'm clearly not into micro optimizations (but rather consider modifications like using base58 instead of the hex encoding for hashes presented to the user - an encoding that's certain to consume more CPU time, not sure how much more, though.) However, reducing the amount of data to be hashed, cached and moved around (in memory, network, etc..) sounds like a generally good idea to me (performance wise). However, it's equally clearly a bad idea from a usability perspective. So there's a balance. That's why I started this thread. Given the arguments so far I tend towards a binary encoding, as I think developers should be able to handle binary data. And if users really don't care... Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serialization format
Hello Stephen, thanks for your feedback. On 04/04/2016 06:58 PM, Stephen Leake wrote: > Human readable makes testing and developing new features much easier. If > we use binary, we will need a separate tool that translates that to > readable, which is then another source of bugs (or the same source, just > in a different place). Yeah, that's a point. However, I'd also argue that we should target the user and not the developer. And from a user's perspective, isn't monotone the very tool that does that kind of translation? Or put another way: Do *users* really care what serialization format monotone uses underneath? Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] serialization format
Hi, I'd like to get some feedback regarding some ideas around the serialization format used for storage and exchange of data in monotone. Currently, we're mostly using basic_io (for revisions, manifests, certs, AFAIK even for automate). Three things are bug me about basic_io: * while well readable, it's a custom format, not used anywhere else * it's flat and cannot represent nested structures * it cannot handle binary data (therefore monotone is spending quite a bit of time converting between hex and raw data (mostly revision ids)) There are plenty of alternatives when considering a binary format: good old ASN.1, Google Protocol Buffers, MessagePack, Blink, etc... Human readable alternatives (which would at least eliminate the first two concerns) might be: JSON, YAML, or (bear with me) even XML. But for hashes and such we need a canonical format. And nothing for those three remains readable in any of their canonical forms that I've seen so far. At the moment, the most important question seems to be: how much do you value the human readable representation? How about a binary format that you can easily transform to and from a human readable one? I appreciate your feedback. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] deferred merge
On 03/26/2016 04:46 AM, Hendrik Boom wrote: > Is there some easy oe-time way of asking a merge to be deferred, Not really, no. Like a commit, this is an atomic operation: either the resulting revision has one (commit) or two (merge) parents. So you can only defer the merge completely. That works pretty well and may be reasonable. For long lived diverges, I usually give one of the branches a specific name. > so > that the "merged" file has both versions in it, complete with > '<<<<<<<<' and ">>>>>>>" and ssuch to mark the conflicts? Well, you can always commit the file including these markers. However, they have no special meaning for monotone and things might get messy with further merges on that same file. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] sockets are a showstopper for many commands
On 03/24/2016 03:51 PM, Lapo Luchini wrote: > mtn: error: '.gnupg/S.gpg-agent' is neither a file nor a directory Yeah, that sucks... Therefore, I just thought monotone to cope with special files in working directories, please give the recent rev a35938 a spin. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] build failure
On 03/03/2016 03:37 AM, J Decker wrote: > Arch Linux has no package for monotone. > it installs a Botan-1.11(?) as 'Botan' You reported this before and were told that Botan 1.11 is a development branch. Please compile Monotone against 1.10, instead. (Or 1.6 or 1.8, if you insist.) Plus: archaurwiki even reported he created a botan-stable and a matching monotone package for arch. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] javascript monotone
Hi, On 03/01/2016 10:16 AM, J Decker wrote: > This is meant for the architect of the innermost guts of monotone... > strip away a database, strip away a file system, and just track > revisions. track merging of chains Huh? What for? And what's your persistence layer, if you strip those? > I read somewhere that in the distribution of monotone revision chunks > that there are conglomerated chunks of revision that get sent and can > later be referenced with a key(?) A revision id. > Maybe that's where the failure is... > Sorry I've been imagining monotone doing a different job than source > control, like ledger transactions for bank accounts. And to share > those. The chains of transactions are verifiable, and I guess that's > what bitcoin is kinda built on. Yeah, Monotone and Bitcoin certainly share the concept of a monotonically growing tree. However, Bitcoin doesn't have any kind of merge functionality and Monotone doesn't need Prove of Work... > I'd like a system for sharing ID's between nodes in a cluster > where IDs are added, sometimes transfer, sometimes don't, those > clusters exist as a memory idea somewhere in monotone at some point? > Even if for optimization it is cursor driven so you can only see a > portion of it at a time. Cassandra? Tahoe-LAFS? There are many projects with somewhat similar use cases. I didn't fully (nor partially) understand your use case. > and something entirely without boost. Implementation detail. > Can that be written and shared as a NPM module for node? :) I hear > that v8 does extra clever things that allow it to more deeply optimize > than a static compile does... it could; but it doesn't. Hearsay. And implementation detail. (I personally find it hard to believe that JIT can generally be faster than ahead of time compilation, but...) > I'd like a VFS interface (virtual file system) interface to monotone > so I can load a place to store the database? I thought about that as well. Just out of curiosity: Why would you want that? And what's the important difference to an ordinary checkout (maybe to a tmpfs)? > I dunno maybe it's not so hard? Given I don't even partly grasp what you're trying to accomplish, it's hard to say... Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone's usage of SHA1
Hi, On 02/09/2016 09:45 PM, grarpamp wrote: > Subscription to the archives is required as said, and is also > documented on the list page. It's free, no human is involved. > Bug them on policy, not me. The context for this thread begins > there and would be of interest to those with interest. > > https://lists.sonic.net/mailman/listinfo/crypto-practicum Okay, thanks, I've read through the archives, now. One thing I'm curious about is the proposal to use Argon2 (a password hash) over SHA3 or Blake2b for user facing hashes (or portions thereof). Do I understand correctly that this "only" makes it (proportionally) harder for Mallory to come up with a collision on the first few bytes of the resulting hash? Or put another way: Is there any point in using Argon2 (compared to Keccak or Blake2), if the full hash is used? Monotone is pretty rigorous in checking its data's hashes. For example, it checks not just after receiving from another node, but even after loading a revision from disk. Therefore, I'd be pretty hesitant to impose that additional computational cost for the normal user. I rather thought about using a more compact encoding, like base58 as used by Bitcoin. That way you'd get 45% more information into those 5-7 chars that humans can comfortably pass around (compared to hex), resulting in 29 - 40 bits of hash. I'm not saying that's enough, either. But in the case of monotone, I'm less concerned, because there we have integrated certs, which check against the full hash. And just to identify a revision out of the set of already validated revisions, 5-7 chars usually are enough. (Sounds suspiciously similar to Linus' argument, except that certs are external to git, AFAIUI.) Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Git's usage of SHA1
Hi, On 02/08/2016 07:52 PM, grarpamp wrote: > A long thread on the below list with the above subject (that SHA1 > is more or less broken and should be proactively replaced along > the lines of other general global movements off of SHA1) mentioned > the snippet below. The same subject should be given consideration > in monotone as well. I agree and have thought about teaching monotone to use other hash functions. There's no need to rush, though. I'd rather like to think this through well. OTOH at the current rate of development, we better hurry up a bit. ;-) > https://lists.sonic.net/mailman/private/crypto-practicum/2016q1/thread.html No access. > Also, historically speaking git's usage of SHA1 almost certainly came > from monotone (monotone.ca), which Linus used as inspiration for git. Yes. > They still use SHA1, but it sounds like it would be much easier to > replace there than in git. I cannot speak for git, but I've already tried in monotone and it's not trivial, either. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813157 Sounds like an entirely different issue. Monotone took the conservative approach, here, and has always checked everything it receives via the network. > https://git.wiki.kernel.org/index.php/LinusTalk200705Transcript Here, Linus' argument is that git only uses SHA-1 as a consistency check, not for security. (I haven't checked how git's OpenPGP integration works.) That's certainly not the case for monotone, where certs reference the revision id (a sha-1 hash). > https://github.com/jayphelps/git-blame-someone-else WTF is that? You're not trying to blame monotone for git's usage of SHA-1, are you? Kind Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] AS400
On 10/09/2015 11:36 AM, Hugo Cornelis wrote: > Hi, is there anyone on this list who has experience using monotone on > the AS400? Not that I've heard of, before. Does it compile? Pass tests? Could you possibly provide a buildbot slave? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn support for password-store
On 10/07/2015 09:58 AM, Lapo Luchini wrote: > JTLUK I'm preparing mtn support for password-store Cool! Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Boton 1.11 failure
Hi, monotone isn't compatible with development branches of botan (i.e. x.y for odd values of y). Please compile against 1.10, instead. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] monotone.ca is down
Lapo, it looks like monotone.ca is unreachable. Could you please revive it? Thanks. Regards Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone.ca is down
Lapo, thanks for your quick response. On 07/07/2015 11:08 PM, Lapo Luchini wrote: Uh... works for me. Can you confirm? (I did nothing yet, I'm just back from my dinner with friends) I used this service to verify: http://downforeveryoneorjustme.com/monotone.ca Now it also says it's just me. It still doesn't quite work for me, for some reason. I get Waiting for monotone.ca for ca. 30 seconds. Then the page loads fine. ?!? Maybe this is related to IPv6. I can successfully ping 144.76.185.163 (v4) as well as 2a01:4f8:200:63a2::8 (v6), FWIW. Uh… this tool tells me the authoritative DNS are mostly not anwesring: http://www.squish.net/dnscheck/ 18.7% Answered from ns3.zonomi.com http://ns3.zonomi.com (128.199.213.165) www.monotone.ca http://www.monotone.ca. 3600IN A 144.76.185.163 IIRC, it always resolved fine from here. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Buildbot-devel] buildbot: correct monotone source step
Pierre, On 04/18/2015 02:17 PM, Pierre Tardy wrote: As an open-source project, buildbot is dependant on its community to make all its features work. As you seem like a monotone expert, we would greatly appreciate if you could contribute a fix to the monotone master side step, that would include making sure the unit tests are correct so that we can maintain the step in a workable state. My spare time is rather limited, but I'll try to help. Here are the guidelines for contributions, which includes creating a Pull-Request on github, so that we can properly review it, and automatically run the unit tests suite on it. https://github.com/buildbot/buildbot/blob/master/CONTRIBUTING.rst I'll have to read through this, as I'm not familiar with github (nor anything specific to the buildbot development process). From quickly glancing over it, two questions arise: * For eight, do I simply file a second pull request on branch 'eight' rather than 'master'? * Is there an easy way to locally run tests? Without having to install and setup a full buildbot master? I'd appreciate some help to get started. Regards Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] buildbot: correct monotone source step
Hi,
on buildbot.monotone.ca, a buildbot master instance is running. As
recently brought up on IRC, I had issues with it since I switched to use
the newer server-side source step.
The attached patch fixes two issues in steps/source/mtn.py:
a) in _sourcedirIsUpdatable, the inline function cont served as a
callback to the deferred returned by _sourcedirIsUpdatable. However,
it uses d.addCallback, where d is what's calling it. I.e. at the
time of execution, d is already called. It seems strange to add
another callback. Further, and probably the actual bug: It doesn't
return a value. I think that's what led to the hang I originally
discovered.
I fixed it rewriting _sourcedirIsUpdatable as an inlined
callback method, which first checks for the existence of both, the
_MTN directory and the database db.mtn, and only decides *after*
both checks. I added proper logging to simplify debugging in the
future.
b) startVC calls _checkDb, which in turn runs 'mtn db info' on the
database db.mtn. However, if the database doesn't exist, yet, that
command fails, writing an error message to stderr (not stdout).
This aborts the entire step, rather than creating and filling the
database.
The fix in the patch is not optimal: I simply set abandonOnFailure
to False. A better solution would be to check for the existence of
the database db.mtn first (that's done in _sourcedirIsUpdatable,
anyways) and only run 'mtn db info' if it is known to exist. (Or
skip the existence test and properly parse stderr. However, that
seems prone to error, IMO.)
The patch as attached applies to buildbot release 0.8.10. I'm happy to
test an improved variant of it, if necessary.
Regards
Markus Wanner
*** a/buildbot/steps/source/mtn.py.orig 2015-04-16 22:27:34.336585869 +0200
--- b/buildbot/steps/source/mtn.py 2015-04-17 14:33:35.539813501 +0200
***
*** 319,325
return d
def _checkDb(self):
! d = self._dovccmd(['mtn', 'db', 'info', '--db', self.database], collectStdout=True)
def checkInfo(stdout):
if stdout.find(does not exist) 0:
--- 319,327
return d
def _checkDb(self):
! d = self._dovccmd(['mtn', 'db', 'info', '--db', self.database],
! collectStdout=True,
! abandonOnFailure=False)
def checkInfo(stdout):
if stdout.find(does not exist) 0:
***
*** 337,352
d.addCallback(checkInfo)
return d
def _sourcedirIsUpdatable(self):
! d = self.pathExists(self.build.path_module.join(self.workdir, '_MTN'))
! def cont(res):
! if res:
! d.addCallback(lambda _: self.pathExists('db.mtn'))
! else:
! return False
! d.addCallback(cont)
! return d
def finish(self, res):
d = defer.succeed(res)
--- 339,358
d.addCallback(checkInfo)
return d
+ @defer.inlineCallbacks
def _sourcedirIsUpdatable(self):
! workdir_path = self.build.path_module.join(self.workdir, '_MTN')
! workdir_exists = yield self.pathExists(workdir_path)
! db_path = self.build.path_module.join(self.workdir, self.database)
! db_exists = yield self.pathExists(db_path)
!
! if not db_exists:
! log.msg(Database does not exist, fallback to a fresh clone)
! if not workdir_exists:
! log.msg(Workdir does not exist, fallback to a fresh clone)
!
! defer.returnValue(db_exists and workdir_exists)
def finish(self, res):
d = defer.succeed(res)
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] colorization
On 04/12/2015 09:15 PM, Timothy Brownawell wrote: Oops, I meant other as in not monotone. With my example being ls (which I have the GNU coreutils version, on current Debian testing). Oh, I see, that makes more sense, now. And yes, I agree, it's a good idea to be consistent with other unix commands like ls, here. If --colorize is given explicitly, I'd think it should colorize regardless of what it thinks the output type is. I see your point. And it seems that would be more consistent with how '--ticker' works as well. I'll change that. Thanks for your input. Changed and committed. Now, on a smart terminal, the following two are equivalent: $ mtn diff $ mtn diff --colorize | less -FRX The same argument could be applied for '--pager', though, where I have a bit of a hard time coming up with a valid use case. Hm... --pager in general is a bit odd really, but maybe I'm just too comfortable with unix pipelines. Well, it IS a unix pipe at work, there. ;-) Admittedly, that feature is inspired by git. The first time git offered me a pager, I was surprised. By now, I'm so used to it that appending | less to many of the mtn commands started to itch. I scratched. --pager means, send the output thru this other program instead of to normal STDOUT. Which does not make sense if STDOUT is being captured, which can be approximated by STDOUT not being a smart terminal. Correct. It also doesn't make much sense to give --pager explicitly, Exactly. since piping to your paging program does the same thing and is more consistent with the rest of the world. Unless you're on Windows I guess? I'm not. Nor does this feature work on Windows, sorry. (Neither colorization nor piping to a pager, to be specific.) That's a use case. Have --pager be a GUI program (notepad, whatever), which doesn't output thru your terminal. In which case you probably want it *especially* if your terminal isn't smart. Such a program would need to be able to read from stdin, but not write to stdout. AFAIUI emacsclient, for example, cannot do that. Are you aware of any such program? In any case, I also changed --pager to always, unconditionally pipe through a pager program. (More importantly, I should now make that pager program configurable.) Regards Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] colorization
Timothy, thanks for testing. On 04/12/2015 06:07 PM, Timothy Brownawell wrote: Nothing in the diff jumps out at me as an issue. $ mtn log --colorize | less No escape codes (good), but also no colors even tho I specifically asked for them. If you pipe to less, mtn isn't writing to a smart terminal, anymore. That currently disables colorization independent of the option, yes. Other colorized commands will output the colorization codes if specifically asked, even to pipes. That in turn surprises me. $ mtn diff --colorize | cat gives monochrome output for me. What specific command and OS do you use? If --colorize is given explicitly, I'd think it should colorize regardless of what it thinks the output type is. I see your point. And it seems that would be more consistent with how '--ticker' works as well. I'll change that. Thanks for your input. The same argument could be applied for '--pager', though, where I have a bit of a hard time coming up with a valid use case. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] colorization
Hi, On 03/30/2015 08:48 PM, Markus Wanner wrote: To argue a bit more objectively: I tried to make the default colors readable on black as well as white background. And I reduced noise a bit by un-coloring a couple of things. Colorization can be adjusted via a lua hook. I just landed this branch on nvm. Together with some support for a pager. Currently still hard-coded to 'less', but I intend to make this configurable via lua. I'd opt for enabling colorization by default. Especially as this feature gets automatically disabled for non-smart terminals. Both - colorization and paging - is now enabled by default for smart terminals (for Linux/Unix systems, that is). I'd appreciate some feedback. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] improving `mtn status`
On 10/18/2014 10:40 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: it's been a while since the C++11 refactoring, but as promised, here's some actually useful work: I scratched a couple of itches I had with recent monotone's status command and started a branch trying to improve it: net.venge.monotone.revamp-status. I landed this on nvm .. uhm .. several moons ago. So as long as you don't change 'mtn auto inventory', this does not affect me. No changes (intended) for auto inventory. One goal might be to make it closer to 'git status', and or 'hg status', so people migrating to/from those are comfortable. I know git a bit, but didn't really try to mimic it. I don't use mercurial. Another naughty example - which I consider a bug - is `mtn status` on a working tree that misses files known to the parent revision (or has mismatches in type - i.e. file vs directory). For example: mtn: warning: missing file 'm4/stlporthashmap.m4' mtn: warning: not a file 'Attic/m4' mtn: warning: expected file 'Attic/m4', but it is a directory. mtn: warning: missing file 'm4/tr1unorderedmap.m4' mtn: misuse: 3 missing items; use 'mtn ls missing' to view. mtn: misuse: To restore consistency, on each missing item run either mtn: misuse: 'mtn drop ITEM' to remove it permanently, or mtn: misuse: 'mtn revert ITEM' to restore it. mtn: misuse: To handle all at once, simply use mtn: misuse: 'mtn drop --missing' or mtn: misuse: 'mtn revert --missing' Even though some files are missing, mtn should still be able to give me more elaborate status information - rather than forcing the user to fix these issues, first. +1 This happens on 'mtn update' as well; Yes. Unlike status, update is a potentially destructive command. IMO the best we can do in that case in listing *all* causes that prevent an update (rather than just the first error). that annoys me, since 'update' is very similar to 'revert'! Perhaps we need an 'update --revert', meaning revert as needed, then update. I don't see much benefit over just 'revert then update'. I certainly wouldn't remember the special argument. :-) Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] colorization
Hi, I picked up the branch net.venge.monotone.colored-diff, brought it up to speed (including the newish status output) and adapted the colorization a bit to .. well .. my taste, I guess. To argue a bit more objectively: I tried to make the default colors readable on black as well as white background. And I reduced noise a bit by un-coloring a couple of things. Colorization can be adjusted via a lua hook. I'd opt for enabling colorization by default. Especially as this feature gets automatically disabled for non-smart terminals. Any objections? Any specific wishes on how to paint this bike shed? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] improving `mtn status`
Hi, it's been a while since the C++11 refactoring, but as promised, here's some actually useful work: I scratched a couple of itches I had with recent monotone's status command and started a branch trying to improve it: net.venge.monotone.revamp-status. I'm using a mtn from that branch for a while now and am pretty content with that new status output. Please give it a try as well; I'd appreciate feedback. In the following, I'm trying to cover the important changes and the reasoning behind. The fundamental conceptual mismatch is that the current `mtn status` basically answers the question: what would happen, if I tried to commit this, now? Where as I expect it to provide more general information about the status of my working tree. Oftentimes without any intention of committing. The current `mtn status` created a hypothetical revision and prints the resulting rev id. Often enough, I created copy-pasta from that and was left wondering why the rev didn't exist. I didn't *ever* need to know what revid a commit *would* create. Therefore, I consider that information not just useless, but harmful. Another message that constantly annoyed me is: THIS REVISION WILL CREATE DIVERGENCE. Firstly, I perceive it as impolite yelling. And second, a lot of the time that message is flat out wrong. Some common scenarios: * if you're just inspecting an old revision, it always appears. Even though you have no intention of ever committing on top of that rev. * it even appears if there's no single file changed and it's impossible to commit such a revision. * the message appears in a freshly setup workspace. While technically correct (there usually are other descendents from the null rev), it clearly is the users intention to start a new project. Bottom line: It usually makes me want to yell back: NO! THERE IS NO SUCH REVISION AND IT WON'T EVER CREATE DIVERGENCE. However, there's potentially useful information that can be gathered from that line: It is telling that there is at least one newer revision and you might want to `mtn up`. The proposed `mtn status` tells you just that (and even gives a rough estimate on how many revs you can advance). I consider that more to the point and much less offensive. Another point: the user might intend to create divergence - no reason for such a bold warning. That's all fine and monotone is well designed to deal with divergence. Some similar points can be made about the message: THIS REVISION WILL CREATE A NEW BRANCH: There simply is no such revision, yet. (Again, it might not even be possible to create it.) But it's usually more correct in that it simply outlines the current user's intention. I personally still prefer an informative style, rather than having that info yelled back at me. Interestingly, it hides the DIVERGENCE message. Granted, given the user wants to create a new branch, he kind of intends to diverge. However, the information that the parent revision could be upgraded (along the old branch) may still be useful. Maybe the users wants to `mtn up` again, before branching? So far, `mtn status` only ever listed one branch. However, if the parent revision is in multiple branches, I consider that useful status information. Clearly, the current branch - where a commit would go to - still needs to be shown. The proposed new `mtn status` tries to do that. Another naughty example - which I consider a bug - is `mtn status` on a working tree that misses files known to the parent revision (or has mismatches in type - i.e. file vs directory). For example: mtn: warning: missing file 'm4/stlporthashmap.m4' mtn: warning: not a file 'Attic/m4' mtn: warning: expected file 'Attic/m4', but it is a directory. mtn: warning: missing file 'm4/tr1unorderedmap.m4' mtn: misuse: 3 missing items; use 'mtn ls missing' to view. mtn: misuse: To restore consistency, on each missing item run either mtn: misuse: 'mtn drop ITEM' to remove it permanently, or mtn: misuse: 'mtn revert ITEM' to restore it. mtn: misuse: To handle all at once, simply use mtn: misuse: 'mtn drop --missing' or mtn: misuse: 'mtn revert --missing' Even though some files are missing, mtn should still be able to give me more elaborate status information - rather than forcing the user to fix these issues, first. The nvm.revamp-status branch addresses these issues. It doesn't quite pass all tests, yet. And there still are minor issues and other UI issues that I'd like to address, eventually. However, I think it's a good point in time to ask for feedback, so please have a look and provide feedback regarding `mtn status`. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-users] botan
On 07/25/2014 10:21 PM, Stephen Leake wrote: mtn must use the shared library it was compiled for, or a strictly upward-compatible one. I don't know if Botan is in general upward-compatible, but I wouldn't bet on it. Botan promises API stability within the same minor version, i.e. between 1.8.x and 1.8.y for all x and y applicable. (So far with only one exception that I consider an unintended glitch). So those should be backwards and forwards compatible. Note that odd minor versions are testing or experimental releases, which don't provide that guarantee (i.e. 1.9.x or 1.11.x). You shouldn't compile monotone against one of those (unless you know what you're doing). Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fixing old commit messages
On 06/14/2014 06:32 PM, Hendrik Boom wrote: When I commit a revision, I get to write a message explaining what this revision does. But sometines I look at the old commit messages and cringe. I have troubleetyping correctly, and there are often typos and worse. Is there any way to edit an old commit message? What I sometimes do is commit to a private feature branch, where I don't have to worry much about the commit message. Then merge the branch with mtn pluck, thinking harder about the message after the entire feature is done (testing takes a while; usually I end up having multiple commits in the branch or even merges from the parent branch) and then suspending that feature branch. Of course, you need to plan ahead for that to work. And technically it's not really editing the commit message, but rather adding an intermediate step. But one that doesn't need to be visible to others. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] fixing old commit messages
On 06/17/2014 06:18 PM, J Decker wrote: isn't it just as simple as adding a comment? Well, that adds a comment. That's a) not the same as a changelog cert and b) doesn't delete the existing changelog cert. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] minimum requirements
Hi, On 05/16/2014 07:12 PM, Markus Wanner wrote: On my wishlist (for minimum requirements): * Mac OS X 10.8 (Mountain Lion) / XCode 5 I successfully compiled and run tests of nvm.mandatory-cxx11 on Mountain Lion, now. As it turned out, the major stumbling block was that Apple (and therefore MacPorts) defaults to use libstdc++ on that OS version, in a version that doesn't offer proper C++11 support. Switching to libc++ (-stdlib=libc++) enables C++11 features. However, as those two are incompatible, this also means you to link against botan and idna libraries using that standard library. Therefore, I had to recompile them against libc++, rather than using the packages provided by MacPorts. Given that OS version reached EOL, already, I don't think that's a hindrance for switching to C++11. * FreeBSD 10 * NetBSD 6.1 * Gentoo Hardened * Solaris 10 As per the build farm, these platforms now compile nvm.mandatory-cxx11 just fine: CentOS 6.5 (using g++ 4.8.2 from devtools-2 package) Cygwin Debian sid Gentoo Hardened MinGW / Msys 1.0 NetBSD 6.1 (using gcc48) OmniOS r151008 (pretending to be SunOS 5.11) Ubuntu precise Manual testing additionally yields good results on: Debian stable FreeBSD 10 Mac OS X 10.8 (Mountain Lion) I just updated NEWS and INSTALL on nvm.mandatory-cxx11 to document the new requirements. And I added installation instructions, please review. Some comments regarding the few test failures: - cow, an Ubuntu 10.04 LTS (precise) box shows a failure on log_dir. That's the same test that fails on GNU Debian/hurd for the 1.0 release. Therefore, I don't think that's related to C++11. - on boar, a Windows Server using MinGW / Msys 1.0 system, all extra tests fail. AFAICT these didn't ever work. (Looks rather like a lua issue.) - armadillo, the CentOS 6.5 box once failed on add,remove,cleanup_registered_workspaces, then passed. Looks like an intermittent issue, so it's hardly related to C++11, either. - wallaby runs Debian/sid using a bleeding-edge llvm/clang toolchain, which seems currently broken. My guess is that the standard library headers provided by the new gcc version (4.9.0) caused that breakage. In any case, I'm not too concerned about failures on that build animal in general. I'm currently providing quite a few build animals to hit my targets and to make my wishes come true. If you want to keep a platform supported, please consider contributing a buildbot or at least run occasional tests on that platform. Given the above successes, the lack of offers to help with other platforms and baring further objections, I plan to land nvm.mandatory-cxx11 within the next few days. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mandatory-cxx11 on Cygwin doesn't have to_string
On 05/20/2014 05:42 PM, Markus Wanner wrote: Yeah, I noticed these as well. Build animal porcupine (build 29) shows pretty much that same error. So does the alpaca (a NetBSD 6.1 box, see its build 25). FWIW, that was with gcc-4.5. The build animal is now using gcc48 from pkgsrc, which still shows that issue, but compiles the current head of nvm.mandatory-cxx11 just fine (i.e. after the revert). (gcc-4.5 run into other issues, so that version is not sufficient on NetBSD.) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mandatory-cxx11 on Cygwin doesn't have to_string
On 05/20/2014 01:15 AM, Stephen Leake wrote: Cygwin does not provide to_string in the string header: ../mandatory-cxx11/src/sanity.cc:38:12: error: ‘std::to_string’ has not been declared Yeah, I noticed these as well. Build animal porcupine (build 29) shows pretty much that same error. So does the alpaca (a NetBSD 6.1 box, see its build 25). (even after adding #include string) Note that base.hh already includes string, so that's unlikely to make a difference. searching for to_string in /usr/include turns up boost references only. On Cygwin, the stdc++ headers live under /usr/lib/gcc/. Any clues? The root cause seems to be that C99 has been disabled for the c++ standard library. See its bits/c++config.h: /* Define if C99 functions or macros from wchar.h, math.h, complex.h, stdio.h, and stdlib.h can be used or exposed. */ /* #undef _GLIBCXX_USE_C99 */ I'm not sure what lead to that decision. I tried to upgrade g++ and the libstdc++ to 4.9.0-1 on cygwin, but that fails even more substantially (and still doesn't define _GLIBCXX_USE_C99 it c++config.h). Bottom line: It looks like we're stuck with boost::lexical_cast for now. Therefore, I reverted the corresponding changes in nvm.mandatory-cxx11. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/19/2014 12:51 AM, Stephen Leake wrote: done, tested, pushed. Thanks. I back-patched that to nvm, as I think it's useful there as well. IMO boost::shared_ptrvoid is equally bogus - even if the compiler doesn't seem to complain in that case. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] minimum requirements
On 05/16/2014 07:12 PM, Markus Wanner wrote: Stephen wants these (and supports them by occasional manual testing): * RHEL 6 Minor update on the RHEL front: build animal armadillo (effectively running CentOS 6.5) now uses a g++ 4.8.2 from the devtools-2 package. With that, it now fails to compile nvm, because with the new compiler, C++11 gets enabled. But the old boost headers on that platform do not seem to cope well with C++11. So using C++11 with old-ish boost (armadillo uses boost 1.41) doesn't work. Note that the branch nvm.mandatory-cxx11 works just fine (as it doesn't use much of boost, anymore). So does disabling C++11 on nvm. To me, that's yet another argument to mandate C++11: Otherwise, we couldn't just turn it on if the compiler is capable enough, but would have to check if boost is recent enough, as well. Or keep it turned off entirely and stick with C++98. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/18/2014 10:02 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: We can put such things in src/base.hh or add to CXXFLAGS via the configure script. I personally prefer the former, but we need to consider that it has no effect on the embedded netxx sources. netxx/* apparently doesn't include base.hh; undefining __STRICT_ANSI__ is also required in nextxx/datagram.cxx. Happened as well: ffec710d4a1399a13c04866a42511ba79c86c665 So now Cygwin compiles nvm. Tests running ... If you invoked with 'make check', expect validate_changes_hook to fail. Running via run_func_tests works just fine. I suspect a PATH issue. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] asio to replace netxx [was: C++11]
On 05/18/2014 10:02 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: (Actually an argument to get rid of those...) Is that what the nvm.asio branch is for? Yes. Back then, Zack started with that branch, but discontinued after adding an m4 macro to detect asio [0]. AFAICT NetXX has been discontinued since at least 2008. That's when we first started to think about a replacement. asio still looks like the best candidate to me, so I've gone forward and tried to implement netsync with asio. I'm not quite content with the quality of that code, so I haven't pushed anything, yet. But I already got basic netsync functionality working (including via unix pipes). Two things to consider: I'm proposing to use the non-Boost variant of asio (as has been discussed, before), so we don't drag in another boost dependency. Second: It's a headers-only library. Available on most Linux and BSD distributions, and easily copied when not packaged. Regards Markus Wanner [0]: asio - a cross-platform C++ library for network [..] programming http://think-async.com/ signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/17/2014 04:48 PM, Stephen Leake wrote: I meant we need to enforce using only standard C++ 2011 constructs, and not allow Gnu extensions, since the Gnu extensions are not likely to be supported by clang and MSVC. Agreed. FWIW, clang tries hard to be compatible to gcc and supports -std=gnu++11, though. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/17/2014 05:08 PM, Stephen Leake wrote: LeJacq, Jean Pierre jeanpierre.lej...@quoininc.com writes: Setting the language level to -std='c++11' enables strict ISO C++ library support Hm.. sure? Other than Cygwin, I saw no platform failing. I think __STRICT_ANSI__ is not defined on anything but Cygwin. I don't think we ever enforced strict ansi compliance, before. So I just tried to make Cygwin consistent with the other platforms by undefining __STRICT_ANSI__. -D'_POSIX_SOURCE=1' -D'_POSIX_C_SOURCE=200809L' -D'_XOPEN_SOURCE=700' -D'_XOPEN_SOURCE_EXTENDED=1' Cygwin still didn't compile. Neither with _POSIX_C_SOURCE=200809L nor _XOPEN_SOURCE=700. But requires undefining __STRICT_ANSI__ to actually define fdopen (see its stdio.h header file). (Even though we don't pass the -ansi argument.) GNU extensions can then be enabled using: -D'_GNU_SOURCE=1' Is there a separate include file for posix? That would be cleaner than messing with these macros. We can put such things in src/base.hh or add to CXXFLAGS via the configure script. I personally prefer the former, but we need to consider that it has no effect on the embedded netxx sources. (Actually an argument to get rid of those...) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mingw 64 bit build
On 05/16/2014 11:34 AM, Stephen Leake wrote: Stephen Leake stephen_le...@stephe-leake.org writes: I'd like to test nvm.msys2-mingw-64 on a 64 bit linux before landing that; I have Redhat 6 64 bit. Done, and passing. Any objections to propagating nvm.msys2-mingw-64 to nvm? No, looks fine from here. Cleared to land. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 12:43 PM, Stephen Leake wrote: Does that g++ version compile plain nvm? That's is using the very same standard library functions from algorithm... But options.hh does not have #include algorithm . Adding that fixes the problem; mtn compiles (tests running ...). Good, that means the compiler and standard libraries are just fine, which I'm glad. Apparently #include algorithm is implied somehow, or included in another include file, in nvm? Maybe C++11 is more restrictive on including header (or allows the library to be written so). Sounds like we want to add that include to nvm as well. If so, it looks like the m4 macro is failing to do its job properly. config.log says it checks 'g++' first (default language version), then 'g++ -std=gnu++11', and that works, so it is used. So yes, this is a bug in the m4 macro. Interesting, I thought I tested that. But you're right, this looks like the macro doesn't do what it's supposed to do. It itself claims: # The first argument, if specified, indicates whether you insist on an # extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g. # -std=c++11). If neither is specified, you get whatever works, with # preference for an extended mode. I left it unspecified, as I'm fine with whatever works (tm). I corrected the order of tests, now. So for gcc, it now yields the c++?? rather than gnu++?? variants. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/12/2014 09:51 PM, Markus Wanner wrote: net.venge.monotone.optional-cxx11: enables C++11 features on compilers supporting it. Doesn't change anything for compilers that do not provide C++11. Given the consensus on enabling C++11 if available, I landed that branch, yesterday. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Rust to the World! [was: C++11]
On 05/16/2014 03:39 PM, Hendrik Boom wrote: And yes, it looks like rust might be tthe right language, too. Are you volunteering to rewrite monotone in rust? ;-) How well does it interface with C++? I think it interfaces with C, but not (directly) with C++. (Rust has an error handling concept very different from C++ exceptions, for example.) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Jack, On 05/14/2014 05:08 PM, Jack Lloyd wrote: I plan to maintain 1.10 at more or less the current level of support (which is essentially: fixing bugs as they are reported but with little to no new development work) for an extended period with 2.0 being a parallel stable track, until at least a majority of distros have switched. That's good to know. Thanks for your continued efforts in providing a decent crypto library. It's worth keeping in mind it may well be another year or more before a new stable tree even happens, there are a lot of open projects I'd like to work on before committing to supporting things for the long haul. Understood, makes sense to me, yes. I think C++11 is somewhat deceptive in that many of the changes seem trivial and 'just' save you some extra typing (auto, range-for, lambdas, and non-static member initializers in particular come to mind in this class) but I've found they can offer a huge advantage in productivity vs C++98. Writing C++11 can often feel more like writing Python or ML than C++98. As a basically solo developer with only intermittent time for side projects anything that enhances my ability to get something done is welcome - I expect monotone is in a somewhat similar situation in that sense. IMO the most generally useful addition to the language is rvalue references; even applications which don't use them directly benefit from its use in the standard library, and where applicable they can definitely help performance. As Monotone spends a good bit of time moving around memory blos I expect you could see some great wins here. The reduced set of compilers that support C++11 is a mixed bag. It is unfortunate, in terms of reducing portability, but wonderful for setting a much higher bar for compiler quality. Not having to worry about weird bugs in GCC 3.4 or Visual C++ 2008 anymore is nice. One other problem is the tool ecosystem (ffi generators, static analyzers, and so on) has not yet caught up to support C++11, though that's started to get better in the last year or so. Thanks for that first-hand experience. Very much appreciated. I absolutely agree that rvalues and the entire concept of moving (rather than copying) is the most useful new feature. But there's a bit of a learning curve. Once you get the hang of it (and I'm not claiming I'm completely there, yet), you're starting to question how you've ever been able to write C++ without it (I certainly had that feeling, already). The library additions are nice but are probably less essential if you already are relying on boost. As previously botan did not use boost, getting the sudden addition of std::function, a portable threading library, regexes, shared_ptr, and so on was a huge help. Yeah, it's quite an improvement. In the past, there certainly were efforts to get rid of boost. I'm not sure about the exact benefits, as of now, but C++11 would certainly get us a huge step towards that goal. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 03:28 PM, Hendrik Boom wrote: Unfortunately, it looks like squeeze is going to be picked for long-term support. Squeeze currently ships monotone-0.48-3. I don't think this affects build requirements of future releases of monotone. I agree it's an indicator that we better remain netsync compatible back to (at least) 0.48. (Why, why, couldn't they haave picked wheezy for this?) Quoting from your link: Importantly, the success of Squeeze-LTS will be used to judge the viability of LTS support for [wheezy and [jessie]. So there's still hope. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 05:17 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: Interesting, I thought I tested that. But you're right, this looks like the macro doesn't do what it's supposed to do. It itself claims: # The first argument, if specified, indicates whether you insist on an # extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g. # -std=c++11). If neither is specified, you get whatever works, with # preference for an extended mode. I left it unspecified, as I'm fine with whatever works (tm). I corrected the order of tests, now. So for gcc, it now yields the c++?? rather than gnu++?? variants. But it says with preference for an extended mode., which means it should pick gnu++ if both work. Which is what it did. Oh, right, I read that the wrong way around. Thanks for clarifying. Either way, the script now does what we want it to do. I should adjust the comment, though. If we are also supporting clang and MSVC, we need c++11, not gnu++11 (I think). Well, the intent of the script is to *test* what works and what not. (And MSVC needs an entirely different build system.) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] minimum requirements
Hi, after quite some messages about C++11, I feel like I still don't have a better idea of what the set of supported platforms should be. Quite independent of C++11 (especially as builds on and runs on are slightly different capabilities). Please consider that each platform in the set needs somewhat regular care and love - some more, some less, but keeping monotone running properly on any one is an effort. Announcing a platform is no longer supported is almost free. The question is not: What platforms can we evict from that set?, but rather: What platforms can we reasonably keep up with?. (And related: Which ones are you willing to help with?) Stephen wants these (and supports them by occasional manual testing): * RHEL 6 * Windows / Msys 2 * Cygwin Thomas Keller provides: * MacPorts packaging Jeff Rizzo provides: * pkgsrc packaging for NetBSD Lapo provides: * FreeBSD packaging Thomas Moschny (promised to) provide: * Fedora packaging My personal minimum requirements (and packaging contributions): * Debian wheezy (stable) * Ubuntu LTS (precise) On my wishlist (for minimum requirements): * Mac OS X 10.8 (Mountain Lion) / XCode 5 * FreeBSD 10 * NetBSD 6.1 * Gentoo Hardened * Solaris 10 On Hendrik's wishlist: * Debian squeeze (oldstable) * Windows XP I would like to explicitly exclude these: * Debian oldstable (squeeze) * all Ubuntu before precise (i.e. older than the last LTS) I'm currently providing quite a few build animals to hit my targets and to make my wishes come true. If you want to keep a platform supported, please consider contributing a buildbot or at least run occasional tests on that platform. Regards Markus Wanner P.S: in the above list, I counted all those that have packaged release 1.1 or promised to do so, by now. Feel free to correct me if you're somehow supporting that recent release, but are not listed above. signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Stephen, thanks for trying. On 05/16/2014 07:47 PM, Stephen Leake wrote: On msys2: g++ --version g++.exe (Rev2, Built by MSYS2 project) 4.9.0 gcc 4.9.0 is pretty new. I just recently got that via Debian testing and haven't used it much, yet. Apparently 'std::shared_ptrvoid' is illegal, and that is enforced in gcc 4.9.0 Yeah, seems like a weird construct. cow_trie::_data is set by the 'walk' code above; apparently we have two node types. So to use a shared_ptr, we need a union of those types. ..or give the two a common base class? Can we use a unique_ptr here? That doesn't make the void pointer any more type safe. We should get rid of void*, that's supposed to be C++, after all. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 01:54 PM, Markus Wanner wrote: Given the consensus on enabling C++11 if available, I landed that branch, yesterday. Looks like that upset some build animals. Interestingly, Debian/sid runs into some boost issue, when C++11 is enabled. I don't see that issue on Debian/testing, so I'm not sure if it's really monotone's fault or due to some sid update. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 08:16 PM, Stephen Leake wrote: The error goes away if I delete '-std=c++11'. Or if I change it to gnu++11! It also vanishes if we undefine __STRICT_ANSI__, as I did in my recent commits. I'm not quite sure if that's the best way, though. Maybe we're better off using gnu++11. Build animal wallaby (using bleeding edge clang) isn't quite happy, either. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/15/2014 03:30 PM, Stephen Leake wrote: You left out Windows: Yes, sorry, that's not due to my aversion against that OS, but because I assumed those to be more of a rolling release style, where you usually have a pretty recent gcc. For the very same reason, I left out Gentoo and Arch Linux. We also have to run RHEL 5 for a couple of version-frozen projects. But those don't need the latest monotone, just netsync compatibility. netsync compat is an entirely unrelated issue. However, there's the RedHat Developer Toolset, shipping gcc 4.7. I was not aware of that, nor of RHEL 7. There's a first release candidate for RHEL 7, AFAIUI. Not that I had ever used that or the Developer Toolset. In addition, we use AdaCore tools, which provide gcc 4.7. I'll try testing with that. Thanks, I'd appreciate that. Right. Or just use an older monotone; as long as we preserve netsync compatibility, using an older monotone is not a serious problem. People using old systems have to accept old tools. Agreed. We could provide 1.1 source tarball on our website for a while, to allow compiling on non-C++-11 systems. Sure. We don't want to discourage interested contributors by saying you can't use the best tool for the job (which would actually be Ada 2012, not C++ 11, but let's not go there :). In honor of the founder of this project: Sorry, no, the best tool would rather be rust. ;-) Regards Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/15/2014 09:18 PM, Stephen Leake wrote: gcc --version gcc (GCC) 4.7.4 20131104 for GNAT Pro 7.2.1 (20140108) for GNAT Pro?!? In file included from ../mandatory-cxx11/src/globish.cc:14:0: ../mandatory-cxx11/src/option.hh: In member function option::option_setT option::option_setT::operator|(const option::option_setT) const': ../mandatory-cxx11/src/option.hh:332:7: error: 'set_union' is not a member of 'std' ../mandatory-cxx11/src/option.hh: In member function option::option_setT option::option_setT::operator-(const option::option_setT) const': ../mandatory-cxx11/src/option.hh:340:7: error: 'set_difference' is not a member of 'std' ../mandatory-cxx11/src/globish.cc: In function std::basic_stringchar::const_iterator compile_charclass(const string, std::basic_stringchar::const_iterator, std::back_insert_iteratorstd::basic_stringchar , origin::type)': ../mandatory-cxx11/src/globish.cc:141:7: error: 'sort' is not a member of 'std' Hm.. there's nothing new about std::sort. Nor set_union or set_difference. This looks more like you're using some weird standard library. Does that g++ version compile plain nvm? That's is using the very same standard library functions from algorithm... Also, I notice you are using -std=gnu++11; shouldn't that be -std=iso9899:2011, so we don't rely on gnu extensions? The m4 script is supposed to use -std=gnu++11 only if -std=c++11 is not supported. I haven't ever seen -std=iso9899:2011, before, but certainly prefer the shorter variant. Does your g++ support -std=c++11? If so, it looks like the m4 macro is failing to do its job properly. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/13/2014 03:51 PM, Stephen Leake wrote: I have no problem moving to the current language standard, as long as we can actually compile everything we need. Good to hear, thanks. We need to show that all (most?) tests pass on the various supported platforms before merging to nvm. Well, the question is: What's the set of supported platforms. And which ones are we willing to drop in favor of migrating to C++11. For somewhat decent C++11 support, I think we need to target gcc-4.6 as the minimum compiler requirement; release date of 4.6.0: March 2011. (Or alternatively, clang of around 3.1 or 3.2, but a) clang isn't that wide spread, and b) we only started to mention clang in INSTALL since release 1.1). This requirement clearly complicates matters for distributions that ship anything older than gcc-4.6. These are (according to what I could find quickly): NetBSD 5.1 shipping gcc 3.3 OpenBSD 5.5 shipping gcc 4.2 Debian squeeze (oldstable): shipping gcc 4.4 Ubuntu 10.04 LTS (lucid): shipping gcc 4.4 RHEL 6: shipping gcc 4.4 CentOS 6.5: shipping gcc 4.4 FreeBSD 9.0 shipping gcc 4.4 Fedora 14: shipping gcc 4.5 OpenSuse 11.4 shipping gcc 4.5 Slackware 13.37 shipping gcc 4.5 These (and newer) should be fine: Ubuntu LTS 12.04 (precise): shipping 4.4 - 4.8 Debian stable (wheezy): shipping 4.6 and 4.8 Fedora 15: shipping gcc 4.6 FreeBSD 9.2 shipping gcc 4.6 OpenSuse 12.1: shipping gcc 4.6 Slackware 14.0 shipping gcc 4.7 NetBSD 6.1 shipping gcc 4.8 RHEL 7 shipping gcc 4.8 (?) Out of these, RHEL 6 hurts the most, IMO. However, there's the RedHat Developer Toolset, shipping gcc 4.7. For other old distributions still in use, you're likely to find a newer gcc as well, I think. Mac OS X uses clang. Given my experiments and Thomas' feedback, it seems we need at least 10.9 (Mavericks) and Xcode 5.0, but I could try again on my Mountain Lion - its clang version (3.3) should theoretically suffice. I don't remember what went wrong. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Hey Hendrik, On 05/13/2014 05:17 PM, Hendrik Boom wrote: monotone should definitely be compilable on C++11. It is. That was one of my goals with release 1.1. However, wit that release, C++11 still isn't enabled by default (at least not by our configure script). nvm.optional-cxx11 would change that. But it's going to be a while before all platforms have C++11 compiler. Absolutely. We cannot (and haven't ever) support all platforms, though. See my list in response to Stephen. I'm thinking of things like long-term-support Ubuntu and Debian Squeeze, older Mac's which do not receive new OS/X's any more, Windows XP machines, and so forth. There are probably even older platforms still in active use somewhere. It's not unusual at all for servers to be running stable long-term-support versions of software and foregoing the latest and greatest for stability. Please keep in mind that you don't need the new compiler to *run* monotone. But yeah, I take this as a vote against adapting C++11 now. I have noo idea how many of these old systems use monotone. Sadly, not many. Just one number: Debian popcon lists around 300 installs. Overall. That's 0.13% percent of all popcon-counted systems. (And that includes my several Debian build animals ;-) ) I maintain that monotone should remain compilable on older C++ compilers. At very least, the pre-C++11 version of monotone should be its own legacy branch and should continue to receive bugfixes for a long time, and should remain net-sync-compatible with the current one. I heard you. Of course, the operational questions here are *when* the transition should occur, and how long dual-operation should be supported when it does. I think the answer to the dual-operation duration is obvious: Zero. We just don't have the man-power. What do you think would be a good time to switch to C++11? I'm a bit concerned that botan is switching to C++11. (And just notice that botan even states gcc-4.7 as the minimum requirement for 1.11 onwards.) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
long,
now (including constants).
Then there's better control of default constructors. You can explicitly
delete one or explicitly use the default one. Or delegate to another
constructor. Or inherit a base class' constructor.
And lots lots more: Initializer lists: listpairstring, int = {{A,
1}, {B, 2}} and in-class member initializers now both work. Variadic
templates, raw string and user-defined literals, attributes, an override
keyword, etc, etc...
Bjarne Stroustrup states that C++11 feels like a new language [0]. I
personally don't think of it as new, but to me C++11 feels more like
what I always wanted C++ to feel like. I absolutely agree with his
follow-up statement: The pieces just fit together better.
Regards
Markus Wanner
[0]: Bjarne Stroustrup's C++11 FAQ:
http://www.stroustrup.com/C++11FAQ.html#think
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/13/2014 07:35 PM, J Decker wrote: I didn't see an answer to 'would you mind to give guys like me some examples / judgement why monotone should switch to C++11? I could think of having less code in monotone because more is taken care of already in the stdlib, but some examples would be nice.' That answer just took a little longer to write. There are so many useful things... ;-) For some more examples, please see the diff between nvm and nvm.optional-cxx11. other than c++11 being new and shiny? I know it has builtin thread support which might removal of some ifdefs ... but I'm sure that's an insignificant change Yeah, monotone doesn't use threads, so that feature is not of use for us. Given the (lack of) manpower, I think it's actually beneficial to the project to reduce the variety of supported platforms. I'm certainly not willing to test gccs back to version 3.2. Nor boost as of 1.33, for example. (As currently stated in INSTALL.) I'd also like to drop support for botan 1.6, maybe even 1.8. Three years after release 1.0, I think it's about time to discuss the set of supported platforms. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Jack, over here at the monotone mailing list, we're discussing a move to C++11, partly inspired by botan's move. On 05/13/2014 07:29 PM, Markus Wanner wrote: I'm a bit concerned that botan is switching to C++11. (And just notice that botan even states gcc-4.7 as the minimum requirement for 1.11 onwards.) What are your plans for botan 1.10.x? Does that branch keep getting bug-fixes after the 1.12.0 release? (I guess so, but don't remember reading a policy or roadmap or the like on your website.) Regarding the new standard: What was your experience with the switch to C++11, so far? Would you recommend the monotone project to switch? Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/13/2014 11:56 PM, Hendrik Boom wrote: It may take some effort to introduce all the C++11 features being discussed here. Absolutely, yes. I see no pressure on that, though. (And no, I don't think we need to introduce *all* those features. I'd like to have the option to use them where applicable.) Getting rid of things that don't work in C++11, well, that's somethingg we'll have to do anyway. I'm not sure what you're talking about, here. monotone 1.1 compiles on gcc and clang with C++11 enabled. I'm not aware of anything that doesn't work. But factoring or refactoring in new C++11 features is probably going to cost us more time than it saves. Unless, of course, there are serious plans to introduce major new facilities into monotone where the improved clarity of the code will benefit us. Sure, there's a trade-off. The way you put it makes me think the bare impression of a living project is already worth the change... And yes, I have some itches with monotone that I'd like to scratch. And I'd like to scratch them the C++11 way. The way we're talking, it almost seems the C++11 is itself a new platform. It mostly is an extension of the existing standards. There are very few legal C++98 constructs that C++11 doesn't tolerate. Monotone doesn't use any of those. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/14/2014 12:00 AM, Hendrik Boom wrote: It's possible that botan may force our hand, whether we want to stay with the old C++ or not. As much as I like the C++11 features: I don't think that's apt. It seems well possible to use botan 1.12 from 'ifdef HAVE_CXX11' blocks. Any platform that doesn't support C++11 is highly unlikely to ever ship botan 1.12. And for the others, we need to support multiple stable versions of botan, anyways. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] C++11
Hi, as you may have realized, I'm considering using C++11 for monotone. A relevant forerunner for that is botan, which already switched to C++11 in its 1.11 development branch. For monotone, there are two branches I'm played with: net.venge.monotone.optional-cxx11: enables C++11 features on compilers supporting it. Doesn't change anything for compilers that do not provide C++11. net.venge.monotone.mandatory-cxx11: mandates C++11 and won't compile anymore on compilers that don't provide C++11. Obviously, the former offers little benefit: We could possibly add minor #ifdef'd optimizations. For example using perfect forwarding and move constructors to avoid some copying if C++11 is used. The latter seems much more interesting, but is a much heftier change as well. Before I proceed with that branch, I'd like to get some feedback and opinions. The most obvious drawback is higher requirements on compilers and standard libraries. However, it seems realistic to be able to support gcc-4.6 and clang-3.3 and newer. (Maybe even older clang, but I didn't try.) Is anybody opposed to raising these? Are you fine with landing these branches and start to use C++11? Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 1.1 released
Thomas, On 05/08/2014 11:04 AM, Thomas Keller wrote: Send me a new one via PM, I can set it up. I think IPv6 vs. IPv4 was the issue. If you use IPv4, then port 22 doesn't get you onto code.monotone.ca. Stephen: Can you upload the win32 installer, now? Regards Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] GPL version for monotone
On 05/07/2014 09:02 AM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: Alternatively, please resolve the ambiguity by clearly allowing distribution of those files under GPL v2 as well, i.e. change the boiler plate there to state GNU GPL version 2.0 or greater, as other source files still do. Thanks. Done Thanks you, perfect. I think we can reasonably back-patch that to the 1.1 tree for distribution, so we don't run into trouble when claiming monotone to be GPL-2+. I'll have to do that for Debian. (I'm surprised nobody noticed that for the entire lifetime of 1.0 in Debian...) Maybe that needs to be revisited, now? Stephen, do you want to pursue a move to GPL-3+, again? I'm always in favor of moving to GPLv3, but I don't think anything has changed in this regard. Well, quite some time has passed since then. With a release manager's hat on, as well as from the Debian Maintainer perspective, I'm glad we can now have that discussion independent of the release process. Thanks again, for quick and easy clarification. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] results from Debian buildd
On 05/06/2014 09:39 PM, Markus Wanner wrote: However, given tests with monotone 1.1 still don't cope well with a missing or dysfunctional network, I simply disable network tests for the Debian package, again. Fortunately, this also made the kfreebsd issue vanish. Update: With 1.1-2, there still is an issue on hurd. :-( I'll take care... Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 1.1 released
Thomas, On 05/05/2014 10:49 PM, Thomas Keller wrote: Oops, that was me that entered this passage three years ago, of course there is no automate atttributes, but only a automate get_attributes command. I fixed and pushed this to nvm. Thanks. Also, I updated http://wiki.monotone.ca/AutomateVersions/ to reflect the minor interface bump and documented the added / changed commands. Oh, good point. Lastly, I pushed an update to MacPorts, so monotone 1.1 should be available via their ports tree soon-ish as well. Great! Shall we remove the Mac OS X Installer and Binary options from the website's downloads site and recommend MacPorts? Or how do I build these universal binaries? Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mingw 64 bit build
On 05/06/2014 02:15 AM, Stephen Leake wrote: Yes, as long as there are no warnings in the compiler output, my workflow works :). I'm glad to hear that. Anything speaking against landing nvm.cleanup-warnings, then? We should add something about this in HACKING, and perhaps suggest compiling new code with -Wunused enabled, to catch bugs before they get too far. Yeah. One hurdle there is that you cannot just pass that in CXXFLAGS, but have to adjust m4/prog_cxx_warnings.m4. :-( Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone-1.1 released
Hello Thomas, On 05/06/2014 10:23 AM, Thomas Klausner wrote: I've updated the pkgsrc package to 1.1. All self tests passed for me on NetBSD-6.99.40/amd64. Thanks a lot, that's great to hear. Most patches we had were not needed any longer, but one still applies, though I'm not sure how necessary it is. Please take a look, it is attached. I'd hope it's not required, anymore, as declaring HAVE_CXX11_UNORDERED_MAP_AND_SET should get you the exact same variant of code. However, I didn't check if configure on NetBSD correctly sets that. (It's known to work on at least FreeBSD 10 and Debian, though.) It's probably safest to keep that patch, for now. Regards Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] results from Debian buildd
Hi, when packaging monotone 1.1 for Debian, I decided to try enabling the network tests, to see how the Debian buildd infrastructure now copes with these (see [0]). After all, some of the tests now detect e.g. a broken or missing DNS server, so I had hopes for some more tests passing. Mainly for future reference: Most of the arches build and test monotone 1.1 just fine. However, these three failed: armel, hurd-i386, kfreebsd-amd64. On armel (host alwyn): https://buildd.debian.org/status/fetch.php?pkg=monotonearch=armelver=1.1-1stamp=1399303079 the test db_opt_fallback_mechanisms fails with: mtn: network error: failed to connect: Network is unreachable The test well checks if DNS resolution works. If it does, it's assuming it can reach code.monotone.ca as well. An obvious bad assumption of mine. Sorry. The existing check is good and needed, but not sufficient. On hurd (host ironforge.sceen.net): https://buildd.debian.org/status/fetch.php?pkg=monotonearch=hurd-i386ver=1.1-1stamp=1399334904 the following tests fail: netsync_hook_errcodes, netsync_key_hooks and netsync_negotiation. netsync seems to work via localhost. One error is related to a wrong exit code from a client in case of failure, so this may well be a real issue on Hurd. Hurd? On kfreebsd-amd64 (host fayrfax): https://buildd.debian.org/status/fetch.php?pkg=monotonearch=kfreebsd-amd64ver=1.1-1stamp=1399287730 only one test fails, but that one really surprises me: log_dir It's puzzling because I'm running a build animal on that very platform. And the test doesn't seem related to the network at all. However, given tests with monotone 1.1 still don't cope well with a missing or dysfunctional network, I simply disable network tests for the Debian package, again. Fortunately, this also made the kfreebsd issue vanish. Regards Markus Wanner [0]: current Debian Package Auto-Building page for monotone: https://buildd.debian.org/status/package.php?p=monotone signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] GPL version for monotone
Stephen,
while COPYING states GPL-2+ as the license for monotone, I just figured
there's exactly two files in the source that state GPL-3+:
src/{unix,win32}/parse_date.cc. You introduced these back in May 2010 in
rev a8147b11, when splitting functionality from dates.cc into these two
platform specific variants.
I realize the has been some discussion regarding switching to GPL-3+
(search the archives for GPLv3 code in monotone), but to me the thread
doesn't quite look like an agreement has been reached for a move to
GPL-3+. Maybe that needs to be revisited, now? Stephen, do you want to
pursue a move to GPL-3+, again?
Alternatively, please resolve the ambiguity by clearly allowing
distribution of those files under GPL v2 as well, i.e. change the boiler
plate there to state GNU GPL version 2.0 or greater, as other source
files still do. Thanks.
[ I'm sorry to bring this up only after the 1.1 release. ]
Regards
Markus
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mingw 64 bit build
Stephen, I understand your point of view and appreciate your efforts. Please continue to maintain the msys2 documentation. I'm not quite satisfied with the general guide for Windows, though, so please allow me to write something. I think that may well fit into INSTALL itself. Do you have any useful hints for what build system to choose for Windows? I mean Cygwin vs the others is somewhat obvious - either you want that POSIX emulation layer or you don't. But all of the MinGW versions confuse me a lot. Why did you choose MinGW64 over MinGW-w64 (!) [0], for example? What about the different C++ exception and threading models? Which one did you (or mingw/msys2) use? What effect do these options possibly have on monotone? Let alone the issue of cross-compiling 32-bit binaries from a 64-bit system tool chain. (And vice versa?) And then there is also MSVC... Granted, most of that should be MinGW / Msys / MinGW-w64 project documentation. And I certainly agree with you that their docs need some love. I find it hard to believe they are not interested in good documentation. Maybe they are not interested in monotone build protocols, yes. Of course, we cannot ever test all possible combinations. We don't do that on any Unix, either. But rather than listing just one or two very specific combinations, we can still state the options, their requirements, what's known to work or fail (for example the issue you faced with gcc 4.6.2). FWIW, I also plan to keep my buildbot on msys 1.0, for now. While I don't intend to maintain the INSTALL_windows_mingw.txt document to the level of detail you used to do it, I'd still like to keep something in there that clarifies that MinGW / Msys 1.0 is known to work. Dropping the file, as you suggested, would lose that knowledge. I'll eventually write up something. Regards Markus Wanner [0] the MinGW-w64 download page: http://mingw-w64.sourceforge.net/download.php signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] monotone 1.1 released
Hi, the monotone team just released version 1.1 of its versions control system. This is mainly a maintenance release, focusing on stability and compatibility. It also fixes various bugs that have accumulated over the years. The sources are available from the usual location [0], static builds, packages and installers should be available, shortly. Here's the relevant portion from the NEWS file: Changes - '_MTN/wanted-testresults' must now have 1 hex-encoded signing key hash in lowercase per line. New features - 'automate atttributes' now also works without a workspace and returns the attributes for a specific file from the revision's manifest - New 'erase_descendants' automate command which returns all input revisions, except those that are a descendant of another revision in the input. - New 'min(A)' selector is now available which returns all revisions selected by A which are not descendants of other revisions selected by A. - New 'not(A)' selector is now available which returns all revisions not selected by 'A'. - All certs for a revision are now output by 'mtn log' with 'suspend', 'testresult', and custom certs placed under a a new 'Other certs' heading. - New conflict 'dropped/modified' allows explicitly resolving the case of a file that is dropped on one side of a merge, and modified on the other. Previously, the modifications were always lost; now you have the option of re-adding the file with the modifications during merge conflict resolution. - New attribute 'mtn:resolve_conflict' allows specifying a persistent 'drop' conflict resolution for a dropped/modified conflict. This is useful in the case where the conflict will occur again in the future, for example when a file that is maintained in an upstream branch is not needed, and therefore dropped, in a local branch. Bugs fixed - Monotone now compiles against Botan 1.10.x (as well as most of the testing releases in 1.9.y). - Struct file_handle got renamed to avoid clash with newer glibc's fcntl.h. - Monotone now compiles just fine with gcc's option -Werror=format-security. - Fixed renaming across devices, for example if parts of the workspace are on NFS. - Fixed recursive file removal on Solaris. - Fixed a failure to revert some files when inodeprints is enabled. - Fix an early abort in netsync on Windows, which caused problems transferring large files. - Work around a 64-bit issue with mktime on Mac OS X for dates in 1901 and before. - Allow an ssh_agent socket path including dashes. - Monotone now works with Lua 5.2, even if it doesn't have backwards-compatibility compiled in. - Various fixes for compatibility with newer boost versions. - mtn add and mtn list are now more consistent in their use of --recursive and --unknown options. - Produce a meaningful error message when trying to disapprove a root. - Allow monotone to compile on platforms where MAXPATHLEN isn't defined (i.e. GNU/Hurd). - Allow monotone to compile on C++11-enabled g++ and clang++. - Allow the test suite to run on systems behind a broken DNS resolver and in cases where names cannot be resolved at all. - Allow the test suite to run from directories containing spaces and lots of other minor tweaks to the test suite making its results more reliable. Internal - The performance and memory usage of regular expressions has been improved throughout. This affects any use of the .mtn-ignore file such as mtn ls unknown and mtn add, and any calls to regex.search in Lua hooks. Other - 'mtn diff' now outputs old and new revision IDs in the diff header when both are specified. - Additional Vim syntax files and an output colorization script in contrib. On behalf of the monotone team, Markus Wanner [0] http://www.monotone.ca/downloads.php [1] http://www.monotone.ca/NEWS signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 1.1 released
On 05/04/2014 03:20 PM, Stephen Leake wrote: Will you be doing the win32 installer? I can build one from an msys2 32 bit build, if needed. I'd appreciate if you do it. Thanks. Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mingw 64 bit build
Stephen, On 05/04/2014 03:48 PM, Stephen Leake wrote: Done in nvm.cleanup-warnings. Cool, thanks. I'll have another look, soon. I think we should; there's nothing worse than trying to follow some install instructions only to discover there is some crucial bit of information missing. Yes, there is something worse than missing parts: Wrong parts. And out-dated stuff is pretty darn close to be wrong. The MinGW instructions prior to the recent release were helpful to some extent, but a lot of it was out-dated. I had to figure which parts still apply and which not. Granted, I didn't use the versions indicated in the doc. I wanted newer stuff. And I wish I had a more general, less verbose guide. Put another way: I just don't think we can keep up install instructions with that much detail for every of at least three different windoze build environments. For example, are the Botan args to configure necessary on Debian? Depends on which version of Botan you want to compile against. Maybe you even want to compile against a self-compiled one in a custom location. We cannot possible cover all variants - nor should we. I just assume so (because they are required on cygwin and msys2), but I didn't check. If I had not done the msys2 install first, I would not have known to use them, and would have wasted time figuring that out for Debian. Configure tells you pretty clearly if it found what it needs or what's missing, if it didn't. Reading through pages of outdated options on how I don't want to do it would certainly waste much more time for me, thanks. On the other hand, a large part of INSTALL_windows_msys2_64.txt talks about how to install msys2. That sort of instruction is not required for Debian and other Linux distros, Huh? If that needs explanation, please go help the mingw or msys2 project. The monotone source tree clearly is the wrong place to put that documentation, as most users in need for it won't find it, there. Notice that a significant portion of the messages we've exchanged are about what tools are you using?. Having identical tool setups is essential to tracking down bugs. I don't think we're in the position to enforce a tool chain on your users. The best we can do is make monotone easy to compile on most platforms. Instead of a lengthy document, why not bundle the entire set of tools required to build monotone in a zip file ready to delpoy? That would save the tedious work of accurately following 100 lines of boring instructions. Why? That will make it harder to follow, which means more likely to get it wrong. No, a more concise variant without exact commands or version numbers (which I neither want nor find anymore) would have been way easier to follow for me. Heck, I'm not a script interpreter. I don't understand the rationale for moving stuff to the wiki. That's harder to edit, and it won't be kept up to date. Wikis hard to edit? Do we use the same Internet? To me, the existing instructions felt more like a protocol of your experience getting monotone to compile from source on Windows. That's fine and certainly helpful to some point. But the source tree isn't the right place for a protocol, IMO. As it stands, an average Windows user would need a guide on how to choose the correct INSTALL_windows_* file. We are not addressing the average Windows user - that's my mom and siblings, who read email but never compile anything. Okay. Point taken. Who are we writing this for? The average Windows developer? We are addressing people who want to compile monotone. That's me and you and a few others. I find these instructions necessary, and I'm doing the work of maintaining them; what's the downside? If you're really going to maintain all of those multiple variants, I can live with it. I still want the rough guide on how to compile if I don't follow your instructions line by line. Thanks for writing up something for INSTALL, I'll review. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of release 1.1
Thomas, thanks for testing! On 05/03/2014 01:39 AM, Thomas Keller wrote: I'm on 10.9 (Mavericks) here. I had no recent enough mtn installation around, so I had to copy sources and build from there. Things that I've stumbled upon so far: * Don't use gcc from MacPorts to build, it will bring up weird linker errors (see my previous post from February), but stick to plain clang (which Apple advertises as gcc and g++ in the /usr/bin prefix) Just out of curiosity: What clang version is it? * Monotone has no support for botan's special versioned package- config file that botan seems to use since 1.10, so some more flag magic was needed, namely botan_CFLAGS=-I/opt/local/include/botan-1.10 botan_LIBS=-lbotan-1.10 Yeah, library.m4 isn't too clever about that, so all systems with newer botan versions need these additional flags. I'll either adjust the documentation or the script... * If gettext is not available, make (not make dist) fails with a cryptic make[2]: Circular po/sv.gmo - po/sv.gmo dependency dropped. I guess this is because of Makefile.am's po/%.gmo: $(srcdir)/po/%.gmo cp $ $@ which looks a bit fishy indeed. Hm.. that's a good hint! I'll check. `make -j$N` for any N bigger than 1 usually fails hanging at some txt2c step, here. Up to date, I couldn't figure why and started to suspect a bug in make. Maybe that's related. I see a small chance that's related... * make install failed for me, because mtn.1 seems to be deleted right after it was created, so it cannot be installed. So `make mtn.1` does create and delete the file, but when I execute the commands of that target in my own shell, mtn.1 persists. Weird, but a minor. Weird, indeed. Adding to my todo list: Makefile massage PS: German translation has been updated. Thanks! Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of release 1.1
On 05/03/2014 09:45 AM, Markus Wanner wrote: On 05/03/2014 02:08 AM, Thomas Keller wrote: mtn: warning: ssh_agent: failed to connect to agent: No such file or directory mtn: misuse: no ssh-agent is available, cannot add key 46ec58576f9e4f34a9eede521422aa5fd299dc50 Maybe also an issue with spaces in the directory? I'm running a test, now. I built and tested from a directory with spaces without running into this issue, so that's unlikely to be the cause (tested on Linux, though). However, I found another one in bash_completion. It turned out the test and the feature had issues. I fixed the test, but don't think shell completion is release critical. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mingw 64 bit build
Stephen, On 05/03/2014 03:54 PM, Stephen Leake wrote: I've built nvm.msys2-mingw-64 with Mys2/MingW64 64 bit. It passes all tests except one func test (empty_environment) and some extra tests. Cool, thanks. What goes wrong in empty_environment? That one works on Msys 1.0. I need to test that branch on a Unix box (I have Debian and Cygwin), since most of the changes are in '#ifdef Windows' areas. I just tried: There are a couple of places where Unix needs an argument that you've commented out. Please revert those. Also, I'm not a fan of the cast to void hack. That clutters the source code quite a bit - especially when you need additional ifdefs to filter based on platform. I'd rather disable that warning. Please also teach your editor to not re-indent code you didn't touch. That greatly eases review. See INSTALL_windows_msys2_64.txt for tools install; there is also INSTALL_windows_msys2_32.txt, which is very similar, but has 32 instead of 64 in lots of places. Having two different files makes it easier to cut and paste the commands. I appreciate your efforts to document the build process. However, please keep in mind that we don't provide half the amount of instructions on building on any other OS. Already before those additions, I felt the urge to merge, simplify and reduce the information into one file. I think exact commands should go into a script or on the wiki, if yo want. In the source tree, I'd say a single INSTALL_windows.txt showing different build options and outlining special considerations for Windows should suffice. As it stands, an average Windows user would need a guide on how to choose the correct INSTALL_windows_* file. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of release 1.1
On 05/03/2014 04:31 PM, Thomas Keller wrote: Not to my knowledge. I looked into the sources and saw that this assertion is triggered when mktime returns -1, i.e. could not interprete the single date components as a valid UNIX timestamp. I have to read the platform's mktime(1) more closely to find out what the issue is here. Sounds like a good hint. I'll have another look. I don't know how the ssh-agent works in detail, but I thought that it communicates over a local pip / socket of some sort that is referenced by the SSH_AUTH_SOCK environment variable - and that pointed to a path without spaces (/var/folders/mb/xkzjkh3d5_g0bv46qhzlznv8gn/T//ssh-wVNuN9lwzL5e/agent.45988). The local user's SSH_AUTH_SOCK is cleared before running tests. The specific test starts its own ssh_agent to check against. I have family time now, will look into it this evening. Enjoy! I have family-off time, now. Which I'm also enjoying ;-) Markus signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
