[Monotone-devel] Re: branch representation
Nathaniel Smith [EMAIL PROTECTED] writes: So the idea is: what if we got rid of branch certs, and put a branch field inside the revision object? So each revision is uniquely, irrevocably, in a single branch. So each revision is not just a snapshot, but a snapshot with a purpose attached. And instead of automatically putting a branch cert on at commit time, you put a yeah, this is good cert on (since the rev already has a purpose built in, your vague affirmation of goodness can be assumed to match that). I can't really follow what you mean with yea, this is good cert. Is that supposed to be a new kind of cert? it seems like the code and users both want to think of branch certs as at least somewhat special. I'm thinking of guess_branch, and update's tricky handling of branches, and netsync filtering by branch... I think a better way is to deemphasize the importance of the branch certificate. I think the concept that it is just a way to get to a revision is very powerfull. The reason I think monotone should by default add a branch certificate at commit time is convenience, nothing more. (Oh and it is a huge convenience.) This idea does add a significant new piece to the model -- instead of the nice clean DAG of snapshots _here_, and generic metadata mechanism _there_ setup, we have a piece of magic metadata, that needs to be handled differently, etc. I like this clear model. I don't think putting the branch inside the revision is going to solve anything. It will reduce the flexibility you have with branches and I don't see any inherit advantage. Also, I think that with the clean structure it has now, monotone is actually easier to grasp than most other VC systems. The hard thing when explaining monotone to others is let realize that it IS simple, making it more complex to alleviate that is the wrong direction IMO. Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Suggestion for new commit variant
People who read my mails might know that I feel sometimes limited by how monotone thinks. Most of it comes down to the fact that I don't have full freedom of arranging the underlying DAG. It just dawned on me that the following command would solve quite a few of my problems: monotone newcommit [-b branch] -parentrevs rev1 rev2 That is, I can commit a set of source files and explicitly specify the parent revisions. This would solve quite a few of my problems: 1 - merging outside of monotone's control: * Check out HEAD1 * Check out HEAD2 * Check out ANCESTOR * Do my merge on my tree * monotone newcommit -parentrevs HEAD1 HEAD2 2 - propagate does not mess up my tree: REV1 branch A \ \ REV2 branch B propagate B A wil change in: monotone newcommit -b branch A -parentrevs REV1 REV2 to yield which results in: REV1 REV3 branch A --- branch A \/ \ / REV2 branch B 3 - I can do an explicit dissapprove REV1 - REV2 branch A branch A / / namely checkout REV1 and do: monotone newcommit -parentrevs REV1 REV2. DISCLAIMER -- This just occured to me, so it might be totally unworkable, if so please let me know. Also, I will be away without any internet access until beginning next week. So I hope I have some reading up to do when I return :-) Wim Oudshoorn. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Suggestion for new commit variant
On Thu, Oct 27, 2005 at 08:55:30AM +0200, Wim Oudshoorn wrote: monotone newcommit [-b branch] -parentrevs rev1 rev2 That is, I can commit a set of source files and explicitly specify the parent revisions. I've been thinking it might be nice to have some sort of explicitly controlled commit command for use in automation, that let you specify all the pieces explicitly instead of having to set up a tree, play nice with the commit editor, etc. A problem with this solution is that you need more than a set of files; you need the changeset from each parent. If there are no renames, the changeset can be derived from the set of files, but... that's a special case, and we should be consistent. This would solve quite a few of my problems: 1 - merging outside of monotone's control: * Check out HEAD1 * Check out HEAD2 * Check out ANCESTOR * Do my merge on my tree * monotone newcommit -parentrevs HEAD1 HEAD2 Merge in working copy is on the TODO list anyway, and the new merge code in the rosters branch should make it much easier to implement. (The current merge code has a baked-in assumption that each conflict is resolved before it continues merging the next part of the tree, which is hard to fix without rewriting everything. Avoiding this is one of the explicit goals of the roster merger.) 3 - I can do an explicit dissapprove REV1 - REV2 branch A branch A / / namely checkout REV1 and do: monotone newcommit -parentrevs REV1 REV2. You want to read the links I posted about disapprove earlier -- they explain why disapproving over a merge is not just a random thing we left out, but an actively bad idea, that doesn't give you the behavior you want. (The key example is A / \ B C \ / D / \ B' C' where B' = B and C' = C, and are created by disapproving D. merge(B', C') does not give you D again; rather, it gives you A (!). See the IRC log for full discussion.) -- Nathaniel -- When the flush of a new-born sun fell first on Eden's green and gold, Our father Adam sat under the Tree and scratched with a stick in the mould; And the first rude sketch that the world had seen was joy to his mighty heart, Till the Devil whispered behind the leaves, It's pretty, but is it Art? -- The Conundrum of the Workshops, Rudyard Kipling ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Suggestion for new commit variant
On Thu, Oct 27, 2005 at 01:00:30AM -0700, Nathaniel Smith wrote: On Thu, Oct 27, 2005 at 08:55:30AM +0200, Wim Oudshoorn wrote: monotone newcommit [-b branch] -parentrevs rev1 rev2 That is, I can commit a set of source files and explicitly specify the parent revisions. I've been thinking it might be nice to have some sort of explicitly controlled commit command for use in automation, that let you specify all the pieces explicitly instead of having to set up a tree, play nice with the commit editor, etc. A problem with this solution is that you need more than a set of files; you need the changeset from each parent. If there are no renames, the changeset can be derived from the set of files, but... that's a special case, and we should be consistent. Hrm, on re-reading, this is ambiguous, sorry. What I mean is that I like the idea in general (first paragraph), but the version of it you describe is missing something (second paragraph). So the this solution in the second paragraph actually refers to what you were saying, not what I was just saying... -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone disapprove does not give correct branch cert
On Wed, Oct 26, 2005 at 08:59:27PM +0200, Wim Oudshoorn wrote: The only model I see now in branches is that branch is a set of revisions sharing a branch certificate. I miss the single origin and the continuity :( That is just my mental model and it is working perfectly. yup. Below I will outline my mental model of what monotone does or should do. Keep in mind that this is JUST my mental model and monotone might do things differently. I will still talk as if monotone works the way I expect, so take it with a grain of salt ;-) I'll try to add some salt from my mental model, then. Forgive me for extensive quoting, I don't want to lose your details as context. MENTAL MODEL (1) The revisions are a simple direct acyclic graph. Not necessary connected. That is: * You have revisions, which are nodes in a graph. A revision correspond to a collection files/directories with a certain content. However the content does NOT uniquely identify a revision. Yes, because the ancestor id is part of the revision, and provides the edit-graph structure. * You have arrows between revisions. Such that there is at most one arrow between two revisions, and you can not return to you'r starting point when you walk the arrows. Yes. These arrows construct the ancestry graph, which represents the editorial history of changes. They also happen to correspond to deltas that store the actual edits made across that edge, but that's not important to this view of the model (you could store each revision in complete form and derive the diffs later instead, if you wanted). Furthermore, there are smaller per-file deltas and graphs that are usually not seen, and are also not important here. (2) Now on these revisions you add some extra data, the certificates. These certificates are not fundamental for the working of monotone. Yes. A common parlance for such things is decoration, or annotation. Certificates add descriptions or attest to statements about revisions. Now the the combination with version control for me is the following: (A) The branch label (or certificate) is used to group revisions together, in some conceptual group of versions (revisions). This group has some identity that stays the same over time. Namely it is a version of the software product you are developing. Note: This label is JUST a convenience label, to make the monotone user interface easy to use. Yes. (B) The edges/arrows between the revisions I use to indicate that one version/revision of the software supercedes another revision. so Rev 1 --- Rev 2 means I think Rev 2 is better than Rev 1, that is the only thing it does. Hm. I'm not entirely certain that even this much interpretation should be ascribed to a revision. I think all this shows is that Rev 2 was an edit made to Rev 1. Good, bad or other interpretations should be described by certificates - and all may change over time or be subjective. One important thing I want to stress here is the fact that for me 'branch' and 'arrow' (being better) are not related at all, they are orthogonal properties. Certainly. So I can easily have: Rev 1 Rev 2 branch A branch B And I still think Rev 2 is better than Rev 1, although the are in different branches. Not really about the 'better' part, as above. It's just edit history.. Rev 2 might be very much worse, by many criteria. The only sense of better than really applies is has had more work done on it, even if that work ends up being bad work. It might be the very first step of a rewrite of a subsystem, where all you've done is rip out the old (working, but a little grotty) implementation in preparation for replacing it with further work. You make statements to this effect by decorating the revisions with certs, especially branch certs. Firstly, by giving B a name that indicates its experimental nature - and secondly by *omitting* the A cert. This part you clearly have right, as below. EXAMPLE I decided to have my source files for version 1.2.9 of my project XYZ grouped together under the branch name XYZ-1.2.9 and the source files for version 1.3.4 of my project XYZ grouped together under the branch name XYZ-1.3.4 A small nit, related to usage and terminology rather than to concepts. These kinds of names for project versions are usually releases, and represented by tags, rather than branches. A branch is often used to maintain a stable copy of the code for critical fixes, before and after the actual release point, and those branches are often named similarly. My only point here is that to explain these concepts very clearly you need to use names and examples that very clearly illustrate the separation between these things, lest users become confused. It can take
[Monotone-devel] Bug in monotone automate inventory
monotone automate inventory crashes. It is the first time that I have run that command since upgrading from version 0.19 to 0.23, I did remember to run the db migrate against the database. I have been checking out, propagating and merging succesfully since the update. Output of the command: monotone automate inventory monotone: fatal: std::logic_error: paths.cc:209: invariant 'I(is_valid_internal(data()))' violated monotone: 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] Full version: monotone 0.23 (base revision: e32d161b8d5cde9f0968998cc332f82f82c27006) Running on: Linux 2.6.8-24.16-default #1 Thu Jun 2 12:09:57 UTC 2005 i686 Changes since base revision: new_manifest [68895899b164e1f443f988efef93e8384f1b182a] old_revision [e32d161b8d5cde9f0968998cc332f82f82c27006] old_manifest [68895899b164e1f443f988efef93e8384f1b182a] 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. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug in monotone automate inventory
On Thu, Oct 27, 2005 at 10:33:12AM +0100, Ian France wrote: monotone automate inventory monotone: fatal: std::logic_error: paths.cc:209: invariant 'I(is_valid_internal(data()))' violated Are you, by chance, running 'automate inventory' from inside the MT/ directory of a working copy? There was a bug in 0.23 (fixed in mainline) that would cause many operations to fail if monotone's initial working directory was an MT/ directory. If not, would it be possible to send the output of running the offending command with --debug? -- Nathaniel -- The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug in monotone automate inventory
Are you, by chance, running 'automate inventory' from inside the MT/ directory of a working copy? There was a bug in 0.23 (fixed in mainline) that would cause many operations to fail if monotone's initial working directory was an MT/ directory. No, I'm afraid not. I have also found that I get the same error when running: monotone list unknown and monotone list ignored. If not, would it be possible to send the output of running the offending command with --debug? Here it is (slightly edited to avoid lots of repetition) monotone: started up on Linux 2.6.8-24.16-default #1 Thu Jun 2 12:09:57 UTC 2005 i686 monotone: command line: 'monotone', '--debug', 'automate', 'inventory' monotone: set locale: LC_ALL=en_GB.UTF-8 monotone: initial abs path is: /home/ifrance/scratch/recruitPlus/client monotone: initializing from directory /home/ifrance/scratch/recruitPlus/client monotone: searching for 'MT' directory with root '/' monotone: 'MT' not found in '/home/ifrance/scratch/recruitPlus/client' with '' removed monotone: search for 'MT' ended at '/home/ifrance/scratch/recruitPlus' with 'client' removed monotone: working root is '/home/ifrance/scratch/recruitPlus' monotone: initial relative path is 'client' monotone: options path is MT/options monotone: branch name is 'uk.co.fcomsrv.recruitplus' monotone: local dump path is MT/debug monotone: setting dump path to MT/debug monotone: Lua::ok(): failed = 0 monotone: opening rcfile '/home/ifrance/.monotone/monotonerc' ... monotone: Lua::ok(): failed = 0 monotone: '/home/ifrance/.monotone/monotonerc' is ok monotone: skipping nonexistent rcfile 'MT/monotonerc' monotone: executing command 'automate' monotone: options path is MT/options monotone: revision path is MT/revision monotone: loading revision id from MT/revision monotone: prepared statement SELECT id FROM revisions WHERE id = ? monotone: binding 1 parameters for SELECT id FROM revisions WHERE id = ? monotone: binding 1 with value '571d4b65a8bbb5ba5209ddf878c966eabcb50b76' monotone: prepared statement SELECT data FROM revisions WHERE id = ? monotone: binding 1 parameters for SELECT data FROM revisions WHERE id = ? monotone: binding 1 with value '571d4b65a8bbb5ba5209ddf878c966eabcb50b76' monotone: old manifest is ffa850affb08f3ec5f469616bd1cfe5fe89025e1 monotone: prepared statement SELECT id FROM manifest_deltas WHERE id = ? monotone: binding 1 parameters for SELECT id FROM manifest_deltas WHERE id = ? monotone: binding 1 with value 'ffa850affb08f3ec5f469616bd1cfe5fe89025e1' monotone: prepared statement SELECT id FROM manifests WHERE id = ? monotone: binding 1 parameters for SELECT id FROM manifests WHERE id = ? monotone: binding 1 with value 'ffa850affb08f3ec5f469616bd1cfe5fe89025e1' monotone: binding 1 parameters for SELECT id FROM manifests WHERE id = ? monotone: binding 1 with value 'ffa850affb08f3ec5f469616bd1cfe5fe89025e1' monotone: prepared statement SELECT data FROM manifests WHERE id = ? monotone: binding 1 parameters for SELECT data FROM manifests WHERE id = ? monotone: binding 1 with value 'ffa850affb08f3ec5f469616bd1cfe5fe89025e1' monotone: old manifest has 750 entries monotone: work path is MT/work monotone: checking for un-committed work file MT/work monotone: read rearrangement from MT/work monotone: restriction includes add file common/src/fcomsrv/rpCommon/event/EventDefinition.java monotone: loading lua hook get_linesep_conv monotone: lua failure: isfunction() in get_fn; stack = nil monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_charset_conv monotone: lua failure: isfunction() in get_fn; stack = nil monotone: Lua::ok(): failed = 1 monotone: concatenating change sets monotone: concatenating 750 and 1 deltas monotone: processing delta on .mt-attrs monotone: delta on .mt-attrs in first changeset renamed to .mt-attrs monotone: processing delta on build.xml monotone: delta on build.xml in first changeset renamed to build.xml monotone: processing delta on client/.cvsignore monotone: delta on client/.cvsignore in first changeset renamed to client/.cvsignore monotone: processing delta on client/README monotone: delta on client/README in first changeset renamed to client/README --- snip --- This continues in the same vein for what seems to be all the files in my project. --- snip --- monotone: delta on common/src/fcomsrv/rpCommon/event/EventDefinition.java in second changeset copied forward monotone: finished concatenation monotone: loading lua hook get_linesep_conv monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_charset_conv monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_linesep_conv monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_charset_conv monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_linesep_conv monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_charset_conv monotone: Lua::ok(): failed = 1 monotone: loading lua hook get_linesep_conv monotone: Lua::ok(): failed = 1 monotone:
Re: [Monotone-devel] Bug in monotone automate inventory
Hi Nathaniel, I took a moment out of java programming to add some logging statements to the monotone code and discovered the problem. I had somehow managed to create a file with the name '^G' i.e. 0x07. Monotone was rejecting this (quite reasonably) as an illegal filename. Sorry to have bothered you with this triviality and thank you for your swift response. Ian. Nathaniel Smith wrote: On Thu, Oct 27, 2005 at 10:33:12AM +0100, Ian France wrote: monotone automate inventory monotone: fatal: std::logic_error: paths.cc:209: invariant 'I(is_valid_internal(data()))' violated Are you, by chance, running 'automate inventory' from inside the MT/ directory of a working copy? There was a bug in 0.23 (fixed in mainline) that would cause many operations to fail if monotone's initial working directory was an MT/ directory. If not, would it be possible to send the output of running the offending command with --debug? -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone-viz oddities again?
Richard Levitte - VMS Whacker [Wednesday 26 October 2005] : In message [EMAIL PROTECTED] on Wed, 26 Oct 2005 10:53:17 +0200, Olivier Andrieu [EMAIL PROTECTED] said: oliv__a Richard Levitte - VMS Whacker [Wednesday 26 October 2005] : oliv__a oliv__a richard I just noticed that I'm currently getting a oliv__a richard disconnected graph in monotone-viz. Am I alone oliv__a richard in this? Olivier, can you remind me how to oliv__a richard generate some debugging output for you? oliv__a oliv__a Yes I've noticed this. Actually it's because the graph is no oliv__a more disconnected. Someone did a commitmerge on a rather old oliv__a revision (from august) which had effect on reconnecting what oliv__a was previously two components. I'm not sure what I could do oliv__a to fix the layout. OK, so if understand correctly, checking for other possible paths is only done when there's a disconnection in the graph, correct? Yes. I understand why you don't do that for all nodes, as I can imagine the time spent would not make it worth it. However, here's an idea: regard apparent leaves as a possible disconnection, and check if monotone really regards them as leaves. If not, they should be treated as a graph disconnection. Hmm ok, I'll try that. I also noticed that the current real leaf doesn't stay at the bottom for the moment (because of the disconnected behavior). While I like the more compact display, in the current situation, it's really confusing to have the real leaf somewhere in the middle of the graph... Monotone-viz puts leaves at the bottom of the graph. If it's in the middle, that's probably because there is a propagate from this revision to another branch. -- Olivier ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone-viz oddities again?
Bruce Stephens [Wednesday 26 October 2005] : Olivier Andrieu [EMAIL PROTECTED] writes: I'm not sure what I could do to fix the layout. Or just don't show the whole graph: show the last six months or something. I'm not sure that would work in this case, but it would reduce the size of the graph. This is planned ! It just need to finish the UI for this (real-soon-now). -- Olivier ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Debian Bugs information: logs for Bug#319116
On Thu, Oct 27, 2005 at 07:33:20PM +0200, Richard Levitte - VMS Whacker wrote: Actually, considering it says 13 (!) UTF-8 characters were incorrect, I doubt the plus symbol had anything to do with it. [...] sjackman $ monotone --db=./monotone.db genkey [EMAIL PROTECTED] sjackman monotone: misuse: error converting 13 UTF-8 bytes to IDNA ACE: non-LDH characte $ echo -n 'claw+monotone' | wc -c 13 The part before and after the @ are handled differently, since i18n domain names have special mangling magic just for them. But as noted, + was added as a legal character back in July, somewhere around the 0.21 release (so I don't know if 0.21 had it without more spelunking, but 0.22 and 0.23 definitely did). BTW, I'm not, offhand, _too_ impressed by the idea of allowing arbitrary text. If Bob Jones [EMAIL PROTECTED] and Rob Jones [EMAIL PROTECTED] are different keys, is anyone going to notice? If you're talking over some channel (IRC or face-to-face or whatever), are you going to paste the whole thing to make sure to be unambiguous? Monotone does a lot of low-profile work behind the scenes to try and make sure informal channels like that work out to have nice security properties without anyone having to really think about it or do anything special, and I'm worried that allowing more free-form, multi-part key names hurt that. -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bug in monotone automate inventory
On Thu, 2005-10-27 at 19:57 +0200, Jon Bright wrote: Emile Snyder wrote: No, this is clearly a bug in monotone. You created a legal file on your system in the working copy, and monotone choked and died. Thanks for digging and figuring it out, An interesting question - should monotone allow you to create any old filename, or should it restrict you to names with half a chance of being cross-platform compatible? I'd argue for at least the default to be the latter, on the grounds that I have no real opinion on this point; I was just saying that 'monotone ls unknown' should *never* die because of the name of any unknown file. If we can't print some filename as is, then we should escape characters in some appropriate way (handwaving here). When you try to 'monotone add' a file like that, it should perhaps disallow it (with some nicer error like 'monotone cannot handle control characters in filenames, not adding filename containing 0x07'), but again, shouldn't dump with an invariant triggered. thanks, -emile a) Almost no-one really, really wants that file to be called that (as in this case) b) Otherwise, monotone gets to play fun games when it tries to check that file out on a system that doesn't support that as a filename... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com 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
[Monotone-devel] Re: monotone-viz oddities again?
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 17:05:44 +0200, Olivier Andrieu [EMAIL PROTECTED] said: oliv__a Monotone-viz puts leaves at the bottom of the graph. If it's oliv__a in the middle, that's probably because there is a propagate oliv__a from this revision to another branch. Ah, that's exactly it. Interesting... Oh, I see. I assumed you were complaining about the same thing I was, that although 7e8d1d331d6fd71d84b0db6b48de9265371b6541 is visible (right at the bottom), its ancestors are way up the display somewhere. That feels suboptimal to me. If I run monotone-viz in a working copy at some revision (or if I specify a revision), then I'm likely to be interested in the ancestors and descendents of that revision. In outline I think that's fairly easy to fix: set the weight of the immediate edges from the revision to 2. I haven't worked out how to code it yet; OCaml's not my language. Obviously the same idea generalises, but I don't know what a suitable rule would be for choosing the edges to mark. [...] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: monotone-viz oddities again?
In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 21:30:47 +0100, Bruce Stephens [EMAIL PROTECTED] said: monotone Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes: monotone monotone In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 17:05:44 +0200, Olivier Andrieu [EMAIL PROTECTED] said: monotone monotone oliv__a Monotone-viz puts leaves at the bottom of the monotone oliv__a graph. If it's in the middle, that's probably monotone oliv__a because there is a propagate from this revision monotone oliv__a to another branch. monotone monotone Ah, that's exactly it. Interesting... monotone monotone Oh, I see. I assumed you were complaining about the same monotone thing I was, that although 7e8d1d331d6fd71d84b0db6b48de9265371b6541 monotone is visible (right at the bottom), its ancestors are way up monotone the display somewhere. Ah, no, but you didn't have a chance to see what I see before now. Just pull and look again and you'll see what I mean (unless someone else pushes something new...). 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] Re: monotone-viz oddities again?
In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 22:59:21 +0100, Bruce Stephens [EMAIL PROTECTED] said: monotone Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes: monotone monotone [...] monotone monotone Ah, no, but you didn't have a chance to see what I see monotone before now. Just pull and look again and you'll see what monotone I mean (unless someone else pushes something new...). monotone monotone Ah, I see. Now 7e8d1d331d6fd71d84b0db6b48de9265371b6541 monotone isn't regarded as a leaf, because it's been propagated to monotone another branch. monotone monotone And that's likely to be common (and *is* common, looking at monotone the graph), so regarding all such branch-crossings to be monotone leaves wouldn't work. Absolutely, it has happened more than once. However, the visual oddity that you see right now hasn't been visible before, because we don't have a disconnected graph very often, so we usually see the leaf at the bottom, propagates or not. So it's not really as much of a problem as the current disconnectedness. 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] call for IRC logs
On Thu, 2005-10-27 at 12:53 -0700, Emile Snyder wrote: Hi all, The loglibrary.com website which was logging the monotone irc channel at irc.oftc.net stopped accepting new data awhile ago. It logged the #monotone channel from February 24 - September 6. The nice folks at colabti.de have started logging for us recently ( http://colabti.de/irclogger/irclogger_logs/monotone ) and I would like to get all the historical data up on their site as well so there's a single point to search from. I've got the data off of loglibrary.com, but would like to ask if anyone has channel logs from before or after the period loglibrary covers. Also, the logs for 2005/03/13, 2005/04/12, 2005/04/13, 2005/08/16, 2005/08/17, 2005/09/01 are empty on loglibrary, so if you have any of them, or one day on either side, that would be appreciated as well. If you can get me logs from any of these non-covered periods I'll try to get them in the right form for the new site and uploaded. If you're sending me more than a 100K or so, please use [EMAIL PROTECTED]; the alumni account dumps large attachments. A week or so of logs (from scrollback) ending 2005-10-03 (140KB): https://netfiles.uiuc.edu/brownawe/www/irclog.txt Logs from 2005-10-14 through now (from XChat logging) (410KB): https://netfiles.uiuc.edu/brownawe/www/OFTC-%23monotone.log Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
