[00:00] morning poolie [00:00] hi spiv, feeling better? [00:01] Yeah, I am. [00:01] Sleeping lots seems to have helped. [00:05] hi igc [00:06] hi lifeless [00:07] igc: when you're up to it, we should talk about tree rules stuff [00:07] where talk is irc|email|voice [00:28] spiv feeling better now? [00:30] rudylattae: yeah, hopefully it lasts. [00:31] spiv: good going [00:44] lifeless: that would be great. Monday morning/lunch on IRC and/or phone suits me best [00:45] ok, cool [00:49] jelmer: http://goran.krampe.se/blog/Squeak/BzrOnDebian.rdoc [00:50] jelmer: there is a issue with normalisation in there, from bzr-svn [00:50] jelmer: do you think its a bzr bug or bzr-svn bug? [00:51] lifeless, this is a blog post from december last year [00:51] yes [00:52] lifeless, My memory of what bugs I've fixed doesn't go back that far :-) [00:52] I don't think its necessarily fixed [00:54] * jelmer tries [00:58] lifeless, we did fix some normalization-related issues a while ago === abadger19991 is now known as abadger1999 [01:30] lifeless: were you still planning to come over this arvo? [01:42] poolie: yah [01:42] poolie: I forgot about that, one minute [01:42] did spiv confirm dinner ? [01:43] not yet [01:43] depends how he's feeling today i guess [01:43] is there some way to make bzr automatically recognise when I've moved files around and done nothing else to them? [01:44] http://michael.ellerman.id.au/bzr/plugins/auto-rename [01:44] poolie: so its a bit of a miserable day outside [01:45] spiv: ping [01:45] yes i'd just been noticing that :) [01:48] lifeless, just confirmed, that repo checks out fine here [01:48] well, *seems* to be [01:48] jelmer: cool [01:48] * alsuren wonders whether there is a plugin installer plugin, or whether that would be a bit too meta :P [01:49] alsuren: there should be :) [01:49] there is a bit of a start towards it with the missing-plugin stuff [01:49] lifeless, we can take a rain check (cheque?) [01:49] poolie: sure thing [01:49] i would like to talk to you on the phone if not in person sometime [01:50] perhaps a rain CHK [01:50] but preferably not til later to preserve my concentration [01:50] such as it is [01:53] bzr branch http://michael.ellerman.id.au/bzr/plugins/auto-rename/ hangs for me [01:53] *goes to bed, and thinks about it tomorrow* [01:54] alsuren, it may just be a slow-over-http format === mw is now known as mw|out [01:56] alsuren: its an old format branch [01:56] poolie: sorry if I'm bad for concentration :P [01:56] poolie: later is fine [02:25] jam: back now. [02:58] lol? http://linux.softpedia.com/get/Programming/Version-Control/bzr-search-40745.shtml [02:59] lifeless: boggle [03:08] hopefully they can certify it as virus free soon [03:16] lifeless: bug 264679 is suggesting that info about 'bzr help configuration' be listed in the output of 'bzr help' [03:16] Launchpad bug 264679 in bzr "expose configuration help in cli" [Undecided,New] https://launchpad.net/bugs/264679 [03:17] god no [03:19] if it didn't have info about branch config etc it would make more sense. 'bzr help user-config' or similar... [03:23] markh: why? [03:24] to give a new user that they might want to run 'whoami', for example [03:24] well - a clue to follow to find that out ;) [03:26] uhm [03:27] I don't think this makes sense; users may not run help at all [03:27] they may assume they know how to use it [03:27] heh [03:27] so who is it for? ;) [03:27] or they might be on a new machine [03:28] 'bzr help' is not 'I am a new bzr user' [03:28] so you are against putting potentially useful information in "bzr help" because users may not run help? [03:29] no [03:29] someone who is not a new user to bzr doesn't need much of the info on the 'bzr help' screen at all [03:29] they already know 'bzr help commands' [03:29] I'm against making 'bzr help' which is already too long, longer, without actually solving the asserted root problem [03:29] a windows user won't run 'bzr help [03:29] of course they will! [03:30] someone following a guide someone else wrote probably won't run 'bzr help' [03:30] I do, and ofcourse its one of the first bzr commands I ever typed! [03:30] no they won't, they'll right click somewhere and start with the first popup screen [03:30] that is a gross generalization ;) [03:30] "linux users will never use the mouse" ;) [03:31] likewise an eclipse user [03:31] are you saying the core change is that 'bzr help' top level output should point to 'help configuration' or is it something else? [03:31] but - I'm not avdocating for that - just trying to understand your reasoning [03:31] markh, the mouse is used to choose the xterm to type in ;-) [03:31] that was the assertion a user made, and lifeless said he didn't understand the proposal. I was just trying to help clarify it for lifeless. [03:31] markh: if the problem is that 'you have to run bzr whoami to be able to use bzr sensibly', then we should put effort into fixing that [03:32] I see it potentially has merit [03:32] and I assert a new user of bzr *will* type 'bzr help' very early on [03:32] but I really don't care ;) [03:32] well, I'm not against a pointer to the config in the top level help [03:32] I am against embedding al the content there [03:32] why? Surely that's for the new user too? [03:33] markh: why not delete the top level help and point to the tutorial? [03:33] because IMO 'bzr help' is useful to the new user, and should be targetted at the new user. [03:33] ISTM you are the one saying otherwise? [03:34] I think bzr help is very good atm for exactly those reasons [03:34] from experience, people get scared off a first help screen that is more than ~ 1 page [03:34] the config documentation is many many pages [03:35] I think a single line 'bzr help config - show info about how to customize bzr for your preferences" *might* be beneficial for new users [03:35] sure, I have no objection to that [03:35] we should remove 'bzr check' too [03:35] that is the proposal!! [03:36] markh: I though it was to copy the contents of bzr help configuration -> bzr help [03:36] god no ;) [03:36] markh: which is what I said [03:37] so, I hope I've help clarify the proposal in that bug you commented on ;) [03:40] abentley: we must be talking past each other or something, on the bug discussing rev specs [03:41] the 'whoami' question is interesting in its own right. The default value will rarely be exactly what the user would choose to type for that value. So the argument could be made that you *do* need to run whoami to have it work sensibly. the first few bzr checkins I made had 'inappropriate' values for the user (certainly 'skip@eden [03:41] ') isn't that useful [03:44] poolie: how was the trip? Your bum recovered? [03:44] it was great thanks [03:44] * markh hopes people don't take that the wrong way ;) [03:44] heh [03:44] bike went well? [03:44] actually it was more my neck that got sore from crosswinds [03:45] markh: better that poolie doesn't take it the wrong way either :P [03:45] :) [03:45] markh, the front shock and forks started leaking after a day of fairly rough roads [03:45] not catastrophically, and they'll be replaced soon under warranty [03:45] bugger - they lasted ok though? [03:45] yes [03:46] it was a bit disturbing to see oil all over the front of the bike [03:46] but fine [03:46] the mechanic said "if i'd been punished like that all day i'd be weeping too" :-) [03:46] yeah, I bet! Did you notice the suspension suffer? [03:46] heh :) [03:46] I'd guess you'd lose dampening? [03:46] no, i just put a bit more preload on to (possibly) make it easier on it [03:47] i guess i would eventually but it probably has not lost enough oil to make a difference [03:47] i actually got much more relaxed on that ride about rough surfaces, dirt, big trucks, wind, etc [03:47] yeah, I shit myself on dirt still :) [03:48] http://flickr.com/photos/mbp_/2824615378/ [03:48] markh: so, bzr design principles - we try to make mistakes easy to recover from; having to read more to be insulated from mistakes strongly suggests to me that we have a too-hard-to-recover-from situation [03:48] it would help if I had a bike designed to go off the tarmac though :) [03:48] markh: and I'm *much* more interested in fixing that that [03:49] i saw two roos go across the road in front of me [03:49] not close enough to be a problem but it does make you think [03:50] lifeless: I think we are agreeing in general. However, I do see value in assuming a new user is likely to run 'bzr help' early on, and best I can tell, the existing help on that page is targetted at a new user. further, pointing such a new user at config options early on may have value too. [03:50] poolie: how close? [03:51] the first one, i braked at about 70% effort and had plenty of room [03:51] the second i just backed off and watched him go [03:52] ack - I bet the first one worried you briefly! You have abs though? [03:53] markh: well, like I said, I'm not against tweaking 'bzr help'. It doesn't enthuse me though - the shed is blue, mmk? (compared to reducing the curve by making mistakes more recoverable). [03:54] i do [03:54] i've never had it activate except when practicing braking [03:54] which is probably good [03:54] nice to know it's there [03:55] so some people on the trip washed their bikes every night, then put covers over them [03:55] each to their own but i found that kinda creepy :-) [03:55] heh - the ducati trips are very much like that ;) [03:55] i bet [03:55] quite amazing [03:55] I admit I wiped the bugs from the front most nights though ;) [03:56] but left a streaky mess in its place :) [03:56] i did wash the screen, lights, etc [03:56] the rest of it looks better with some dirt [03:57] back soon [03:57] your enjoyment suffers when you are too anal about things like that [03:58] so, about half our trip overall was just up and down the bruce hwy [03:58] there is a lot of sugar cane [03:58] there were some pretty amazing roads in between [04:01] I bet [04:50] poolie: back to those tests - how should we proceed on silencing the lock contention test failures? [04:50] you're talking about the outright failures rather than xfail i presume [04:52] yeah [04:52] it seems xfail already catches some of those errors [04:52] we just try and arrange for xfail for all of them? [04:53] so that would be the laziest way to do it [04:53] at least then we'd detect if anything new breaks [04:54] i think it would be worth trying to work out why they are failing [04:54] for instance [04:54] - is it just a bug in the test that eg it has two objects pointing at the same file [04:54] in which case ideally we'd fix the test [04:54] - or is it something that is kind of broken by design on windows [04:55] - or is it something that we could fix but that'll be nontrivial [04:55] that kind of thing [04:55] i suspect there are some in the first category and it would be nearly as easy to fix them as to block out the tests [04:55] There are a couple of cases where we try and take a readlock and a writelock on the same directory [04:55] I'll try and find the thread - give me a few... [04:57] It was in IRC. "[09:05] I'm tracking down LockContention on Windows and I don't understand how it is supposed to work. I've instrumented 'do_merge' and can prove that in some cases, self.this_tree._dirstate._filename == self.base_tree._dirstate._filename" [04:58] so - many of the test failures stem from that. It should be quite easy to instrument any platform to check for that condition [04:58] ok, i recall that from before i left [04:58] on Linux, you *can* lock like that, on Windows you can not [04:58] so i'd want to know - are the dirstate objects the same? if so, are the tree objects the same? [04:58] apparently yes [04:59] lifeless says there are a number of valid use cases for that [04:59] hm [04:59] bzr merge . for instance [04:59] which is why I proposed a relatively trivial tweak to dirstate that avoids this [04:59] but it seems to be stalled [05:00] and it won't fix WT4 regardless [05:00] so i want to avoid having "xfail os locks are not process-wide" when that is only the proximate cause [05:02] how about a "Feature"? [05:02] I'm not sure how these solutions would impact the output of the test run though [05:03] Hm. There are some minor long-standing test failures on my system... [05:03] IIUC that would make them a "skip" or something though... [05:03] markh: skip isn't appropriate for something that can't be fixed [05:03] But I got a stack of others while trying to reproduce them. Figures. [05:03] Features seems like the easiest implementation though ;) [05:04] so [05:04] if the object is already locked, why are we trying to lock the same file through a different file handle? [05:05] I think the answer is "because we can" :) [05:05] it wasn't about feature vs xfail, rather that if we're going to say "it's not really a failure" i'd like to be clear about what is causing it [05:05] an option I proposed was simply to detect we already have a write lock and don't bother with the read lock. lifeless suggested that wasn't really an appropriate fix and he had ideas for the correct fix [05:06] markh: I mailed my proposal to the list [05:06] markh: its not a good fix because its very incomplete [05:06] lifeless: understood, but there is a dependency issue [05:07] lifeless, you're talking about the proposal to rename the file? [05:07] i guess i just don't see why this would need any on-disk changes [05:07] why can 'bzr merge .' not work with our current format? [05:07] do we want to wait for that fix before we try and make tests give reasonable output? There is only one of you ;) , so doing something in the meantime makes some sense [05:08] markh: theres no need for me to do the deeper fix; and I haven't suggested waiting on addressing the tests issue [05:08] lifeless: understood - was just explaining myself :) [05:08] poolie: bzr merge . is something the test suite does; bzr diff while a bzr commit window is open is a more common occurence of the same defect [05:09] they're different because in the first case there is only one process in play [05:09] the second is a known bug, sure [05:10] the first one seems to me to be accidentally failing [05:11] poolie: when you say "accidentally failing", you mean "bzr is accidentally taking more lock than it needs" or "test suite is in error"? [05:12] it could be either [05:12] a one line hack to do_merge will reproduce the problems for you [05:12] i mean 'accidentally' because the design limit that affects the second case should not be causing this to fail afaics [05:12] just fail whenever the 2 paths are the same and run the test suite [05:24] bug 114528 [05:24] Launchpad bug 114528 in bzr "dirstate locks don't work on Apple AFP network mounts" [Medium,Confirmed] https://launchpad.net/bugs/114528 [05:24] another example o f the same thing [05:28] lifeless: to me it looks like that's just saying that file locks don't work at all in some environments [05:39] poolie: yes, and the ongoing problems with dirstate are due to that [05:56] poolie: the test related patch in the queue I referred to is at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C019a01c8fe73%2427a26f30%2476e74d90%24%40com.au%3E - John has already voted 'approve' [05:58] * markh didn't think the patch was *that* scary... [05:58] i'll look [06:02] who would be the person to ask about bzr's sftp transport? [06:02] anyone really [06:02] in particular, is there any likelyhood it sends the "realpath" sftp command? [06:02] spiv, poolie, I, jam, vila, have all had sustantial interactions with it [06:03] unlikely I think [06:03] that's what i thought too [06:03] which is why your server is bust :P [06:03] yeah [06:03] well [06:04] it's why our server can be bust and still host bazaar branches without exploding [06:04] (realpath returns url-encoded paths atm) [06:05] markh, it looks fine to me, i'll merge it [06:12] poolie_: thanks! [06:32] poolie_: call time ? [06:33] woo, passing [06:34] what a great time for a call :) [06:57] goood morning bazaar [06:59] morning vila [07:02] mwhudson: I highly doubt we use the realpath command in our sftp client, paramiko may though === thekorn_ is now known as thekorn [08:49] poolie_, lifeless: I don't think I'll be doing dinner with you guys tonight, I'm still not quite 100%. [08:50] spiv, sure, we're not either [08:53] poolie_: great ;) [09:03] spiv, can you look quickly at my partial patch on bug 261315 [09:03] Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 [09:05] * spiv looks [09:06] It looks like I have a fix for the ObjectNotLocked bug that affects 'bzr cat bzr://...' etc, just waiting for tests to pass. [09:06] It *might* let me delete some cruft, too. [09:11] poolie_: that looks ok to me [09:11] thanks [09:11] it'd be nice to eliminate these things of having two objects representing the same thing [09:12] poolie_: the obvious way to avoid that forcing _ensure_real on every branch open would be by having a new Branch.open RPC that returns the stacked_on URL, I guess. [09:12] Branch does seem like a good place to start in removing real objects [09:13] Yeah, keeping two different objects representing the same entity in sync is the source of lots of hpss bugs. [09:13] Including the ObjectNotLocked one. [09:18] i might try that soon [09:18] maybe not tonight [09:18] i should finish off LockableFiles too... [09:19] i was also looking at the locking gc warning thing [09:19] it seems to me that every case we currently warn is in a test for lock-breaking or similar [09:19] where we really are meaning to have the lock object leak [09:21] so i guess we could explicitly mark them as abandoned or something, and then suppress the lock leak [09:21] but it seems like diminishing returns === mvo__ is now known as mvo [10:59] Ooh, it looks like I *can* finally delete some cruft from RemoteBranch.lock_write [11:00] I think I just figured out part of the confusion that had stopped me doing that earlier: it was possible for the code to overwrite the _real_repository object sometimes. Debugging hilarity ensues. [11:02] * spiv goes on a XXX-deletion spree [11:03] Among other things, RemoteBranch.lock_write doesn't force _ensure_real any more :) [11:49] jam: RemoteBranch.lock_read fix sent to list [11:50] jam: it includes some bonus extra sanity on top of just fixing the immediate bug :) [11:51] * spiv wanders afk [12:11] I'm trying to use bzr import-dsc on the history of a non-native Debian package, and running into some trouble: namely, it works if I just run it in an ordinary branch, but not if I create a repository first. What would you need in order to debug this? [12:18] oh, I forgot James was on holiday, ok [12:20] cjwatson: I'd suggest pasting the appropriate part of your .bzr.log somewhere. [12:24] http://paste.ubuntu.com/43603/ [12:27] cjwatson: Hmm, yeah, that's something I can't really help with. [12:27] Doing it in a branch and then branching into your repository should work around it though. [12:28] right, that's what I did [12:28] it's perfectly reproducible, so I'll grab James about it when he gets back [12:28] cjwatson: File a bug? [12:28] yeah === jelmer is now known as Guest51940 [12:53] So..... [12:54] 'find -name .bzr $ -prune -printf "%h\n" $' runs in about 0.5seconds and uses hardly any memory while doing so. Whereas, 'bzr branches' eats looooads of memory and spends a great deal longer time finding out the same information... [12:56] Oh and it chews a great amount of CPU too [12:58] 'branches' is that bad? Hmmm. [12:59] real 0m0.022s <= 'find | sed'. real 0m13.015s <= 'bzr branches' [12:59] Jeepers, you're right. It hit 112 MB of RAM by the time it was done. [12:59] Mhm :) [13:00] I'm running it on a VPS, so I think I just dumped the entire disk cache, but at least I didn't swap. [13:00] Perhaps I should post to the mailinglist? [13:00] Sure. [13:01] Oh, I just realized that my little script doesn't use "bzr branches" anyway. [13:01] It uses subprocess.Popen(['find']). Cough. [13:01] Hehe [13:01] Ya.. I use: [13:01] find -name '.bzr' $ -prune -printf "%P\n" $ | sed -e 's,/\.bzr$,,' [13:02] Heh. I just use 'find' to get a list of all directories and then loop through it. === vk5foss is now known as kgoetz [13:21] to anyone: there used to be a bug regarding errors that occur when redirection takes place, does anyone remember the # by accident? [13:22] LeoNerd: Heh, I have a powershell script for the same reason === AnMaster_ is now known as AnMaster [13:23] mmmm [13:23] Sounds like 'bzr branches' needs some work then [13:23] ls | where { $_.PSIsContainer } | ls -force -inc .bzr | where { ($_.Name -eq ".bzr") } | foreach { $_.Parent } [13:24] It doesn't recurse, but some of my trees are .. large, and I don't want to recurse them [13:25] That's what the -prune is for [13:25] I'm not very skilled with "find" as yet [13:37] Hmm, replacing my 'find' hack with os.walk was quite easy. Yay. :) [13:37] (I've never used os.walk before.) [13:50] Peng_: There's a bug in the svn bindings that can cause ludicrous memory consumption, if you have bzr-svn. But branches uses bzr transports, and they're not very efficient for this. [13:51] abentley: What exactly is triggering that? [13:52] hi jelmer/guest51940 :p [13:52] Guest51940: I don't know. [13:53] abentley, Just a regular pull/push with bzr-svn doesn't use more memory than usual these days [13:54] Guest51940: That's with the new bindings? I'm talking about the old ones. [13:54] abentley, ah, ok [13:54] And I'm talking specifically about the 'branches' command. [13:54] Which uses BzrDir.find_branches. [13:55] abentley: I do have bzr-svn installed, but none of the branches in question use it in any way (though some are copies of svn imports). [13:56] Peng_: Doesn't matter whether they use it. [13:56] I'm not using svn at all [13:57] Ah. You're talking about the 'bzr multi-pull consumes 1GB resident' funness? [13:57] LeoNerd: Are you seeing ludicrous memory consumption? [13:58] Yup [13:59] In fact, if I run 'bzr branches' from my $HOME, it throws everything else out to swap, then OOM killer bites [13:59] Format for file:///home/lamont/stuff/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance [13:59] what check (short of a bzr command) can I use to see that this warning is going to come out, I wonder? [14:01] LeoNerd: Please file a bug, then. So far, every case of this has been solved by uninstalling bzr-svn. [14:02] Ahright :) [14:03] lamont: I don't think there's anything you can do without running a bzr command. The list of deprecated formats will be different depending on your bzr version. [14:04] right. specifically, 1.6 vs knit, or "is there a way to tell that I have a knit1 format by just checking a file or its contents?" [14:05] lamont: you can "cat $PATH_TO_REPO/.bzr/repository/format" [14:05] cool [14:05] Wait...my os.walk() code is completely broken. === robtaylor is now known as robtaylor-test [14:06] Anyway, off-topic. === robtaylor-test is now known as robtaylor === fta_ is now known as fta [14:35] Weird...I seem to have poked one of my bzr branches over http. === mw|out is now known as mw [14:53] ls [14:53] oops [14:56] . .. docs movies warez xxx [15:00] * awilkins wonders if Pieter executes any other commands [15:00] rm -rf /dev/brain [15:01] rm: command not found === Guest51940 is now known as jelmer [16:06] Using bzr 1.6 on Windows XP, I am suddenly getting this error on every operation: "bzr: ERROR: invalid header line: ''" My dirstate file appears to be empty. [16:06] Does anyone know how to recover from this situation? [16:06] mitchchapman: do you have any changed files? [16:07] Yes. [16:07] Move all your files except .bzr into a temp directory [16:08] delete .bzr/checkout and its contents. [16:09] run "bzr checkout ." [16:09] That should give you a tree in the state you last committed. [16:09] Then copy your working tree files back in place. [16:09] If you had added or moved any files, you'll have to do that again. [16:28] abentley: That did the trick, thank you very much! [16:28] mitchchapman: You're welcome. [16:28] Hi all. In bzrlib, what's the best way to find if a revisionid exists in a branch? All the ways I see in bzrlib.branch work only if the revision also has an integer revno. [16:32] chadmiller: bzr log -r revid:$REVISION_ID [16:32] If that shows the entry, it's in the branch. If it raises an exception, it's not. [16:36] abentley: Okay. I'll reverse-engineer what "log" does. Surely there's a smarter way. Note my "In bzrlib," preposition. [16:37] chadmiller: Oh, then "best" is highly variable. [16:37] cheapest? "if revid in some_hash:"... [16:38] * chadmiller greps around for NoSuchRevision [16:38] Cheapest would be branch.repository.get_graph.iter_ancestry([branch.last_revision]) [16:40] Or I guess branch.repository.get_graph().is_ancestor(candidate, branch.last_revision()) [16:41] However, *any* operation that can answer your question will scale badly if the answer is "no". [16:41] So I would reconsider trying to do that. [16:44] abentley: Well, I'm trying to use Graph.find_unique_ancestors(), which lists every rid if the exceptions list contains only an invalid rid. [16:45] Arguably, it should raise an exception. I can't wait, though. [16:47] chadmiller: I think that anything that can answer your question will take at least as long as find_unique_ancestors if there is an invalid revision-id. [16:48] The only way to know if a revision_id is present in a branch is to walk the ancestry of the last revision in the branch. [16:48] until either you find it, or you reach the graph origin. [16:49] Right. I'm not worried about time for missing revid. I must raise a warning though, in the case where someone gives me an invalid revisionid. [16:50] Invalid revision ids are those that end with a single ':' [16:52] I wouldn't mind taking the graph origin as an error. I'll look at that. I can test if the set Graph.find_unique_ancestors() contains the origin, I suppose. Hrm. Now, to get the origin.... [16:52] abentley: When I say it, I mean "invalid" to be "not present in the history at all" [16:56] chadmiller: No, you mean "not present in the ancestry at all". If it's present in the ancestry but not the history, it doesn't have an integer revno. But you said you wanted to allow things without integer revnos. [16:56] abentley: Thank you. bzr internals argot is still new to me. [17:32] abentley: well technically you can walk both ancestries, and if you find them converge [17:32] then you only need to search some of the ancestry [17:32] (things that are descendents of the common point) [17:33] I use that sort of logic in the lazy revno code I've been putting together [17:34] and it is also somewhat how "Graph.find_distance_to_null()" works. [17:34] chadmiller: the 'origin' is "NULL_REVISION" [17:34] but that is going to be common to all revisions [17:34] so won't show up in "find_unique_ancestors()" [17:34] Actually, I would be surprised if "find_unique" returns the complete set [17:34] unless the ancestries are completely separate [17:36] chadmiller: http://rafb.net/p/M1l6OR91.html [17:36] there is also "Graph.find_difference()" [17:36] which can give you the difference on each side [17:36] if one side is empty [17:36] then that revision is in the ancestry of the other. [17:40] jam: Hrm. "...the difference on each side"? I have only a revisionid and one branch. I don't see how find_difference() can help. [17:40] chadmiller: Branch.last_revision() [17:41] left_unique, right_unique = graph.find_difference(Branch.last_revision(), old_last_revision()) [17:41] if len(right_unique) == 0: [17:41] then old_last_revision is in the ancestry of the current tip [17:41] because it has no unique ancestors [17:42] Otherwise left_unique == graph.find_unique_ancestors(Branch.last_revision(), [old_last_revision]) [17:42] chadmiller: does that help? [17:42] find_difference() computes the symmetric difference [17:42]