[00:56] lifeless, Do you know when the UNRELEASED package of bzr-svn is going to be uploaded to Debian? [00:57] no idea [00:57] lifeless, ok - no worries.. thanks :) [00:58] jelmer will [00:58] but hets not online just now [00:59] lifeless, yeah, i saw he was offline and he made the change.. I wondered if you knew as it seems you are both uploaders.. [00:59] lifeless, thanks... it is not urgent, just that it is stuff in oneiric atm.. Depends bzr < 2.4 === medberry is now known as med_out [07:13] if I have done ‘bzr shelve’ and the shelf is now created, can I apply a message to it post-hoc? [07:13] so that it shows up in ‘bzr shelve --list’. [09:08] morning all [09:14] morning all [09:22] mwhudson: lucky yoU! === hunger_ is now known as hunger === gerard_1 is now known as gerard_ [09:49] Riddell: if you're still looking for things to do, https://bugs.launchpad.net/bzr/+bug/785633 perhaps? :) [09:49] Ubuntu bug 785633 in Bazaar "bzr missing doesn't like :parent" [Low,Confirmed] [09:50] LarstiQ: I'll keep it in mind [09:59] mgz: bzr branch --switch . ../new-feature-branch [09:59] bzr revert -r submit: [09:59] # revert everything to upstream [09:59] bzr revert file1 file2 # stuff I want to keep [09:59] bzr commit [09:59] bzr switch ../orig-branch [10:00] bzr merge ../new-feature-branch [10:00] bzr revert . [10:00] bzr commit -m "supersede new-feature-branch" [10:00] for the next one, you want to do "bzr branch --switch -r XXX" before you split of new-feature-branch [10:00] otherwise the branches end up depending on eacother [10:08] Thanks jam, that makes sense. [10:15] jelmer: I can try to talk to you via irc [10:15] they sometimes stay quite for like 10 min [10:15] jam: That works too :) [10:15] but you never know wehn [10:16] You're welcome to talk alound [10:16] I'm listening [10:22] hi [10:22] vila: hi, are you still release manager? [10:23] bialix: he is but he's talking to poolie right now [10:23] hi Riddell, ok, thanks, np [10:23] bialix: yup [10:24] have a couple of minutes? re windows installers [10:25] short question: can I expect to see new beta very soon? [10:36] bialix: err, see the lp page ? [10:37] right 2.4b3 is planned for next week (2011-05-26) for freeze [10:37] ok, I need fixes for sphinx [10:37] new ones ? [10:37] latest [10:41] mgz: can I have your little help? [10:44] anybody has idea about https://bugs.launchpad.net/bzr/+bug/785661 [10:44] Ubuntu bug 785661 in Bazaar "`make chm-sphinx` is always exits with error code 1" [Undecided,New] [10:44] looks like htmlhelp is failing? [10:44] try running just that command seperately? [10:45] make is make.bar actually, I have to use call make ... [10:45] my bad [10:47] sorry, for the noise. [10:50] so, I have problems with chm-sphinx anyway, even with latest patches for it [11:08] maxb: https://bugs.launchpad.net/bzr/+bug/741375 [11:08] Ubuntu bug 741375 in Launchpad itself "using +branch/~user/project/branch prevents automatic stacking of new branches pushed to Launchpad" [High,Triaged] [11:16] jelmer: poke [11:17] The _cleanup thing is a bug [11:17] def unlock() should only call _cleanup when the lock is finally released [11:17] not for every unlock call [11:17] arguably path2ids shouldn't have needs_read_lock (because I'd like to get rid of those in general) [11:17] but we shouldn't be nuking the ignore list on a re-entrant lock [11:19] bug 785671 [11:19] Launchpad bug 785671 in Bazaar "calling WorkingTree.path2id resets ignore list cache" [Medium,Confirmed] https://launchpad.net/bugs/785671 [11:19] mgz: thanks, though jelmer, you can just fix that to land your apply delta stuff [11:20] it is really just moving the call further down after the "if lock_count == 0" sort of stuff [11:20] jam: I'm now using inventory.path2id to work around it [11:20] Though perhaps I should indeed just Do The Right Thing [11:23] jelmer: I thought the whole point of this was to get away from inventory [11:23] Hi there [11:24] hello [11:24] jam: that's what I initially set out to do, but I had to use inventory deltas so the foreign plugins need a custom implementation anyway [11:25] I'm using a git-like workflow with bzr. And I've refactored a bit my code in my latest branch, so that functions have a slightly different name (a sed was enough). However, when I patch my stable branch and merge up the patch, it screws up all my refactoring. Does bazaar have facilities that could solve this? [11:25] jam: They already have custom implementations now (and can take some shortcuts, as there's no need to worry about e.g. directories for hg and git) [11:25] jelmer: converting from iter_changes => inventory delta should be straightforward (I think) [11:25] jam: I'm now just focussing on fixing bug 146165 [11:25] Launchpad bug 146165 in Bazaar "smart_add uses _get_inventory, _write_inventory, but should not" [Medium,In progress] https://launchpad.net/bugs/146165 [11:26] jelmer: sure, and thats a good start, but the unlock thing should be pretty easy [11:26] jam: I'm not disagreeing :) [11:27] Hello everyone. I think I've found a bug in bzr-svn but I thought it best to discuss here before I file a bugreport [11:27] hi chriscauser [11:27] etenil, hi [11:28] hi jelmer [11:28] etenil, what do you mean exactly with "it screws up all my refactoring"? [11:29] When I have a checkout of trunk, and I do a "bzr diff https://scm...../branchname", it whirrs for ~ 2 hours on "9197kB 1171kB/s / fetching changes for file ids 0/415" with the download size getting larger and larger (probably > repo size) before falling over [11:29] jelmer: well let's say I've renamed my function foo() to bar() and updated all the code accordingly, when I merge up my patch from stable (where foo() is still foo()), I'd like foo() to get renamed to bar() automatically [11:31] chriscauser: I assume that "bzr diff $" is having to do a conversion of the history to get the information you want. [11:31] probably better to fetch it locally, and then "bzr diff ../local" instead [11:31] etenil: merge doesn't have any custom support for C functions so it just does a three way merge [11:32] jelmer: right, I'd just like it to be aware of the name change. Maybe I could hook up sed or something? [11:32] jam: Thanks [11:32] jelmer: would it be a lot of work to factor the smart_add stuff into a helper class, I'm a bit sad to see *more* nested functions. [11:33] etenil, You can write a plugin for bzr which adds a custom merger for those files and basically does the sed [11:33] ah [11:33] mmh [11:33] well I'll see about that then. Or maybe I'll just suffer a bit longer until my unstable branch becomes stable :D [11:33] etenil, however, it's easy to do something that handles the trivial case but hard to handle all cases properly without actually properly parsing the full file [11:34] ok [11:34] jam: Sure, I'll have a look. [11:34] well thanks for your help jelmer, I think I'll just stick to manual handling for the time being [11:34] jam: Although I think perhaps something else is going on because the diff downloads substantially more than the repo size [11:35] Hmm [11:35] chriscauser: You're probably better off pulling down the repository and looking at it locally [11:35] chriscauser: well, you're doing cross-format conversions [11:35] We don't always try to optimize the bandwidth, etc. [11:36] jam: I guess that's it. I'll work with branching the two branches and working locally [11:36] Thanks! [11:37] chriscauser, can you file a bug about this particular case? [12:13] is bug 785377 a dupe of one that was recently fixed? [12:13] Launchpad bug 785377 in Bazaar "merging into a new branch leaves working tree in bad state (bzr: ERROR: exceptions.ValueError: WorkingTree.set_root_id with fileid=None)" [Undecided,New] https://launchpad.net/bugs/785377 [12:13] about merge into a new directoly? === gerard_1 is now known as gerard_ [12:37] poolie: yeah, well the fix from Riddell was to just refuse with a nicer message [13:12] So Riddell's niceness will now infect bzr? "bzr: Friendly version control" [13:15] :) [13:16] I miss when it used to laugh at you for screwing up :( [13:17] fullermd: yeah, but hooking into sound libraries seemed too big of a dependency [13:17] If you wanna make an omlette, you gotta break a few lions. [13:18] LarstiQ, hi, how is your bzr-pypy branch going? need someone to test it? [13:19] santagada: nothing new from my end, jam did some work on the test cleanups [13:19] santagada: I got lost in trying to debug the locking code [13:19] LarstiQ: well, only getting bits of it merged into bzr.dev [13:19] jam: for which I'm thankful :) [13:20] santagada: on the pypy there seems to be an issue with keeping around the loops too long [13:21] santagada: antoncuni seems interested in that [13:24] santagada: maybe you could help drive that along by providing him with data when needed? [13:29] jelmer: Will do. === Ursinha is now known as Ursinha-afk [14:04] jam, well, refusing that merge with a nice message should avoid the bad state [14:04] canny version control [14:10] jam i don't know if you overheard but http://babune.ladeuil.net:24842/job/chroot-natty/ should now be pretty stable [14:10] as far as avoiding spurious vmbox or jenkins failures [14:10] fingers crossed [14:10] also it should build up to every hour if there are new commits [14:12] poolie: sounds nice, though if we still go through pqm first, I don't see *natty* being a super important target [14:12] unless pqm is just lucid? [14:12] still nice for it to be stable [14:22] hm [14:23] pqm is on lucid [14:23] but really the main point here is that it's stable [14:23] and we ought to be able to replicate it for other ubuntu releases and other linux distributions [14:24] and then that should mean there are so few actually running as vms that they can run all the time, which should avoid another class of problems [15:00] jam, i think they reliably fail for me on wine [16:16] jelmer, hey, I just remembered, are you adding the new substitution variables to the plugin help via the module docstring? [16:17] I think the current ones are documented there [16:17] james_w: Ah, I wasn't aware of that. I'll update it - thanks for the reminder. [16:17] np [16:19] jelmer, if you could add in https://bugs.launchpad.net/launchpad/+bug/624094 while working on these, that would be great [16:19] Ubuntu bug 624094 in Launchpad itself "Support package version found in branches when specifying version numbers in recipe" [Medium,Triaged] [16:21] james_w: sure [16:21] thanks [16:21] james_w: would it perhaps be useful to have a variable for just the debian revision than the entire thing? [16:21] maybe [16:21] for this use case we want the whole thing, epoch, debian revision and all [16:56] can someone tell me if bzr has something like svn:externals or git submodules? [17:01] there's bzr-externals and bzr-scmproj plugins [17:07] mgz: ok so nothing in bzr core itself? Mhhm too bad === elmo is now known as ihateyoutoo [17:55] nearly time for me to head off [18:06] poolie, mgz, jam, maxb, jelmer, Riddell, vila: http://wiki.bazaar.canonical.com/May2011Sprint === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [21:41] Is it unusual to see ghost-revisions when inspecting a svn repository which has had bzr commits pushed to it? [21:42] I have a branch which I've just pushed which contained several merges. If I look at the history in the bazaar branch it looks fine, but if I branch from the svn repository anything with depth > 1 appears as a ghost. [21:53] dcoles: there is a config setting that might help iirc [21:53] dcoles: push_merged_revisions [21:54] For the svn server or for bazaar? [21:54] dcoles: for bzr-svn [21:54] Ah. I'll take a look if I've got that set. [21:54] First time I've used bzr-svn on an extended svn project. [22:03] Ah. Yes. Expected behavior: https://bugs.launchpad.net/bzr-svn/+bug/569360/comments/3 [22:03] Ubuntu bug 569360 in Bazaar Subversion Plugin "bzr log skips merge revisions" [Undecided,Invalid] [22:03] Thanks LarstiQ [22:04] I forget why it doesn't default to that [22:04] I think it will create branches automagically [22:04] Much like tags do [22:04] really? [22:04] Which may be unexpected. [22:04] * LarstiQ hasn't used bzr-svn in a while, admittedly [22:04] dcoles: right [22:05] dcoles: but ending up in your situation isn't nice either [22:05] At least that's how it sounds like it's supposed to work. :) [22:05] Yes. I hope I have some of those branches around locally. [22:07] * LarstiQ nods [22:07] Otherwise I just lost the individual commits. The reason I use bzr-svn rather than subversion [22:07] although bzr should be able to cope with ghosts [22:07] you may hit some rough corners [22:08] Bazaar is fine (though doesn't show them well in the UI). bzr qlog pukes a bit (bug reported) [22:08] https://bugs.launchpad.net/ubuntu/+source/qbzr/+bug/785967 [22:08] Error: Launchpad(https://launchpad.net) bug 785967 not found [22:08] Oh. Private. [22:11] The other fix is to just push the merge branches to the subversion branches by hand [22:14] dcoles: right [22:14] dcoles: if you still have them [22:15] bzr heads from bzrtools might help find them in some cases [22:26] Hi! how can I fast-export a _repository_ (as opposed to a single branch)? All the references to fast-export that I can find by googling deal only with branches. "bzr fast-export" says "" [22:26] I mean it says "bzr: ERROR: Not a branch: "/path/to/repo/.bzr/branch/": location is a repository." [22:27] (i.e. fast-export -ing a bzr "shared repository") [22:43] abeld: it's not really geared to that I don't think [22:43] abeld: it might make sense to extend it, but I don't know the fast-export format enough to judge [22:43] So what is the recommended way to convert such a shared repository to a git one? [22:44] Will fast-export (then fast-import to git) the branches inside the repository one-by-one make me end up with a 'many branches in one repo' git repository? [22:44] abeld: I would assume so, but I don't know [22:45] abeld: you could also see if bzr-git could be of help [22:45] abeld: I know bzr-svn has svn-import to do it the opposite direction atleast [22:47] Last time I used bzr-git I'd either push my branches by hand or checkout each branch in git and then push to them from bazaar. [22:48] Hmm. bzr fast-export has a "--git-branch=...." arg, I'll try that to specify the name when exporting the repositories. [22:48] Bazaar doesn't handle the colocated git repos all that great. [22:49] dcoles: does bzr-colo improve that at all? [22:50] or is that wishful thinking, bzr-colo and bzr-git interoperating magically [22:50] I'm not sure. I don't think that existed about a year/year-half ago. [22:51] Certainly the issue I was having was dependent on colocated branches. [22:51] launchpad.net/bzr-colo fwiw [22:58] I think it was the case where you wanted to check out a git repository with branches... but I've not used git for a while and can't remember the exact weirdness that goes on. [23:02] Ok, I tried it out, and it apparently worked (at least it did what I wanted). I ran 'bzr fast-export path/to/bzr_repo/branchname/ --git-branch=branchname | git fast-import' for each branch [23:02] Nice. [23:02] The git repo I ended up with contained the right branches, and commits merged from one to the other were apparently not duplicated (which was what I was afraid of might happen) [23:03] So this will work for me. [23:03] I think it's pretty good so long as you do it from the same repo. [23:05] I know some exporters will end up with non-determanistic ids if run from different machines, but I think there's a cache that keeps track of the mappings. [23:18] Another cool feature is the svn branch name can differ from the bzr branch name and it will still find the correct mapping. [23:56] if I have done ‘bzr shelve’ and the shelf is now created, can I apply a message to it post-hoc? [23:56] so that the message shows up in ‘bzr shelve --list’.