[00:00] but it's actively bad, just poorly performant [00:00] mwhudson: Yeah. [00:00] mkanat: i guess i'd say it's ok as it is [00:00] Race conditions and bug fixes that don't always work make me feel icky. [00:00] Objectively, it's an improvement over hte current situation, but.. [00:00] mkanat: maybe put a comment in? [00:01] mwhudson: That seems reasonable. [00:01] or maybe try the extra lock and see how performance goes? [00:01] mwhudson: Sure, I'll try the second lock. [00:03] mwhudson: It has no noticeable effect on performance (within the margin of error of my tests). [00:04] Could Loggerhead still get killed by a bunch of different caches being built at once? [00:04] Peng: That's what we're going to see. [00:05] Peng: That problem didn't actually happen in the hang logs--it was always the building of a graph for the same project over and over. [00:05] Huh. [00:06] mkanat: Ah, I see what you wrote on the bug. [00:06] OK. [00:08] Okay, pushed a new version. [00:09] Hmm, the preview diff doesn't include my newly-pushed commit? [00:09] it takes a minute [00:09] to update [00:09] Ah, okay. [00:09] minute==little while, not precisely a minute [00:10] the cronjob runs every minute now actually [00:10] This is getting excessively pedantic, but should the new lock use a try...finally too? :D [00:11] (The answer is probably no!) [00:11] i reviewed the branch [00:11] Peng: Yeah, no. :-) [00:11] it's lunchtime though [00:11] Peng: I don't think anything in there can throw an exception. [00:11] Peng: want to land if if you're happy with it? [00:11] mkanat: well anything _can_ fail (consider memoryerror) [00:11] but.... [00:11] oh no [00:11] Yeah. [00:11] Oh no? [00:12] hm [00:12] we have this thread killer in launchpad [00:12] so we should be really paranoid i think [00:12] Given the consequences (LH would basically die), paranoid sounds good to me. [00:12] i can't see why a thread would have only got this far in 300 seconds or whatever [00:12] but what Peng says [00:13] jam, does https://bugs.edge.launchpad.net/bzr/+bug/507040 suggest anything to you? [00:14] mwhudson: Okay. [00:14] Launchpad bug 507040 in bzr "NoSuchRevision during "bzr check"" [Medium,Confirmed] [00:14] With that change, I'd be happy to land it. [00:14] * mwhudson vanishes for a bit [00:14] Peng: thanks [00:15] Okay, pushed. [00:16] AnnotateUI is still really slow. [00:16] But everything else is fast. [00:16] And "really slow" now is 11 seconds, not 120. [00:16] mkanat: Awesomesocks, thanks. [00:18] 2x users = 5x time. [00:20] Pushing now. [00:22] Peng: Once it's live, an easy way to test would be to open several tabs that would all build a revision graph cache at once, for one branch. [00:22] Peng: That seems to be what people were doing that caused the hangs. [00:23] Peng: It has to be on a huge branch though, like launchpad or bzr itself or mysql. [00:24] Mm. [00:25] It's totally _possible_ for someone to do the same thing to several different branches of LP or MySQL, just even less likely./ [00:26] Peng: Yeah. And also, that's a level of concurrency that loggerhead should validly handle. [00:26] Peng: Whereas buliding multiple revision graph caches for the same branch is something that's never necessary. [00:27] Peng: If we see problems across multiple projects, then we can switch to a global semaphore around the per-branch lock. [00:27] Peng: The problem then is that we have to make some judgement about how many caches it's OK to build simultaneously, which we can't really know, and that gets into needless configuration by the admin, and so on. [00:29] Plus, it would be a shame to block everyone building a little cache as well. [00:33] BBIAB -- Hopefully we didn't just blow anything up. [01:05] Yay, nothing exploded. [01:06] Yay. :-) [01:06] Now we see if the hangs keep happening. [03:27] poolie: bug #507040 looks to me like a missing inventory that is expected to be there [03:27] Launchpad bug 507040 in bzr "NoSuchRevision during "bzr check"" [Medium,Confirmed] https://launchpad.net/bugs/507040 [03:27] which hints at a stacking issue [03:27] but it isn't something I've specifically seen === tchan1 is now known as tchan === thumper is now known as the-watcher [03:54] Is there documentation about how bzr works internally? The object format... are full files stored or just deltas. [03:54] Both. === the-watcher is now known as thumper [03:55] Peng, where? [03:55] Err, i was answering the second question. :P [03:55] It mainly uses deltas, but occasionally throws in a fulltext to keep performance up. [03:55] Oh. [03:56] magcius: there's some docs in the doc/developers directory [03:56] (or http://doc.bazaar.canonical.com/bzr.dev/developers/) [03:57] magcius: but they are far from complete on this sort of topic :/ [04:52] hi, how do i get combined diff (without using revision numbers) after some "local commits" in a "bzr checkout" directory? [04:56] Hmm, possibly "bzr diff :bound" ? [04:58] spiv: no, it didn't work :( [05:05] You'd probably need something more like 'bzr diff -rancestor::bound..' I'd guess. [05:10] spiv: Did you get the e-mail that contained my bzr logs? It was sent a while ago. [05:11] StevenK: hmm, I think so yes [05:50] when I make a merge directive, will it contain my log messages that I committed locally with? [05:51] or does the patch simply forget them and treat em all as one change? [05:51] yes, no [05:51] oh, so from the merge directive, how can I see/extract the log messages? [05:51] will it automatically happen when I merge? [05:51] yes [05:52] ah, great. Out of curiosity, is it possible to view them prior to that? [05:52] don't know, sorry [05:53] ok, that's fine. Thanks [06:03] how can I temporarily set my HEAD to an older revision. (not revert, I don't want uncommitted changes) [06:03] sort of like a svn update -r [06:05] bzr branch -r old-thing [06:05] Sorry, “bzr branch -r current-branch old-revision”. [06:05] won't that make a new branch? [06:06] scorp007: if you have a recent bzr 2.1, you can use update -r [06:06] otherwise I must make a new branch each time? [06:07] poolie: Interesting. How does that handle allowing you to get back to your old branch? [06:07] raof, it only sets the working tree back to an old revision, it doesn't change the branch [06:07] so plain update will take you back to the tip [06:07] Hm. That could be useful, yah. [06:08] so scorp's question is a bit contradictory: it fulfils the aspect of being like svn update [06:08] poolie: the exit button in tribunal-view-subunit is greyed out for me. [06:08] yes :) [06:08] it is a placeholder for useful tb buttons [06:08] i saw your mail [06:08] ok [06:08] I wasn't sure if it was just me :( [06:08] s/(/) [06:08] i don't think it's good for gui programs to default to reading stdin [06:09] cos it tends to make them just sit there waiting for stuff [06:09] poolie, I'm not sure I understand. [06:09] lifeless: you should use that as the title for your memoirs. [06:09] i'd be happy to have it understand '-' as an argument though [06:09] poolie: oh, ok. I did that because of the module docstring. [06:09] I made a new branch as a copy from my main one -- I want to simulate a merge using a merge directive [06:09] s/(/) [06:09] but my copy is alreadt at the latest verison [06:09] poolie: 'Reads a subunit stream from stdin ...' - I figured it was a bug I was fixing for you :) [06:10] heh [06:10] anyhow i'll look at merging it [06:10] poolie: yeah, - would be better. [06:11] i'd like to eventually give it commands to open files and to run subprocesses [06:11] poolie: what I /wanted/ was for no-args to not crash with an IndexError, and to put in the testrepository support [06:11] :-) [06:11] as another comment notes, reading from a pipe will suck a bit until it's done asynchronously [06:11] I'm going to have dinner with scott, see you tomorrow [06:11] poolie: if you want code to read from a pipe asynchronously in gtk [06:11] oh ok [06:11] say hi for me please [06:12] poolie: see subunit2gtk - it has code to do that. [06:12] ok [06:12] feel free to liberate and repurpose to your hearts desie [06:12] s/ie/ire/ [06:12] mneptok: econtext [06:12] k [06:13] * lifeless is gone [07:12] thanks for the imports spiv [07:30] hi all ! [07:39] hi vila [07:39] hey poolie ! [08:00] <_Andrew> Is there something like svn's propset in bzr? I want to insert the revision number into a file [08:03] _Andrew: http://wiki.bazaar.canonical.com/KeywordExpansion [08:32] vila, circular imports are hurting me :/ [08:32] where ? [08:32] i want to set ui.ui_factory to be an instance of the TextUIFactory [08:32] but that's declared in a submodule of ui of course [08:33] hmm, setting a global instance is always tricky, generally you need to involve a call somewhere to add some lazyness in the loop [08:34] If you can't.... you need to rethink your design :D [08:35] mm [08:52] good night [09:42] heya bzr [09:48] hi bialix [09:48] hi vila [09:51] vila: I'm fairly sure my solution worked. I have pushed the clean branch to our repository. [09:51] vila: it seems to merge cleanly with other related branches, which is the main test. [09:51] (if I'd done it wrong, merges would be expected to cause conflicts) [09:51] http://instantrimshot.com/ [09:51] vila: I'm just writing up a report for the mailing list, although I have plenty of work to do so I might not email it for a day or two. [09:52] quicksilver: great ! as long it comes in, I'm happy [09:52] f/win29 [09:52] bah === loxs_wrk is now known as loxs === mrevell is now known as mrevell-lunch [13:01] hi! I want to implement central shared repository. How could I prevent someone will delete the repository? Thx === jkprg_ is now known as jkprg === gnomefreak is now known as thunderstrck === thunderstrck is now known as gnomefreak === gnomefreak is now known as gnomefreak76 === gnomefreak76 is now known as gnomefreak === gnomefreak is now known as gnomefreak76 === gnomefreak76 is now known as gnomefreak === mrevell-lunch is now known as mrevell [14:19] hi guys, if i have a branch with a working tree, and i want to create a "central" branch with no working tree from that branch, how do i do that? [14:21] davertron: 'bzr push' or 'bzr branch --no-tree" [14:21] bzr: ERROR: no such option: --no-tree [14:22] What version of bzr are you using? [14:22] i'm using 1.12 [14:22] maybe too old? [14:22] Ancient [14:22] figures [14:37] Hi, right now I have an SVN repository with tons of data (and over 5k revisions), I'm willing to change to BZR, but I'm not sure how to deal with access control. Could someone give me some guidance please? [14:38] wundo: really the only way to deal with access control is to do it at the system level. [14:39] wundo: due to the distributed nature of DVCS, commit-access isn't as much of an issue at the repo level (since everyone gets their own repo). [14:39] so the only way to really stop write access is to do so at the system level. [14:40] I'm willing to use bzr with a centralized workflow... And I'm willing to prevent people from reading certain directories too, not only writing. [14:41] I don't think bzr works well with people only having access to certain directories? [14:42] in my experience you always get a whole branch. [14:42] exactly [14:42] if you're looking for per-directory/per-file permissions, you'd have to split up the repo [14:42] bzr doesn't allow for partial checkouts [14:43] hmm... [14:44] Hi! Do I see this correctly that there is no "commit --amend" for bzr, as there is for git, and that I'd have to uncommit and commit manually to get a similar effect? [14:44] If so, would you agree that this would be a nice feature to have, should be feasible, and would warrant a request for enhancement in lp? [14:45] MvG: you are correct there is no commit --amend [14:45] there has been debate IIRC about that feature. [14:46] another question, most of the people work from our office, is possible to have an local mirror from the central repository where the people can commit/checkout their code without using our internet connection? [14:47] yes [14:47] this is how bzr was designed [14:47] they each can have their own repo as a copy of the "central" branch [14:48] rubbs: There was some discussion back in 2007 for editing the comment: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/21558 [14:50] I mean, there are 5 people in our LAN, but our internet connection is off... assuming user A has new changes he wants to share it to user B. Could he commit to a local server from which user B can checkout and when the internet is back on the local server seamless synchronizes with the external server? [14:50] MvG: I am not a dev... but as I recall the biggest problem with doing an amend is that changing history at all can screw up with some other people's things. [14:50] wundo: yes [14:50] wundo: you can push and pull to different locations [14:50] rubbs: As can uncommit, and it's still there, and I'm glad it is. Rule is, once you pushed something, then changing it can cause divergence. Nothing new there. [14:51] rubbs: any how to setup it available? [14:51] wundo: when you branch from the central repo,bzr would remember that repo, but you could tell it to pull, push , or merge from another one quite easily. [14:51] wundo: http://doc.bazaar.canonical.com/bzr.2.0/en/ [14:51] check them out that might help [14:52] MvG: good point [14:52] MvG: you could try requesting it again. [14:52] Will do so. [14:53] wundo: if you are looking for a pseudo-centralized workflow check out this: http://doc.bazaar.canonical.com/bzr.2.0/en/tutorials/centralized_workflow.html [14:53] uncommit loses the commit message though I think? [14:53] minor disadvantage of it. [14:54] quicksilver: yes, it does... that's why he want's an ammend. [14:54] amend* [14:54] * quicksilver nods [14:54] morning vila, rubbs and quicksilver [14:54] morning jam. [14:54] quicksilver: I thought there was a hook that preserved uncommit [14:54] check with vila / qbzr [14:54] mornign jam [14:54] you're more likely to be right than me jam ;) [14:54] the very very long message I'm writing to the bzr mailing list does mention this point as an aside. [14:55] I don't think 'bzr commit' defaults to reusing it, but certainly "bzr qcommit" can remember something [14:55] AFAIK both bzr-gtk and qbzr saves commit/uncommit messages in branch.conf [14:55] Morning === salgado is now known as salgado-lunch [14:56] MvG: wundo: I have to go to a meeting, but others here can help if you have any other questions. [14:56] another trick is to have a qlog running around and copy/paste from there [14:56] thanks rubbs [14:57] still is not an one hour decision to change a whole company VCS :P [14:57] I will probably be here when you come back... [14:57] I'm also copy and pasting from console output, but that's not nice. Writing a lp whishlist item for commit --amend just now. [15:01] MvG: search for duplicates instead and click the affects me too button instead [15:01] MvG: I'm 80% sure this has been reported [15:01] vila: I did search, and found nothing. [15:02] ok, thks for trying :D [15:02] Problem is, it's kind of difficult to find suitable terms for it. [15:02] Does lp do a full text search? [15:04] when you file a bug, lp does a pretty good search, details available at #laundpad-dev :) [15:10] hey folks, does anybody have a second to look at this 8 lines of error and tell me if this might be a fluke... http://gist.github.com/277228 === phinze_ is now known as phinze [15:12] Using bzrlib, What's the best way to check if a local working tree has commits which are not pushed (assuming push_location is set) [15:14] anyone know if John Whitley hangs out on IRC? [15:15] phinze: that looks like a really low-level failure [15:15] as it means "import os" is failing [15:15] do you have a "posix.py" file somewhere in your path? [15:15] that's what i figured -- we run bzr every minute in a cron job and that came up once last night -- so there is much room for flukes [15:16] (some platforms accidentally set things up to include the current working dir in the python search path.) [15:16] phinze: could the system have been updating itself? [15:16] python -> 'import posix' works fine [15:16] jam: mmm good thought [15:17] it doesn't help that '' in PYTHON_PATH also means add current directory [15:17] might want to see what other cron jobs run on our build server and pause all the bzr activity for that time [15:17] doctormo: last_local_rev = wt.branch.last_revision(); push_url = wt.branch.get_push_location(); push_branch = bzrlib.branch.Branch.open(push_url); push_last_rev = push_branch.last_revision() [15:18] so, tentative conclusion is -- not really bzr's job to handle that sort of error? [15:18] if last_local_rev == push_last_rev: then you know there is nothing to do [15:18] otherwise you may have local changes, or remote may have changes [15:18] you can use graph = wt.branch.repository.get_graph(push_branch.repository) [15:18] jam: I see, what if we assume that remote doesn't have changes. [15:19] phinze: so far, the occurrences have been rare enough that the bug hasn't been fixed (there is one I can't remember the # just now ) [15:19] graph.find_difference() if you care about both sides [15:19] or [15:19] jam: See what would be good is to be able to say "Have there been any commits after the last push command" [15:19] graph.find_unique_ancestors(local_rev, [push_rev]) [15:19] doctormo: well, if the local revision is different than remote [15:19] and nobody else updates remote [15:19] then yes [15:19] there must be something to push [15:19] vila: sounds good -- initial bug searches for the text of my error weren't yielding much [15:20] at the end of the day i'm not too worried either [15:20] jam: OK, if that's the only way, I just want to avoid remote requests if I can. [15:20] doctormo: if you are writing your own stuf [15:20] you can save the revision at push time === CardinalXiminez_ is now known as CardinalFang [15:20] using something like a "post_branch_tip_changed" hook [15:21] however, *bzr* does not track that [15:21] it doesn't save a 'this branch was pushed at this revision' anywhere [15:21] I think there is also a post_push hook, if you just wanted to trap that [15:21] I see, then perhaps I should do a bit of code to track and then fall back on discrepency [15:33] vila: https://bugs.launchpad.net/bzr/+bug/507529 [15:36] Is there a command-line way to get the nearest common ancestor of two branches? [15:39] quicksilver: 'bzr merge --preview --show-base' may not be the pretiest, but from command-line... it's the only way I can think of [15:40] there was an approximate command in bzrtools at one point but I'm pretty sure it's not up to date [15:41] I want to set up a few potential complicated ignore-rules. Anyone here proficient in ignores with regular expressions? [15:42] vila: Hmm. Bzr is very clever but it's a bit hard to get the information out of it sometimes. I suppose you're expected to use bzrlib. [15:42] vila: do any of the visualisation tools help you visualise the relationship between a bunch of branches? [15:43] quicksilver: bug filing time ! :D [15:43] I have an /src directory in a project which contains lots of files and directories. I want to ignore everything in there, with a few (something like 10) exceptions, which I want to track. [15:43] qlog accepts seveal branches as input like : bzr qlog b1 b2 b3 [15:43] quicksilver: it then display special tags for the tips and doing a very good job at displaying the multiple heads [15:43] vila: but still shows you all the revisions doesn't it? [15:44] quicksilver: if the branches diverge a lot it becomes harder to track though [15:44] What are ghosts? [15:44] Is there some kind of document (wiki page, source file, mailing thread) that I could read to get an idea about what ghosts are and how different parts of bzrlib deal with them, i.e. which parts take care of them themselves and which expect the caller to deal with them? Or could you tell me in a few lines here? [15:44] Might be important to get support for them into trac-bzr one day, I'm not sure. [15:44] quicksilver: qlog default to masking most of the merged revisions but you can then open the ones marked with a '+' [15:45] an close the ones marked with a '-', obvious when you use, akward to describe :) [15:46] vila: sure. The thing is all I want is an overview which shows branches and all of their nearest common ancestors. [15:46] vila: so I can see what branched from where, when. [15:47] I don't want ot see individual revs at all [15:47] then definitely give a try to bzr qlog **/* or whatever [15:47] that's the closest I can think of [15:48] you will see the revs but one line for each but that's the best we have to present a *graph* with multiple heads so far [15:49] vila: *nod* [15:49] DaffyDuck_`: Simply ignore the whole dir and add the files you want to track. Ignore only affects untracked files; once you told bzr about the ones you are interested in, it will track them. [15:49] vila: I don't really like GUI toolkits. [15:49] vila: I was thinking of something a bit more elegant like a .dot file or a PDF file or something :) [15:49] quicksilver: I use almost no GUI myself *except* qlog [15:50] quicksilver: You want to write a bzr plugin generating dot output? [15:50] vila: giving qlog a repo will do everything underneath, I don't know about a plain dir [15:50] MvG: no, I want someone else to :P [15:50] quicksilver: there is also "graph-ancestry" from bzrtools [15:50] quicksilver: I've played with .dot files and intend to replay with one day.... when time permits [15:50] quicksilver: You want to pay someone else to... doesn't matter, still no time... [15:50] which does generate DOT output [15:50] or PNG (generated from DOT), etc [15:51] jam: that looks promising :) [15:51] quicksilver: how many revisions in your repo ? (all revisions not only the mainline ones) [15:51] I think it can also take a revision range [15:51] vila: 2000 or so? I'm not sure [15:51] You may have to tweak it if you want specific information [15:52] last time I played I started with graph-ancestry but my graph was too big but it was a decent starting point [15:52] I think it handles 2 branches, but not more than that [15:52] vila: I think it now supports giving a range of revisions so you don't have to graph the whole thing [15:52] ah, right. So not quite what I'm after but definitely thinking in the right direction. [15:52] quicksilver: IME dot doesn't like graphs with more than ~100 revs [15:52] 100 nodes [15:52] jam: I only want a node per 'most-recent-ancestor' really [15:52] from memory I'd say 2000 will blow away graph-ancestry (or give you a result you can't really use) [15:53] jam: qlog or graph-ancestry ? [15:53] so I'm talking 20 branches and 20 MRAs at most, I think. [15:53] I tried using it with a 100k object graph... and after 8 hours an 2GB of memory... it still hadn't finished formatting to -Tplain [15:53] vila: graph-ancestry [15:53] dot itself doesn't handle lots of nodes very well [15:53] it would probably be better with revision graphs, since there is less cross-linking and no cycles [15:54] unlike object reference graphs [15:55] well something else to think about next time I have free time... [15:55] not immediately clear how you find the right set of MRAs either [15:56] although I'm sure it should be clear. === beuno is now known as beuno-lunch === raimue is now known as Raim === salgado-lunch is now known as salgado === beuno-lunch is now known as beuno [17:09] can loggerhead cope with multiple bzr branches or is that a launchpad feature? [17:09] when I say 'cope with' I mean have some idea of the relationship between, I suppose. [17:12] quicksilver, what do you mean by a relationship? [17:12] well the fact that one branch is a branch of the other [17:12] they're not just two unrelated lumps of code. [17:13] so, the loggerhead instance running on Launchpad is the same one as trunk (minus some glue) [17:17] beuno: I'm not quite clear how much of what I look at is generated by launchpad and how much by loggerhead [17:17] beuno: for example : https://code.launchpad.net/loggerhead [17:18] beuno: is that page launchpad or loggerhead? [17:19] quicksilver, launchpad [17:19] * quicksilver nods [17:20] beuno: but this one is loggerhead: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/files I presume? [17:20] quicksilver, correct [17:20] anything UI under http://bazaar.launchpad.net is loggerhead [17:20] I suspect that what you want isn't part of loggerhead, but it may not be too hard to do [17:21] * quicksilver nods [17:21] loggerhead looks like a 'branch inspector' so it inspects one branch at a time. [17:22] yes it does [17:22] within a directory [17:22] but you can infer some relationship with commid revids and parent URLs [17:22] launchpad is different, because it stuffs everything into a DB :) [17:23] * quicksilver nods [17:59] hi. how to protect shared (centralized) repository against deleting or corrupting? [18:01] Don't give people write access to it. [18:01] Seriously, though. If you use stacked branches, that's a viable solution. [18:02] Peng: Stacked branches? I have to read about it [18:06] That's what Launchpad does, FYI. [18:06] Stacking policy, too. [18:08] Peng: Is there no need to have write access to whole shared repository to push changes? [18:08] jkprg: If you use stacked branches, it's not necessary. [18:10] jkprg: one option is that you also only need read access to existing objects [18:10] so once a transfer finishes, you could mark all files in .bzr/repository/packs and indices as readonly [18:11] (note that new ones will get created, old ones get moved to obsolete_packs and eventually deleted...) === vxnick_ is now known as vxnick === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === vxnick_ is now known as vxnick [20:05] jam: hello! thanks for the explanation about "bzr log" order constraints; I understand (1), but not (2): [20:05] "2) We also output a revision after the last revision which did not have it in [20:05] the ancestry. [20:05] what is "it"? === salgado is now known as salgado-afk [20:27] guilhembi: hi [20:27] so if you have revs A B C. [20:27] If B is in the ancestry of C, but not in the ancestry of A [20:27] then B will appear in the log output between A & C [20:27] if you go back to the graph I put up on the bug [20:28] I detailed the difference between that an just 'topological' [20:29] jam: I promised I read it, I saw "(2) says that C E G" [20:29] but I cannot parse (2) [20:30] could (2) mean: a revision is always after the last revision which didn't have it in its ancestry... [20:30] could (2) mean: a revision is always after the last revision which isn't a child of it? [20:31] No, that wouldn't imply that "that C E G has to come after F ". [20:32] C has to come after F because F does not have C in the ancestry [20:32] is that an easier way to see it? [20:33] A revision X will appear in the log after all revisions which do not contain X in their ancestry [20:33] jam: but I could also say "F has to come after C because C does not have F in its ancestry"...? [20:33] guilhembi: left ancestry first :) [20:34] something has to come first [20:34] let me think of a way to word it [20:34] jam: I'm grateful for the current effort to phrase that! [20:35] back in a sec [20:53] a revision X will appear before any child revision Y (topological), further if Y's left-hand parent (Z) does not contain X, then X will appear between Z and Y in the output [20:53] guilhembi: how's that? [20:56] * guilhembi reads and reads again [20:56] jam: "a revision X will appear before any child revision Y" [20:56] no, children appear first (newest revision on top) [20:57] guilhembi: I always draw time downwards (--forward) [20:57] you can reverse the statement [20:57] a revision X will appear after any child revision Y (topological), further if Y's left-hand parent (Z) does not contain X, then X will appear between Y and Z in the output [20:58] Note that the graphs in the bug report are also directed that way, in case you had some confusion there as well [20:58] A is the *first* commit [21:01] yes, I had understood graphs in the proper way. Re-reading the new sentence now... [21:03] Testing that sentence on various examples posted in the bug report... [21:04]