| mkanat | cheater99: Also, for people who are familiar with CVS or Svn, it has a basically-compatible command set. | 00:00 |
|---|---|---|
| mkanat | cheater99: And finally, it can do remote operations, which git cannot. | 00:00 |
| cheater99 | ok | 00:00 |
| mkanat | cheater99: git's advantage is that it is ridiculously, blindingly fast. | 00:01 |
| cheater99 | what's the slowest thing in bzr? | 00:01 |
| mkanat | cheater99: Probably annotate, like every DVCS (git and hg will be the same). Also, "bzr log -v" can be slow on large projects. | 00:01 |
| poolie_ | interesting question | 00:01 |
| poolie_ | 'check' is probably the least optimized code | 00:01 |
| cheater99 | what is the slowest thing in bzr that is comparably very fast in git? | 00:02 |
| mkanat | poolie_: But also one that normal users will almost never be running. | 00:02 |
| poolie_ | probably also check | 00:02 |
| cheater99 | what about local branching? | 00:02 |
| poolie_ | bzr being in python has a startup time overhead of a fraction of a second on each command, which git doesn't have | 00:02 |
| cheater99 | how does that work out? | 00:02 |
| cheater99 | aha | 00:03 |
| mkanat | cheater99: If you have created a "repository" with bzr, local branching is very fast. | 00:03 |
| cheater99 | but can't you have a python daemon.. | 00:03 |
| poolie_ | bzr commit was recently measured (benchmarks are all bogus) as faster than hg | 00:03 |
| poolie_ | which didn't used to be true | 00:03 |
| cheater99 | mhm | 00:03 |
| mkanat | cheater99: The day-to-day difference of speed using bzr and git makes no significant difference in my development productivity. | 00:03 |
| cheater99 | but if you have a running python process already then there's no startup overhead | 00:03 |
| mkanat | cheater99: But if I had 100,000 commits in my repo, that might be a different story. | 00:04 |
| mkanat | cheater99: The startup overhead is not something that's going to affect your productivity. | 00:04 |
| mkanat | cheater99: There isn't any common operation where there isn't a linear difference between bzr and git. | 00:04 |
| cheater99 | aha | 00:04 |
| cheater99 | that is good to know | 00:04 |
| poolie_ | cheater99, there is a plugin that gives you a longrunning python process | 00:05 |
| poolie_ | and then a c program that passes commands to it | 00:05 |
| mkanat | poolie_: That's cool; I didn't know that. | 00:05 |
| cheater99 | nice | 00:05 |
| mkanat | cheater99: Also, I suppose one of the advantages of bzr is that you go into #bzr and the project lead helps you out, there. Hahaha. | 00:06 |
| mkanat | (Although actually, pretty much everybody in this channel I've found to be pretty helpful.) | 00:06 |
| cheater99 | who's the project lead? | 00:06 |
| mkanat | cheater99: poolie | 00:06 |
| cheater99 | ah | 00:06 |
| cheater99 | nice | 00:06 |
| cheater99 | hi | 00:06 |
| cheater99 | also, very different experience from the git channel :) | 00:07 |
| mkanat | Yeah. | 00:07 |
| mkanat | Where you go in and people insult you because you're not doing it right. :-D | 00:07 |
| mkanat | (Well, not always, though. Sometimes #git is helpful.) | 00:07 |
| cheater99 | that's sadly the kind of experience i got | 00:07 |
| cheater99 | what do you think is missing most in bzr? | 00:08 |
| poolie_ | ah, cleaner colocated (git-style) branches | 00:09 |
| poolie_ | s//and built-in | 00:09 |
| poolie_ | ditto built in nested trees aka submodules aka externals | 00:09 |
| cheater99 | is it far off? | 00:10 |
| cheater99 | i guess it doesn't matter that much though :) | 00:12 |
| cheater99 | bzr feels very solid | 00:12 |
| cheater99 | what i really like about it is the manuals are so friendly | 00:12 |
| cheater99 | big difference from cvs, git, svn, rcs, .. | 00:12 |
| cheater99 | can i somehow make bzr version files inside archives? | 00:13 |
| poolie_ | how do you mean? | 00:13 |
| cheater99 | well | 00:13 |
| cheater99 | some applications save documents as archives. for example, mysql workbench | 00:14 |
| cheater99 | it has this .mwb file format, which is in fact a zip with xml and other ascii files in it | 00:14 |
| cheater99 | :) | 00:14 |
| fullermd | cheater99: The answer to that is "no, but it comes up from time to time" | 00:15 |
| cheater99 | cool | 00:15 |
| cheater99 | i would need to convert from cvs to bzr. | 00:16 |
| cheater99 | will that make historical commits in cvs atomic? | 00:17 |
| mwhudson | most of the conversion tools put some effort into that, yes | 00:17 |
| cheater99 | cool | 00:18 |
| cheater99 | does that actually work? | 00:18 |
| cheater99 | the repository i'm talking about isn't huge | 00:18 |
| fullermd | Often :) | 00:18 |
| cheater99 | and it wasn't extremely busy | 00:18 |
| cheater99 | about up to 5 developers at any time... doing just a handful of commits every day | 00:18 |
| mwhudson | should be fine | 00:18 |
| cheater99 | that will atomize the non-atomic commits in cvs? | 00:19 |
| cheater99 | really? | 00:19 |
| cheater99 | nice! | 00:19 |
| cheater99 | hm, one thing that would be cool: to be able to use bzr for my editing buffer in vim ;) | 00:20 |
| cheater99 | for undo/redo | 00:20 |
| cheater99 | :) | 00:20 |
| fullermd | Well, most converters try. CVS makes it difficult to be sure of success, so results vary. | 00:21 |
| cheater99 | that's cool though | 00:21 |
| cheater99 | after all we're not talking about rocket brain surgery | 00:21 |
| fullermd | If you haven't done repo surgery, or a lot of cross-branch work, it usually turns out OK. | 00:22 |
| cheater99 | not at all | 00:22 |
| cheater99 | i would say, maybe 3 concurrent branches at most | 00:22 |
| fullermd | Well, things like having a file on one branch that are later added to another branch can be squirrely. And figuring branch points is educated guesswork. | 00:23 |
| fullermd | It really just ends up as "try and see". | 00:23 |
| jbowtie | cheater99: I'm drafting a blueprint specifically for that use case (diffing and merging zip files) | 00:24 |
| fullermd | (that's not bzr-specific; it's the "figure out what actually should have happened from CVS records" side of things) | 00:24 |
| cheater99 | jbowtie: nice! | 00:24 |
| cheater99 | jbowtie: any cool bits to talk about? :) | 00:25 |
| jbowtie | The proposal is specifically for working with free software formats that we currently treat as unmergable binaries. | 00:26 |
| cheater99 | yes | 00:27 |
| cheater99 | but then i ask myself | 00:27 |
| cheater99 | if a zip has a zip in it | 00:27 |
| cheater99 | you will have to merge recursively. | 00:27 |
| jbowtie | For zip files (and variants and other archives) we should be able to treat them as folders. | 00:27 |
| cheater99 | and then you are really defining a new "dimension" of files | 00:27 |
| cheater99 | so not only horizontally across the file system | 00:28 |
| cheater99 | but also vertically inside files. | 00:28 |
| jbowtie | And we already know how to merge folders recursively. | 00:28 |
| cheater99 | yes | 00:28 |
| cheater99 | i guess if you think of it that way | 00:28 |
| cheater99 | then it becomes easy | 00:28 |
| cheater99 | a folder is just a different "file format" then | 00:28 |
| cheater99 | and then, i guess, other formats which do not depend on zip etc, but still have some sort of modules in them, could possibly have a plugin that talks to some sort of api | 00:29 |
| jbowtie | Well, there are going to be performance issues working with archives (particularly tar files) but the improved user experience should make up for it. | 00:29 |
| cheater99 | yes | 00:29 |
| jbowtie | Yes, that's what I really need to pin down in the blueprint proposal - what the API looks like. | 00:29 |
| cheater99 | but those "performance issues" should only happen when they choose to merge, right? | 00:29 |
| dOxxx | any operation that requires accessing the contents of the files is going to incur some overhead from decompression | 00:31 |
| cheater99 | i think the simplest api would be: present the plugin with both files to be merged, expect a third file in a special location :)) | 00:31 |
| jbowtie | Correct; I imagine in the first iteration of an implementation you'd have to turn it on via plugin. | 00:31 |
| cheater99 | dOxxx: that's obvious :) | 00:31 |
| dOxxx | that's me, captain obvious :P | 00:31 |
| cheater99 | jbowtie: but if you want your merge to only overwrite? | 00:32 |
| cheater99 | jbowtie: you'd need to have a special way to do that too | 00:32 |
| cheater99 | i.e. i want to merge, but all my binaries overwrite remote binaries. | 00:32 |
| dOxxx | something like that might be possible with the per_file merge hooks | 00:32 |
| cheater99 | ah | 00:33 |
| dOxxx | there's already a plugin that handles merging of NEWS files specially | 00:33 |
| cheater99 | but, that's a bit crappy not to have this granularity then and there | 00:33 |
| jbowtie | We just need to make sure the merge hook API covers our scenarios, and add corresponding diff hooks. | 00:33 |
| cheater99 | i would even like to be able to say "bzr always-overwrite-on-merge myarchive.tgz" | 00:34 |
| dOxxx | yeah, I'm not sure how configurable it is, whether it can selectively operate on some files some of the time | 00:34 |
| jbowtie | What you do is have your plugin use the hooks, then make the plugin configurable. | 00:34 |
| cheater99 | :) | 00:34 |
| dOxxx | theoretically, the plugin could add a file to the .bzr directory in the branch which contains a list of files that have to merged specially | 00:34 |
| cheater99 | btw | 00:35 |
| cheater99 | can i use bzr with github? | 00:35 |
| cheater99 | not as the main repository | 00:35 |
| cheater99 | but just so that i can use github statistics, graphs, and all that silly stuff | 00:35 |
| jbowtie | But I'm also looking at more complex scenarios, like merging Photoshop files - the diff and merge works on layers instead of lines of text. | 00:35 |
| cheater99 | yes | 00:35 |
| jbowtie | Yes, just use the bzr-git plugin. | 00:35 |
| cheater99 | i guess you'd need a graphical log then huh? | 00:35 |
| cheater99 | displaying graphics :) | 00:36 |
| cheater99 | i really like this jbowtie | 00:36 |
| jbowtie | I think you need to work with the GIMP folks to see what can be reported in text (layer names perhaps) as well as hooks for the (existing) graphical diff tools. | 00:37 |
| jbowtie | My goal is to ultimately make bzr a good experience for artists as well as programmers. | 00:37 |
| mkanat | jbowtie: Does bzr even do binary deltas right now? | 00:38 |
| jbowtie | Working on, say, a game, you should be able to version your art assets in the same repository as your code assets. | 00:38 |
| mkanat | jbowtie: That would definitely fix the third common unanswerable question that people come in here with. | 00:39 |
| mkanat | jbowtie: "I have this repository with these 20GB files in it, and..." | 00:39 |
| jbowtie | mkanat: I'm pretty sure it does, but diff and merge is reduced to (these binaries differ) and (choose mine or theirs) respectively. | 00:39 |
| jbowtie | mkanat: Though I'd actually have to look at the branch format to see how it stores things. | 00:40 |
| mwhudson | the problem of course is that compressed content doesn't diff well, on the whole | 00:40 |
| mkanat | jbowtie: *nod* | 00:40 |
| cheater99 | jbowtie: great idea | 00:41 |
| mwhudson | hard to squeeze out entropy in two ways at once | 00:41 |
| cheater99 | jbowtie: does it let you interactively download and open the two binaries? | 00:42 |
| cheater99 | jbowtie: so that you actually know what you're overwriting, | 00:42 |
| cheater99 | and so that you can open it in, for example, photoshop. | 00:42 |
| jbowtie | cheater99: Yes, if you use qdiff right now it shows you images side-by-side, that sort of thing. | 00:43 |
| cheater99 | yeah but what if they're, say, UnrealED maps. | 00:44 |
| cheater99 | i need to open them in the level editor | 00:44 |
| cheater99 | (just giving you an idea of where you need access to the files) | 00:44 |
| jbowtie | cheater99: That's the point of the blueprint I'm drafting; so you have an API that lets plugins hook in and provide that for both diffing and interactively merging. | 00:45 |
| === sidnei-dinner is now known as sidnei | ||
| cheater99 | yep | 00:45 |
| cheater99 | but that api won't be implemented for everything! | 00:45 |
| cheater99 | so the situation i describe will still be the default for most things.. | 00:46 |
| jbowtie | Absolutely - but we'll start by handling zips (I would think) and start talking to the main free software artist tools. | 00:46 |
| jbowtie | Once we've got a decent API and good examples to build of off, people will be able to write plugins for any binary format. | 00:47 |
| jbowtie | And we always have a fallback for generic, unhandled binary files, which is the current behaviour. | 00:47 |
| cheater99 | yup | 00:47 |
| cheater99 | :) | 00:47 |
| cheater99 | i'm off to sleep, cya guys! | 00:48 |
| cheater99 | thanks for the info! | 00:48 |
| cheater99 | :) | 00:48 |
| dOxxx | ciao | 00:49 |
| mkanat | poolie: I'm going to do some loggerhead research and possibly some work today. :-) | 01:00 |
| poolie | mkanat: nice | 01:07 |
| mkanat | I can't help but feel like loggerhead.config is a reinvention of a wheel that exists somewhere else. | 01:14 |
| mkanat | It's not that complex, though. | 01:14 |
| mkanat | There's got to be duplicate code in bzrlib, though, since it's doing very bzr-ish things. | 01:15 |
| mkanat | In fact, looking over the general startup code for loggerhead, I'm tempted to join the "this should entirely be a bzr plugin" camp. | 01:17 |
| mkanat | Man, there's a lot of Paste stuff in loggerhead, strewn about. :-( | 01:26 |
| mkanat | Largely because Paste itself does too many things. | 01:28 |
| mkanat | jam: Does the existing bzr-history-db stuff do on-disk file locking? That is, would multiple loggerhead processes running be OK? | 01:32 |
| mkanat | I assume it does, and that it's just part of the normal bzr locking mechanisms. | 01:32 |
| poolie | mkanat: i think that's correct | 01:52 |
| poolie | it uses a pack db i think, which is multi writer safe | 01:52 |
| mkanat | poolie: Okay. | 01:52 |
| jbowtie | poolie: Did you need any supporting material for my CV? Last time I asked you were still waiting on HR. | 02:01 |
| * poolie looks | 02:02 | |
| poolie | i still am waiting :/ | 02:02 |
| poolie | will ping them tonight | 02:02 |
| poolie | actually can you send me a copy direct, in parallel? | 02:02 |
| jbowtie | Sure, will do. | 02:04 |
| jbowtie | poolie: Sent through to your canonical account. | 02:12 |
| poolie | thanks | 02:26 |
| mkanat | poolie: I'm starting to lean toward's lifeless's suggestion of making a 1-thread paste server and running it multiple times, and just putting it behind a proxy. | 02:27 |
| poolie | ok, interesting | 02:28 |
| poolie | why behind a proxy? | 02:28 |
| mkanat | poolie: The reason being that Paste is sort of littered throughout the code. | 02:28 |
| mkanat | poolie: For load-balancing. | 02:28 |
| mkanat | poolie: That is, we simply would run serve-branches four times, on four different ports, on a four-core machine. | 02:29 |
| mkanat | Or we'd run it 10 times, if we wanted to be able to handle 10 simultaneous requests. | 02:29 |
| poolie | you know you can actually have multiple processes listening on the same port | 02:29 |
| mkanat | poolie: Yes, with a master + forking situation. | 02:30 |
| mkanat | poolie: Which would be Spawning, then, not Paste, since Paste can't do multi-process. | 02:30 |
| poolie | doesn't SO_REUSADDR let you bind a port that's already open? | 02:31 |
| mkanat | poolie: Unless you just mean have the process release the port when it's working, and then wait in a queue. | 02:31 |
| poolie | imbw | 02:31 |
| poolie | i'm just saying it seems nice to avoid adding a proxy if it's only going to distribute work across ports | 02:31 |
| mkanat | poolie: What lifeless suggested is what Launchpad does now. | 02:32 |
| mkanat | poolie: The advantage is that it's just a configuration change. | 02:32 |
| mkanat | Although I'd have to test it locally and make sure that running multiple loggerhead processes actually works. | 02:32 |
| mkanat | poolie: The scaling problem is only a problem at Launchpad, AFAIK. | 02:37 |
| poolie | ok, that makes sense | 02:37 |
| mkanat | poolie: The complexity of threading is a problem everywhere, so it would still be nice to switch to a multi-process model, and I'd love the code cleanup that would involve. But I feel like the best time investment might be to investigate the 1-thread paste server solution. | 02:38 |
| GungaDin | how do I get the source for bzr-rewrite? using bzr? | 02:40 |
| GungaDin | I have the url for trunk... but how do I check it out? | 02:40 |
| GungaDin | doesn't seem to be a repo | 02:40 |
| poolie | GungaDin: 'bzr branch lp:bzr-rewrite' doesn't work? | 02:41 |
| GungaDin | will try | 02:41 |
| GungaDin | works | 02:41 |
| GungaDin | thx | 02:41 |
| mkanat | poolie: Next time I work on loggerhead I'm probably going to try out the 1-thread system and see if it works and what would need to be fixed. | 02:58 |
| jbowtie | spiv: Thanks for reviewing those doc patches so quickly. | 02:59 |
| jbowtie | I was thinking that more of those links should be turned in Sphinx ref directives, might reduce link breakage bugs. | 03:00 |
| spiv | jbowtie: yeah, that sounds good | 03:03 |
| spiv | jbowtie: we only switched to just Sphinx relatively recently | 03:03 |
| spiv | Before that we were a bit limited by also supporting plain docutils. | 03:03 |
| GungaDin | I've accidently rebased a branch and I'd like to undo it... how can I do that? | 03:05 |
| GungaDin | (using bzr rebase) | 03:05 |
| spiv | GungaDin: Perhaps with 'bzr pull --overwrite -r revid:OLD_REVID', if you know the old revision ID (or can find it with 'bzr heads' from the bzrtools plugin) | 03:07 |
| GungaDin | something very weird happened.. because I specified a branch I had merged into and not the parent branch | 03:08 |
| GungaDin | and now both branches looks the same | 03:08 |
| * spiv -> lunch. Looking forward to some replies from PQM when I get back... | 03:33 | |
| anteru | Good evening | 04:24 |
| anteru | http://img137.imageshack.us/img137/2454/bzr3.png (some more work on a new website) | 04:30 |
| anteru | (for bzr, that is :) ) | 04:31 |
| poolie | hi there anteru | 04:33 |
| poolie | spiv could you take a pass through the New bug queue? | 04:33 |
| anteru | Slow progress, as I'm investing 1 hour every two weeks or so right now, busy with work... | 04:33 |
| poolie | it's good | 04:34 |
| poolie | i wonder if the command-line samples are a bit too directly derivative of the git homepage? | 04:34 |
| anteru | hg has the same :) | 04:34 |
| poolie | also, to me, the different shades of blue kind of clash with each other | 04:34 |
| anteru | Yeah, the colors are crap, I need to fabricate a few images later on. | 04:35 |
| anteru | And I still wonder how to place the explorer screenshot | 04:35 |
| anteru | after all, it's a usp for bzr | 04:35 |
| poolie | right, i think we want to communicate both the gui and cli bits | 04:36 |
| jbowtie | I assume you're going to align the second block to the grid at some point? | 04:36 |
| anteru | I'm going to pull a grid over this really soon now, wanted to get the big fat bazaar text right today. | 04:36 |
| anteru | navigation will be close to what ubuntu.com has, that shouldn't be a problem as it's canonical here as well | 04:38 |
| anteru | I wonder if someone agrees that it's enough to have the version number at the downloads instead of having it below the bazaar text? | 04:39 |
| anteru | At least for me as a user, I'm going to search the version at downloads, to see if X.Y is available for my OS. | 04:39 |
| jbowtie | I agree, though it would be good if a major release made a bit of a splash on that page - is there an obvious place for that? | 04:42 |
| poolie | agree | 04:42 |
| poolie | i like having the blog and announcements syndicated there | 04:42 |
| poolie | above the fold | 04:42 |
| poolie | also it kind of sucks to say "no test release" | 04:42 |
| poolie | let's just omit that if there is none | 04:42 |
| anteru | well, you could always add a big 3 next to bazaar | 04:42 |
| === FryGuy_ is now known as FryGuy- | ||
| anteru | Ok, taking some notes: Different color scheme, gridified layout, place for syndication, less version numbers. | 04:45 |
| jbowtie | For the color scheme you might want to see what the full Ubuntu palette looks like (I'm sure they have compatible shades of yellow and blue to go with their dominant colors) | 04:49 |
| jbowtie | Once you've nailed down the grid I'll start overhauling the documentation templates to coordinate. | 04:51 |
| jbowtie | That'll probably bring up color issues with the images in the doco. | 04:51 |
| anteru | Do you have a link to the ubuntu color scheme? | 04:53 |
| jbowtie | I'd probably start on design.canonical.com - I'm just running off to a meeting or I'd hunt it down. | 04:58 |
| anteru | Ok, thanks! | 04:58 |
| anteru | Should do it | 04:58 |
| anteru | Found the color palette | 04:59 |
| GungaDin | when merging only several commits, how come you can't see the merged commits in qlog? | 05:28 |
| anteru | You don't see the plus sign? | 05:30 |
| GungaDin | nope | 05:31 |
| GungaDin | just one commit | 05:31 |
| GungaDin | without a plus sign | 05:31 |
| anteru | and bzr log --include-merges shows it? | 05:32 |
| GungaDin | qlog doesn't accept that. and with just log doesn't seem so . | 05:37 |
| anteru | If bzr log doesn't show it, then it's not a qlog problem. | 05:38 |
| anteru | Are you sure you didn't push? | 05:38 |
| * anteru never had an issue with a merge loosing history ... | 05:38 | |
| GungaDin | just merged and commited | 05:46 |
| GungaDin | no, log doesn't show them. | 05:47 |
| anteru | Sounds like a bug. | 05:49 |
| spiv | GungaDin: "merging only several commits", you mean "bzr merge -r x..y"? | 05:56 |
| spiv | GungaDin: if so, then that's cherrypicking, bzr can't record those as merges, it's more like just applying the diff | 05:57 |
| spiv | GungaDin: if you look at the "bzr st" output before committing that sort of merge it won't have any "pending merges" | 05:58 |
| spiv | GungaDin: so I think it's not a qlog issue, just a bzr limitation: http://doc.bazaar.canonical.com/latest/en/user-guide/adv_merging.html#cherrypicking | 05:59 |
| GungaDin | yes | 06:01 |
| GungaDin | -r x..y | 06:01 |
| GungaDin | I'm just looking for a way to move commits to a different branch... if that's possible. | 06:02 |
| GungaDin | I have a branch where there are two sets of commits which are mutually exclusive. | 06:02 |
| spiv | Well, one option may be to "bzr branch original-branch different-branch; cd different-branch; bzr merge -r Y..X; bzr ci -m 'Revert changes from X to Y'" — note the order of Y..X, i.e. a reverse cherrypick. So all the revs are still in the history, but then you add a rev that undoes the changes those revs make. | 06:08 |
| spiv | Not sure if that suits your needs or not. | 06:08 |
| anteru | Hm, is bzr going to track cherrypicking in the future? | 06:09 |
| spiv | anteru: hopefully, but we're unlikely to work on that in the near future :( | 06:10 |
| spiv | Stuff like co-located branches are higher on Canonical's todo list... but patches are always welcome ;) | 06:10 |
| anteru | Ok. I often cherry-pick something before merging the rest of the branch later on, didn't notice that yet. | 06:10 |
| anteru | spiv: I'll look again at contributing to bzr when I'm back at home, ~ 2 months. | 06:11 |
| anteru | The use case I'm running into is that I do some quick fix on a feature branch, and I want to move that fix immedialtey back to my trunk, and merge the rest of the feature later. | 06:12 |
| spiv | In practice cherrypicking often works out ok, because although bzr doesn't track them, it does avoid reporting a conflict when you merge two branches that appear to have independently made an indentical change. | 06:12 |
| spiv | s/indentical/identical/ | 06:12 |
| anteru | Ah ok. Colocated-branches is branches svn:external? | 06:12 |
| anteru | Args: Colocated branches are the svn:external equivalent? | 06:12 |
| spiv | No, colocated branches is having a single working tree that can contain multiple branches that you can 'bzr switch' between. | 06:13 |
| anteru | Similar to what git does? | 06:14 |
| spiv | Right. | 06:14 |
| anteru | Ah ok. All the DVCS are so similar now, it's just a question until they converge to a common feature set ... | 06:14 |
| spiv | There's a bzr-colo plugin already, but there's some progress towards making it a polished feature of core bzr. | 06:14 |
| anteru | Sounds useful for some of the C++ stuff I do, as I won't need to have several build trees. | 06:15 |
| spiv | Right. | 06:16 |
| spiv | You can already have a single working tree for multiple branches in bzr, but it's a bit more effort to set up and use than we'd like. | 06:17 |
| spiv | (Make a shared repo of tree-less branches, and have a single lightweight checkout that you 'bzr switch' between those branches, and of course create/remove/etc branches in the repo) | 06:18 |
| anteru | I can see why colocated branches are moving into core :) | 06:22 |
| spiv | :) | 06:22 |
| anteru | I really hope that some more high-profile projects finally pick up Bzr, the amound of Fud on the intertubes is incredible. | 06:25 |
| GungaDin | it'd be nice if cherry picking was better supported. | 06:25 |
| GungaDin | if you could see the actual partial commits that have been merged.. | 06:25 |
| anteru | night | 06:51 |
| poolie | i'm using colo now | 06:58 |
| poolie | quite good so far | 06:58 |
| vila | poolie: quick chat ? | 07:51 |
| vila | err, hi all ! | 07:52 |
| spiv | Hi vila :) | 07:52 |
| vila | spiv: hey ! | 07:52 |
| vila | spiv: did I thank you for the unicode patch ? I don't think so, so THanks ! | 07:52 |
| vila | spiv: is there a reason you didn't try to target it at 2.0/2.1 ? | 07:53 |
| spiv | vila: 2.2 was the source of the initial repot | 07:54 |
| vila | spiv: ok | 07:54 |
| spiv | It's probably easy to backport (at least of the affected tests doesn't exist in 2.1, I'm fairly sure). | 07:54 |
| vila | spiv: if we try to activate the testsuite during the builds in the future we may want to backport it | 07:54 |
| vila | spiv: if you could do that that will be great | 07:55 |
| spiv | vila: your 644855-test-isolation just bounced due to a NEWS conflict, btw | 07:55 |
| spiv | yeah, a backport makes sense to me. | 07:55 |
| vila | spiv: shudder, thanks for the heads-up | 07:55 |
| vila | spiv: I thought about it and... forgot :-/ | 07:56 |
| vila | spiv: I mean, I suspected that adding the first bug entry may lead to problems down the road and forgot to check | 07:56 |
| vila | dOxxx: thanks for merging my README changes ! | 08:03 |
| vila | dOxxx: <cough> of course I made typos :-/ I'll fix them in the 2.3 branch | 08:03 |
| poolie | hi there vila | 08:04 |
| vila | poolie: we can't officially release 2.2.1 yet, we still miss the windows installers, and a complete bzr-proposed PPA | 08:08 |
| poolie | ok | 08:08 |
| maxb | vila: I just uploaded the last bits to bzr/proposed | 08:10 |
| maxb | Unfortunately the launchpad build farm is broken | 08:10 |
| vila | maxb: hurrah ! | 08:11 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| vila | maxb: does this means that *you* need to resubmit something or only that your submissions are delayed ? | 08:12 |
| maxb | Just a delay, I hope | 08:15 |
| maxb | vila: Is there anything left to do under "ping Debian maintainers" on http://wiki.bazaar.canonical.com/Releases/2.2.1 ? | 08:16 |
| vila | maxb: hmm, I was waiting for an answer from them, but I think you proxied quite nicely so I guess we should delete this item | 08:17 |
| jelmer | 'evening maxb, vila | 08:35 |
| vila | jelmer: wow, now, *where* are you ? | 08:36 |
| vila | jelmer: maxb, maxb: jelmer, I think you have matter to discuss and I will carefully listen :) | 08:36 |
| jelmer | vila: I'm in California :-) | 08:37 |
| maxb | we do? Debian packaging? Nothing urgent if jelmer is somewhere esoteric | 08:37 |
| vila | jelmer: cool :) | 08:37 |
| poolie | hello jelmer! | 08:38 |
| poolie | are you at a conference? | 08:38 |
| jelmer | 'morning poolie! | 08:38 |
| vila | maxb, yes, debian packaging and plugins for the PPAs needing (or not( new releases), this also can have an impact on OSX and windows installers | 08:38 |
| vila | meh | 08:39 |
| jelmer | yep, I'm at the storage conference in Santa Clara | 08:39 |
| vila | maxb, yes, debian packaging and plugins for the PPAs needing (or not) new releases, this also can have an impact on OSX and windows installers | 08:39 |
| vila | I can't tolerate typos in parens, no way | 08:39 |
| vila | :D | 08:39 |
| maxb | vila: On the second point, if bzrlib has not api-bumped in 2.3, then it's purely an issue with the debian packaging metadata assuming it will | 08:42 |
| maxb | vila: proposed PPA is now complete apart from one karmic build which is still running | 08:46 |
| vila | maxb: rock-and-roll ! Thanks a lot for all your efforts there ! | 08:47 |
| vila | maxb: started 28 minutes ago on shipova ? | 08:48 |
| vila | so all we need now are the windows installers and we can push for testing, which means the official release is already delayed until at least monday | 08:52 |
| vila | I will mail the list as soon as I get feedback from Gary | 08:52 |
| vila | that's for 2.2.1 | 08:53 |
| vila | maxb: what's the overall status of the bzr-beta-ppa ? Already testable ? | 08:53 |
| jelmer | maxb: email is perhaps the best medium for me at the moment, the connection is pretty bad here. | 08:56 |
| jelmer | alternatively we can discuss it when I get back on monday | 08:56 |
| poolie | vila, re the SRU | 08:59 |
| poolie | http://doc.bazaar.canonical.com/bzr.dev/developers/releasing.html#getting-the-release-into-ubuntu | 08:59 |
| poolie | basically says subscribe the sru team | 08:59 |
| poolie | (it should say) tag it sru | 08:59 |
| poolie | and add a comment asking for it | 09:00 |
| vila | just a comment then and "they" will now how to get the diff ? | 09:00 |
| poolie | well, you may need to get in #ubuntu-devel and nag someone to help with it | 09:01 |
| poolie | they're basically just going to pull in the new tarball or tag, i think | 09:01 |
| vila | ok, yeah, I'd like to better understand what happens there and what is missing to make it easier and/or address the issues (or at least understand what they are) | 09:02 |
| vila | I know it's about parallel imports but I'm unclear about what workarounds are available... or not | 09:03 |
| poolie | vila, well, i think diving in and trying to document or solve things that come up is pretty worthwhile | 09:05 |
| vila | poolie: so, bug #636930 to start with. It already affects 'bzr (Ubuntu)' so I sould nominate it for maverick | 09:06 |
| ubot5` | Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 876)" [High,Triaged] https://launchpad.net/bugs/636930 | 09:06 |
| vila | but there is no 'nominate' button anymore ;) so is it 'also affects distribution' or 'target to release' ? Neither it seems | 09:07 |
| poolie | both i think | 09:10 |
| vila | poolie: well, 2.2 is already targeted, and distribution seems to be for Ubuntu (not maverick or lucid) | 09:11 |
| * poolie looks | 09:12 | |
| vila | or may be I don't have enough access to add the needed distrotask (or whatever it's named) to the 'bzr (Ubuntu)' part | 09:13 |
| vila | I can't even change the assignee to 'ubuntu-sru'. 'no items matched "ubuntu-sru"' >-/ | 09:14 |
| poolie | so basically you want to follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure | 09:15 |
| vila | eerk https://bugs.edge.launchpad.net/ubuntu/+source/bzr 28 New bugs ??? | 09:15 |
| poolie | though, you can't do all of that | 09:15 |
| spiv | Ok, I have a small human grabbing at my foot, time to go I think :) | 09:16 |
| poolie | you need to subscribe them, not assign them | 09:16 |
| poolie | omomom | 09:16 |
| poolie | g/l | 09:16 |
| maxb | poolie: the StableReleaseUpdates wike page still says subscribe ubuntu-sru, not tag sru | 09:16 |
| spiv | Happy weekend, everyone! | 09:16 |
| vila | maxb: yeah but we want to tag it anyway for easier tracking for *us* | 09:17 |
| maxb | ah | 09:17 |
| poolie | you can tag it | 09:17 |
| poolie | vila, so i think: tag it, subscribe them, create a distro task, post a comment asking for an SRU | 09:17 |
| poolie | let's do that and see if they have any further feedback | 09:17 |
| maxb | vila: HAH | 09:18 |
| vila | ok, but still, how do I 'create a distro task' ? | 09:18 |
| maxb | I have found the missing nominate button | 09:18 |
| vila | maxb: haaa, where ? | 09:18 |
| poolie | "also affects distribution" | 09:18 |
| maxb | nope | 09:18 |
| poolie | can you add this to the docs too? | 09:18 |
| vila | poolie: no, it's the already existing 'bzr (Ubuntu)' | 09:19 |
| maxb | So, it appears that Launchpad shows "Target to release" if the selected bugtask is a project one, and "Nominate for release" if it's a distro one | 09:19 |
| poolie | ok, you don't need to do anything else then | 09:19 |
| poolie | ah yes, you can go into the distro bug context | 09:19 |
| poolie | that's pretty damn obscure | 09:19 |
| poolie | https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/636930 | 09:19 |
| ubot5` | Launchpad bug 636930 in Launchpad Bazaar Integration "Upgrading a repository fails with 'Inter1and2Helper' object has no attribute 'source_repo' (affected: 4, heat: 38)" [High,Triaged] | 09:20 |
| maxb | So, if you want to create an Ubuntu maverick task, you first hack the URL changing bzr to ubuntu/+source/bzr | 09:20 |
| poolie | so this would be maverick only? | 09:20 |
| === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | Release Manager: vila | bzr 2.2.0 is officially out | bzr-2.0.6, 2.1.3, 2.2.1 and 2.3b1 need installers, aTdHvAaNnKcSe ! Some of them are already available, please test !| work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ | ||
| vila | maxb: 8-( | 09:20 |
| vila | poolie: pfewwwwwwwwww. ok, I'll try to replicate that for the others and will document in in releasing.txt | 09:22 |
| vila | maxb: thanks the back-magic hint | 09:22 |
| vila | black | 09:22 |
| * vila kills one more chicken, deploring that it becomes a bad habit especially for the chikens | 09:22 | |
| poolie | i'll comment there | 09:23 |
| poolie | :) | 09:23 |
| vila | poolie: ok, I'm watching the blinken lights :) | 09:23 |
| vila | poolie: p-e-r-f-e-c-t, that's all I needed, I'll do the others | 09:26 |
| vila | adapting the comments as the policy will be slightly different (open to discussion) for 2.1 and 2.0 | 09:27 |
| vila | and 2.3 | 09:27 |
| fullermd | vila: Maybe you should switch to goats? | 09:27 |
| vila | but 2.3 is irrelevant for now | 09:27 |
| poolie | done | 09:28 |
| maxb | vila: Hmm, didn't the TB want us to run the testsuite as part of the buildd build? | 09:28 |
| poolie | yes | 09:28 |
| maxb | In which case, shouldn't we be doing the packaging work for that *first* | 09:28 |
| poolie | istm the reasonable thing is to grandfather the current releases where that doesn't pass | 09:28 |
| vila | fullermd: chickens and chicken thieves are the rage in France these says (black humour)... | 09:28 |
| vila | these days | 09:29 |
| vila | maxb: it will most probably fail with various degrees for 2.0 2.1 2.2, we can only try to make it succeed for the next releases for the *build* itself | 09:30 |
| vila | maxb: see my mail about the related bugs | 09:30 |
| maxb | ah, ok | 09:30 |
| maxb | So, we're going to opt for getting a -proposed upload done, and then playing with selftest against the built package until we've convinced ourselves the world is good? | 09:31 |
| vila | maxb: I'm trying to target as low as 2.0 as possible and spiv will also try to backport its fix, but that will probably not be enough | 09:31 |
| vila | maxb: how, we *are* convinced the world is good :) We want to reach the point where the build itself share this conviction ;D | 09:31 |
| maxb | lol | 09:32 |
| fullermd | Yeah, but chickens have limited power. Sacrificing a few goats can be much more effective at smoothing the way. | 09:32 |
| maxb | noooo | 09:32 |
| vila | maxb: care to add some goats to the packaging branches ? | 09:32 |
| vila | I... am not sold yet myself on goats | 09:32 |
| * fullermd sells vila to some goats. | 09:33 | |
| vila | . o O (Great, as if my desk wasn't already such a mess...) | 09:33 |
| fullermd | See? Perfect solution; a couple goats will eat your desk clean in no time ;) | 09:34 |
| vila | Noooo ! Not these notes ! Boom, one goat sacrificed already... there goes the restriction... | 09:35 |
| fullermd | My neighbor has been mostly out of town for, like, the last year. I keep her front lawn mowed, but the back is an absolute jungle. | 09:36 |
| fullermd | She quite seriously says she'll just drop a few goats back there when she gets back. | 09:36 |
| vila | I see where the goat selling stuff is coming from now... | 09:37 |
| vila | you've got mail: Want some goats ? I'm the lawyer of... | 09:37 |
| fullermd | Teehee. "My late husband was Minister of Finance for Ghana. I require your assistance to transfer five million US goats..." | 09:38 |
| poolie | ok, good night all | 09:40 |
| vila | poolie: good night ! | 09:49 |
| vila | fullermd: lol | 09:49 |
| vila | maxb: I'm sure you could answer this one: I'm about to ask for an SRU for 2.1 in lucid and 2.0 in karmic, should I also target jaunty and hardy for 2.0 ? Or are they already considered EOLed and we should just tell people to use the stable ppa for them ? | 09:52 |
| maxb | jaunty is EOL real soon now | 09:53 |
| maxb | It's not worth the effort of SRU processing | 09:53 |
| vila | maxb: just what I wanted to hear :) And about hardy ? | 09:53 |
| maxb | The only kind of SRU that would be eligible for hardy would be a 1.3.2 release :-) | 09:53 |
| vila | maxb: good ! I'm making progress :) | 09:54 |
| maxb | Hmm. I have a question. Is there any way to move the tree root file-id to not-the-tree-root, and create a new root? | 09:54 |
| vila | maxb: where to you want to move the old root ? | 09:55 |
| vila | maxb: you can't | 09:56 |
| maxb | :-/ | 09:56 |
| maxb | I was pondering Chris Hecker's "help getting a clue about tracking changes in an integrated library" email | 09:56 |
| vila | what you can do is merge a whole tree inside an existing one (eventually into a sub folder) | 09:57 |
| vila | I don't remember if we support this directly and from which release, but that's definitely something we want to improve | 09:57 |
| maxb | Won't that lose the root-id of the secondary tree? | 09:58 |
| vila | no, we fixed a bug about that | 09:58 |
| vila | so you can then merge again from this tree | 09:58 |
| maxb | *blink* | 09:58 |
| vila | maxb: was I unclear ? | 09:59 |
| maxb | How can that work? You merge the secondary tree, and all its contents end up in the root of the merge target initially | 09:59 |
| maxb | How is the root-id of the secondary tree going to end up assigned to the new subdir that you then make to move all the stuff into? | 09:59 |
| vila | 1) you can move the merged content 2) we manage to track the parent of the merge files and recognized that they once was in the other root-id | 10:00 |
| vila | merged files | 10:01 |
| maxb | 2) sounds very magic | 10:01 |
| vila | we don't track the root-id itself, we track where it was used as a *parent* | 10:01 |
| vila | maxb: that was bug #375898 | 10:02 |
| ubot5` | Launchpad bug 375898 in Bazaar "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1' (affected: 11, heat: 13)" [High,Fix released] https://launchpad.net/bugs/375898 | 10:02 |
| * maxb reads | 10:02 | |
| vila | maxb: prepare some coffee first :) | 10:02 |
| vila | https://code.edge.launchpad.net/~vila/bzr/375898-fix-root-more will NOT show you the diff because... it has been merged... sounds like a bug to me even if I kind of understand why the diff is empty :-/ | 10:04 |
| vila | ha no, silly me, it's there: https://code.edge.launchpad.net/~vila/bzr/375898-fix-root-more/+merge/22625 | 10:04 |
| vila | I'm afraid the patch itself will make you think it's even more magic though :-/ | 10:05 |
| maxb | hrm | 10:08 |
| maxb | I think this is a subtley different thing to what I want | 10:08 |
| maxb | I am addressing the question of newly added files in the subproject's upstream branch, which I want to *automatically* merge in underneath the subtree in the aggregate branch | 10:09 |
| vila | maxb: right, it fixes a case in the same area so most of the support was there already | 10:09 |
| maxb | For what I want to work, I think the tree_root fileid of the subproject needs to end up propagated to the container directory within the aggregate branch | 10:09 |
| vila | maxb: I'm not sure about this precise point but at worst they will end up in the root of the new tree and may need to be renamed | 10:09 |
| maxb | yes, that's what happens | 10:09 |
| vila | ha | 10:10 |
| vila | file a bug | 10:10 |
| vila | or search for a duplicate maybe | 10:10 |
| maxb | I think the fix basically involves making bzr merge-into a first-class command | 10:10 |
| vila | maxb: I think spiv worked on that to make it possible to define it in core or something | 10:11 |
| vila | I don't remember the outcomes though | 10:11 |
| maxb | either that or doing something loathesome like resetting the fileid of an added directory to match the old parent of its children if they are all being freshly added | 10:11 |
| maxb | It is at this point I should stop pondering the guts of bzr and actually go to work | 10:12 |
| vila | bzr-builddeb may also have some hacks for some cases, I'm not (yet) up to date there | 10:12 |
| vila | well, I'm totally out-of-date here to be honest :-} | 10:12 |
| vila | maxb: and the plan is to get involved in the bzr packaging using udd to address that | 10:13 |
| vila | maxb: starting now by watching what you're doing :D | 10:14 |
| * maxb chuckles and enworkifies | 10:24 | |
| cheater | hi | 10:31 |
| vila | chuckle | 10:35 |
| vila | lol, bad window :) | 10:36 |
| cheater | :) | 10:36 |
| vila | can't find the meaning of enworkify though :-/ | 10:36 |
| cheater | quick question: bzr on an older suse system - does bzr have a lot of dep's? | 10:36 |
| cheater | we can't use the package manager for one thing | 10:36 |
| Glenjamin | it has mostly python deps | 10:37 |
| cheater | mhm | 10:37 |
| Glenjamin | so pip/easy_install should do it | 10:37 |
| cheater | this one has no internet connection | 10:37 |
| cheater | but i can handle that | 10:37 |
| vila | you'll need pyrex to generate the c files unless you start with a tarball that shoul contain them | 10:37 |
| cheater | i don't know | 10:37 |
| cheater | what's the best thing to install from source? | 10:37 |
| vila | then you'll "just" need to run 'make' | 10:37 |
| vila | cheater: if you need to bootstrap you can't 'bzr branch lp:bzr' so you need to start from a tarball | 10:38 |
| cheater | yes | 10:39 |
| vila | cheater: from there it depends when and how you intend to update | 10:39 |
| cheater | mhm | 10:39 |
| vila | cheater: you can't use the package manager because you don't have an internet connection ? | 10:39 |
| Glenjamin | is there any way to get remerge to only do bits that are still herringboned? I fixed half a file manually then ran into two methods which were mixed up together, after a remerge --weave its fixed the really broken one, but undone my other fixes | 10:39 |
| cheater | yes | 10:39 |
| cheater | well, i can use the package manager | 10:40 |
| vila | I confess I don't know what is packaged in suse anyway | 10:40 |
| cheater | but it's an old suse that hasn't been supported for the last 3 years :p | 10:40 |
| Glenjamin | at the risk of asking a silly question | 10:40 |
| vila | wow, so better start from source then, | 10:40 |
| Glenjamin | why not upgrade/replace the box? | 10:40 |
| cheater | yes vila :) | 10:40 |
| cheater | Glenjamin: it's not mine :) | 10:40 |
| vila | cheater: which python version ? python -V | 10:41 |
| cheater | i think it's 2.6 | 10:41 |
| cheater | so that shouldn't be a problem | 10:41 |
| cheater | maybe 2.5.. | 10:41 |
| cheater | let's see | 10:41 |
| vila | really ? 3 years old and already 2.6 ? | 10:41 |
| cheater | i think they updated it | 10:41 |
| vila | suse or opensuse ? | 10:42 |
| vila | there is http://wiki.bazaar.canonical.com/DistroDownloads#openSUSE but I don't know how up-to-date it is nor how it applies to your case | 10:42 |
| cheater | 2.3.3 xDD | 10:44 |
| vila | cheater: updating the wiki page with your own case will be welcome ;) (hint hint nudge nudge) | 10:44 |
| vila | cheater: python ? argh | 10:44 |
| fullermd | Well, either that or a REALLY up to date bzr :p | 10:44 |
| cheater | that'll be FUN. | 10:44 |
| vila | cheater: end of story then, we support >= 2.4 ~< 2.7 | 10:44 |
| cheater | vila: that's ok, i'll upgrade it | 10:44 |
| cheater | :) | 10:45 |
| * cheater has root | 10:45 | |
| vila | cheater: go for 2.6 then | 10:45 |
| cheater | yeah | 10:45 |
| cheater | i see no reason to go for 2.7 yet | 10:45 |
| cheater | most libs aren't ported are they? | 10:45 |
| * cheater doesn't actually know | 10:45 | |
| vila | cheater: the support for 2.7 is... a bit unknown | 10:45 |
| cheater | ok | 10:46 |
| vila | cheater: from a bzr pov that is | 10:46 |
| fullermd | vila: You could upgrade that vm and make it known ;p | 10:46 |
| vila | fullermd: the vm *is* upgraded and we know we have failures but no time to investigate :-/ | 10:46 |
| fullermd | Well, knowing is half the battle, so we're almost done! | 10:47 |
| vila | fullermd: hehe, yeah almost... | 10:48 |
| vila | fullermd: except almost when it comes to regression testing is marginally better than not at all. I've missed several incidents because I'm used to the red icon meaning 'failures' even when the failure involved a vm crash and a file system corruption :-/ | 10:49 |
| fullermd | Ah, you just need to run a more reliable OS then... | 10:50 |
| vila | hehe, I'm pretty sure the OS is not involved here as the failures has happened across all the OSes used by babune including ... nah that would be cheap ;) | 10:51 |
| fullermd | Pfft. Since when has that stopped you? :p | 10:52 |
| vila | fullermd: always ! You saw only the expensive ones ;) | 10:53 |
| cheater | lol | 10:55 |
| Glenjamin | is there anything I can do about ghost revisions? | 11:11 |
| cheater | what are ghost revisions? | 11:15 |
| vila | cheater: revisions created by a bzr ghost, but you won't be there until you kill your bzr, you need a bzr first | 11:15 |
| vila | Glenjamin: it depends on where you encounter them and if it causes problems or not | 11:16 |
| cheater | i have bzr on my laptop | 11:16 |
| cheater | :) | 11:16 |
| vila | ;) | 11:16 |
| spiv | maxb: I actually did implement a cmd_merge_into, but removed it before the final landing, but it should still be in the revision history | 11:17 |
| spiv | maxb: look at the parent revisions of where MergeIntoMerger landed, I guess | 11:18 |
| spiv | Or use bzr-search ;) | 11:18 |
| vila | spiv: what was the rationale for not landing it ? | 11:18 |
| spiv | vila: we weren't sure it was a good feature, IIRC, but check the review comments on the merge proposal. | 11:19 |
| spiv | https://code.edge.launchpad.net/~spiv/bzr/merge-into-merger/+merge/28824 I think? | 11:19 |
| vila | spiv: nah, just wanted a quick summary ;) My stack already includes too many pending items ;) | 11:20 |
| vila | including reading the night mail... | 11:20 |
| spiv | Hmm, actually the reason isn't in those comments. | 11:20 |
| spiv | But the comments do say "(This history of this patch includes an | 11:21 |
| spiv | updated cmd_merge_into it could use.)" | 11:21 |
| spiv | (talking about updating bzr-merge-into to use the APIs from this patch, rather than its own old code that doesn't work with 2a) | 11:21 |
| vila | ha right, so the plan is more to update merge-into than to make it a core command, at least for now, right ? | 11:22 |
| spiv | Yeah. | 11:24 |
| Glenjamin | vila: in the history, some blame/log commands wont work | 11:24 |
| spiv | Anyway, there's a UI for it now: make a recipe and use bzr-builder ;) | 11:24 |
| Glenjamin | it's not crucial, but it's annoying sometimes. And i think it messes up loggerhead a bit | 11:24 |
| spiv | But the cmd_merge_into I had had a fairly flexible (although perhaps not intuitive?) UI. | 11:24 |
| * spiv wanders off | 11:25 | |
| vila | dOxxx: small problem here, It seems I can fetch pycrypto, I will copy the 2.2/src one manually instead | 11:26 |
| vila | Glenjamin: first, try 'bzr check' just to be sure | 11:26 |
| vila | Glenjamin: then, do you know where these ghosts are ? | 11:27 |
| Glenjamin | http://pastebin.com/Yv6f1cXS | 11:27 |
| spiv | vila: http://bazaar.launchpad.net/~spiv/bzr/merge-into-merger/revision/5272 is the diff removing cmd_merge_into | 11:27 |
| vila | Glenjamin: if you do, it may just be a matter of fetching these revisions into your repo | 11:28 |
| Glenjamin | I'm not sure they exist anywhere | 11:28 |
| vila | Glenjamin: like 'bzr branch -r<ghost> <dummy> ; rm -fr <dummy>' | 11:28 |
| vila | Glenjamin: ha, this kind of ghost | 11:28 |
| Glenjamin | we used bzr locally with an svn server for about 8 months | 11:29 |
| Glenjamin | i've got the rev id of a ghost; GhostRevisionError: {mbrown@macbook-mb.genesys.local-20100716092059-4so0wsqli7tqcxwy} is a ghost. | 11:29 |
| vila | Glenjamin: we intend to support them as gracefully as possible, so file bugs if you're annoyed so we can fix it | 11:30 |
| vila | Glenjamin: do you know who mbrown is ? Can you check whether or not this revision exists in one of its repos ? | 11:30 |
| vila | Glenjamin: start by checking in whatever central or shared repo you have of course | 11:31 |
| Glenjamin | he's sitting next to me, how do i find out? | 11:31 |
| fullermd | Start with a pair of pliers and a blowtorch... | 11:31 |
| vila | ...of course | 11:32 |
| fullermd | "*slap* What were you doing the morning of July 16th?! TALK!" | 11:32 |
| Glenjamin | bzr cat-revision -r revid:{id} is how I test if it's there? | 11:38 |
| vila | Glenjamin: like 'bzr branch -r<ghost> <dummy>' or even bzr log -c<ghost> should do (not sure about the later though as they're may be a check against the branch ancestry) | 11:38 |
| vila | Glenjamin: yup, same caveat about cat-revision than for log | 11:39 |
| Glenjamin | bzr branch -r<ghost> <repo> <dummy> presumably? | 11:40 |
| vila | yeah, but with an existing branch for <repo> just to find the repo | 11:40 |
| Glenjamin | vila: if i manage to get a ghost repo into my local repo, do i just push the dummy branch to the central repo to get it across? | 12:03 |
| vila | Glenjamin: yup | 12:03 |
| vila | Glenjamin: if the central repo is a bzr repo that is | 12:04 |
| Glenjamin | it is | 12:04 |
| vila | k | 12:04 |
| vila | Glenjamin: I'm about to do a break for lunch, did your ghost chase gave any results ? | 12:57 |
| vila | gave... ? give ? | 12:58 |
| vila | garyvdm, GaryvdM: Get out of this grep and come talk to me, I'll be there in ~1h ;-P | 13:00 |
| Glenjamin | vila: i got as far as doing -v on check to get the list, and found that the rev ids aren't in any of the repos | 13:00 |
| dOxxx | vila: hmmm pycrypto website seems to be dead | 13:08 |
| dOxxx | vila: I'll be off IRC today until ~7pm EST. Email me if you need anything for the Mac installers. | 13:21 |
| Glenjamin | how difficult would it be to add a post-resolve hook? I'd quite like something to remind me to commit after a merge before making any other changes | 14:07 |
| Glenjamin | does http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/builtins.py work for anyone? | 14:23 |
| vadi2 | How can I diff a file between two bzr revisions? need to repair some partial damage | 14:30 |
| Glenjamin | in the same branch? | 14:32 |
| vadi2 | yes | 14:32 |
| Glenjamin | bzr diff -r<revision>..<revision> <path> | 14:32 |
| vadi2 | thanks much | 14:32 |
| Glenjamin | Interestingly, I can't see a way to diff 2 revisions of a file in different branches. | 14:33 |
| fullermd | Arbitrarily more complex revspecs. | 14:33 |
| fullermd | Actually, I'd imagine you could select any rev in the repo by revid, so if the branches are sharing a repo you could just go like that. | 14:34 |
| vila | dOxxx: bah, too late, anyway, I managed to build the 2.3b1 installer for OSX 10.5 by copying the parmiko .tgz so all is well | 14:35 |
| vila | Glenjamin: ok, so your ghosts are lost then | 14:36 |
| vila | Glenjamin: try #launchpad if the problem persists on this link | 14:37 |
| Glenjamin | it's been like that for days | 14:37 |
| Glenjamin | i think its loggerhead | 14:37 |
| Glenjamin | big file, lots of history | 14:37 |
| vila | Glenjamin: diff --old <branch1> --new <branch2> <file> should work | 14:37 |
| vila | Glenjamin: ha, no, just got a response | 14:37 |
| Glenjamin | vila: how to specify revisions form each branch? | 14:38 |
| Glenjamin | aha, works for me now too | 14:38 |
| fullermd | See help revisionspec. You can do 123:/some/branch to get revnos from the branch. | 14:38 |
| vila | Glenjamin: ooooh, the tricky one now... | 14:38 |
| vila | pfew, saved by fullermd :) | 14:38 |
| Glenjamin | ah | 14:39 |
| Glenjamin | was looking at revisionspec, but didn't see that bit | 14:39 |
| fullermd | (this "working between branches" thing is one place where branches being FS objects makes things arbitrarily inconvenient :| ) | 14:39 |
| === tchan1 is now known as tchan | ||
| Glenjamin | something along the lines of git's remotes might be nice | 14:41 |
| Glenjamin | some sort of intelligent bookmarks, but i'm not really sure how they'd work | 14:41 |
| dobey | hmm | 14:50 |
| dobey | wasn't there a bzr plug-in somewhere to allow arbitrary shortcut definitions? something like how lp:foo works, but so that you could define gnome:foo or otherserver:foo for example? | 14:52 |
| Glenjamin | I've been writing my own for each repo we use here | 14:53 |
| Kamping_Kaiser | not aware of it, but sounds handy | 14:53 |
| Kamping_Kaiser | i thoguht the thing was 'copy the lp one' | 14:53 |
| Glenjamin | i'm not sure how the plugin would store it, but it's simply enough to do | 14:53 |
| Glenjamin | you just need prefix, url pairs | 14:53 |
| vila | Glenjamin: the most recent one I heard about in this family is lp:bzr-debuntu (be aware that it will be merged in to bzr-builddeb though IIUC) | 14:55 |
| Glenjamin | i was just reading the source for that | 14:55 |
| vila | dobey: | 14:55 |
| Glenjamin | it sets stuff up with a dict | 14:55 |
| Glenjamin | the slightly non-trivial bit is moving the dict to a config file | 14:56 |
| vila | and then rely on lp for the resolution | 14:56 |
| vila | bzr config files should be able to provide a mapping to a [xxx] section to a dict with little nudge I think (but that's not part of the officially supported stuff) | 14:57 |
| dobey | what i want to do is set up a "lp:foo" alias to point to "file:///tmp/blah/blah/foo" for example, for unit tests | 14:57 |
| Glenjamin | we don't really need a dict, just pairs | 14:57 |
| dobey | or well, s/want/need/ | 14:57 |
| vila | dobey: not sure I understand the constraints here, but if you're using bzr TestCaseWithTransport or even TestCaseWithTempDir, your current dir is already under /tmp so you can use relative paths 'dir/file' | 14:59 |
| vila | dobey: if you need a transport, you can (with TestCaseWithTransport) do self.get_transport('dir') too | 14:59 |
| dobey | vila: i'm trying to write more unit tests for some of the code in tarmac, which is currently untested, which handles the actual merging of branches and talks to launchpad to get proposals and stuff. and tarmac complains if branch identities do not use the lp: protocol. and with the TestCaseInTempDir (which we're already using), lp: is not a valid protocol, so after setting up the config for a couple of branches to test the merger of, | 15:01 |
| james_w | bzr-bookmarks is the arbitrary one | 15:02 |
| dobey | james_w: i was looking at it last night, but it seems to only allow doing "foo = file:///foo" rather than "lp:foo = file:///foo" afaict | 15:03 |
| vila | dobey: you don't access lp: right ? | 15:03 |
| james_w | dobey: right, it's not what you need | 15:03 |
| james_w | you need to define a directory service in your tests | 15:03 |
| vila | dobey: so you can *redefine* the lp: protocol for your tests no ? | 15:03 |
| dobey | vila: i need to avoid hitting the network, yes. can i redefine it? | 15:04 |
| vila | dobey: sure | 15:04 |
| dobey | the lp plug-in tests seem to have a way to set up a fake Factory for the URLs, but it seems to only support doing it for one url at a time? | 15:04 |
| vila | dobey: you wan to look at bzrlib.transport.transport.list_registry | 15:06 |
| vila | dobey: you wan to look at bzrlib.transport.transport_list_registry | 15:06 |
| vila | dobey: the latest transport registered for a given protocol wins, so your tests need to register your lp: implementation (and presumably unregister it during cleanup), | 15:07 |
| dobey | hmm, ok | 15:07 |
| vila | dobey: look in bt.test_transport.py for more examples | 15:08 |
| dobey | ok | 15:08 |
| vila | dobey: hmm, and poke the lazy that put a FIXME there instead of doing the cleanup so you'll get proper examples ;) | 15:09 |
| vila | dobey: there is also bt.per_transport.py | 15:10 |
| dobey | heh | 15:11 |
| vila | maxb: yeah for bzr/proposed !! | 15:12 |
| vila | GaryvdM: hey ! | 15:13 |
| Glenjamin | here's a thought | 15:14 |
| Glenjamin | why do directory services have to be instantiated? | 15:14 |
| Glenjamin | return service().look_up(name, url) | 15:14 |
| Glenjamin | it's easier to factory object which have a lookup method than to factory objects which after being called have a lookup method :| | 15:15 |
| GaryvdM | vila: Hi | 15:19 |
| GaryvdM | vila: Esh - I've been busy a work! - But I'm free now | 15:19 |
| vila | Glenjamin: ECANTPARSE, could you rephrase in simpler english ? (I'm not a native speaker) | 15:19 |
| vila | GaryvdM: great ! I wanted to ask about the windows installers | 15:20 |
| vila | GaryvdM: 2.2.1 being the priority | 15:20 |
| GaryvdM | Trying to get going with with win installers, but need to finish off the bzrw/qbzr/tbzr/bzr-explorer | 15:20 |
| GaryvdM | issue | 15:20 |
| vila | ok, do you have an estimate ? | 15:21 |
| GaryvdM | can I answer that in a while - Not sure yet. | 15:21 |
| vila | I'd like to mail the list asking for testing focused on 2.2.1 | 15:21 |
| GaryvdM | Ok | 15:21 |
| mgz | which bit are you on now Gary? I'm actually around today and this weekend | 15:21 |
| vila | GaryvdM: ok, take your time, | 15:21 |
| vila | GaryvdM: you still have.. 5 minutes or such | 15:22 |
| vila | GaryvdM: mwhahahaha kidding of course | 15:22 |
| mgz | (so, yell if you need help, was the subtext there) | 15:22 |
| GaryvdM | vila: If people want to test, the installer I linked to on this page: http://wiki.bazaar.canonical.com/Releases/2.2.1 | 15:23 |
| vila | GaryvdM: I know, I wanted to ask you put it on lp instead, if there are problems you will have to use a new name anyway, so need to buffer here IMHO | 15:23 |
| vila | so *no* need to to buffer | 15:24 |
| vila | GaryvdM: unless you think it's not usable yet, in which case, better wait for the fix since we will need it to be tested again anyway | 15:25 |
| GaryvdM | vila: I've seen lots of people who don't consider themselves as testers get test copies of installers from launchpad, and then complain about instability | 15:25 |
| GaryvdM | So I think it is important to buffer. | 15:25 |
| GaryvdM | (by dropbox may not be the best place... | 15:26 |
| GaryvdM | *but | 15:26 |
| vila | hmm, you're right of course... chicken-and-egg | 15:26 |
| GaryvdM | I've not been keeping up with the mailing list. :-0 waterfall.... | 15:27 |
| vila | On the other hand, that's what test is about... if people don't want to test they can just wait, the release hasn't been officially announced (whatever my poor phrasing was ;-) | 15:27 |
| mgz | just read the Roadmap for Bazaar thread, unless you're really interested in nested trees | 15:28 |
| mgz | or visual studio integration | 15:28 |
| mgz | or vila's many release posts :) | 15:28 |
| vila | GaryvdM: don't even read that :) Focus on the present, the future can wait :-D | 15:28 |
| GaryvdM | This is the issue I'm trying to fix: http://osdir.com/ml/bazaar/2010-09/msg00189.html | 15:29 |
| vila | GaryvdM: release posts are "present" in this respect ;) | 15:29 |
| GaryvdM | Easy fix, then have to release new versions of qbzr, tbzr, and bzr explorer... | 15:29 |
| Glenjamin | vila, directory_service.DirectoryServiceRegistry.dereference does return service().look_up(name, url) | 15:30 |
| mgz | ah, yeah, I saw that and was going to respond, but poolie posted saying what I was going to before I got there | 15:30 |
| vila | GaryvdM: wrong way, delay 2.3b1 if you want, but not 2.2.1 unless it's critical | 15:30 |
| Glenjamin | look_up is an instance method of a directory service, it'd make more sense for it to have been a static/class method | 15:30 |
| * GaryvdM often wants to merge bzr-explorer in to qbzr to reduce release work... | 15:30 | |
| vila | GaryvdM: when releasing, there is *nothing* easy | 15:31 |
| GaryvdM | vila: It's a regression in 2.2.0, So I think it's important. | 15:31 |
| GaryvdM | Caused by bzrw.exe. | 15:31 |
| vila | GaryvdM: then it's critical, ok | 15:31 |
| GaryvdM | and bad code. | 15:32 |
| GaryvdM | ok | 15:32 |
| * GaryvdM focusses... | 15:32 | |
| vila | Glenjamin: ISTM that making it a static/class method reduces the flexibility no ? | 15:33 |
| Glenjamin | in the general case maybe, but the constructor gets no arguments | 15:34 |
| vila | Glenjamin: oh, you want to pass some arguments to service() constructor ? | 15:34 |
| vila | hehe, crossed on the wire ;) | 15:34 |
| Glenjamin | well not really, i'd rather not have to make something instantiable | 15:34 |
| Glenjamin | i'll show you in a sec, just making the plugin | 15:34 |
| vila | I encounter the same problem in a another area and resort to define class attributes and new classes :-/ | 15:35 |
| vila | 137 downloads for the 2.3b1 tarball, do we have so many installer builders ??? | 15:37 |
| vila | or packagers | 15:37 |
| Glenjamin | I always install from source on my windows box | 15:37 |
| mgz | or gentoo users? | 15:37 |
| Glenjamin | or did, when I did any dev on it | 15:37 |
| vila | any gentoo packagers around ? | 15:38 |
| vila | mgz: I'm not sure gentoo users will jump on the first beta... | 15:38 |
| Glenjamin | vila: lp:~glenjamin/+junk/bzr-shortcuts (the __call__ hack works around having to be callable) | 15:39 |
| vila | mgz: 'lost connection during test' rings a bell ? | 15:39 |
| mgz | yeah, babune hits it sometimes, it's a generic subunit failure scenario | 15:39 |
| vila | mgz: subunit, thanks | 15:40 |
| mgz | if for instance, the child process dies | 15:40 |
| * mgz hopes he's remembering this correctly | 15:40 | |
| vila | mgz: yeah, find another example will you, I don't like that one :D | 15:40 |
| mgz | child process closes the pipe? :) | 15:40 |
| vila | far better :) | 15:41 |
| vila | keep going :) | 15:41 |
| vila | I want one that could match a spurious failure that can be target at someting outside the test suite :) | 15:42 |
| vila | 6 jobs in raw failing on jaunty for different reasons.... some bug wants to die today... or knows I'm knee-deep in releases... | 15:43 |
| vila | in a row (right ?) | 15:44 |
| Glenjamin | dobey: Kamping_Kaiser lp:~glenjamin/+junk/bzr-shortcuts is a first draft of a plugin for defining arbitrary url prefixes | 15:45 |
| vila | Glenjamin: it's a bit weird or at least not using the API as it was intended, i.e. you don't call register_transport | 15:48 |
| vila | Glenjamin: it's true that this sounds a bit heavy in your case, but you're supposed to call register_urlparse_netloc_protocol less often then register_transport | 15:49 |
| vila | blah | 15:49 |
| vila | you're supposed to call register_urlparse_netloc_protocol less often then register_transport | 15:50 |
| Glenjamin | i think i just copied the launchpad one | 15:50 |
| dobey | hmm | 15:50 |
| vila | in your case you want to call register_netloc and register_transport for each one | 15:50 |
| Glenjamin | what does register transport do? | 15:50 |
| vila | >-/ | 15:50 |
| Glenjamin | as i'm not defining a transport, just an alias | 15:51 |
| vila | Glenjamin: oh, sorry, wrong layer | 15:53 |
| dobey | hmm | 15:53 |
| dobey | interesting | 15:53 |
| vila | Glenjamin: I think you should at least mail the list about it, I'm not sure there is a lot of users of DirectoryServiceRegistry and even then, we can find ways to make the API evolve | 15:56 |
| Glenjamin | it's not exactly prohibitive, but its a bit odd | 15:56 |
| vila | Glenjamin: forget most of my previous remarks I wasn't on the right page | 15:56 |
| Glenjamin | and every matching service instantiates an object unnecessarily | 15:56 |
| vila | the class has a single method too, so it may just mean it did the job when it was introduced | 15:57 |
| mgz | ugh, two failures on maverick from my selftest changes and test_selftest sucking | 16:07 |
| mgz | will work around rather than launching in to making the tests sane | 16:07 |
| vila | the 7th was the good... looks like goats work better than chicken ? | 16:09 |
| mgz | there's more blood in a goat. | 16:10 |
| vila | mgz: 24,567 tests... took 36ms... | 16:10 |
| vila | mgz: ha, so you're part of this conspiracy against goats too... | 16:11 |
| mgz | I'll fix that timing thing when I work out where it needs fixing. | 16:11 |
| vila | mgz: plan for mutiple targets :D | 16:12 |
| === deryck is now known as deryck[lunch] | ||
| vila | GaryvdM: sorry to interrupt, just one question: do you plan to build installers for 2.0/2.1/2.2/2.3 or only 2.2/2.3 ? I'll tend to prefer the later if that matters | 16:14 |
| * GaryvdM wishes that bzr (version|plugins -v) would tell me what dirs it looks for plugins in. | 16:14 | |
| GaryvdM | vila: I prefer to only volunteer to to 2.2/2.3 | 16:14 |
| vila | GaryvdM: fine | 16:15 |
| GaryvdM | the build method is different, and I've never done a 2.0/2.1 build | 16:15 |
| vila | GaryvdM: I;m not sure we should continue to support 2.0/2.1 on windows at all, but it's not the place nor the time to discuss it | 16:16 |
| Glenjamin | if i sent a message to the list and got bounced for not being a member, then joined; is it better to resend or leave someone to approve it? | 16:16 |
| vila | GaryvdM: and, until "bzr (version|plugins -v) would tell" you, remember that you get full control with BZR_PLUGIN_PATH | 16:17 |
| GaryvdM | vila: Yes - and you can also see in .bzr.log. | 16:17 |
| vila | Glenjamin: depends on the list, if it's bazaar@, feel free to sent it again, at worst we;ll get it twice, but AIUI, the moderators are more harmed by spammers than by good willing citizens | 16:18 |
| Glenjamin | i'll just resend then, ta :) | 16:19 |
| GaryvdM | It's just easier to type bzr plugins -v than less ~/.bzr.log - ^H^H^H^H^H^ Aghhh where is .bzr.log on windows :-) | 16:19 |
| mgz | %APPDATA%/.bzr.log by default I think | 16:20 |
| mgz | but point taken :) | 16:20 |
| GaryvdM | mgz: :-) | 16:20 |
| vila | GaryvdM: LOL | 16:20 |
| Glenjamin | i think it belongs in version -v | 16:20 |
| vila | Glenjamin: right, but most of the people that really care about it, especially care about it after running plugins -v and pestering that it's still not there :) practicality vs purity, I'm 50/50 | 16:22 |
| Glenjamin | should it be at the top of plugins -v or the bottom? :p | 16:23 |
| vila | Glenjamin: blue | 16:23 |
| mgz | I prefer pink. | 16:23 |
| vila | mgz: I knew it :) | 16:23 |
| mgz | and on that topic... /me gets back to it | 16:24 |
| GaryvdM | No! the bikeshead should be yellow! | 16:24 |
| dobey | Glenjamin: hrmm, does your plug-in actually work? | 16:24 |
| GaryvdM | :-P | 16:25 |
| dobey | Glenjamin: how can i test it? | 16:25 |
| vila | ok, blue, yellow, pink, which country flag is that ? | 16:25 |
| Glenjamin | dobey bzr info test: | 16:25 |
| Glenjamin | you'll get an error that http://example.com isn't a repo | 16:25 |
| mgz | http://bazaar.launchpad.net/~parthm/bzr/403687-shelve-summary-in-status/revision/5426/bzrlib/shelf.py <- funny commit, says something about lazy_import (lack of) usability I think | 16:26 |
| dobey | Glenjamin: hrmm, i wonder if the bzr testcase is preventing me from doing the same thing inside the testcase setUp() then :( | 16:26 |
| Glenjamin | is the thing you're testing itself dereferencing locations? | 16:27 |
| dobey | well, bzr is trying to do something, and then gives me UnsupportedProtocol: Unsupported protocol for url "lp:branch1" | 16:28 |
| === Ursinha is now known as Ursinha-lunch | ||
| Glenjamin | at a guess, i'd say lp: isn't registered with the netloc urlparse thing | 16:29 |
| Glenjamin | what throws that exception? | 16:30 |
| dobey | File "/usr/lib/python2.6/dist-packages/bzrlib/transport/__init__.py", line 1576, in convert_path_to_url | 16:31 |
| dobey | it seems like my factory isn't getting called | 16:31 |
| mgz | things tend to run with --no-plugins for testing by default? | 16:33 |
| mgz | how about stubbing in a fake lp: thingy just for your tests? | 16:33 |
| mgz | ...wait, that's what you're trying to do | 16:33 |
| mgz | post some code? | 16:34 |
| dobey | that is exactly what i'm doing. i'm not calling load_plugins() | 16:34 |
| mgz | it needs to run in setUp or later as tests are isolated from general hooks | 16:34 |
| dobey | it's in setUp() | 16:34 |
| dobey | mgz: http://pastebin.ubuntu.com/499785/ | 16:35 |
| mgz | thanks. | 16:35 |
| Glenjamin | dobey: name is undefined there | 16:35 |
| Glenjamin | shouldn't it be throwing an exception | 16:36 |
| mgz | presume that's just an extracting c/p error | 16:36 |
| dobey | undefined where? | 16:36 |
| Glenjamin | directories.register in setUp | 16:36 |
| mgz | the general idea looks fine, any ideas vila? | 16:36 |
| vila | EOVERFLOW | 16:36 |
| james_w | there's no upcall in setUp() that might be making things wonky | 16:37 |
| dobey | Glenjamin: true, not sure why it didn't except there, but changing it to a string had no useful effect :) | 16:37 |
| mgz | was guessing that's also a c/p error, as we throw if you forget | 16:37 |
| dobey | james_w: there is a super() for it, i just omitted it in the pastebin | 16:37 |
| Glenjamin | if it really was undefined, it means setUp isn't being called | 16:37 |
| james_w | dobey: is the super before or after that? | 16:37 |
| Glenjamin | althought it might have just picked up a variable called "name" from a different scope | 16:38 |
| dobey | james_w: it's the first call in the setUp() | 16:38 |
| dobey | setUp() is being called, because it's failing after things that are done in setUp, are successfully completed | 16:39 |
| Glenjamin | can you inspect the directories registry and try a call to directories.dereference at the end of setup? | 16:41 |
| Glenjamin | dobey: eureka | 16:42 |
| Glenjamin | http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/registry.py#L107 | 16:42 |
| Glenjamin | override_existing defaults to false. | 16:42 |
| Glenjamin | although it excepts, so its not that :< | 16:42 |
| dobey | yeah i don't know what it is | 16:48 |
| GaryvdM | Ok - Fix committed - another bug is now showing, but maybe not critical. | 16:49 |
| * GaryvdM kicks off install build. | 16:49 | |
| dobey | :-/ | 16:50 |
| mgz | you're a star Gary. | 16:50 |
| mgz | dobey, my next step would be to pdb the test and look at the various internals during the run | 16:51 |
| dobey | yeah, will have to wait though. it's nigh time for me to hop off for lunch and an appointment | 16:54 |
| jml | hello | 16:55 |
| jml | we're geting a strange status. a file is showing up as "nonexistent" in status | 16:55 |
| jml | it's a .OTHER file for something that we've deleted. | 16:55 |
| jml | we're not sure what to do about it | 16:55 |
| vila | jml: you deleted it in your branch but modified in the other, if you still don't care about this file delete .OTHER and resolve | 16:56 |
| jml | vila, .OTHER does not exist! | 16:56 |
| vila | jml: oh, and .THIS was modified ? | 16:56 |
| jml | vila, who knows? | 16:57 |
| jml | vila, bzr is just telling us that there's a thing called foo.OTHER that has the status of 'nonexistent' | 16:57 |
| vila | jml: you ? | 16:57 |
| vila | jml: it was probably modified :) | 16:57 |
| jml | vila, perhaps. foo doesn't exist in our tree either. | 16:57 |
| vila | huh | 16:58 |
| === deryck[lunch] is now known as deryck | ||
| vila | jml: shudder | 16:58 |
| vila | jml: .bzr/checkout/conflicts pastebin ? | 16:59 |
| Glenjamin | tried revert/resolve on it? | 16:59 |
| vila | Glenjamin: I think jml wants to know before acting | 16:59 |
| vila | jml: anything related to the parent dir ? | 17:00 |
| Glenjamin | heh, my userland approach would be to hit it with sticks til it worked :) | 17:00 |
| jml | vila, I don't have access to the branch... it's on someone else's machine | 17:00 |
| * vila cries | 17:00 | |
| Glenjamin | oh, on the ghost thing - is there any way for me to make some fake revisions to replace the missing ones? | 17:00 |
| vila | jml: 'nonexistent' or 'missing' ? | 17:02 |
| jml | vila, nonexistent | 17:02 |
| vila | jml: I need to know the conflict type | 17:04 |
| jml | vila, ok. let me reproduce locally... | 17:05 |
| jml | vila, http://paste.ubuntu.com/499800/ | 17:06 |
| jml | vila, buildd-dispatching.txt is the "foo" from above | 17:06 |
| jml | If I do "bzr status", lib/lp/soyuz/doc/buildd-dispatching.txt.BASE is "missing" | 17:07 |
| vila | jml: ok, Contents conflict, always misleading, content refers to the path: The files are of different types (or both binary), or not present | 17:08 |
| jml | vila, right. | 17:09 |
| jml | vila, the file has been deleted in our local branch, and we want to keep it deleted | 17:09 |
| jml | vila, if I just do "bzr resolve lp/.../buildd-dispatch.txt", resolve the other conflict and then commit... | 17:10 |
| vila | jml: so deleted in this and modified in other, so yes | 17:10 |
| jml | vila, I get this... http://paste.ubuntu.com/499804/ | 17:10 |
| vila | jml: how did you resolve ? | 17:11 |
| vila | bzr resolve lp/.../buildd-dispatch.txt --take-this | 17:11 |
| Glenjamin | reminds me, i get an attribute error whenever i do --take-other | 17:12 |
| jml | vila, no option. | 17:12 |
| vila | Glenjamin: file a bug, with a reproducing recipe if possible, the simplest the best | 17:12 |
| Glenjamin | mm, doing now | 17:13 |
| vila | jml: bzr version ? | 17:13 |
| vila | jml: nvm, 'bzr rm lp/.../.OTHER' ; 'bzr resolve lp/.../.OTHER' | 17:13 |
| jml | $ bzr rm lib/lp/soyuz/doc/buildd-dispatching.txt.OTHER | 17:15 |
| jml | bzr: ERROR: Can't safely remove modified or unknown files: | 17:15 |
| jml | added: | 17:15 |
| jml | lib/lp/soyuz/doc/buildd-dispatching.txt.OTHER | 17:15 |
| jml | Use --keep to not delete them, or --force to delete them regardless. | 17:15 |
| vila | jml: sudo amke me a sandwich | 17:16 |
| vila | --force | 17:16 |
| jml | aiee | 17:16 |
| * fullermd slaps vila with a salami. | 17:16 | |
| * vila seriously reconsider paying for those goats | 17:17 | |
| Glenjamin | why does --take-other do a transform, rather than just a filesystem move? | 17:17 |
| jml | un baguette de pain | 17:17 |
| vila | Glenjamin: EOVERFLOW, nasty edge cases | 17:18 |
| vila | jml: une ! :) | 17:18 |
| Glenjamin | anyway, bug posted as 646961 | 17:18 |
| vila | jml: can't you guess from the shape ??? | 17:18 |
| jml | vila, heh heh | 17:18 |
| fullermd | If we hit you enough, it'll be whatever gender we WANT it to be! | 17:18 |
| jml | vila, I suggest you steal fullermd's salami and make your own sandwich | 17:18 |
| * fullermd has a feeling this conversation took a turn somewhere... | 17:19 | |
| vila | jml: will think about it, AFTER you tell me your conflict is gone for good | 17:19 |
| mgz | was that a multilingual pun? | 17:20 |
| jml | vila, that works. | 17:21 |
| jml | mgz, yes. | 17:21 |
| vila | pfew | 17:21 |
| vila | jml: so, 'bzr version' ? | 17:21 |
| jml | Bazaar (bzr) 2.2.0 | 17:21 |
| mgz | un pain de peine would also work. | 17:22 |
| vila | mgz: I don't know what 'un pain de peine' is | 17:22 |
| vila | Now, that's a multilingual pun :-D | 17:22 |
| mgz | or my french fails. | 17:22 |
| fullermd | My french should be great. Heck, in school, I took 4 years of French I. | 17:23 |
| jml | gone | 17:24 |
| roryy | i've got patch for bug 202374 at https://code.launchpad.net/~ryorke/bzr/202374-pull-update-showbase -- do i just run bzr lp-propose and take the defaults? | 17:24 |
| ubot5` | Launchpad bug 202374 in Bazaar "pull and update should accept --show-base (affected: 0, heat: 4)" [Medium,In progress] https://launchpad.net/bugs/202374 | 17:24 |
| mgz | roryy: you can also click "Propose for merging" and fill in the details on that page | 17:25 |
| roryy | mgz: ok. do i need to worry about what the submit branch is? | 17:26 |
| mgz | you pick what you based it off, which should be lp:bzr (the default) | 17:26 |
| roryy | mgz: ok, thank you | 17:27 |
| === beuno is now known as beuno-lunch | ||
| roryy | s'pose i should actually run *all* the tests before proposing a merge | 17:40 |
| === Ursinha-lunch is now known as Ursinha | ||
| mgz | it's not the end of the world if you don't, as PQM will do that for you before landing | 17:45 |
| mgz | but doing `./bzr selftest -s bt.test_source -s $your_test_module` can be useful | 17:45 |
| GaryvdM | mgz: Please could you test an installer for me? http://dl.dropbox.com/u/4494367/bzr-2.2.1%7Ed-setup.exe | 17:48 |
| GaryvdM | http://dl.dropbox.com/u/4494367/bzr-2.2.1~d-setup.exe | 17:48 |
| mgz | getting. | 17:49 |
| vila | GaryvdM: I'm about to crash, I'm sending an email to the ML about the releases status | 17:49 |
| GaryvdM | vila: ok | 17:50 |
| vila | GaryvdM: feel free to reply to it once you're comfortable with your installers | 17:50 |
| vila | GaryvdM: I tried to make it quite clear that we want testers, | 17:50 |
| vila | GaryvdM: the osx installers are already on lp so it;s up to you to decide where you want them to be dl from | 17:51 |
| GaryvdM | Ok - I'll reply with links to what ever I have. | 17:51 |
| vila | GaryvdM: a big thank you for your help here ! | 17:51 |
| mgz | do you need me to include tortoisebzr? | 17:51 |
| GaryvdM | mgz: yes - | 17:51 |
| GaryvdM | mgz: I'm just writing up reproduce steps for a bug. | 17:52 |
| vila | ok, EODing EOWing but will probably pass around... | 17:53 |
| vila | have fun ! | 17:53 |
| mgz | looks fine at first blush, anything in particular that needs poking with a stick? | 17:54 |
| mgz | bye vila! | 17:54 |
| GaryvdM | bye vila. | 17:54 |
| GaryvdM | mgz: http://pastebin.ubuntu.com/499833/ | 17:54 |
| mgz | ta. | 17:54 |
| GaryvdM | mgz: I'm trying to reproduce that with out tbzr | 17:55 |
| GaryvdM | I saw something similar when I was fiddling with bzrw's boot_common.py | 17:55 |
| mgz | I didn't get anything there, I'll try again. | 17:56 |
| GaryvdM | When bzr is finished tries to flush stderr/stdout, which was erroring. | 17:56 |
| GaryvdM | And there's nothing in .bzr.log :-( | 17:56 |
| GaryvdM | I'm blaming tbzrcommand at the moment. | 17:56 |
| mgz | okay, trying with a bigger shared repo, and log is struggling... | 17:58 |
| mgz | hm, still no error message here | 17:59 |
| GaryvdM | Oh - Ok | 17:59 |
| GaryvdM | mgz: The other thing I would like for you to try for me is to try run the testsuite. | 18:00 |
| GaryvdM | I wonder how that will go. | 18:00 |
| mgz | just selftest on the command line? | 18:00 |
| GaryvdM | mgz: Unless you think that this is something to try between releases? | 18:01 |
| mgz | no, it's worth doing, I filed a bug on it a bit back, as there are a few things that need resolving | 18:01 |
| mgz | ha, couple of deprecation warnings, and that __subclasscheck__ thing Andrew was fixing | 18:02 |
| GaryvdM | mgz: I'm just going to grab so food. | 18:05 |
| GaryvdM | bbl | 18:05 |
| mgz | nothing unusual looking so far | 18:05 |
| tsmith | is it possible to remove tags? | 18:16 |
| mgz | they're part of the history, so it's the same story as commit messages, you'd need to rewrite history | 18:16 |
| tsmith | nah | 18:16 |
| tsmith | bzr tag --delete <tag> | 18:17 |
| tsmith | thanks | 18:17 |
| mgz | ha, whoops, so overwrite has been implemented there where it hasn't been for messages | 18:17 |
| mgz | need to poke around some of the bits of bzr I never use | 18:20 |
| maxb | It's not a case of overwrite being implemented | 18:23 |
| maxb | It's simply a case of tags not actually being part of history, but mere annotations on top of it | 18:24 |
| mgz | ah, so I was wrong about the base thingy? | 18:24 |
| maxb | base thingy? | 18:24 |
| mgz | concept maybe, pick a word. | 18:25 |
| mgz | have we got any dev docs on tags? I'm not finding much. | 18:29 |
| maxb | Tags are a dictionary of name: revid, stored in a branch. | 18:30 |
| maxb | That's pretty much it | 18:30 |
| mgz | okay, I'll go back to not worrying about them but be able to answer the question correctly next time | 18:32 |
| === beuno-lunch is now known as beuno | ||
| jasonlife | If I maintain a branch for each release, and keep updating master with new features and bug fixes, how can I apply the bug fixes to the released branch? | 21:48 |
| jasonlife | it seems "bzr merge" doesn't work for this purpose.. | 21:49 |
| fullermd | Well, it sorta does, insofar as you can cherry pick. How well that works over time is more questionable. | 21:50 |
| jasonlife | I need to digging the cherry pick stuff.. I always wondered what the cherry pick is.. | 21:52 |
| jasonlife | I'm new to bzr.. :) | 21:52 |
| fullermd | A cherrypick is basically any merge that, for one reason or another, can't be recorded as a merge. | 21:53 |
| fullermd | In this case, it would be a cherrypick because the graphs are disjoint; a merge of one revision transitively includes all its ancestors. | 21:53 |
| fullermd | Since you don't actually want that in this case, we can't make it a real merge. | 21:54 |
| jasonlife | yes.. | 21:54 |
| jasonlife | I can't do the real merge.. I need *partial* merge for bug fixes.. | 21:55 |
| fullermd | You could make sure everything's connected by using DaggyFixes, but that would probably just get increasingly more difficult as time went by, so it's probably not really a general option. | 21:55 |
| fullermd | Right. So we can't record the merge; as far as bzr is concerned after the fact, it's no different from you manually editing the files and committing, so it can't use any of that information to attempt future merges. | 21:55 |
| jasonlife | I might make a patch file from the master for the bug fixes, then apply the patch to the released branch, but I would think there is a better way.. | 21:55 |
| fullermd | It often works just fine, and it's pretty much always going to be at least as smart as doing diff | patch yourself. | 21:56 |
| fullermd | But as things get more diverged, there'll tend to be more and more cases where bzr can't figure out how to move things across, because the common ancestor it works from gets really far back. | 21:56 |
| jasonlife | except from bazaar wiki.. "A cherrypick is an operation in which the delta between two revisions is applied to a working tree. The process is roughly similiar to generating a diff between two revisions and applying it to a working tree." I think this is what I need.. | 22:02 |
| jasonlife | thanks.. | 22:02 |
| jasonlife | s/except/excerpt | 22:02 |
| === Ursinha is now known as Ursinha-afk | ||
| jasonlife | fullermd: thanks.. cherrypicking works beautifully.. | 22:18 |
| === Ursinha-afk is now known as Ursinha | ||
| jasonlife | Is there a bzr command to list the braches available? | 23:29 |
| jasonlife | like "git branch -a".. | 23:29 |
| mgz | ls | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
