Re: [Monotone-devel] 3rd party libraries
* Zack Weinberg: * pcre, idna: I'm not too sure about these, but dynamic linking seems to make more sense. I didn't hit any stumbling block so far in nvm.stripped. Concur. API/ABI stability shouldn't be an issue with these. The PCRE C++ API/ABI is not stable, and the regexp syntax isn't, either. (For instance, \R used to match R, but it doesn't anymore.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [offtopic] Google Analytics for monotone's website
* Thomas Keller: There are two downsides, though: The first is that only HTML contents can be tracked, but not individually downloaded files, since Google only notices those contents from which the Javascript code is executed, so afaik its not possible to generate download statistics through that [1]. The other downside is that the statistics are not publically viewable by everybody unless he or she is added to the account either as administator (full access) or user (read-only). The user has to give an email for which a Google account is registered to one of the other administrators to be added. The other downside is that this kind of privacy-invasive technology is usually not associated with free software projects. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] pcrewrap.cc vs pcre_config.h
* Stephen Leake: On the other hand, when using a pre-installed pcre library, apparently pcre_config.h is _not_ available. No, this is intentional. A library config.h files cannot be included elsewhere because they conflict with the application config.h files. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: re-licensing the monotone manual
* Nathaniel Smith: PLEASE REPLY TO THIS EMAIL, CC'ING monotone-devel@nongnu.org, AND SAY THAT YOU ARE FINE WITH YOUR CONTRIBUTIONS TO monotone.texi BEING RELEASED UNDER THE GPL (v2 or later). I'm fine with relicensing my (minor) contributions under the GNU GPL, version 2 or later. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Deterministic *-merge
* Nathaniel J. Smith: This is where key idea 2 comes in again. Let's define an equivalence relation ~, as: for all x and y that are not equal to #, x ~ y iff x = y. for all x, # ~ x is always true. Or in words: every normal value is similar to itself, plus, # is similar to _everything_. All objects are equivalent if ~ is in fact an equivalence relation. But I don't think this is a problem. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: sha1/botan stuff
* Nathaniel Smith: mozilla : 36.9 MiB/s openssl (no-asm debian-i386) : 56.5 MiB/s openssl (no-asm debian-i386-i686/cmov) : 56.5 MiB/s botan: 64.1 MiB/s beecrypt (from debian) : 87.0 MiB/s nettle (lsh's library, from debian) : 147.1 MiB/s openssl (with asm) : 263.2 MiB/s Have you tried libgcrypt? I suppose it's in the Mozilla range, though. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] RFC: Fake IDs
* Zack Weinberg: Typical use case (from cmd_merging.cc - I'm not posting a diff for that, as I have a lot of other changes in that file right now): // Just pick some unused revid, all that's important is that it not // match the work revision or any ancestors of the base revision. - r_target_id = revision_id(hexencid(54321500)); + r_target_id = revision_id(fake_id()); Can't you use a tagged union of an SHA-1 hash and a fake (but guaranteed to be unique within the ssion) ID? On 64 bit architectures, this shouldn't result in an observable space difference. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] monotone 0.25-0.1
* Richard Levitte: Wasn't it concluded that we (monotone ppl) would use the 0.25-0.x standard, and that Debian maintainers would use 0.25-y, so there would be a difference between us and Debian? Yes, but this was an NMU on Debian's side, so the 0.25-0.x syntax is strongly suggested. Perhaps the package should be co-maintained at Debian's side, to avoid future NMUs. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Debian apt-friendly monotone archive
* Steven E. Harris: I decided to ask here because the testing version is still at 0.19-1. 0.24-1 needs a new boost, which will hit testing later today. The current monotone version will migrate to testing at the same time. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] temporary attributes, cvssync
* Christof Petig:
My requirements are very simple: I need to attach a list of {CVS
revision per file} to an existing revision.
Do you need to attach this information to the *revision*, or to a
specific version of a file?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Serving * does not work
* Bruno Hertz: As a sidenote, this will happen more often as monotone becomes more widespread, since ppl tend to be confused by tools which implement their own globbing syntax (cf. 'find'). Especially so when it's differing from shell semantics or limited to a subset of it. Couldn't monotone print a warning if it detects an argument which does not match any branch? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Serving * does not work
* Wim Oudshoorn: All of them are expanded. It is obviously a problem with the msys shell. Not necessarily. On Windows, wildcard expansion is typically performed by the application (or some kind of libc stub which initializes the argv array). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Unnecessary performance hit on push?
* Nathaniel Smith: Oh, sure, it's obviously waiting on IO. The question is what IO are we doing that takes so long, and how can we not do that :-). It's probably the effect of internal database fragmentation, coupled with file system fragementation: monotone.db: 8686 extents found, perfection would be 1 extent Running VACUUM seems to help quite a bit, defragmenting the file at the file system level doesn't make such a big difference. (But this is for reading the certs before pull. I didn't notice soon enough that this thread is about push performance.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Cvssync status
* Richard Levitte: Can you say how it handles a CVS history where some files have been re-tagged? Is re-tagging visible in the CVS repository at all? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Cvssync status
* Zbynek Winkler: Has it been considered to let someone else do this work for monotone? I think git is using cvsps [1] to import cvs repositories. Does cvsps still open one connection per file and revision? That behavior was rather antisocial. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Proposal for human readable revision IDs
* Jon Bright: I also agree with this. For me, 568b-2462-456e-9a57-4326-93df-936d-4835 would be much more readable than 568b2462456e9a57432693df936d4835 Only the latter can be copied to the X selection with a single double click. (BTW, that's the reason why I don't think long hashes are a problem--except in annotate output, of course.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Patch to speed up add operation
* Eric Anderson: Is .data() assumed to be contigous as well? Yes. The difference to .c_str() is that the character array to which a pointer is returned is not guaranteed to be NUL-terminated. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Renaming branches and tags
* Matthew A. Nicholson: for REV in `monotone automate select b:OLDBRANCH`; do yes PASSWORD | monotone cert $REV branch NEWBRANCH done That should keep you from having to enter the password for each cert On multi-user machines, this is not a good idea because the command line is a publicly readable resource. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] how to merge trees
* Nathaniel Smith: Also, I'm going to assume that we don't support file suturing -- a file is born exactly once, and in any particular downwards path through the ancestry, dies exactly once or not at all. With such a model, wouldn't it be easier to track file identity with artificially generated names at creation time (called UID in other posts)? AFAICS, this approach breaks down when you try to merge changesets with only partial history, where you would have to fall back to an algorithm like the one you described. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [cdv-devel] more merging stuff (bit long...)
* Nathaniel Smith: (One horrible idea I had, suitable for scaring small children who are interested in merge algorithms: since it seem like trees may actually be _easier_ to merge than text, by passing to the representation of nodes-and-pointers-to-parents and then applying a nice scalar merge algorithm, why not apply the same trick to the linear ordering structure that makes up text? Model each line as a (text, pointer to preceding line) pair, and merge on those. I've been thinking about the very same thing (I call this atom inference, and my atoms are your scalars). Actually, I'm convinced that this is the language textual merges should be described in. This problem is quite similar to figuring out the adds/deletes/renames in a particular change from a before-the-change tree and an after-the-change tree. I doubt it can be fully automated, and users probably don't want to document each hunk in the required detail (this -/+ change replaces the same line with a new version vs this -/+ change deletes a line and adds a new, unrelated one). However, I hope that your voting algorithm does not require this level of detail. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: The new macro M is no good...
* Nathaniel Smith: Well, yes, it's good advice. But since M _cannot_ be a non-macro, What is it doing, actually? Maybe there's a completely different way to get things done. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ANNOUNCE: monotone 0.20
* Nathaniel Smith: When is venge.net switching to 0.20? Just switched it over. With monotone at manifest d538000d4a53ebe2c9b275cb30639aeba22f9e80, I get the following error message when I try to run monotone pull: monotone: warning: caught bad_decode exception decoding input from peer venge.net: 'bad checksum 0xde836079 vs. 0x122b5343' What's going wrong? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] ANNOUNCE: monotone 0.20
Florian Weimer schrieb: With monotone at manifest d538000d4a53ebe2c9b275cb30639aeba22f9e80, I get the following error message when I try to run monotone pull: monotone: warning: caught bad_decode exception decoding input from peer venge.net: 'bad checksum 0xde836079 vs. 0x122b5343' Try to download 0.20, compile it, sync into your existing database and update. I don't know what caused this either, but the bug does not occur if you use 0.20+ against the server. I think d538000d4a53ebe2c9b275cb30639aeba22f9e80 *is* 0.20. Maybe some files weren't recompiled; I'll try a fresh checkout. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Bug in monotone lca
* Wim Oudshoorn: However in that case lcad has a bug :-) Consider the following graph: A / \ B C | /| | / E D |\ | F \ | | G | H | | | I \ J | \ / K L monotone lcad L K // version 0.19 will return C, not E. But E doesn't dominate L, so it would be an incorrect choice. C seems to be correct for lcad, and lca should give E. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Handling the debian files
* Tomas Fasth: But I don't have a better solution, either, because I can never commit myself to a certain timeframe, especially not a tight one, because of my own business, my wife and kids, and also the other Debian packages I have to maintain (hm, just a few, really). Maybe with a co-maintainer, it would be possible to do things in a more consistent time frame? In this case, I'd suggest to remove the debian/* files from the net.venge.monotone branch, and keep the official Debian package sources on a separate branch. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] 3 proposed changes to manifest/changeset format
* Matt Johnston: If it'll fix dir dropping etc, sounds sane. Would this have consequences for making the root directory renamable? I'd like to seen renamable root directories eventually getting supported, as it seems to provide a convenient way to bring third party branches into a project I'm not sure if this is going to work. You could end up with multiple instances of the same file, which will be rather painful to deal with (if I'm not mistaken). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: 3-way merge considered harmful
* Nathaniel Smith: On Sun, May 01, 2005 at 06:51:54PM +0200, Florian Weimer wrote: * Nathaniel Smith: Fortunately, it seems like codeville-merge is a viable replacement here (it can be applied to both content merges and tree rearrangement merges), and with some recent improvements that Bram and some other people (including me) have been playing with, it may (I'm not sure yet) be strictly more powerful than 3-way merge. Is there some formal model of codeville-merge which one could check? We're working on figuring out whether it has some formal properties, Well, it certainly has. I was just asking for a high-level spec. actually, like equivalent to 3-way merge in the cases where 3-way merge is the right thing to do, clean merges are order invariant, etc. Well, without a formal spec, it's hard to tell. 8-) Yes, it's possible for two people to make redundant changes. This is one reason why it's impossible define a merge algorithm that works for all the various I's one might like. Given that, then, the responsibility of a merge algorithm is to fail in ways that make sense, so the user can have some conceptual model of what the system is doing and how to correct for its failings. And that's where test cases come in. The invariant I (well, I should have mad that a J, sorry) could be expressed as a test case, which would address the problem neatly and might have other benefits, too. However, it seems to be rather desirable to fix this bug. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: 3-way merge considered harmful
* Richard Levitte: In message [EMAIL PROTECTED] on Sun, 1 May 2005 00:29:48 -0700, Nathaniel Smith [EMAIL PROTECTED] said: njs Here's another pathological case for 3-way merge: njsA njs| njsB njs / \ njs C D njs Suppose that a file was added on the A-B edge, and then removed again njs in B-C, while it was left alone on the B-D edge. We want to merge njs C and D. Let's assume that for some reason we decide to use A as a njs common ancestor. What will happen? Our file does not exist in either njs A or C, so when comparing A and C 3-way merge will think that nothing njs has happened. Our file _does_ exist in D, though, so when comparing A njs and D, 3-way merge will decide that a file has been added. Therefore, njs says 3-way merge, this file should exist in the new merged node. njs But, this is obviously wrong; the file was deleted between B and C, njs and this delete should have caused a delete of D's copy as well. I disagree with that conclusion. It's quite possible the removal of the file in the B-C edge is a mistake, and that the person leaving it along in the B-D edge had it right. Especially in a fairly loose network of cooperating programmers, disagreements of that kind are bound to happen (and have happened). Others might call them oopses rather than disagreements... I think Nathaniel wanted to say that there is an implied conflict which 3-way merge cannot detect, not that one choice is better than the other. The argument that there is a hidden conflict which should be flagged as such is quite convincing (and, as a result, the zombie changeset term is misleading). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Descriptors do make a difference 8-O
* Christof Petig: Is func((some_string+something).c_str()) guaranteed to work with every compiler. Yes, deallocation of the temporary will be deferred to after the evalation of the full expression. And what are descriptors? ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Two new lists to get commit logs
* Richard Levitte: In message [EMAIL PROTECTED] on Mon, 18 Apr 2005 12:27:07 +0200, Florian Weimer [EMAIL PROTECTED] said: fw Would it be possible to include the diffs inline, and not as fw attachments? In other words, Content-Disposition: inline fw instead of Content-Disposition: attachment? Hmm, is that wise? Does it work in all mail programs? I think so, but I cannot offer firm guarantees, of course. A few interpret it as attachment, though. The safest approach would be to include the patches directly in the first part. My rationale for this change is that these messages are mostly used for code review. For this purpose, it makes sense if the mail reader is instructed to include the patches directly within the message, and not as separate files. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [RFC] ideas for an automate status command
* Bruce Stephens: I think you're right that inventory would be more suited to listing files that are in the repository (like monotone cat manifest but without the hash, I guess). Actually, it's called list known. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Two new lists to get commit logs
* Richard Levitte: I was a bit clumsy in the way I wrote that. My question is, how do I correctly detect a binary blob from text? A few GNU tools use the presence of NUL characters to identify binary files (some of them only in the first few K of the file, AFAIK). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
