Re: [Monotone-devel] Monotone support for tailor.py
At 2005-04-19T12:15:30+0200, Markus Schiltknecht wrote: did monotone update first but it didn't compile: commands.cc: In function `boost::posix_time::ptime commands::string_to_datetime(const std::string)': I've investigated and found out: This was a problem in the 1_31 release -- the constructor was accidently droped. The file has been fixed in CVS. You can patch your 1_31 release by getting the latest /boost/date_time/posix_time/ptime.hpp I'm updating to boost 1_32, being quite sure that got fixed. Maybe you want to add a hint stating 1_31 as buggy. I tried to circumvent the problem, but I didn't manage to see through the complicated boost c++ headers... Thanks. The line causing this compile problem when using 1.31.0 headers has been dropped from mainline; it was added recently to avoid a compiler warning, but since then a better solution has been put in place. Cheers, -mjg -- Matthew Gregan |/ /|[EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] cvs_import/sync questions
Hi all, Is it worth looking at cvs bugs on the main branch, or is the cvssync branch going to supersede it? Is cvssync close to merging? Is cvssync stable enough that I should try to figure out bugs on it, or is it still in flux and I should just let Christof do his thing? thanks, -emile +-- Bother, said Pooh, Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three. -- Robert Billing +-- signature.asc Description: This is a digitally signed message part ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] call for volunteers: auto-build+test machines
Hi, Kevin Greiner wrote: Which Win32 OS's compilers do you have already? We've covered this on IRC, but for completeness: The only compiler it works on, MinGW :-) As on IRC, there is a net.venge.monotone.visualc branch which I did before 0.17 but which hasn't been touched since then. This was targeted at VS.NET. Some of the changes necessary were too icky to be committable to mainline. VS.NET 2003 (and eventually, 2005) may well significantly improve the situation. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] newbie question - SHA1 vs serials
Just reading the manual yesterday and the obvious question came to mind. Why SHA1 instead of serials? The manual suggested that any reasonable alternative be offered. So here it is. The obvious alternative in my mind is a serial number. I understand that there's a problem in trying to provide globally unique serials without a central authority. It's the old space-time problem. How do you determine if two events occur at the same time if they don't occur in the same place? And the answer from physics is that you can't, really, because space and time are part of the same thing. To provide globally unique serials, one would need to include some representation of the location at which an event occurred. In this case, I'd suggest the domain name of the machine involved. So something like 1:monotone.venge.com, 2:monotone.venge.com, etc. If each repository used it's own name, (presumably it's domain name in most cases), and kept it's own list of serials, wouldn't this both provide a guaranteed unique id as well as providing that oh-so-sought-after monotonically increasing number people so love to see? --rich ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] newbie question - SHA1 vs serials
On 4/19/05, K. Richard Pixley [EMAIL PROTECTED] wrote: Jon Bright wrote: Hi, Hey. :-). To provide globally unique serials, one would need to include some representation of the location at which an event occurred. It's an idea that's been considered, but has a number of difficulties: 1. Not everyone's machine has a (valid) domain name. I have a number of domains, so I could pick one, but if I didn't, the only name I'd have would be p34543522.dip.t-dialin.net or whichever name my ISP gives me today. This is why I suggested that the repository be named. Presumably, the name would be based on domain name, but the real point is that domain names follow hierarchical delegation. But how is this enforced? 3. I have machine foo.bar.com - what to do about some unpleasant person who decides to incorrectly name their machine foo.bar.com too? (There are a number of workarounds for this, each with advantages and disadvantages) You do nothing. It's up to the administrator of bar.com to resolve this collision. Only one of you is actually authorized to use this name. Repository name doesn't necessarily change with IP or domain name change. But people sometimes do things without being authorized. Now, if you decided to change the name of an existing repository, that might represent a potential problem. The new name would work, but anyone who ever tried to reuse the old name would create a collision. I'm not sure this is a problem in practice, though. 4. The number's not actually monotonically increasing when viewing the tree as a whole. Ignoring branches, I'd still get 1:foo.bar.com | 1:baz.foo.com | 2:baz.foo.com [...] ...which kind-of seems to defeat the point. The point is two-fold: 1) provide human readable visual ordering. Since global ordering really isn't possible, the only ordering that has any meaning is per-repository ordering. And that's what you're seeing. Might be useful, but couldn't this be done just as well with a show ancestry command? 2) providing unique id's. But only if everyone behaves themselves. I think serials on named repositories do address these points. This requires some sort of central authority to work. As I understand it, one of the features of monotone is that there doesn't have to be any such central authority. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] newbie question - SHA1 vs serials
Timothy Brownawell wrote: This is why I suggested that the repository be named. Presumably, the name would be based on domain name, but the real point is that domain names follow hierarchical delegation. But how is this enforced? The same way monotone currently enforces branch naming. Which is to say, monotone already uses domain names on a conventional basis to provide uniqueness for branch names. 3. I have machine foo.bar.com - what to do about some unpleasant person who decides to incorrectly name their machine foo.bar.com too? (There are a number of workarounds for this, each with advantages and disadvantages) You do nothing. It's up to the administrator of bar.com to resolve this collision. Only one of you is actually authorized to use this name. Repository name doesn't necessarily change with IP or domain name change. But people sometimes do things without being authorized. And when they do, things break. I believe this is a reasonable expectation. The point is two-fold: 1) provide human readable visual ordering. Since global ordering really isn't possible, the only ordering that has any meaning is per-repository ordering. And that's what you're seeing. Might be useful, but couldn't this be done just as well with a "show ancestry" command? Dunno. Does monotone currently include information about which repository initially spawned a particular delta? I didn't notice anything like that in the manual, but I could easily have overlooked it. 2) providing unique id's. But only if everyone behaves themselves. Well, sure. And if they don't, we stop listening to them. The entire internet is a cooperative venture. Just getting IP packets from one side of the world to the other involves a lot of people trusting a lot of other people to behave themselves. If they didn't, the packets wouldn't flow. (And sometimes they don't.) I think serials on named repositories do address these points. This requires some sort of central authority to work. As I understand it, one of the features of monotone is that there doesn't have to be any such central authority. Different types of central authority. There is no single daemon running anywhere in the world whose lack of availability would stop this procedure from working. In that sense, there is no central authority. Monotone already relies conventionally on domain names for unique branch names. In this sense, monotone already relies on a central authority. If domain names and the attendant hierarchical delegation of naming authority are sufficiently decentralized and sufficiently unique for this purpose, I submit that the same mechanism is sufficiently unique and sufficiently decentralized to support repository naming. --rich ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] newbie question - SHA1 vs serials
Richard Levitte - VMS Whacker wrote: rich *Conclusion:* using /serial:repostory-name/ would probably rich require some level of security on a repository basis. Another conclusion is that your digging yourself into security-related problems that aren't needed in the first place. That's certainly possible. monotone does authenticate changes. Every revision in a monotone repository is signed with the committer's key. For that revision to be accepted in my database, I must tell my monotone process that I accept things signed with that key, of which I must have the public half. Understood. However, I can also see a desire to allow only those such changes which also come from a trusted place; that is, a refinement of what will be accepted. In message [EMAIL PROTECTED] on Tue, 19 Apr 2005 08:54:02 -0700, K. Richard Pixley [EMAIL PROTECTED] said: rich The same way monotone currently enforces branch naming. monotone doesn't enforce any branch naming. I can name my branches 'foo', 'bar', 'cookie' and 'oh-sexy-baby' if I wish to do so. It's not wise if I eventually want to share my development with others over a wide-spread network, but that's a different matter. So it's not monotone that enforces it, it's my wish to socialise with other developers. It's *recommended* to use your domain name in some sort of creative way, that's true. That's not enforcing, though... Exactly so. And naming of repositories could follow precisely the same procedure. If it's sufficiently unique and sufficiently distributed for use in branch naming, then I submit that it's sufficiently unique and sufficiently distributed for repository naming. rich Dunno. Does monotone currently include information about which rich repository initially spawned a particular delta? Nope, and that's not interesting. Every revision carries along the key identity of the committer, however. That's probably more interesting than the particular host the revision came from. I might care about the host as well. I learn a lot from determining whether you checked this change in initially from your laptop Macintosh or from your desktop freebsd box or from our hardware in development which happens to be an embedded arm running Linux. I also learn where to look if I want to complete a change someone else may have unintentionally committed incompletely. I also care if I want to track the geographic distribution of a particular revision. rich Monotone already relies conventionally on domain names for rich unique branch names. In this sense, monotone already relies on rich a central authority. Not really. A central authority is an entity that decides for the others what they should do. There's no such central authority for monotone per se. However, our intelligence helps us make decisions that helps the greater good (in this case, cooperation). In the case of branches, the monotone manual recommends to use a structure that's already in place for other purposes. Understood and agreed. If you think of a closed environment, like a software company, there's absolutely nothing saying they have to follow the recommended branch naming scheme. And the same would be true for repository names. If they later decided to share code with another company, and found that they had collisions on branch names or repository names, we'd simply write it off as short sightedness on their part. rich If domain names and the attendant hierarchical delegation of rich naming authority are sufficiently decentralized and sufficiently rich unique for this purpose, I submit that the same mechanism is rich sufficiently unique and sufficiently decentralized to support rich repository naming. I still believe you are needlessly tangling yourself in security issues that currently don't exist. Heard. I'm not currently a monotone user or developer. I like many of the features offered though I'm thinking SHAT1 for version id's is going to be a hard sell. --rich ___ 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
Don't Panic (was Re: [Monotone-devel] I'm sorry, I fscked up.)
On Tue, Apr 19, 2005 at 11:39:23PM +0200, Richard Levitte - VMS Whacker wrote: I have to appologise to everyone involved with the development of monotone. I've effectively stopped you from making any further updates, you are now locked to revision e018e6f9690d07166a0eecef6627493445db12ad as soon as it is in your database unless you do what I will describe below. Richard's sent some followups that clarified this a bit more, but just to make doubly sure: this is not nearly so bad of a problem as it sounds like above. The situation is: -- Monotone has a concept of a testresult cert. Monotone only cares about these certs in exactly one condition: when you type update with no argument, and it goes to guess which revision you would like to update to. The exact effect is controlled by a hook, but the default is that if your current revision has a passing testresult cert on it, monotone will only guess a revision that has a corresponding passing testresult cert on it. This is a somewhat underdeveloped and underdesigned bit of monotone -- more of a sketch of some desired functionality than an actually useful feature -- and no-one has ever used it intentionally so far as I know. It doesn't much hurt anything to leave it there until someone sits down to work out a better way, though. -- If you do not have a working copy in _exactly the revision_ that got the testresult, then its existence will effect you. Otherwise, it will have no effect at all. -- If you _do_ have a working copy in exactly the revision that got the testresult, unwedging yourself is trivial -- the next time you go to run update, you have to run update SOMEREV, instead of update. That's all. -- as a DoS method, it leaves something to be desired; if someone can write into your database, they'll have much more luck filling your disk with junk. (They won't have too much in any case, since once you realize what's going on, you revoke their write access, smite them, and then delete whatever isn't signed by actually trusted people.) Hope that helps calm down anyone who was freaking out about this :-). -- Nathaniel -- Lull'd in the countless chambers of the brain, Our thoughts are link'd by many a hidden chain: Awake but one, and lo! what myriads rise! Each stamps its image as the other flies -- Ann Ward Radcliffe, The Mysteries of Udolpho ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] bug after trying to drop a file
hi, i was playing with monotone following the tutorial i tried to drop file a/b/c/d/e, which -- i guess -- would have also drop empty directories a/b/c/d here are the commands i tried : [00:26:22][pts/1][~/treshautdebit][#86][0] [EMAIL PROTECTED] monotone drop a monotone: adding a to working copy delete set monotone: warning: SORRY -- 'drop somedir' is not going to work. monotone: warning: Revert and try 'find somedir -type f | xargs monotone drop' [00:26:46][pts/1][~/treshautdebit][#87][0] [EMAIL PROTECTED] monotone drop a/b/c/d/e monotone: fatal: std::logic_error: path_component.cc:53: invariant 'I(! null_name(*i))' violated monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to MT/debug [00:26:56][pts/1][~/treshautdebit][#88][0] [EMAIL PROTECTED] monotone drop a/b/c/d/e monotone: fatal: std::logic_error: path_component.cc:53: invariant 'I(! null_name(*i))' violated monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to MT/debug [00:27:05][pts/1][~/treshautdebit][#89][0] [EMAIL PROTECTED] monotone update monotone: fatal: std::logic_error: path_component.cc:53: invariant 'I(! null_name(*i))' violated monotone: monotone: this is almost certainly a bug in monotone. monotone: please send this error message, the output of 'monotone --full-version', monotone: and a description of what you were doing to [EMAIL PROTECTED] monotone: wrote debugging log to MT/debug [00:27:10][pts/1][~/treshautdebit][#90][0] [EMAIL PROTECTED] monotone --full-version monotone 0.18 (base revision: e8c9e4eb0534a4c6e538935576330de34ec42052) Running on: Linux 2.6.11-powerpc #1 Mon Apr 4 04:03:40 CEST 2005 ppc Changes since base revision: new_manifest [cbc23fa42b07e4f6f7d3a327c5eb1d4f4a782a75] old_revision [e8c9e4eb0534a4c6e538935576330de34ec42052] old_manifest [cbc23fa42b07e4f6f7d3a327c5eb1d4f4a782a75] Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. Generated from data cached in the distribution; further changes may have been made. I've attached MT/debug and MT/work. Thanks -- Benot Dejean JID: [EMAIL PROTECTED] GNOME http://www.gnomefr.org/ LibGTop http://directory.fsf.org/libgtop.html started up on Linux 2.6.11-powerpc #1 Mon Apr 4 04:03:40 CEST 2005 ppc command line: 'monotone', 'update' set locale: LC_CTYPE=fr_FR.UTF-8, LC_MESSAGES=fr_FR.UTF-8 initial path is /home/benoit/treshautdebit searching for 'MT' directory with root '/' search for 'MT' ended at '/home/benoit/treshautdebit' with '' removed initializing from directory /home/benoit/treshautdebit found working copy directory /home/benoit/treshautdebit options path is MT/options local dump path is MT/debug setting dump path to MT/debug opening rcfile '/home/benoit/.monotonerc' ... '/home/benoit/.monotonerc' is ok skipping nonexistent rcfile 'MT/monotonerc' executing update command options path is MT/options revision path is MT/revision loading revision id from MT/revision db.fetch(SELECT id FROM 'revisions' WHERE id = 'a23aee2cbf80acfe2483c5414347f5d3444722a5') db.fetch(SELECT data FROM revisions WHERE id = 'a23aee2cbf80acfe2483c5414347f5d3444722a5') old manifest is 3cc752f6d6eda18bb48da8e0ee39231e0966cd7d db.fetch(SELECT id FROM 'manifest_deltas' WHERE id = '3cc752f6d6eda18bb48da8e0ee39231e0966cd7d') db.fetch(SELECT id FROM 'manifests' WHERE id = '3cc752f6d6eda18bb48da8e0ee39231e0966cd7d') db.fetch(SELECT id FROM 'manifests' WHERE id = '3cc752f6d6eda18bb48da8e0ee39231e0966cd7d') db.fetch(SELECT data FROM 'manifests' WHERE id = '3cc752f6d6eda18bb48da8e0ee39231e0966cd7d') old manifest has 3 entries work path is MT/work checking for un-committed work file MT/work read rearrangement from MT/work empty restricted path set; 'a' included restriction includes delete dir a path_component.cc:53: invariant 'I(!null_name(*i))' violated delete_dir a ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug after trying to drop a file
In message [EMAIL PROTECTED] on Wed, 20 Apr 2005 00:32:58 +0200, Benoît Dejean [EMAIL PROTECTED] said: benoit.dejean i tried to drop file a/b/c/d/e, which -- i guess -- benoit.dejean would have also drop empty directories a/b/c/d benoit.dejean benoit.dejean here are the commands i tried : benoit.dejean benoit.dejean [00:26:22][pts/1][~/treshautdebit][#86][0] benoit.dejean [EMAIL PROTECTED] monotone drop a benoit.dejean monotone: adding a to working copy delete set benoit.dejean monotone: warning: SORRY -- 'drop somedir' is not going to work. benoit.dejean monotone: warning: Revert and try 'find somedir -type f | xargs monotone benoit.dejean drop' This is well known. As you noticed, everything you tried afterwards got screwed up. A very simple fix is to remove (or rename,just to be safe) MT/work, since it only contains the entry to delete a directory, and the try all the other stuff. I wouldn't recommend this as a long- term solution, but I think it'll have to do for now. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug after trying to drop a file
In message [EMAIL PROTECTED] on Wed, 20 Apr 2005 04:18:13 +0200 (CEST), Richard Levitte - VMS Whacker [EMAIL PROTECTED] said: richard In message [EMAIL PROTECTED] on Wed, 20 Apr 2005 00:32:58 +0200, Benoît Dejean [EMAIL PROTECTED] said: richard richard benoit.dejean i tried to drop file a/b/c/d/e, which -- i guess -- richard benoit.dejean would have also drop empty directories a/b/c/d richard benoit.dejean richard benoit.dejean here are the commands i tried : richard benoit.dejean richard benoit.dejean [00:26:22][pts/1][~/treshautdebit][#86][0] richard benoit.dejean [EMAIL PROTECTED] monotone drop a richard benoit.dejean monotone: adding a to working copy delete set richard benoit.dejean monotone: warning: SORRY -- 'drop somedir' is not going to work. richard benoit.dejean monotone: warning: Revert and try 'find somedir -type f | xargs monotone richard benoit.dejean drop' richard richard This is well known. As you noticed, everything you tried afterwards richard got screwed up. A very simple fix is to remove (or rename,just to be richard safe) MT/work, since it only contains the entry to delete a directory, richard and the try all the other stuff. I wouldn't recommend this as a long- richard term solution, but I think it'll have to do for now. Agh! Silly me. 'monotone revert a' fixes the problem. Time for me to go to bed, I think... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] newbie question - SHA1 vs serials
On Tue, Apr 19, 2005 at 11:56:32AM -0700, K. Richard Pixley wrote: Richard Levitte - VMS Whacker wrote: Nope, and that's not interesting. Every revision carries along the key identity of the committer, however. That's probably more interesting than the particular host the revision came from. I might care about the host as well. I learn a lot from determining whether you checked this change in initially from your laptop Macintosh or from your desktop freebsd box or from our hardware in development which happens to be an embedded arm running Linux. I also learn where to look if I want to complete a change someone else may have unintentionally committed incompletely. I'm currently doing exactly this with the current infrastructure, with author names of [EMAIL PROTECTED] and [EMAIL PROTECTED], etc. If more detailed information were required , it is very simple to just go : monotone cert thisrev dev-uname `uname -a` or monotone cert thisrev monotone-version `monotone --version` to add any information you want. I'm fairly sure this could be automated in the current commit hooks - if not, it might be worth adding there. Matt ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
