| mkanat | What are "ghosts"? | 00:13 |
|---|---|---|
| mkanat | 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:16 | |
| Peng | Me neither. It sounds scary. | 00:19 |
| mkanat | I'm not quite sure that's what they are--I was just trying to figure it out from the loggerhead code. | 00:21 |
| Peng | That's what they are, AFAIK. | 00:22 |
| Peng | Well, I don't know why you specifically said "but are listed as parent revids for a revision". | 00:22 |
| Peng | 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 |
| Peng | I really don't know any more about ghosts than you do, but you're definitely on the right track, at least. :P | 00:23 |
| mkanat | Hahahaha, okay. :-) | 00:24 |
| mkanat | Peng: Well, here's what loggerhead does to strip ghosts from a graph: | 00:24 |
| mkanat | evision_graph[key] = tuple(parent for parent in parents if parent | 00:24 |
| mkanat | in revision_graph | 00:24 |
| mkanat | (But of course, that first var is "revision_graph", not "evision_graph".) | 00:24 |
| Peng | Hm, good point. | 00:24 |
| * Peng shrugs | 00:24 | |
| mkanat | 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 |
| Peng | IIRC there's not. | 00:49 |
| Peng | I'm dumb, so someone could easily prove me wrong, but don't be too hopeful. | 00:50 |
| mkanat | Okay. But theoretically...I could just take the first part of the tuple, no? | 00:50 |
| mkanat | (the dotted_revno tuple, that is.) | 00:50 |
| Peng | Dotted revnos are based on where it branched *off*, not where it merged back. | 00:52 |
| Peng | Actually, does Loggerhead have a data structure tracking that info? | 00:52 |
| Peng | Or just revids and dotted revnos? | 00:52 |
| mkanat | Peng: It has a *crazy* data structure tracking that info. | 00:52 |
| Peng | :D | 00:53 |
| Peng | If you want to know where it branched off, the revno will tell you that, yes. | 00:54 |
| mkanat | Ah, okay. Yeah, I see that now. Yeah, no, I want to know where it was merged in, unfortunately. | 00:54 |
| mkanat | And it seems to be the only reason we need that crazy data structure. | 00:56 |
| wgrant | 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:18 |
| mkanat | Oh, wow. | 01:19 |
| mkanat | Foreign VCS == confusing. :-) | 01:19 |
| mkanat | Wow, so I have to merge_sort the whole graph to know where a revision was merged in? | 02:07 |
| mkanat | mwhudson: That appears to be the only reason that we have the revision graph. | 02:11 |
| mkanat | (That is, that we have the graph cache.) | 02:11 |
| mwhudson | weeeelll | 02:11 |
| mwhudson | more or less yes | 02:11 |
| mkanat | It seems like bzrlib ought to be able to tell me that more easily, but I'm really not finding a way. | 02:11 |
| mwhudson | revision numbering (the way bzr does it) is slow | 02:11 |
| mwhudson | mkanat: if you can, 'bzr log' would like to talk to you :-) | 02:12 |
| mkanat | mwhudson: Hahaha, but doesn't it just do what I said above? | 02:12 |
| * mkanat goes to go look. | 02:12 | |
| mkanat | See, in bzr log, it makes sense to merge sort the whole graph, because we probably want the whole graph. | 02:12 |
| mkanat | But in loggerhead, it doesn't make any sense, because we just want to know where a single revision was merged in. | 02:13 |
| lifeless | you need an ancestry oracle | 02:14 |
| mkanat | lol | 02:14 |
| === spundun is now known as sp|afk | ||
| mkanat | 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 |
| mwhudson | 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:19 |
| lifeless | mkanat: I wasn't joking, the data structure you need is an ancestry oracle | 02:21 |
| mkanat | lifeless: I'm not familiar with that term.... | 02:21 |
| lifeless | oracles? | 02:21 |
| mkanat | lifeless: Unless you mean the Greek kind, yeah. | 02:22 |
| mwhudson | mkanat: an oracle is something that gives you answers | 02:22 |
| mkanat | Ahh. | 02:22 |
| devmod | if i have a branch inside a branch, will it be listed when looking at the main branch? or are they independent entities? | 02:23 |
| lifeless | deparate | 02:24 |
| lifeless | s/d/s | 02:24 |
| devmod | ohh ok that explains it :) | 02:24 |
| mkanat | lifeless: More like reverse ancestry. | 02:25 |
| mwhudson | mkanat: http://en.wikipedia.org/wiki/Oracle_machine | 02:25 |
| mwhudson | i was interested to read recently that you can prove that P != NP if you assume a particular oracle | 02:26 |
| mkanat | Ha! :-) | 02:26 |
| mkanat | Yes, that's what I need, is a "where did this thing merge into" oracle. | 02:26 |
| bob2 | send your revid on a postcard to lifeless | 02:27 |
| mkanat | lol | 02:27 |
| mkanat | 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:27 |
| mkanat | mwhudson: I suppose another option is to AJAX any operation that needs that information. | 02:28 |
| mwhudson | mkanat: weeelll | 02:28 |
| mwhudson | i'm not sure that's really an answer | 02:28 |
| mkanat | 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:29 |
| mwhudson | get_revids_from is conceptually pretty easy i think | 02:30 |
| mwhudson | it's just recursively taking the left hand parent from a particular starting point | 02:30 |
| mwhudson | get_merge_point_list i have no idea at all about :-) | 02:31 |
| mwhudson | i think it can probably be taken away and replaced with something much more sensible | 02:31 |
| mkanat | mwhudson: From what I can see in get_revids_from, though, we still need the _rev_info structure. | 02:31 |
| mkanat | mwhudson: At least, if its doc string is accurate. | 02:32 |
| mwhudson | hm, maybe i misremembered | 02:32 |
| mkanat | Okay, yeah, get_merge_point_list can almost certainly be replaced with something simpler. | 02:33 |
| mkanat | It's only used inside of get_changes. | 02:33 |
| mwhudson | my memories are awakening slightly | 02:34 |
| mwhudson | i think get_revids_from is like that for the case where you're showing changes to a particular file | 02:34 |
| james_w | finding *a* point a revision was merged in is not hard, finding the point it was first merged is much more work | 02:35 |
| mwhudson | 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:35 |
| mkanat | mwhudson: Yeah, it's mostly used in get_file_view. | 02:36 |
| mwhudson | ah ok | 02:43 |
| mwhudson | there's something else that it would be really nice to achieve as a side effect of this stuff | 02:43 |
| mwhudson | and that's aligning the apis in history.py rather more with the uses of said apis | 02:43 |
| mwhudson | (after all, there aren't very many such uses) | 02:44 |
| mkanat | You know, yeah, I was kind of thinking about that. | 02:44 |
| lifeless | mwhudson: ciik | 02:44 |
| mwhudson | lifeless: ? | 02:45 |
| mwhudson | lifeless: is your right hand one key to the left? | 02:45 |
| devmod | uhm what would a bzr repo structure look like for a project (done the bzr way) ? | 02:45 |
| mwhudson | mkanat: it's not as bad as it used to be :-p | 02:45 |
| mkanat | mwhudson: :-) | 02:46 |
| mkanat | mwhudson: Was History written more as a generic representation and then brought to use afterward? | 02:46 |
| mwhudson | mkanat: no idea | 02:46 |
| mkanat | Okay. | 02:47 |
| mwhudson | mkanat: as you said earlier, it's probably still got lots of hgweb in it | 02:47 |
| * mkanat nods. | 02:47 | |
| mkanat | At the least, I could sane-iify _rev_info. | 02:47 |
| mkanat | That might tell me a bit more about what information we're actually using from it. | 02:48 |
| mkanat | 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:50 |
| mkanat | 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 |
| mkanat | That will probably have to happen tomorrow; today I've been working for like 10-ish hours now. | 02:51 |
| mwhudson | mkanat: that would be very useful | 02:52 |
| mkanat | mwhudson: Okay. :-) | 02:52 |
| mwhudson | mkanat: though i'd meta-ize that even one more step | 02:52 |
| mwhudson | mkanat: what do we WANT to use this information for? | 02:52 |
| mwhudson | that may not be what we're currently doing :) | 02:52 |
| mkanat | mwhudson: Oh, that's a good point too. | 02:52 |
| devmod | any suggestion on how to checkout a project with symlinks on windows? | 04:25 |
| bob2 | what happens when you try? | 04:32 |
| devmod | error lol | 04:40 |
| devmod | bzr: ERROR: Unable to create symlink | 04:41 |
| nicoInattendu | Hi, there is bazaar command to list all the modified files ? | 05:46 |
| nicoInattendu | like bzr diff -r 37.., but who displays only modified files | 05:46 |
| Kamping_Kaiser | status? | 05:47 |
| Kamping_Kaiser | bzr help modified | 05:48 |
| Kamping_Kaiser | Purpose: List files modified in working tree. | 05:48 |
| Kamping_Kaiser | ? | 05:48 |
| nicoInattendu | Ok thanks Is exctly why I needed. | 05:49 |
| nicoInattendu | bzr status -r 37.. : Is exactly what I m looking for | 05:49 |
| nicoInattendu | Thanks ! | 05:50 |
| vila | YES ! news_merge plugin works :D | 08:37 |
| mneptok | vila: so i can push branches to CNN? | 08:38 |
| vila | mneptok: not yet, we are still sorting out the deal. But you can pull in the mean time :D | 08:39 |
| gerard_ | hey | 08:42 |
| gerard_ | igc & other devs: maybe you could take a look at https://code.launchpad.net/~gerard-/bzr/update ? | 08:43 |
| bialix | vila: do you have an URL? | 09:42 |
| vila | bialix: for the news_merge plugin ? It's part of bzr.dev | 09:43 |
| bialix | ok | 09:43 |
| vila | bialix: hi by the way :D | 09:43 |
| bialix | hi vila | 09:43 |
| vila | 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:44 |
| bialix | щл | 09:45 |
| bialix | ok | 09:45 |
| bialix | sorry | 09:45 |
| vila | bialix: its aim is to avoid the usual conflicts in NEWS and I see it work live minutes ago :D | 09:45 |
| bialix | vila: I understand what you talking about | 09:45 |
| bialix | it's great | 09:45 |
| bialix | is it possible to write my own mergers? without rocket sciense? | 09:46 |
| bialix | e.g. for PO or XML files... | 09:46 |
| vila | yeah, just have a look at it or the one we implemented for bzr-builddeb | 09:46 |
| bialix | I'm not good in bzr-buildeb staff | 09:47 |
| vila | hmm, both are extremely good ideas | 09:47 |
| bialix | I hope there will be some simple way to plug-in extrnal utility | 09:48 |
| bialix | vila: how's 2.1 going? | 09:48 |
| vila | bialix: look at revno 399 in bzr-builddeb trunk, the parts you need are mostly in __init__.py | 09:49 |
| vila | bialix: 2.1.0final should be cut tomorrow AIUI | 09:50 |
| bialix | COOL | 09:50 |
| bialix | this is good news | 09:50 |
| bialix | custom mergers are part of 2.1, right? | 09:50 |
| vila | bialix: yes | 09:56 |
| vila | bialix: but 2.1.0rc2 has a bug which will be fixed in 2.1.0final | 09:56 |
| vila | bialix: I merged the fix into bzr.dev though | 09:57 |
| bialix | news_merge.py does not seems very simple though | 10:00 |
| vila | bialix: plugging a merge algorithm is simple, the algorithm itself remains.... hard stuff | 10:00 |
| bialix | yep | 10:01 |
| bialix | may I suggest to provide an example of invoking external utility (like diff3) for merging? | 10:01 |
| bialix | the signature is simply awful: def merge_text(self, params): | 10:02 |
| bialix | what is params? | 10:02 |
| vila | 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 |
| vila | I'm pretty sure it's documented at the hook level | 10:03 |
| vila | bialix: search for MergeHookParams in merge.py | 10:05 |
| bialix | ok | 10:07 |
| === salgado-afk is now known as salgado | ||
| === sven is now known as Guest47505 | ||
| jam | morning all | 14:22 |
| jelmer | 'lo | 14:25 |
| rubbs | morning | 14:27 |
| === salgado is now known as salgado-lunch | ||
| vila | morning jam | 14:56 |
| vila | 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:58 |
| vila | Hmm, well callable in the case I'm interested in is __init__ or __new__ if that may help | 14:59 |
| jam | vila: http://paste.ubuntu.com/368238/ | 15:12 |
| jam | func.__self__.__class__ | 15:12 |
| vila | jam: that doesn't work if the method is inherited | 15:13 |
| poolie | hi vila | 15:13 |
| poolie | and jam | 15:13 |
| vila | jam: let say B inherits from A which define methA, I'd like to get 'A' from B().methA | 15:14 |
| poolie | vila, thanks for taking that sftp hook | 15:14 |
| vila | hey poolie ! | 15:14 |
| jam | hi poolie | 15:14 |
| vila | poolie: I'm trying to go a step further and move all test servers out of bzrlib.transport | 15:14 |
| jam | vila: f.im_class ? | 15:14 |
| vila | poolie: but I run into a problem when deprecating transport.Server | 15:14 |
| poolie | vila, yay | 15:14 |
| vila | I use a deprecated_method decorator but the message mention the daughter class which looks a bit silly | 15:15 |
| vila | a deprecated_method on __init__ tha is | 15:15 |
| vila | that | 15:15 |
| vila | jam: no im_class there :-/ | 15:15 |
| jam | well, func.im_class seems to be the same as func.__self__.__class__ in my checking | 15:16 |
| vila | __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 |
| vila | jam: are you trying on an __init__ method ? | 15:17 |
| jam | vila: No, but regardless, I'm not really seeing anything to get at it | 15:18 |
| jam | o.func.im_class == child | 15:18 |
| vila | well, I think I'll punt and see if some reviewer has better ideas :D | 15:18 |
| jam | you could always just manually deprecate something if you need to... | 15:19 |
| vila | you mean inlining deprecated_method in my __init__ method ? | 15:19 |
| poolie | vila, just inline a specific message | 15:20 |
| vila | will do | 15:20 |
| jam | is there an open bug that when bzr.dev gets updated it doesn't regenerate merge proposals? | 15:23 |
| jam | poolie: just checking but: https://code.edge.launchpad.net/~mbp/bzr/417881-selftest-no-apport/+merge/18489 | 15:23 |
| jam | should only have a small bit, right? | 15:23 |
| poolie | jam, oops, i forgot to set the dependent branch | 15:27 |
| poolie | if i resubmit it might update | 15:28 |
| jam | poolie: well, I can just review locally | 15:28 |
| poolie | i'll redo it | 15:28 |
| jam | but your dependent branch landed | 15:28 |
| poolie | try https://code.edge.launchpad.net/~mbp/bzr/417881-selftest-no-apport/+merge/18527 | 15:28 |
| jam | and the diff is still the full diff | 15:28 |
| poolie | yes i saw | 15:28 |
| jam | poolie: yeah, small diff now | 15:28 |
| jam | 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 |
| jam | why plugins before arguments? | 15:29 |
| poolie | mm | 15:30 |
| poolie | i could revert that | 15:30 |
| jam | poolie: and why have APPORT_DISABLE in the selftest command, rather than in the TestCase setUp() ? | 15:30 |
| poolie | it was a bit impulsive | 15:30 |
| poolie | because the plugin list made the traceback scroll off the screen on my laptop | 15:31 |
| poolie | jam, for the second, it's because you don'nt want to see it if there is eg a SyntaxError | 15:31 |
| poolie | or ^C | 15:31 |
| poolie | I already have it in setUp actually | 15:31 |
| jam | poolie: ah, so you are just getting it disabled earlier... | 15:31 |
| jam | anyway, if you feel it is nicer, fine with me | 15:32 |
| poolie | i don't want apport to pop up if i ^c a test run | 15:32 |
| poolie | and it does at the moment | 15:32 |
| poolie | arguably we should not do that in any case actually | 15:32 |
| poolie | hm | 15:32 |
| jam | poolie: does it pop up if you ^C a normal command? | 15:32 |
| jam | that doesn't seem ideal | 15:32 |
| poolie | no it doesn't, does it | 15:32 |
| jam | ^C log should *not* pop up an apport | 15:33 |
| poolie | agree | 15:33 |
| jam | though we have specific code there | 15:33 |
| jam | which may catch it at a different level | 15:33 |
| jam | the @display_command decorator | 15:33 |
| poolie | in normal use it doesn't seem to pop up | 15:33 |
| poolie | and it shouldn't | 15:33 |
| poolie | well | 15:33 |
| poolie | report_exception distinguishes ^c and various other things, and that should normally be on the path to report_bug | 15:35 |
| jam | poolie: so it would seem odd that selftest would act differently here | 15:38 |
| poolie | jam, actually i think perhaps for errors in selftest we want just a shorter display | 15:38 |
| poolie | i'm not sure why | 15:38 |
| poolie | it did happen | 15:38 |
| poolie | perhaps i hit some narrow window | 15:38 |
| poolie | actually i could have interrupted it even before it got to establishing our thing | 15:38 |
| poolie | our except block | 15:38 |
| poolie | so i might have been seeing the ubuntu-wide reporter | 15:39 |
| jam | james_w: /wave if you're around | 15:57 |
| Peng | poolie: Is https://code.edge.launchpad.net/~mbp/bzr/bzr-fail supposed to exist? | 16:05 |
| Peng | poolie: crash.py links to it in a comment, but it 404s for me. | 16:06 |
| === salgado-lunch is now known as salgado | ||
| poolie | hi peng | 16:15 |
| poolie | Peng sorry it's ~mbp/+junk/bzr-fail | 16:15 |
| jam | 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 |
| rockstar | jam, that was from when we talked a few weeks ago, methinks. | 16:47 |
| jam | yeah, that's what I thought, but I just wanted to make sure | 16:47 |
| lifeless | poolie: hihi | 17:07 |
| jam | hey lifeless | 17:08 |
| jam | odd to see you come online after me :) | 17:08 |
| jam | well, depending on where you set the before/after threshold | 17:08 |
| lifeless | jam: H :). I'm normally after you :) | 17:08 |
| poolie | hi lifeless | 17:13 |
| vila | blam | 17:21 |
| vila | that was rude | 17:21 |
| vila | welcome back all :-/ | 17:23 |
| poolie | ~. | 17:25 |
| jam | vila: check your xp-32bits vm | 17:35 |
| vila | LOL | 17:35 |
| vila | jam: now, that's a private chat :D | 17:36 |
| * vila pants on | 17:36 | |
| poolie | jam, hi, really away? | 18:29 |
| poolie | igc, hi, around? | 18:30 |
| vila | 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 |
| poolie | vila, hm | 18:33 |
| poolie | is the bug in 2.1? | 18:33 |
| vila | yup, but the patch for the bug is far smaller and already proposed | 18:34 |
| poolie | i don't think that's a reasonable change to land there | 18:34 |
| poolie | oh good | 18:34 |
| vila | I'll target bzr.dev for the big one | 18:34 |
| kfogel | this just happened to me: | 18:35 |
| kfogel | <kfogel> adeuring: 'cd patches-view-mega-integration; bzr merge ../db-devel' | 18:35 |
| kfogel | <kfogel> Warning: criss-cross merge encountered. See bzr help criss-cross. | 18:35 |
| kfogel | 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 |
| kfogel | poolie: ^^ | 18:36 |
| kfogel | anyone? :-) ^^ | 18:37 |
| poolie | kfogel: no :) | 18:37 |
| kfogel | poolie: thank you | 18:37 |
| kfogel | poolie: So I got to this via the following route: | 18:38 |
| kfogel | cd patches-view-mega-integration | 18:38 |
| kfogel | bzr merge https://code.edge.launchpad.net/~intellectronica/launchpad/sort-by-patch-age (which is based off p-v-mega-integration) | 18:38 |
| kfogel | bzr commit | 18:38 |
| kfogel | cd ../db-devel | 18:38 |
| kfogel | bzr pull | 18:39 |
| kfogel | (see many updates come down) | 18:39 |
| gerard_ | hey | 18:39 |
| kfogel | cd ../patches-view-mega-integration | 18:39 |
| jam | poolie: I'm just back from lunch | 18:39 |
| kfogel | bzr merge ../db-devel | 18:39 |
| kfogel | poolie: that's when I got the criss-cross merge warning. | 18:39 |
| kfogel | 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:39 |
| kfogel | (and more importantly, avoided the conflicts?) | 18:40 |
| jam | kfogel: you merged sort-by-patch-age back into the branch it was based on, right? | 18:40 |
| kfogel | jam: uh, right | 18:40 |
| jam | #1 you could try "bzr merge --weave" to avoid the conflicts | 18:40 |
| rubbs | gerard_: hey | 18:41 |
| jam | My guess is that something merged into pvmi was also merged into db-devel | 18:41 |
| jam | perhaps unrelated to what you were doing | 18:41 |
| kfogel | 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 |
| jam | kfogel: so the criss-cross happens when a feature branch is merged into 2 integration branches, which are themselves merged into eachother | 18:41 |
| kfogel | jam: *nod* | 18:42 |
| jam | 1 isn't enough to trigger criss-cross, but if it happens 2 times | 18:42 |
| jam | then both of those feature branches are common ancestors | 18:42 |
| jam | and we can't trivially pick one over the other | 18:42 |
| kfogel | 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 |
| jam | kfogel: you won't destroy history, and most likely you will resolve the criss-cross | 18:43 |
| jam | (so future merges won't complain) | 18:43 |
| jam | but you may also try "bzr remerge --weave" etc | 18:43 |
| kfogel | jam: thanks, I clearly need to read up on --weave | 18:44 |
| kfogel | jam: so you're saying just resolving the conflicts will make the criss-cross problem go away for future merges? | 18:44 |
| jam | kfogel: well, not resolving the conflicts, but landing a new merge which creates a new ancestor that can be used | 18:46 |
| jam | which supersedes both of the old ancestors | 18:46 |
| kfogel | jam: okay, that makes sense, thanks | 18:49 |
| jam | 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:55 |
| jam | (I'm trying to get debian/changelog for a source package) | 18:56 |
| jam | Is it just apt-get source? | 18:56 |
| EdWyse_Office | 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:00 |
| jam | oh, and how would one get the lucid package when you are in a karmic install... | 19:01 |
| jam | EdWyse_Office: needs someone to update bzr, no easy way to do it as a user | 19:01 |
| EdWyse_Office | Oh! There's an update for that? I just installed it last week from the latest windows build. | 19:02 |
| jam | EdWyse_Office: no, I mean someone needs to do coding to make it happen | 19:02 |
| jam | needs a change to the build script to build a target that doesn't use a console | 19:02 |
| jam | sorry to be unclear about 'update' | 19:02 |
| EdWyse_Office | That's okay. I don't have any machines with a windows compiler or I'd fix it myself. | 19:03 |
| Noldorin | hi jelmer | 19:14 |
| === eric is now known as Guest56445 | ||
| lifeless | jam: btw doing three-way inside debian/changelog sections is apparently critical | 19:22 |
| lifeless | for udd | 19:22 |
| mtaylor | ++ | 19:22 |
| mtaylor | lifeless: o hai | 19:23 |
| lifeless | mtaylor: hi | 19:23 |
| mtaylor | 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:23 |
| mtaylor | lifeless: I'm wondering if there's anything you can see in 3 seconds that I'm just stupid about | 19:24 |
| mtaylor | the build recipe and the way I'm calling it are: http://pastebin.com/mde396ee | 19:25 |
| lifeless | posssibly an old bzr-uilder | 19:26 |
| jam | mtaylor: this is the error?: | 19:26 |
| jam | E: drizzle: debian-changelog-file-contains-invalid-email-address hudson@(none) | 19:26 |
| lifeless | you should grab my ppa watching builder branch too | 19:26 |
| lifeless | set an environment variable in hudson for DEB_EMAIL | 19:26 |
| lifeless | sorry DEBEMAIL | 19:26 |
| mtaylor | lifeless: ok. I can do that bit ... what about the "file size not the same / file contents don't match errors" ? | 19:26 |
| lifeless | get a newer bzr builder I think | 19:27 |
| mtaylor | lifeless: k. will try that. thx! | 19:27 |
| lifeless | mtaylor: in fact its a failure in the package import system too I think | 19:28 |
| lifeless | so its probably dpkg fuckage we need to track down - are you running hardy or newer? | 19:29 |
| lifeless | scratch that, similar not same | 19:30 |
| mtaylor | lifeless: it's a squeeze box | 19:30 |
| mtaylor | and I'm running lp:bzr-builder ... is there a better branch to follow here? | 19:31 |
| lifeless | so two processes are reading the same tar a second or so apart and reading different lengths | 19:31 |
| mtaylor | that's beautiful | 19:31 |
| lifeless | no, unless you want my 'watch the ppa' code, so that you can build in a ppa rather than locally | 19:31 |
| lifeless | I'd ssh in and try debuild | 19:32 |
| mtaylor | eventually... but first I'd like to just get the local build working | 19:32 |
| lifeless | local builds are harder :P | 19:32 |
| mtaylor | heh. debuilds work just fine... generating source packages on the other hand... | 19:34 |
| mtaylor | (expected one of drizzle_daily1.orig.tar.gz,... | 19:34 |
| mtaylor | too bad there _is_ a drizzle_daily1.orig.tar.gz in the parent dir :( | 19:34 |
| === salgado is now known as salgado-afk | ||
| === eric is now known as Guest98573 | ||
| === radoe_ is now known as radoe | ||
| vila | It's too bad we don't have a quotes page for commit messages... Imagine: | 20:26 |
| vila | I so hate TDD: | 20:27 |
| vila | (mbp) turn off selftest globally in cmd_selftest | 20:27 |
| vila | :D | 20:27 |
| vila | of course poolie meant apport... | 20:27 |
| james_w | hi jam | 20:28 |
| blueyed | 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:29 |
| blueyed | 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:31 |
| james_w | whu | 20:33 |
| james_w | first question "conflicted" means what? | 20:33 |
| blueyed | after merge-upstream.. some files in debian/ are in a conflicted state (it wanted to remove them, but I had changed them already) | 20:34 |
| blueyed | 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:35 |
| blueyed | also, I'm wondering what mark-uploaded really does (could not find an answer in the docs) | 20:36 |
| Peng | vila: Don't forget "silly commit". | 20:37 |
| james_w | blueyed: it tags with the version number | 20:43 |
| Noldorin | hi | 21:04 |
| Noldorin | i'm having trubling pushing to github using bzr-git | 21:04 |
| Noldorin | C:\Users\Alex\Documents\Visual Studio 2010\Projects\IRC.NET\devel>bzr dpush git+ | 21:04 |
| Noldorin | ssh://git@github.com:Noldorin/IRC.NET.git | 21:04 |
| Noldorin | Permission denied (publickey). | 21:04 |
| Noldorin | bzr: ERROR: The remote server unexpectedly closed the connection. | 21:04 |
| gerard_ | Noldorin: did you register your public key with github? | 21:07 |
| Noldorin | gerard_, i believe i have | 21:08 |
| Noldorin | and it's in pageant...at least, it works with normal bzr | 21:08 |
| Noldorin | https://github.com/account#profile_bucket | 21:08 |
| gerard_ | does pushing using git work? | 21:08 |
| gerard_ | Noldorin: I need to login, and I don't have an account there | 21:09 |
| gerard_ | I prefer gitorious myself | 21:09 |
| Noldorin | gerard_, a normal git push does indeed work | 21:10 |
| gerard_ | does --verbose add anything useful? | 21:10 |
| Noldorin | i'll take a look | 21:13 |
| blueyed | 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:13 |
| Noldorin | gerard_, nothing new there | 21:18 |
| Noldorin | is there some bzr 2.0 equivalent of Dhtransport option? | 21:19 |
| Noldorin | jelmer, hello? | 21:23 |
| jelmer | Noldorin, hi | 21:23 |
| Noldorin | hey | 21:23 |
| mwhudson | jelmer: hello, found some failing git and hg imports just now... | 21:24 |
| Noldorin | jelmer, was just wondering if you had a minute totake a look at a few more of my git/github problems | 21:24 |
| jelmer | mwhudson, hey | 21:24 |
| jelmer | Noldorin, sure, which ones? | 21:24 |
| Noldorin | i'm still getting the "permission denied" error | 21:24 |
| mwhudson | git: https://code.edge.launchpad.net/~vcs-imports/buildbot/trunk | 21:24 |
| mwhudson | hg: https://code.launchpad.net/~vcs-imports/cython/latest | 21:24 |
| Noldorin | jelmer, should be just a little bit up in your log | 21:24 |
| jelmer | Noldorin: -Dtransport ? | 21:25 |
| mwhudson | jelmer: amusingly the last two failures for cython are completely different... | 21:25 |
| Noldorin | ah, i had the option wrong | 21:25 |
| Noldorin | cheers | 21:25 |
| jelmer | mwhudson, have you tried removing and re-adding the buildbot import ? | 21:26 |
| Noldorin | jelmer, http://pastebin.com/m3efbfff4 | 21:26 |
| mwhudson | jelmer: admittedly, no | 21:26 |
| jelmer | mwhudson, can you file a bug about the cython issue? | 21:27 |
| jelmer | I don't think there is one yet | 21:27 |
| mwhudson | jelmer: ok | 21:27 |
| jelmer | Noldorin, you need to use a / rather than a : to separate the hostname and the path in a URL | 21:27 |
| Noldorin | jelmer, oh. makes exactly no difference to the log output though :S | 21:28 |
| Noldorin | same stack trace exactly | 21:28 |
| Noldorin | for git+ssh://git@github.com/Noldorin/IRC.NET.git | 21:28 |
| mwhudson | jelmer: https://bugs.edge.launchpad.net/bzr-hg/+bug/516758 | 21:29 |
| ubottu | Ubuntu bug 516758 in bzr-hg "cython import fails with unicode and infinite recurson" [Undecided,New] | 21:29 |
| jelmer | mwhudson, thanks | 21:29 |
| jelmer | Noldorin: I can connect just fine and get a proper error: | 21:30 |
| jelmer | ERROR: Permission to Noldorin/IRC.NET denied to jelmer. | 21:30 |
| Noldorin | hrm | 21:30 |
| Noldorin | jelmer, what seems to be the problem then...bad installation? | 21:30 |
| Noldorin | i thought i finalyl had a good installation after all the trouble last time :/ | 21:30 |
| jelmer | Noldorin, your ssh setup - can you connect to github manually using ssh? | 21:31 |
| Noldorin | jelmer, how would i test that? | 21:31 |
| jelmer | Noldorin: use a ssh client to try to log in | 21:31 |
| Noldorin | if you remember, i'm on windows btw. but if i'm going to have to use cygwin, that is ok i guess | 21:31 |
| Noldorin | k | 21:31 |
| jelmer | Noldorin: how do you have your ssh key set up? | 21:33 |
| jelmer | using pageant? If so, please try putty | 21:33 |
| Noldorin | jelmer, it seems to authenticate, but the putty window closes before i can see properly | 21:33 |
| Noldorin | yeah | 21:33 |
| Noldorin | in pageant | 21:33 |
| jelmer | ok, so the ssh side of things seems to work | 21:33 |
| Noldorin | and i have paramiko or whatever set up | 21:33 |
| Noldorin | yeah | 21:33 |
| jelmer | and connecting to launchpad works too? | 21:33 |
| Noldorin | yep | 21:34 |
| jelmer | (over ssh, that is) | 21:34 |
| jelmer | mwhudson: the recursive call thing seems weird | 21:34 |
| Noldorin | jelmer, oh hmm | 21:36 |
| Noldorin | seems there is a problem actually | 21:36 |
| Noldorin | putty displays the output: | 21:36 |
| Noldorin | Using username "git". | 21:36 |
| Noldorin | Authenticating with public key "noldorin-dev@noldorin.com" from ageant | 21:37 |
| Noldorin | Server regused to allocate pty | 21:37 |
| Noldorin | --- | 21:37 |
| jelmer | that seems right, you're probably not allowed shell access on github :-) | 21:37 |
| Noldorin | ah | 21:37 |
| Noldorin | jelmer, if you want me to add your public key on github, so you can try pushing to the project yourself, i'll be happy to do that | 21:38 |
| Noldorin | jelmer, ? | 21:42 |
| jam | hey james_w, I had some questions about the builddeb stuff | 21:43 |
| jam | #1, I've started switching the per-file hook over to using debian_bundle, and then updating it to do a 3-way merge | 21:44 |
| jam | But also, I poked around the Unicode handling. | 21:44 |
| jam | which basically seemed... it doesn't very much | 21:44 |
| jam | And I was wondering if we should be hacking python-debian, or bzr-builddeb for that sort of change | 21:45 |
| jelmer | Noldorin: We can give it a try, but I doubt that'll fail. | 21:45 |
| Noldorin | jelmer: would be helpful to see anyway, if you don't mind :) | 21:45 |
| Noldorin | you just pushing anything from bzr-git.... | 21:45 |
| jelmer | Noldorin, see privmsg | 21:45 |
| Noldorin | k | 21:47 |
| jelmer | Noldorin, should be pushed now | 21:53 |
| Noldorin | ok i'll check | 21:53 |
| Noldorin | jelmer, you pushed from a bzr repo? | 21:55 |
| jelmer | Noldorin, yep | 21:55 |
| jelmer | ganieda:~/tmp/IRC.NET.git% bzr dpush git+ssh://git@github.com/Noldorin/IRC.NET.git | 21:55 |
| Noldorin | hmm, ok | 21:55 |
| jelmer | so there's either something broken in dulwich/bzr-git on windows or an issue in your ssh setup | 21:56 |
| lifeless | jam: python-debian | 21:59 |
| lifeless | unless it seems bzr glue specific | 21:59 |
| Noldorin | jelmer: hmm. maybe i should give up with windows and just get it working on cygwin? | 22:01 |
| jelmer | Noldorin: to be honest, it's very hard to recommend anything without knowing exactly what's going wrong | 22:01 |
| jelmer | Noldorin: have you asked on the bzr(-windows) mailing list? | 22:02 |
| Noldorin | jelmer: could we have a go setting it up on cygwin at least perhaps? | 22:02 |
| Noldorin | not yet... | 22:02 |
| jelmer | I'm not the best authority on bzr-git on windows, since I don't run windows but I know other people have. | 22:02 |
| Noldorin | jelmer, you are the best authority on bzr-git in general though :D | 22:03 |
| james_w | jam: either works for me, I have commit rights for both | 22:03 |
| jelmer | Noldorin: I'm not convinced this is a bzr-git problem though | 22:03 |
| Noldorin | hrm | 22:03 |
| Noldorin | jelmer: i'd like to at least try it out on cygwin though, and see from there, if you don't mind suggesting a few things :) | 22:03 |
| jam | lifeless, james-w: so python-debian and bzr-builddeb sort of need to keep in sync. As to whether Block.author is a unicode or str object | 22:04 |
| jam | because we can't have them both .decode | 22:04 |
| jam | or neither :) | 22:04 |
| jelmer | Noldorin: sure | 22:04 |
| Noldorin | wait a sec: how does bzr-git get the ssh key? | 22:05 |
| Noldorin | and authenticate | 22:05 |
| Noldorin | does it do the paramiko/pageant stuff separetly? | 22:05 |
| jelmer | Noldorin: it uses the normal functionality in bzr for using ssh | 22:06 |
| Noldorin | jelmer, which means it's quite odd ssh auth is working fine normally, but not for bzr-git :S | 22:06 |
| Noldorin | jelmer: well, i am getting the same error udner cygwin, but that's probably because it's using the windows path | 22:06 |
| Noldorin | hrmmm | 22:08 |
| Noldorin | jelmer, maybe there is some way to detect which key bzr-git is using? | 22:08 |
| james_w | jam: I guess we should keep python-debian the same them so it doesn't break API for others | 22:09 |
| jelmer | Noldorin: the login seems to work but the server hangs up | 22:09 |
| Noldorin | hmm | 22:09 |
| Noldorin | jelmer,anything to suggest then? | 22:10 |
| jelmer | Noldorin, are you familiar with python ? | 22:10 |
| jelmer | can you add a "print path" statement in dulwich/client.py, SSHGitClient.send_pack() ? | 22:11 |
| Noldorin | jelmer: not really, but i've messed with it a *very small* bit, and program in other languages | 22:11 |
| Noldorin | so if you give me the code to paste, i'll be happy to do so :) | 22:11 |
| Noldorin | ok | 22:11 |
| Noldorin | will do | 22:11 |
| Noldorin | so what's the exact line? | 22:11 |
| jam | james_w: where do I file bugs against python-debian? | 22:11 |
| jam | For example, passing an actual file or list of lines to Changelog causes it to add a newline to every line | 22:12 |
| jam | and Version objects implement __eq__ but not __hash__ which means you can't really use them as dict keys | 22:12 |
| jam | (you can get them out with the exact object, but if you try to use an equivalent one, it fails) | 22:12 |
| Noldorin | jelmer,(?) | 22:13 |
| jelmer | Noldorin: add "print path" as the first line in that function | 22:13 |
| james_w | jam: against the debian or ubuntu packages | 22:15 |
| jam | k | 22:19 |
| jam | james_w: https://code.edge.launchpad.net/~jameinel/bzr-builddeb/changelog-parser/+merge/18557 | 22:19 |
| jam | Uses python-debian for parsing | 22:19 |
| jam | and implement 3-way merge logic | 22:19 |
| jam | (for the per-file merge hook) | 22:19 |
| jam | though the diff may need to be updated | 22:19 |
| mtaylor | bzr-builddeb question ... I'm trying a new packaging layout - namely the debian dir in a branch with the upstream code - but bzr-builddeb is still trying to download a tarball rather than creating one from the source tree... am I doing something competely stupid? | 22:20 |
| Noldorin | jelmerkk | 22:20 |
| Noldorin | jelmer, odd, nothing | 22:23 |
| Noldorin | no printed output | 22:23 |
| jelmer | Noldorin: sorry, my bad - it needs to be in fetch_pack | 22:23 |
| james_w | jam: cool, thanks | 22:24 |
| jelmer | Noldorin: Hmm | 22:24 |
| Noldorin | jelmer, ok sure | 22:24 |
| james_w | jam: though the strict= thing is why I am not sure about using it for the parsing | 22:24 |
| jam | james_w: that's what you are doing for import_dsc... | 22:24 |
| james_w | jam: yes, because we don't round trip | 22:24 |
| Noldorin | jelmer, nothing still :S | 22:24 |
| jam | james_w: though if you consider the non-parsing 3-way merge logic | 22:25 |
| jam | I would think this would help improve changelog strictness | 22:25 |
| jam | (be loose in what you accept, but strict in what you emit) | 22:25 |
| jam | If you really wanted, we could set strict=True | 22:25 |
| jam | and if we get an exception | 22:25 |
| jam | we can fall back to the default merge logic | 22:25 |
| jam | (we just need to return 'not_applicable') | 22:26 |
| jam | Though I don't know what exceptions will be raised from python-debian | 22:26 |
| Noldorin | jelmer: | 22:26 |
| Noldorin | def fetch_pack(self, path, determine_wants, graph_walker, pack_data, | 22:26 |
| Noldorin | progress): | 22:26 |
| Noldorin | print path | 22:26 |
| Noldorin | that's the code | 22:26 |
| Noldorin | no luck though | 22:26 |
| Noldorin | jelmer, so it seems it's not even getting that far perhaps? | 22:28 |
| jelmer | Noldorin: I'm quit sure it's getting beyond that point - see the backtrace | 22:28 |
| Noldorin | hrmm | 22:29 |
| Noldorin | then i have no idea why nothing is getting printed | 22:29 |
| jam | james_w: 2 bugs submitted | 22:29 |
| jam | (for python-debian) | 22:29 |
| james_w | thanks | 22:32 |
| Noldorin | jelmer: keep sending me as many tests to make in the python source as you like, i'll be happy to do so. :) | 22:32 |
| mkanat | mwhudson: Off the top of your head, do you know what's up with this? http://bzr.mozilla.org/bugzilla/trunk/files | 22:32 |
| jelmer | Noldorin, are you sure you | 22:32 |
| jelmer | 're editing the right copy of dulwich ? | 22:32 |
| mkanat | mwhudson: (I can't look at the logs on that server.) | 22:32 |
| Noldorin | jelmer: yes, because if i create a syntax error, bzr picks it up | 22:33 |
| mwhudson | mkanat: no | 22:33 |
| mkanat | mwhudson: Okay. | 22:33 |
| mwhudson | jelmer: yes | 22:40 |
| Noldorin | jelmer? | 22:43 |
| lifeless | jam: are you sure 471292 is a dupe? | 22:44 |
| jam | bug 471292 | 22:45 |
| ubottu | Launchpad bug 471292 in bzr-builddeb "import-dsc fails on UTF-8 characters (dup-of: 508251)" [Wishlist,Confirmed] https://launchpad.net/bugs/471292 | 22:45 |
| ubottu | Launchpad bug 508251 in udd "Failure to import when decoding changelog authors" [Medium,Confirmed] https://launchpad.net/bugs/508251 | 22:45 |
| Noldorin | jelmer, interesting. it seems path is null/empty | 22:45 |
| jam | lifeless: the former was reporting that it fails when the author name is not ascii | 22:45 |
| Noldorin | since when i print "foo", it works | 22:45 |
| jam | which is what bug 508251 is about | 22:45 |
| lifeless | jam: ah but the source of the data is different I think | 22:46 |
| lifeless | if you look at the crash file, 471292 is failing in import_upstream | 22:46 |
| jelmer | Noldorin: Hmm | 22:46 |
| lifeless | jam: I'm going to undup, I'm pretty convinced its separate | 22:47 |
| jam | lifeless: I'm pretty sure it is effectively a dupe | 22:47 |
| jelmer | Noldorin, what's the exact command you're running? | 22:47 |
| jam | 471292 is because bzr-builddeb is trying to pass a plain str (not Unicode) as the author | 22:47 |
| jam | the others are failing for effectively the same reason | 22:47 |
| jam | it is parsing the Changelog but *not* decoding the entries | 22:48 |
| lifeless | yes, but the source of the strings are different AFAICT | 22:48 |
| Noldorin | jelmer: hmm? "print path" | 22:48 |
| Noldorin | 'print "foo"' works | 22:48 |
| jelmer | Noldorin: No, the bzr command | 22:48 |
| Noldorin | oh sorry | 22:48 |
| jam | lifeless: given the UnicodeDecodeError string, I'm pretty sure it is a failure to decode authors in both cases | 22:48 |
| jam | you can be as picky about exact tracebacks as you like | 22:48 |
| lifeless | jam: hmm, I gues what I want is to know that it is fixed; and I'm concerned that as a dup it won't get separately tested | 22:48 |
| Noldorin | $ bzr dpush git+ssh://git@github.com/Noldorin/IRC.NET.git | 22:49 |
| Noldorin | jelmerthat's it | 22:49 |
| jam | lifeless: as yet, I don't really see how to properly test import_dsc, without just pushing it to james_w and having him run it on the importer... | 22:49 |
| jam | (certainly there are unit tests, but testing with real-world data would be better) | 22:49 |
| jam | I suppose eventually we'll get some real-world test cases | 22:49 |
| lifeless | jam: I'll have a look at 471292 in a few minutes in more depth; if I can't see it using DEBEMAIL then I will redup it for you | 22:50 |
| lifeless | ok ? | 22:50 |
| lifeless | [I'm not trying to be picky about exact tracebacks] | 22:50 |
| jam | If you feel it is a different source, feel free | 22:50 |
| jam | It sure looked the same to me | 22:50 |
| lifeless | ack | 22:50 |
| Noldorin | jelmer: bit busy atm? | 22:56 |
| jelmer | Noldorin, sorry | 22:56 |
| Noldorin | it's ok | 22:56 |
| jelmer | Noldorin: we'd have to debug where that path comes from | 22:56 |
| jelmer | Noldorin, it should be extracted from the URL | 22:56 |
| Noldorin | i see | 22:57 |
| Noldorin | jelmer, well feel free to suggest anything. i'm here to do any necessary testing atm :) | 22:57 |
| Noldorin | jelmer, i'm just stopped by my unfamiliarity with the lib mainly heh | 23:00 |
| jelmer | Noldorin: you could try poking around in bzr-git's remote.py | 23:00 |
| Noldorin | okies | 23:00 |
| spiv | Good morning! | 23:01 |
| Peng | Hi! | 23:02 |
| lifeless | yo spiv | 23:03 |
| Noldorin | jelmer, anywhere in particular? | 23:05 |
| jelmer | _get_path | 23:05 |
| jelmer | and the SmartTransport constructor | 23:05 |
| Noldorin | ok, thanks | 23:06 |
| Noldorin | jelmer, ok, so that path variable is getting set fine | 23:09 |
| Noldorin | to /Noldorin/IRC.NET.git | 23:09 |
| Noldorin | jelmer, i guess it's the interop with dulwich we want to look at next? | 23:11 |
| Noldorin | jelmer: wherever that is :) | 23:18 |
| lifeless | jam: I was wrong, redudped | 23:18 |
| lifeless | james_w: please let me know when I can zap those debhelper branches | 23:19 |
| james_w | http://package-import.ubuntu.com/status/ifenslave-2.6.html#2010-01-12 23:56:32.979164 would be a good failure to look at as well | 23:24 |
| lifeless | james_w: run check on that? | 23:28 |
| Noldorin | jelmer: i think we're on to something here... oh well, i'll catch you another time hopefully. | 23:29 |
| james_w | lifeless: I don't have any of the trees to hand | 23:31 |
| lifeless | could you make the system tar up failures like that? | 23:33 |
| james_w | it keeps them around now | 23:34 |
| lifeless | ok but we need access to the machine right ? | 23:35 |
| james_w | yes | 23:37 |
| james_w | I could put tarballs publically if you wanted | 23:37 |
| james_w | wouldn't help this case though | 23:37 |
| james_w | and I think there are more important things to do | 23:38 |
| lifeless | sure | 23:39 |
| lifeless | just a bit hard to investigate that one - it smells like local data/race issue | 23:40 |
| doctormo | How would I get a branch at a sepcific revision or turn a branch back to specific revision? I want to test pull code, but I need to move it back once I've done my test. | 23:41 |
| Peng | You want to pull something, mess with it a bit, then undo the pull? | 23:43 |
| spiv | doctormo: 'bzr branch -r 1234 URL' will get a branch at a specific revision | 23:43 |
| spiv | There are also ways to "turn a branch back to a specific revision", but the exact command depends on exactly what you mean by that. | 23:45 |
| spiv | Possibly you just want "bzr pull -r 1234 --overwrite"? | 23:45 |
| lifeless | spiv: + . | 23:46 |
| Peng | Ah, didn't think of that. | 23:46 |
| Peng | I was thinking "bzr merge", don't commit, then "bzr revert". | 23:47 |
| lifeless | if you're writing test code though, just use a throwaway branch ;) | 23:47 |
| doctormo | spiv: Thanks a lot! | 23:50 |
| spiv | lifeless: ah right. | 23:50 |
| spiv | lifeless, jam: Thanks for the ConfigurableFileMerger refactoring | 23:51 |
| spiv | lifeless, jam: it looks like a much nicer API, although I don't yet understand how it avoids re-reading the config for each file to merge. | 23:53 |
| spiv | Ah, I think I see. | 23:54 |
| spiv | The active_hooks attribute. | 23:55 |
| lifeless | spiv: each object maintains its own state | 23:55 |
| lifeless | spiv: rather than putting the state on the Params, which wass new-per-file | 23:56 |
| lifeless | spiv: are you back on deck ? | 23:56 |
| spiv | lifeless: I am | 23:56 |
| spiv | lifeless: yeah, I see now, the bit I was missing is that the hook objects aren't new-per-file anymore, just per-merge, which seems sane. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!