[00:56] <Daviey> lifeless, Do you know when the UNRELEASED package of bzr-svn is going to be uploaded to Debian?
[00:57] <lifeless> no idea
[00:57] <Daviey> lifeless, ok - no worries.. thanks :)
[00:58] <lifeless> jelmer will
[00:58] <lifeless> but hets not online just now
[00:59] <Daviey> 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] <Daviey> lifeless, thanks... it is not urgent, just that it is stuff in oneiric atm.. Depends bzr < 2.4
[07:13] <bignose> if I have done ‘bzr shelve’ and the shelf is now created, can I apply a message to it post-hoc?
[07:13] <bignose> so that it shows up in ‘bzr shelve --list’.
[09:08] <jam> morning all
[09:14] <mgz> morning all
[09:22] <spiv> mwhudson: lucky yoU!
[09:49] <LarstiQ> Riddell: if you're still looking for things to do, https://bugs.launchpad.net/bzr/+bug/785633 perhaps? :)
[09:50] <Riddell> LarstiQ: I'll keep it in mind
[09:59] <jam> mgz: bzr branch --switch . ../new-feature-branch
[09:59] <jam> bzr revert -r submit:
[09:59] <jam> # revert everything to upstream
[09:59] <jam> bzr revert file1 file2 # stuff I want to keep
[09:59] <jam> bzr commit
[09:59] <jam> bzr switch ../orig-branch
[10:00] <jam> bzr merge ../new-feature-branch
[10:00] <jam> bzr revert .
[10:00] <jam> bzr commit -m "supersede new-feature-branch"
[10:00] <jam> for the next one, you want to do "bzr branch --switch -r XXX" before you split of new-feature-branch
[10:00] <jam> otherwise the branches end up depending on eacother
[10:08] <mgz> Thanks jam, that makes sense.
[10:15] <jam> jelmer: I can try to talk to you via irc
[10:15] <jam> they sometimes stay quite for like 10 min
[10:15] <jelmer> jam: That works too :)
[10:15] <jam> but you never know wehn
[10:16] <jam> You're welcome to talk alound
[10:16] <jam> I'm listening
[10:22] <bialix> hi
[10:22] <bialix> vila: hi, are you still release manager?
[10:23] <Riddell> bialix: he is but he's talking to poolie right now
[10:23] <bialix> hi Riddell, ok, thanks, np
[10:23] <vila> bialix: yup
[10:24] <bialix> have a couple of minutes? re windows installers
[10:25] <bialix> short question: can I expect to see new beta very soon?
[10:36] <vila> bialix: err, see the lp page ?
[10:37] <vila> right 2.4b3 is planned for next week (2011-05-26) for freeze
[10:37] <bialix> ok, I need fixes for sphinx
[10:37] <vila> new ones ?
[10:37] <bialix> latest
[10:41] <bialix> mgz: can I have your little help?
[10:44] <bialix> anybody has idea about https://bugs.launchpad.net/bzr/+bug/785661
[10:44] <mgz> looks like htmlhelp is failing?
[10:44] <mgz> try running just that command seperately?
[10:45] <bialix> make is make.bar actually, I have to use call make ...
[10:45] <bialix> my bad
[10:47] <bialix> sorry, for the noise.
[10:50] <bialix> so, I have problems with chm-sphinx anyway, even with latest patches for it
[11:08] <spiv> maxb: https://bugs.launchpad.net/bzr/+bug/741375
[11:16] <jam> jelmer: poke
[11:17] <jam> The _cleanup thing is a bug
[11:17] <jam> def unlock() should only call _cleanup when the lock is finally released
[11:17] <jam> not for every unlock call
[11:17] <jam> arguably path2ids shouldn't have needs_read_lock (because I'd like to get rid of those in general)
[11:17] <jam> but we shouldn't be nuking the ignore list on a re-entrant lock
[11:19] <mgz> bug 785671
[11:19] <jam> mgz: thanks, though jelmer, you can just fix that to land your apply delta stuff
[11:20] <jam> it is really just moving the call further down after the "if lock_count == 0" sort of stuff
[11:20] <jelmer> jam: I'm now using inventory.path2id to work around it
[11:20] <jelmer> Though perhaps I should indeed just Do The Right Thing
[11:23] <jam> jelmer: I thought the whole point of this was to get away from inventory
[11:23] <etenil> Hi there
[11:24] <jam> hello
[11:24] <jelmer> 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] <etenil> 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] <jelmer> 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] <jam> jelmer: converting from iter_changes => inventory delta should be straightforward (I think)
[11:25] <jelmer> jam: I'm now just focussing on fixing bug 146165
[11:26] <jam> jelmer: sure, and thats a good start, but the unlock thing should be pretty easy
[11:26] <jelmer> jam: I'm not disagreeing :)
[11:27] <chriscauser> 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] <jelmer> hi chriscauser
[11:27] <jelmer> etenil, hi
[11:28] <etenil> hi jelmer
[11:28] <jelmer> etenil, what do you mean exactly with "it screws up all my refactoring"?
[11:29] <chriscauser> 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] <etenil> 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] <jam> chriscauser: I assume that "bzr diff $" is having to do a conversion of the history to get the information you want.
[11:31] <jam> probably better to fetch it locally, and then "bzr diff ../local" instead
[11:31] <jelmer> etenil: merge doesn't have any custom support for C functions so it just does a three way merge
[11:32] <etenil> jelmer: right, I'd just like it to be aware of the name change. Maybe I could hook up sed or something?
[11:32] <chriscauser> jam: Thanks
[11:32] <jam> 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] <jelmer> etenil, You can write a plugin for bzr which adds a custom merger for those files and basically does the sed
[11:33] <etenil> ah
[11:33] <etenil> mmh
[11:33] <etenil> 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] <jelmer> 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] <etenil> ok
[11:34] <jelmer> jam: Sure, I'll have a look.
[11:34] <etenil> well thanks for your help jelmer, I think I'll just stick to manual handling for the time being
[11:34] <chriscauser> jam: Although I think perhaps something else is going on because the diff downloads substantially more than the repo size
[11:35] <chriscauser> Hmm
[11:35] <jelmer> chriscauser: You're probably better off pulling down the repository and looking at it locally
[11:35] <jam> chriscauser: well, you're doing cross-format conversions
[11:35] <jam> We don't always try to optimize the bandwidth, etc.
[11:36] <chriscauser> jam: I guess that's it. I'll work with branching the two branches and working locally
[11:36] <chriscauser> Thanks!
[11:37] <jelmer> chriscauser, can you file a bug about this particular case?
[12:13] <poolie> is bug 785377 a dupe of one that was recently fixed?
[12:13] <poolie> about merge into a new directoly?
[12:37] <jam> poolie: yeah, well the fix from Riddell was to just refuse with a nicer message
[13:12] <ScottK> So Riddell's niceness will now infect bzr?  "bzr: Friendly version control"
[13:15] <Riddell> :)
[13:16] <fullermd> I miss when it used to laugh at you for screwing up   :(
[13:17] <jam> fullermd: yeah, but hooking into sound libraries seemed too big of a dependency
[13:17] <fullermd> If you wanna make an omlette, you gotta break a few lions.
[13:18] <santagada> LarstiQ, hi, how is your bzr-pypy branch going? need someone to test it?
[13:19] <LarstiQ> santagada: nothing new from my end, jam did some work on the test cleanups
[13:19] <LarstiQ> santagada: I got lost in trying to debug the locking code
[13:19] <jam> LarstiQ: well, only getting bits of it merged into bzr.dev
[13:19] <LarstiQ> jam: for which I'm thankful :)
[13:20] <LarstiQ> santagada: on the pypy there seems to be an issue with keeping around the loops too long
[13:21] <LarstiQ> santagada: antoncuni seems interested in that
[13:24] <LarstiQ> santagada: maybe you could help drive that along by providing him with data when needed?
[13:29] <chriscauser> jelmer: Will do.
[14:04] <poolie> jam, well, refusing that merge with a nice message should avoid the bad state
[14:04] <poolie> canny version control
[14:10] <poolie> jam i don't know if you overheard but http://babune.ladeuil.net:24842/job/chroot-natty/ should now be pretty stable
[14:10] <poolie> as far as avoiding spurious vmbox or jenkins failures
[14:10] <poolie> fingers crossed
[14:10] <poolie> also it should build up to every hour if there are new commits
[14:12] <jam> poolie: sounds nice, though if we still go through pqm first, I don't see *natty* being a super important target
[14:12] <jam> unless pqm is just lucid?
[14:12] <jam> still nice for it to be stable
[14:22] <poolie> hm
[14:23] <poolie> pqm is on lucid
[14:23] <poolie> but really the main point here is that it's stable
[14:23] <poolie> and we ought to be able to replicate it for other ubuntu releases and other linux distributions
[14:24] <poolie> 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] <poolie> jam, i think they reliably fail for me on wine
[16:16] <james_w> jelmer, hey, I just remembered, are you adding the new substitution variables to the plugin help via the module docstring?
[16:17] <james_w> I think the current ones are documented there
[16:17] <jelmer> james_w: Ah, I wasn't aware of that. I'll update it - thanks for the reminder.
[16:17] <james_w> np
[16:19] <james_w> jelmer, if you could add in https://bugs.launchpad.net/launchpad/+bug/624094 while working on these, that would be great
[16:21] <jelmer> james_w: sure
[16:21] <james_w> thanks
[16:21] <jelmer> james_w: would it perhaps be useful to have a variable for just the debian revision than the entire thing?
[16:21] <james_w> maybe
[16:21] <james_w> for this use case we want the whole thing, epoch, debian revision and all
[16:56] <BjornW> can someone tell me if bzr has something like svn:externals or git submodules?
[17:01] <mgz> there's bzr-externals and bzr-scmproj plugins
[17:07] <BjornW> mgz: ok so nothing in bzr core itself? Mhhm too bad
[17:55] <mgz> nearly time for me to head off
[18:06] <spiv> poolie, mgz, jam, maxb, jelmer, Riddell, vila: http://wiki.bazaar.canonical.com/May2011Sprint
[21:41] <dcoles> Is it unusual to see ghost-revisions when inspecting a svn repository which has had bzr commits pushed to it?
[21:42] <dcoles> 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] <LarstiQ> dcoles: there is a config setting that might help iirc
[21:53] <LarstiQ> dcoles: push_merged_revisions
[21:54] <dcoles> For the svn server or for bazaar?
[21:54] <LarstiQ> dcoles: for bzr-svn
[21:54] <dcoles> Ah. I'll take a look if I've got that set.
[21:54] <dcoles> First time I've used bzr-svn on an extended svn project.
[22:03] <dcoles> Ah. Yes. Expected behavior: https://bugs.launchpad.net/bzr-svn/+bug/569360/comments/3
[22:03] <dcoles> Thanks LarstiQ
[22:04] <LarstiQ> I forget why it doesn't default to that
[22:04] <dcoles> I think it will create branches automagically
[22:04] <dcoles> Much like tags do
[22:04] <LarstiQ> really?
[22:04] <dcoles> Which may be unexpected.
[22:04]  * LarstiQ hasn't used bzr-svn in a while, admittedly
[22:04] <LarstiQ> dcoles: right
[22:05] <LarstiQ> dcoles: but ending up in your situation isn't nice either
[22:05] <dcoles> At least that's how it sounds like it's supposed to work. :)
[22:05] <dcoles> Yes. I hope I have some of those branches around locally.
[22:07]  * LarstiQ nods
[22:07] <dcoles> Otherwise I just lost the individual commits. The reason I use bzr-svn rather than subversion
[22:07] <LarstiQ> although bzr should be able to cope with ghosts
[22:07] <LarstiQ> you may hit some rough corners
[22:08] <dcoles> Bazaar is fine (though doesn't show them well in the UI). bzr qlog pukes a bit (bug reported)
[22:08] <dcoles> https://bugs.launchpad.net/ubuntu/+source/qbzr/+bug/785967
[22:08] <dcoles> Oh. Private.
[22:11] <dcoles> The other fix is to just push the merge branches to the subversion branches by hand
[22:14] <LarstiQ> dcoles: right
[22:14] <LarstiQ> dcoles: if you still have them
[22:15] <LarstiQ> bzr heads from bzrtools might help find them in some cases
[22:26] <abeld> 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] <abeld> I mean it says "bzr: ERROR: Not a branch: "/path/to/repo/.bzr/branch/": location is a repository."
[22:27] <abeld> (i.e. fast-export -ing a bzr "shared repository")
[22:43] <LarstiQ> abeld: it's not really geared to that I don't think
[22:43] <LarstiQ> abeld: it might make sense to extend it, but I don't know the fast-export format enough to judge
[22:43] <abeld> So what is the recommended way to convert such a shared repository to a git one?
[22:44] <abeld> 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] <LarstiQ> abeld: I would assume so, but I don't know
[22:45] <LarstiQ> abeld: you could also see if bzr-git could be of help
[22:45] <LarstiQ> abeld: I know bzr-svn has svn-import to do it the opposite direction atleast
[22:47] <dcoles> 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] <abeld> Hmm. bzr fast-export has a "--git-branch=...." arg, I'll try that to specify the name when exporting the repositories.
[22:48] <dcoles> Bazaar doesn't handle the colocated git repos all that great.
[22:49] <LarstiQ> dcoles: does bzr-colo improve that at all?
[22:50] <LarstiQ> or is that wishful thinking, bzr-colo and bzr-git interoperating magically
[22:50] <dcoles> I'm not sure. I don't think that existed about a year/year-half ago.
[22:51] <dcoles> Certainly the issue I was having was dependent on colocated branches.
[22:51] <LarstiQ> launchpad.net/bzr-colo fwiw
[22:58] <dcoles> 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] <abeld> 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] <dcoles> Nice.
[23:02] <abeld> 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] <abeld> So this will work for me.
[23:03] <dcoles> I think it's pretty good so long as you do it from the same repo.
[23:05] <dcoles> 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] <dcoles> 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] <bignose> if I have done ‘bzr shelve’ and the shelf is now created, can I apply a message to it post-hoc?
[23:56] <bignose> so that the message shows up in ‘bzr shelve --list’.