Re: [Monotone-devel] automate stdio: wrong output size information on windows
On Thu, 2006-04-27 at 08:13 +0200, [EMAIL PROTECTED] wrote: it seems to me that on windows, the size of the output in the response of 'mtn automate stdio' is evaluated _before_ line endings are expanded to CRLF: The real error is that automate stdio output is binary, and should not be subjected to Windows' text mangling. This was fixed about a day after 0.26 was released. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] update bug with read only file
Hello, I found a bug in 0.24, it still exist in 0.26. This is on windows. Scenario: You have a working directory with some version controlled files. Change the permission of them to read only. Sync the monotone database with someone that has made changes. Do mtn update, monotone will now crash when it tries to update the read only files. $ mtn log --next 4 - Revision: 7ee27ff3e659d674a8008c4b7db814fcbac3968c Ancestor: Author: [EMAIL PROTECTED] Date: 2006-04-27T07:13:31 Branch: test Added files: bar Added directories: ChangeLog: - Revision: f200d6554b8b33f3f63b551988641f01bb837ae6 Ancestor: 7ee27ff3e659d674a8008c4b7db814fcbac3968c Author: [EMAIL PROTECTED] Date: 2006-04-27T07:17:05 Branch: test Modified files: bar ChangeLog: [EMAIL PROTECTED] ~/test/foo $ chmod 444 bar [EMAIL PROTECTED] ~/test/foo $ ls -l total 1 drwxr-xr-x2 johanAdminist0 Apr 27 07:21 _MTN -r--r--r--1 johanAdminist4 Apr 27 07:18 bar [EMAIL PROTECTED] ~/test/foo $ mtn update mtn: updating along branch 'test' mtn: selected update target f200d6554b8b33f3f63b551988641f01bb837ae6 mtn: updating bar mtn: wrote debugging log to c:/Documents and Settings/johan/Mina dokument/test/foo/_MTN/debug mtn: if reporting a bug, please include this file /Johan debug.gz Description: GNU Zip compressed data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Empty change log
Hello, This is more of an question than a bug report:-) Currently it's not possible to do: $ mtn commit -m mtn: beginning commit on branch 'test' mtn: misuse: log message rejected: empty messages aren't allowed But it's possible to do: $ mtn commit -m mtn: beginning commit on branch 'test' mtn: committed revision 7ee27ff3e659d674a8008c4b7db814fcbac3968c Now I guess that in the case you enter the commit message in the text editor this is a protection mechanism (which I find very usefull). But when doing it form the command line I can only assume that you folks don't like empty commit messages. If that is the case I think that the second example should fail too (only white space in commit message). P.S. This was for testing my previously reported bug, I don't do this IRL:-) BR, Johan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] results of mercurial user survey
Well, I found them interesting to read, anyway :-): http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey -- Nathaniel -- But in Middle-earth, the distinct accusative case disappeared from the speech of the Noldor (such things happen when you are busy fighting Orcs, Balrogs, and Dragons). This email may be read aloud. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] results of mercurial user survey
Nathaniel Smith schrieb: Well, I found them interesting to read, anyway :-): http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey Two quotes interesting to us would be (comments about other known SCM): Chose Monotone, got confused, switched to Mercurial. I don't know anything about Mercurial (so I don't know how they handle revisions,...), but as I started off with monotone, the hardest thing for me was to think in hashes and to deal with 40 Byte long revision numbers... Monotone is simply too slow to use, even on smallish trees on my dual amd64. The obvious bottle-neck IMHO is pulling large repos, like the monotone one, as this takes far too long to do security checks there (as far as I can remember what Nathaniel once told me). This would be definitely a point for improvement. The other actions happen quite fast, and I have no dual machine. Thomas. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: results of mercurial user survey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Keller wrote: Nathaniel Smith schrieb: snip Monotone is simply too slow to use, even on smallish trees on my dual amd64. The obvious bottle-neck IMHO is pulling large repos, like the monotone one, Pulling the monotone repo could have been nearly twice as fast, since almost half of the revisions are merges. 'commit before update' is great, but PR wise you are shooting yourselves in the foot IMO. regards, KOen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEUI67MkyGM64RGpERAsulAJ9dFb9Vbv52rrPtTGzKl/sCGkDDRQCfSxXR hRmGdh8hVv7TA9sgST8JDFU= =rIlP -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Annotate in the tutorial?
Hi. I have written a small section for the annotate command. I don't know if this kind of humore is OK for the manual, but well, there it is. J. patch.annotate.texi Description: TeXInfo document ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] results of mercurial user survey
Thomas Keller wrote: Chose Monotone, got confused, switched to Mercurial. While I have some issues with the monotone model as well (ie. branch as a bag of (possibly) unrelated discontinuous revisions) I do not find it any more 'difficult' than mercurial's. Monotone is simply too slow to use, even on smallish trees on my dual amd64. That is probably THE reason why I switched from monotone to mercurial. I do not like the way mercurial stores all revision data in *each* workspace and works around this by using hardlinks or the way publishing remote branches works (ie. is more difficult than it needs to be) but I've learnt to live with it because it is reasonably fast and works over ssh (no new ports on firewalls needed, no new daemon listening for incoming connections etc.). Zbynek -- http://zw.matfyz.cz/ http://robotika.cz/ Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Empty change log
On Thu, 2006-04-27 at 09:43 +0200, Johan Bolmsjö wrote: Hello, This is more of an question than a bug report:-) Currently it's not possible to do: $ mtn commit -m mtn: beginning commit on branch 'test' mtn: misuse: log message rejected: empty messages aren't allowed But it's possible to do: $ mtn commit -m mtn: beginning commit on branch 'test' mtn: committed revision 7ee27ff3e659d674a8008c4b7db814fcbac3968c Now I guess that in the case you enter the commit message in the text editor this is a protection mechanism (which I find very usefull). In that case, it should say mtn: misuse: empty log message; commit canceled . (Should this maybe be a W() or P() followed by return, instead of an N()? It's more a poorly-documented way to cancel a commit, rather than user error.) But when doing it form the command line I can only assume that you folks don't like empty commit messages. If that is the case I think that the second example should fail too (only white space in commit message). It's the default version of the validate_commit_message hook. I don't think it's a very good default, so would anyone object to removing it? Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Getting rid of bad signatures is certs
Matthias Hoelzl [EMAIL PROTECTED] writes: [...] Is there some way for me to get rid of these certificates or (even better) to sign them with my key or have him sign them with his good key? Creating new certs is easy, just use monotone cert rev name value. So you can easily produce well signed versions of those certs (use monotone automate certs rev to find what the existing certs contain). Removing the old ones is trickier. I think the only way to do it is by using db execute. So you could make a copy of the database, then do monotone db execute drop from revision_certs where id='65e0ed8783197348f16b0fa8baf839153e06bb95' then add the new certs. You'd need everyone with a copy of the database to do the db execute thing, otherwise I think the bad certs will reappear. I think that would work, anyway. (Untested, no warranty, etc. Make a backup first!) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Empty change log
Timothy Brownawell wrote: It's the default version of the validate_commit_message hook. I don't think it's a very good default, so would anyone object to removing it? bikeshed I definitely think that rejecting empty log messages by default is a good thing. I'd also go with rejecting whitespace-only messages by default. /bikeshed I don't really feel too strongly on the subject, though. -- Jon ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] update bug with read only file
On Thu, 2006-04-27 at 09:38 +0200, Johan Bolmsjö wrote: Hello, I found a bug in 0.24, it still exist in 0.26. This is on windows. ... [EMAIL PROTECTED] ~/test/foo $ chmod 444 bar [EMAIL PROTECTED] ~/test/foo $ ls -l total 1 drwxr-xr-x2 johanAdminist0 Apr 27 07:21 _MTN -r--r--r--1 johanAdminist4 Apr 27 07:18 bar [EMAIL PROTECTED] ~/test/foo $ mtn update mtn: updating along branch 'test' mtn: selected update target f200d6554b8b33f3f63b551988641f01bb837ae6 mtn: updating bar mtn: wrote debugging log to c:/Documents and Settings/johan/Mina dokument/test/foo/_MTN/debug mtn: if reporting a bug, please include this file Interesting lines from the log: ... using MoveFileEx for renames ... attempted rename of '_MTN/data.tmp.1848' to 'bar' failed: 5 [that line is repeated 12 times] Looking at the code, that line should be repeated 16 times, and should be folloved by error: renaming '_MTN/data.tmp.1848' to 'bar' failed: 5 . 5 is ERROR_ACCESS_DENIED, which I think is the expected result from the destination file being read-only (we should probably use FormatMessage to print a string, instead of / in addition to the number). What I don't get is how rename_clobberingly apparently crashed in some way other than throwing an exception (else it would have given the this is almost certainly a bug text), in the middle of a loop that should be doing the exact same thing each time. I tried to reproduce this, and got the expected behavior. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Empty change log
On 4/27/06, Jon Bright [EMAIL PROTECTED] wrote: Timothy Brownawell wrote: It's the default version of the validate_commit_message hook. I don't think it's a very good default, so would anyone object to removing it? bikeshed I definitely think that rejecting empty log messages by default is a good thing. I'd also go with rejecting whitespace-only messages by default. /bikeshed I agree with this sentiment. A whitespace-only commit message is essentially the same as an empty one. I don't really feel too strongly on the subject, though. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Empty change log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Patrin wrote: On 4/27/06, Jon Bright [EMAIL PROTECTED] wrote: Timothy Brownawell wrote: It's the default version of the validate_commit_message hook. I don't think it's a very good default, so would anyone object to removing it? bikeshed I definitely think that rejecting empty log messages by default is a good thing. I'd also go with rejecting whitespace-only messages by default. /bikeshed I agree with this sentiment. A whitespace-only commit message is essentially the same as an empty one. Reminds me of auto* requiring a README, AUTHORS, etc but not checking for actual contents regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD4DBQFEUSwTMkyGM64RGpERAk5AAJ9UlpN67h6diYA6ccNHMTpAO6k3fACXc6sg hp1eEMGioUZWCxf+Z3yPoQ== =Rlx9 -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Another patch to the manual
On Thu, Apr 27, 2006 at 07:03:00AM -0300, Jeronimo Pellegrini wrote: I think a $ was missing in the packet tutorial... Indeed. Also, maybe this introductory paragraph would be nice? Yes, it would. I'll tweak your wording ever so slightly, but will add this change shortly. Thanks! -- Dan. pgpAzMwv7DIOC.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Empty change log
On Thu, Apr 27, 2006 at 01:57:21PM -0500, Timothy Brownawell wrote: But when doing it form the command line I can only assume that you folks don't like empty commit messages. If that is the case I think that the second example should fail too (only white space in commit message). It's the default version of the validate_commit_message hook. I don't think it's a very good default, so would anyone object to removing it? Ah-hah, is that what it is! I had been wondering, since we pretty much hashed this out before: http://thread.gmane.org/gmane.comp.version-control.monotone.devel/4365 and I thought we had decided that -m should just work, if someone was going to bother doing it. I guess we made that work, and then the validate_commit_message change changed it again? IMHO the validate_commit_message hook should default to accepting _all_ messages, while keeping the current empty commit message in an editor means cancel this commit behavior. -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Empty change log
On 4/27/06, Nathaniel Smith [EMAIL PROTECTED] wrote: On Thu, Apr 27, 2006 at 01:57:21PM -0500, Timothy Brownawell wrote: But when doing it form the command line I can only assume that you folks don't like empty commit messages. If that is the case I think that the second example should fail too (only white space in commit message). It's the default version of the validate_commit_message hook. I don't think it's a very good default, so would anyone object to removing it? Ah-hah, is that what it is! I had been wondering, since we pretty much hashed this out before: http://thread.gmane.org/gmane.comp.version-control.monotone.devel/4365 and I thought we had decided that -m should just work, if someone was going to bother doing it. I guess we made that work, and then the validate_commit_message change changed it again? IMHO the validate_commit_message hook should default to accepting _all_ messages, while keeping the current empty commit message in an editor means cancel this commit behavior. ::shrug:: that works too. As long as en empty commit message from an editor means abort I'll be happy. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: results of mercurial user survey
On Thu, Apr 27, 2006 at 11:28:27AM +0200, Koen Kooi wrote: Pulling the monotone repo could have been nearly twice as fast, since almost half of the revisions are merges. 'commit before update' is great, but PR wise you are shooting yourselves in the foot IMO. Well, maybe. We _should_ be fast enough that it doesn't matter, though :-). (We also could make the initial pull go at line speed trivially, if we wanted; just feed the raw data straight out of the db and straight into the other side's db. It's just that we're still trying to see how far we can get with safe before we give it up.) Also, data point: in the monotone repo, only ~1/5 of the revisions are merges. (Presumably this varies with a group's habits.) Getting rid of 1/5 of the revisions probably would make things somewhat faster, it's true... in monotone's case, it was only a few months ago that we _had_ 4/5 as many revisions as we do now. Using a pull of net.venge.monotone is slightly problematic as a benchmark, because the benchmark data set has been growing larger almost as fast as we've been optimizing :-). -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] results of mercurial user survey
On Thu, Apr 27, 2006 at 02:45:53PM +0200, Georg-W. Koltermann wrote: Hg really appeals to me. Picking Hg or monotone mainly becomes a matter of your preference for either a more star-like topology with a couple of oligarchic interconnected repositories keeping all the history (well, to the extent of their inter-netsyncing), or a fully p2p topology with all the flexibility but also all the anarchy that it allows. Basically with the full p2p topology it is very easy to loose track of where your history is and where it isn't. And then suddenly when you remove one of I'm not sure I'd phrase it as star topology versus p2p topology. At the communication level, both monotone and hg allow totally arbitrary (p2p?) communication flows. the peers you may easily loose a part of your history. Which may be a good thing if you were careful to merge the parts of history that you want to keep to somewhere else beforehand, and thus you only loose the parts that were more like sandboxish experimentation. But it really depends, you might as well loose valuable history if your merge flow was not rigorous enough. But, exactly, your idea is right on. Monotone uses fully decentralized _mechanics_ to implement a centralized working model, with shared branches and everything -- two people can still be working on the same branch even if they're disconnected. We replaced the centralized server with one of those amorphous clouds you see in networking diagrams (Here Be Internet), but conceptually things don't really change that much. Hg (and darcs, git, bzr, bk, arch, ...), in contrast, are not just decentralized but scattered. I tend to visualize project history in their models as a bunch of little points with empty space between them, lying all over the world, and the full project history is the assemblage of them all together. We don't really have any idea yet which model is better, or how that depends on the user in question -- though different people will have different guesses. Since monotone is the only one even trying its approach, though, I feel like we owe the idea our labor, to give it a fair chance at life :-). -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: results of mercurial user survey
On Friday 28 April 2006 00:03, Nathaniel Smith wrote: On Thu, Apr 27, 2006 at 11:28:27AM +0200, Koen Kooi wrote: Pulling the monotone repo could have been nearly twice as fast, since almost half of the revisions are merges. 'commit before update' is great, but PR wise you are shooting yourselves in the foot IMO. Well, maybe. We _should_ be fast enough that it doesn't matter, though :-). (We also could make the initial pull go at line speed trivially, if we wanted; just feed the raw data straight out of the db and straight into the other side's db. It's just that we're still trying to see how far we can get with safe before we give it up.) Also, data point: in the monotone repo, only ~1/5 of the revisions are merges. (Presumably this varies with a group's habits.) Getting rid of 1/5 of the revisions probably would make things somewhat faster, it's true... in monotone's case, it was only a few months ago that we _had_ 4/5 as many revisions as we do now. Using a pull of net.venge.monotone is slightly problematic as a benchmark, because the benchmark data set has been growing larger almost as fast as we've been optimizing :-). -- Nathaniel For what it's worth I've been using monotone with a 200 MB repository (8000+ files) and it's definitely not too slow for me. Compared to clearcase it's a relief:-) On the other hand I rarely do a fresh pull on this big repository. But with a 20-30 MB one I do it once in a while. monotone is hardly complicated to use? I think it gets better all the time. I have some small scripts that checks for updates in the repository compared to my workdir and so on... The SSH complaint is nil in my opinion, just set up a SSH tunnel. Or am I missing something? P.S. I have a dual core X2. Don't think monotone makes much use of the second core though? :-) /Johan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: results of mercurial user survey
On Thu, Apr 27, 2006 at 03:36:20PM -0700, Justin Patrin wrote: For those of you who don't know we've solved this problem for OpenEmbedded by having a snapshot database for download on a system which is updated every night. This was when people are just starting they can grab the snapshot and pull only a few revisions. Having someone pull the entire OpenEmbedded database over netsync is really problematic as it takes hours and hours to finish and most people want it *now*. Right, this is basically the cheating idea I mentioned -- essentially doing the same thing as pulling over HTTP would do, just doing it internally inside netsync. Certainly the idea has occurred to us (it would be so easy to do!). Oh, well, I guess I'll write one of those long responses, that may be useful to point to later... To be fair, 0.26 does look to be faster, but an initial pull is still going to take far too long on a decent sized database. IMHO an initial pull into an empty DB could be changed to not verify revisions (as this is the extremely long and complex part), although if there is a possibility for corruption in netsync this could be a problem (although I don't see how there could be, assuming it's over TCP). It's not so much corruption in netsync -- it's corruption _anywhere_. Monotone, of course, always validates the data it is handling, so things like checkouts always check that the version being checked out is fine. But initial pull is important because it's the only time we can get away with checking _everything_, and in particular, the bulk of old history which can go years without being used directly. (This is the majority of data, so it's very probable that any accidental corruption would end up somewhere in it, rather than in the small percentage of the data that gets commonly hit.) This isn't a particularly made up problem, either. Lots and lots of long-running CVS projects have simple disk corruption in their old history, that was unnoticed until backups were gone. (In particular, I've heard stories about NFS issues that ended up with random blocks of null bytes in the middle of the file.) Monotone has twice had RAID issues on its shared server that caused single-byte errors in old files; if not for the checking netsync does, we might _still_ not have noticed that. db check will also catch this, of course, but it's rather easy for no-one to think of running that for long periods as well... Or, here's what Larry McVoy has to say: BK is a complicated system, there are 10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.[1] And this wouldn't be caught by checksumming, either, you need real semantic validity checking to prevent this source of corruption. (Similarly, remember: when engineering for reliability, your threat model includes not just hardware failure and over-eager users, but _yourself_. Everyone writes bugs.) And, well, I don't have $35,000, so... Believe me, we're really aware of how much pain the slowness causes on a day to day basis :-(. But once you give up safety, there's really no way to get it back. I'm not sure how well I would sleep at night if I was recommending software that could bite you that hard -- especially if I gave up on safety while there were still things to try. As it happens, the actual checking proper seems to be almost invisible in profiles of 0.26's pulls. There's still some reason to think that this is all doable. So, that's why I think we should keep trying the improve speed while refusing to give up safety strategy for now... Cheers! -- Nathaniel [1] http://os.newsforge.com/os/05/04/11/118211.shtml?tid=2tid=25tid=3 -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: results of mercurial user survey
On Thu, Apr 27, 2006 at 04:26:12PM -0700, Nathaniel Smith wrote: As it happens, the actual checking proper seems to be almost invisible in profiles of 0.26's pulls. There's still some reason to think that this is all doable. So, that's why I think we should keep trying the improve speed while refusing to give up safety strategy for now... If you give up on safety with an archiving tool, what's the point of having one? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Branch arguments to mtn serve
Greetings, During my dealings with my monotone server today, I had to restart it to change the branch patterns it serves. This got my wheels turning, and after some discussion on IRC, I discovered that the branch arguments to mtn serve, duplicate the functionality of the `get_netsync_read_permitted' hook. I am wondering if there are any objections to removing the branch arguments to mtn serve. If there are not, I am willing to look into removing them. -- Matthew A. Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
