[00:13] What are "ghosts"? [00:16] Oh, revisions that don't actually exist in the repository but are listed as parent revids for a revision? [00:16] * mkanat doesn't exactly understand how that's possible. [00:19] Me neither. It sounds scary. [00:21] I'm not quite sure that's what they are--I was just trying to figure it out from the loggerhead code. [00:22] That's what they are, AFAIK. [00:22] Well, I don't know why you specifically said "but are listed as parent revids for a revision". [00:23] I have no idea how you get ghosts -- most of them are probably remnants from the early days of bzr, and perhaps conversions. [00:23] I really don't know any more about ghosts than you do, but you're definitely on the right track, at least. :P [00:24] Hahahaha, okay. :-) [00:24] Peng: Well, here's what loggerhead does to strip ghosts from a graph: [00:24] evision_graph[key] = tuple(parent for parent in parents if parent [00:24] in revision_graph [00:24] (But of course, that first var is "revision_graph", not "evision_graph".) [00:24] Hm, good point. [00:24] * Peng shrugs [00:49] In bzrlib, is there a straightforward way to ask "what's the mainline revision that this merged revision belongs to" no matter how deep a merge it is? [00:49] IIRC there's not. [00:50] I'm dumb, so someone could easily prove me wrong, but don't be too hopeful. [00:50] Okay. But theoretically...I could just take the first part of the tuple, no? [00:50] (the dotted_revno tuple, that is.) [00:52] Dotted revnos are based on where it branched *off*, not where it merged back. [00:52] Actually, does Loggerhead have a data structure tracking that info? [00:52] Or just revids and dotted revnos? [00:52] Peng: It has a *crazy* data structure tracking that info. [00:53] :D [00:54] If you want to know where it branched off, the revno will tell you that, yes. [00:54] Ah, okay. Yeah, I see that now. Yeah, no, I want to know where it was merged in, unfortunately. [00:56] And it seems to be the only reason we need that crazy data structure. [01:18] mkanat, Peng: I've seen ghosts where bzr-svn has been used to merge a branch into a Subversion repository. The branch revisions do not actually exist within the svn repo, so you get a ghost when you check it out again. [01:19] Oh, wow. [01:19] Foreign VCS == confusing. :-) [02:07] Wow, so I have to merge_sort the whole graph to know where a revision was merged in? [02:11] mwhudson: That appears to be the only reason that we have the revision graph. [02:11] (That is, that we have the graph cache.) [02:11] weeeelll [02:11] more or less yes [02:11] It seems like bzrlib ought to be able to tell me that more easily, but I'm really not finding a way. [02:11] revision numbering (the way bzr does it) is slow [02:12] mkanat: if you can, 'bzr log' would like to talk to you :-) [02:12] mwhudson: Hahaha, but doesn't it just do what I said above? [02:12] * mkanat goes to go look. [02:12] See, in bzr log, it makes sense to merge sort the whole graph, because we probably want the whole graph. [02:13] But in loggerhead, it doesn't make any sense, because we just want to know where a single revision was merged in. [02:14] you need an ancestry oracle [02:14] lol === spundun is now known as sp|afk [02:19] lifeless: So I assume that I'm correct then, and that's what I have to do, and there's absolutely no faster or simpler way? [02:19] mkanat: it's currently a sad fact that to know where one revision is merged in, you have to look at ~the whole graph [02:21] mkanat: I wasn't joking, the data structure you need is an ancestry oracle [02:21] lifeless: I'm not familiar with that term.... [02:21] oracles? [02:22] lifeless: Unless you mean the Greek kind, yeah. [02:22] mkanat: an oracle is something that gives you answers [02:22] Ahh. [02:23] if i have a branch inside a branch, will it be listed when looking at the main branch? or are they independent entities? [02:24] deparate [02:24] s/d/s [02:24] ohh ok that explains it :) [02:25] lifeless: More like reverse ancestry. [02:25] mkanat: http://en.wikipedia.org/wiki/Oracle_machine [02:26] i was interested to read recently that you can prove that P != NP if you assume a particular oracle [02:26] Ha! :-) [02:26] Yes, that's what I need, is a "where did this thing merge into" oracle. [02:27] send your revid on a postcard to lifeless [02:27] lol [02:27] lifeless: I assume that there is no such oracle in bzrlib, and that's why we have a crazy data structure in loggerhead to figure stuff like that out. [02:28] mwhudson: I suppose another option is to AJAX any operation that needs that information. [02:28] mkanat: weeelll [02:28] i'm not sure that's really an answer [02:29] mwhudson: Yeah, very possibly. I haven't looked through all the code to see where get_revids_from and get_merge_point_list are used. [02:30] get_revids_from is conceptually pretty easy i think [02:30] it's just recursively taking the left hand parent from a particular starting point [02:31] get_merge_point_list i have no idea at all about :-) [02:31] i think it can probably be taken away and replaced with something much more sensible [02:31] mwhudson: From what I can see in get_revids_from, though, we still need the _rev_info structure. [02:32] mwhudson: At least, if its doc string is accurate. [02:32] hm, maybe i misremembered [02:33] Okay, yeah, get_merge_point_list can almost certainly be replaced with something simpler. [02:33] It's only used inside of get_changes. [02:34] my memories are awakening slightly [02:34] i think get_revids_from is like that for the case where you're showing changes to a particular file [02:35] finding *a* point a revision was merged in is not hard, finding the point it was first merged is much more work [02:35] so you get a sack of revids (those that change the file) but you want to show the mainline revisions that merged those particular revisions [02:36] mwhudson: Yeah, it's mostly used in get_file_view. [02:43] ah ok [02:43] there's something else that it would be really nice to achieve as a side effect of this stuff [02:43] and that's aligning the apis in history.py rather more with the uses of said apis [02:44] (after all, there aren't very many such uses) [02:44] You know, yeah, I was kind of thinking about that. [02:44] mwhudson: ciik [02:45] lifeless: ? [02:45] lifeless: is your right hand one key to the left? [02:45] uhm what would a bzr repo structure look like for a project (done the bzr way) ? [02:45] mkanat: it's not as bad as it used to be :-p [02:46] mwhudson: :-) [02:46] mwhudson: Was History written more as a generic representation and then brought to use afterward? [02:46] mkanat: no idea [02:47] Okay. [02:47] mkanat: as you said earlier, it's probably still got lots of hgweb in it [02:47] * mkanat nods. [02:47] At the least, I could sane-iify _rev_info. [02:48] That might tell me a bit more about what information we're actually using from it. [02:50] Can I at least guarantee that the merged-in revno is higher than the first part of the dotted revno of the merged revision? [02:51] mwhudson: I think I need to do what you said, and really just figure out what we're actually using this info for, first. [02:51] That will probably have to happen tomorrow; today I've been working for like 10-ish hours now. [02:52] mkanat: that would be very useful [02:52] mwhudson: Okay. :-) [02:52] mkanat: though i'd meta-ize that even one more step [02:52] mkanat: what do we WANT to use this information for? [02:52] that may not be what we're currently doing :) [02:52] mwhudson: Oh, that's a good point too. [04:25] any suggestion on how to checkout a project with symlinks on windows? [04:32] what happens when you try? [04:40] error lol [04:41] bzr: ERROR: Unable to create symlink [05:46] Hi, there is bazaar command to list all the modified files ? [05:46] like bzr diff -r 37.., but who displays only modified files [05:47] status? [05:48] bzr help modified [05:48] Purpose: List files modified in working tree. [05:48] ? [05:49] Ok thanks Is exctly why I needed. [05:49] bzr status -r 37.. : Is exactly what I m looking for [05:50] Thanks ! [08:37] YES ! news_merge plugin works :D [08:38] vila: so i can push branches to CNN? [08:39] mneptok: not yet, we are still sorting out the deal. But you can pull in the mean time :D [08:42] hey [08:43] igc & other devs: maybe you could take a look at https://code.launchpad.net/~gerard-/bzr/update ? [09:42] vila: do you have an URL? [09:43] bialix: for the news_merge plugin ? It's part of bzr.dev [09:43] ok [09:43] bialix: hi by the way :D [09:43] hi vila [09:44] bialix: it's more an example of a per-file merge hook and only apply to bzr, you need to add news_merge_files = NEWS in the relevant section of your locations.conf or in branch.conf [09:45] щл [09:45] ok [09:45] sorry [09:45] bialix: its aim is to avoid the usual conflicts in NEWS and I see it work live minutes ago :D [09:45] vila: I understand what you talking about [09:45] it's great [09:46] is it possible to write my own mergers? without rocket sciense? [09:46] e.g. for PO or XML files... [09:46] yeah, just have a look at it or the one we implemented for bzr-builddeb [09:47] I'm not good in bzr-buildeb staff [09:47] hmm, both are extremely good ideas [09:48] I hope there will be some simple way to plug-in extrnal utility [09:48] vila: how's 2.1 going? [09:49] bialix: look at revno 399 in bzr-builddeb trunk, the parts you need are mostly in __init__.py [09:50] bialix: 2.1.0final should be cut tomorrow AIUI [09:50] COOL [09:50] this is good news [09:50] custom mergers are part of 2.1, right? [09:56] bialix: yes [09:56] bialix: but 2.1.0rc2 has a bug which will be fixed in 2.1.0final [09:57] bialix: I merged the fix into bzr.dev though [10:00] news_merge.py does not seems very simple though [10:00] bialix: plugging a merge algorithm is simple, the algorithm itself remains.... hard stuff [10:01] yep [10:01] may I suggest to provide an example of invoking external utility (like diff3) for merging? [10:02] the signature is simply awful: def merge_text(self, params): [10:02] what is params? [10:03] it contains all the needed stuff: lines from both sides, your custom parameters (common to all the file merges invoked for the same tree) [10:03] I'm pretty sure it's documented at the hook level [10:05] bialix: search for MergeHookParams in merge.py [10:07] ok === salgado-afk is now known as salgado === sven is now known as Guest47505 [14:22] morning all [14:25] 'lo [14:27] morning === salgado is now known as salgado-lunch [14:56] morning jam [14:58] How can I find the class a method is defined in from its callable ? self being the object and self.callable the method I'm interested in, self.callable.__class__ is the same as self.__class__ even if callable is inherited :-/ [14:59] Hmm, well callable in the case I'm interested in is __init__ or __new__ if that may help [15:12] vila: http://paste.ubuntu.com/368238/ [15:12] func.__self__.__class__ [15:13] jam: that doesn't work if the method is inherited [15:13] hi vila [15:13] and jam [15:14] jam: let say B inherits from A which define methA, I'd like to get 'A' from B().methA [15:14] vila, thanks for taking that sftp hook [15:14] hey poolie ! [15:14] hi poolie [15:14] poolie: I'm trying to go a step further and move all test servers out of bzrlib.transport [15:14] vila: f.im_class ? [15:14] poolie: but I run into a problem when deprecating transport.Server [15:14] vila, yay [15:15] I use a deprecated_method decorator but the message mention the daughter class which looks a bit silly [15:15] a deprecated_method on __init__ tha is [15:15] that [15:15] jam: no im_class there :-/ [15:16] well, func.im_class seems to be the same as func.__self__.__class__ in my checking [15:17] __init__ may be harder to handle right than "normal" methods, I can try to check the class hierarchy for the presence of the said method but that sounds hairy and may not even be right [15:17] jam: are you trying on an __init__ method ? [15:18] vila: No, but regardless, I'm not really seeing anything to get at it [15:18] o.func.im_class == child [15:18] well, I think I'll punt and see if some reviewer has better ideas :D [15:19] you could always just manually deprecate something if you need to... [15:19] you mean inlining deprecated_method in my __init__ method ? [15:20] vila, just inline a specific message [15:20] will do [15:23] is there an open bug that when bzr.dev gets updated it doesn't regenerate merge proposals? [15:23] poolie: just checking but: https://code.edge.launchpad.net/~mbp/bzr/417881-selftest-no-apport/+merge/18489 [15:23] should only have a small bit, right? [15:27] jam, oops, i forgot to set the dependent branch [15:28] if i resubmit it might update [15:28] poolie: well, I can just review locally [15:28] i'll redo it [15:28] but your dependent branch landed [15:28] try https://code.edge.launchpad.net/~mbp/bzr/417881-selftest-no-apport/+merge/18527 [15:28] and the diff is still the full diff [15:28] yes i saw [15:28] poolie: yeah, small diff now [15:29] hmm... I often find the bzr version to be useful, it was nice to have a known location (scroll to the bottom). However, I can live with it being moved [15:29] why plugins before arguments? [15:30] mm [15:30] i could revert that [15:30] poolie: and why have APPORT_DISABLE in the selftest command, rather than in the TestCase setUp() ? [15:30] it was a bit impulsive [15:31] because the plugin list made the traceback scroll off the screen on my laptop [15:31] jam, for the second, it's because you don'nt want to see it if there is eg a SyntaxError [15:31] or ^C [15:31] I already have it in setUp actually [15:31] poolie: ah, so you are just getting it disabled earlier... [15:32] anyway, if you feel it is nicer, fine with me [15:32] i don't want apport to pop up if i ^c a test run [15:32] and it does at the moment [15:32] arguably we should not do that in any case actually [15:32] hm [15:32] poolie: does it pop up if you ^C a normal command? [15:32] that doesn't seem ideal [15:32] no it doesn't, does it [15:33] ^C log should *not* pop up an apport [15:33] agree [15:33] though we have specific code there [15:33] which may catch it at a different level [15:33] the @display_command decorator [15:33] in normal use it doesn't seem to pop up [15:33] and it shouldn't [15:33] well [15:35] report_exception distinguishes ^c and various other things, and that should normally be on the path to report_bug [15:38] poolie: so it would seem odd that selftest would act differently here [15:38] jam, actually i think perhaps for errors in selftest we want just a shorter display [15:38] i'm not sure why [15:38] it did happen [15:38] perhaps i hit some narrow window [15:38] actually i could have interrupted it even before it got to establishing our thing [15:38] our except block [15:39] so i might have been seeing the ubuntu-wide reporter [15:57] james_w: /wave if you're around [16:05] poolie: Is https://code.edge.launchpad.net/~mbp/bzr/bzr-fail supposed to exist? [16:06] poolie: crash.py links to it in a comment, but it 404s for me. === salgado-lunch is now known as salgado [16:15] hi peng [16:15] Peng sorry it's ~mbp/+junk/bzr-fail [16:47] rockstar: for some reason I have recorded that we wanted a phone call today. Did I just write down the date wrong from when we talked 2 weeks ago? [16:47] jam, that was from when we talked a few weeks ago, methinks. [16:47] yeah, that's what I thought, but I just wanted to make sure [17:07] poolie: hihi [17:08] hey lifeless [17:08] odd to see you come online after me :) [17:08] well, depending on where you set the before/after threshold [17:08] jam: H :). I'm normally after you :) [17:13] hi lifeless [17:21] blam [17:21] that was rude [17:23] welcome back all :-/ [17:25] ~. [17:35] vila: check your xp-32bits vm [17:35] LOL [17:36] jam: now, that's a private chat :D [17:36] * vila pants on [18:29] jam, hi, really away? [18:30] igc, hi, around? [18:33] poolie: I'm about to EOD :) Moving all test servers out of bzrlib.transport ends up being a *masssssive* cleanup, the patch is ~4700 lines but all tests are passing again... [18:33] vila, hm [18:33] is the bug in 2.1? [18:34] yup, but the patch for the bug is far smaller and already proposed [18:34] i don't think that's a reasonable change to land there [18:34] oh good [18:34] I'll target bzr.dev for the big one [18:35] this just happened to me: [18:35] adeuring: 'cd patches-view-mega-integration; bzr merge ../db-devel' [18:35] Warning: criss-cross merge encountered. See bzr help criss-cross. [18:36] I now have 4 conflicts in the integration branch. I can resolve them, but if I commit, and my integration branch is later merged to db-devel, will that screw up db-devel's history? [18:36] poolie: ^^ [18:37] anyone? :-) ^^ [18:37] kfogel: no :) [18:37] poolie: thank you [18:38] poolie: So I got to this via the following route: [18:38] cd patches-view-mega-integration [18:38] bzr merge https://code.edge.launchpad.net/~intellectronica/launchpad/sort-by-patch-age (which is based off p-v-mega-integration) [18:38] bzr commit [18:38] cd ../db-devel [18:39] bzr pull [18:39] (see many updates come down) [18:39] hey [18:39] cd ../patches-view-mega-integration [18:39] poolie: I'm just back from lunch [18:39] bzr merge ../db-devel [18:39] poolie: that's when I got the criss-cross merge warning. [18:39] poolie: if I had done this in the other order -- merged db-devel into p-v-m-integration first, and *then* merged intellectronica's branch, would that have avoided the warning? [18:40] (and more importantly, avoided the conflicts?) [18:40] kfogel: you merged sort-by-patch-age back into the branch it was based on, right? [18:40] jam: uh, right [18:40] #1 you could try "bzr merge --weave" to avoid the conflicts [18:41] gerard_: hey [18:41] My guess is that something merged into pvmi was also merged into db-devel [18:41] perhaps unrelated to what you were doing [18:41] jam: so the order in which I merged first sort-by-patch-age and then db-devel into p-v-m-integration is not itself an issue here, then? [18:41] kfogel: so the criss-cross happens when a feature branch is merged into 2 integration branches, which are themselves merged into eachother [18:42] jam: *nod* [18:42] 1 isn't enough to trigger criss-cross, but if it happens 2 times [18:42] then both of those feature branches are common ancestors [18:42] and we can't trivially pick one over the other [18:43] jam: I'm curious to know more, but we're on very tight deadline right now, so I have to retreat over to #launchpad-dev and just find a way to solve the problem. As long as we can't screw up db-devel's history when we land, I'm happy. [18:43] kfogel: you won't destroy history, and most likely you will resolve the criss-cross [18:43] (so future merges won't complain) [18:43] but you may also try "bzr remerge --weave" etc [18:44] jam: thanks, I clearly need to read up on --weave [18:44] jam: so you're saying just resolving the conflicts will make the criss-cross problem go away for future merges? [18:46] kfogel: well, not resolving the conflicts, but landing a new merge which creates a new ancestor that can be used [18:46] which supersedes both of the old ancestors [18:49] jam: okay, that makes sense, thanks [18:55] I'm trying to look into some of the unicode failures for package-import, anyone know how to get the changelog for a given package? [18:56] (I'm trying to get debian/changelog for a source package) [18:56] Is it just apt-get source? [19:00] Is there a good way to hide the DOS window that starts with the windows GUI? The text that's displaying on it is confusing my co-worker. [19:01] oh, and how would one get the lucid package when you are in a karmic install... [19:01] EdWyse_Office: needs someone to update bzr, no easy way to do it as a user [19:02] Oh! There's an update for that? I just installed it last week from the latest windows build. [19:02] EdWyse_Office: no, I mean someone needs to do coding to make it happen [19:02] needs a change to the build script to build a target that doesn't use a console [19:02] sorry to be unclear about 'update' [19:03] That's okay. I don't have any machines with a windows compiler or I'd fix it myself. [19:14] hi jelmer === eric is now known as Guest56445 [19:22] jam: btw doing three-way inside debian/changelog sections is apparently critical [19:22] for udd [19:22] ++ [19:23] lifeless: o hai [19:23] mtaylor: hi [19:23] lifeless: if you have a sec... I'm trying to use bzr builder to test deb making in hudson, and I'm getting this: http://hudson.drizzle.org/view/Drizzle-build/job/drizzle-build-debian-packaging/232/console [19:24] lifeless: I'm wondering if there's anything you can see in 3 seconds that I'm just stupid about [19:25] the build recipe and the way I'm calling it are: http://pastebin.com/mde396ee [19:26] posssibly an old bzr-uilder [19:26] mtaylor: this is the error?: [19:26] E: drizzle: debian-changelog-file-contains-invalid-email-address hudson@(none) [19:26] you should grab my ppa watching builder branch too [19:26] set an environment variable in hudson for DEB_EMAIL [19:26] sorry DEBEMAIL [19:26] lifeless: ok. I can do that bit ... what about the "file size not the same / file contents don't match errors" ? [19:27] get a newer bzr builder I think [19:27] lifeless: k. will try that. thx! [19:28] mtaylor: in fact its a failure in the package import system too I think [19:29] so its probably dpkg fuckage we need to track down - are you running hardy or newer? [19:30] scratch that, similar not same [19:30] lifeless: it's a squeeze box [19:31] and I'm running lp:bzr-builder ... is there a better branch to follow here? [19:31] so two processes are reading the same tar a second or so apart and reading different lengths [19:31] that's beautiful [19:31] no, unless you want my 'watch the ppa' code, so that you can build in a ppa rather than locally [19:32] I'd ssh in and try debuild [19:32] eventually... but first I'd like to just get the local build working [19:32] local builds are harder :P [19:34] heh. debuilds work just fine... generating source packages on the other hand... [19:34] (expected one of drizzle_daily1.orig.tar.gz,... [19:34] too bad there _is_ a drizzle_daily1.orig.tar.gz in the parent dir :( === salgado is now known as salgado-afk === eric is now known as Guest98573 === radoe_ is now known as radoe [20:26] It's too bad we don't have a quotes page for commit messages... Imagine: [20:27] I so hate TDD: [20:27] (mbp) turn off selftest globally in cmd_selftest [20:27] :D [20:27] of course poolie meant apport... [20:28] hi jam [20:29] Can you tell me what magic bzr-builddeb does when using merge-upstream? It just committed rev4 on the "upstream"(?) branch, conflicted, but I don't know how to revert this, being on "the other"/regular branch at rev17. Can I switch manually to the "upstream" branch? [20:31] james_w: good you are around.. I've done bad things using builddeb.. first the question above.. and then: to fix importing a mangled upstream zip (where I had added debian/ myself apparently), it should be enough to merge a new upstream tarball again (which should then remove debian/) and re-add it after the merge again, correct? You can see it at lp:ubuntu/popfile [20:33] whu [20:33] first question "conflicted" means what? [20:34] after merge-upstream.. some files in debian/ are in a conflicted state (it wanted to remove them, but I had changed them already) [20:35] my plan is to revert, then move debian away.. merge-upstream (which may conflict again), but then it's easier to resolve, commit and add debian again. [20:36] also, I'm wondering what mark-uploaded really does (could not find an answer in the docs) [20:37] vila: Don't forget "silly commit". [20:43] blueyed: it tags with the version number [21:04] hi [21:04] i'm having trubling pushing to github using bzr-git [21:04] C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+ [21:04] ssh://git@github.com:Noldorin/IRC.NET.git [21:04] Permission denied (publickey). [21:04] bzr: ERROR: The remote server unexpectedly closed the connection. [21:07] Noldorin: did you register your public key with github? [21:08] gerard_, i believe i have [21:08] and it's in pageant...at least, it works with normal bzr [21:08] https://github.com/account#profile_bucket [21:08] does pushing using git work? [21:09] Noldorin: I need to login, and I don't have an account there [21:09] I prefer gitorious myself [21:10] gerard_, a normal git push does indeed work [21:10] does --verbose add anything useful? [21:13] i'll take a look [21:13] james_w: I've now uncommitted just before the messup and redone the things.. it's probably very bad for the same reasons why rebase is bad, but should cause no problems, when uploading, does it? [21:18] gerard_, nothing new there [21:19] is there some bzr 2.0 equivalent of Dhtransport option? [21:23] jelmer, hello? [21:23] Noldorin, hi [21:23] hey [21:24] jelmer: hello, found some failing git and hg imports just now... [21:24] jelmer, was just wondering if you had a minute totake a look at a few more of my git/github problems [21:24]