[00:06] <glyph> hey #bzr
[00:06] <glyph> is 'bzr branches' supposed to work on remote svn repositories?
[00:06] <glyph> I ran it on my SVN repo's /branches directory, and it's been going for about an hour now.
[00:10] <fullermd> I'd guess that if it does, it has to do all the work of converting the repo to do it...
[00:13] <spiv> glyph: hmm
[00:14] <spiv> glyph: 'bzr branches' is pretty simple-minded, I wouldn't be surprised to discover it is pathologically slow with an SVN repo.
[00:14] <glyph> spiv: well, consider yourself having discovered it :)
[07:13] <vila> hi all !
[07:13] <fullermd> Eep!
[07:13] <vila> :)
[07:14] <vila> spiv: Right, so, what *do* you think we should use then ? only regexps ?
[07:25] <spiv> vila: something that feels the same as ignore rules, bzrmeta/rules, locations.conf wildcards..?  Not sure.
[07:27] <vila> meh, those are globs AFAIK i.e. fnmatch, *I* don't mind using regexps, but it seem we tend to propose globs instead of regexps so I thought it was a deliberate choice
[07:28] <vila> ignores can use regexps but you have to explicitly ask for them
[08:52] <GaryvdM> Hi all
[08:54] <GaryvdM> Is there a way to get bzr to use words, rather than lines when merging? I'm trying to merge  wikipedia article changes
[08:55] <vila> GaryvdM: hi !
[08:55] <GaryvdM> Or is there maybe some external app that I can pass THIS, BASE, OTHER to?
[08:55] <GaryvdM> Hi vila!
[08:55] <vila> GaryvdM: In theory, yes, in practice.. I don't think you can achieve that without coding something ;)
[08:56] <vila> GaryvdM: there is a mp from doxxx about that
[08:56] <vila> (about invoking external tools that is)
[08:56] <GaryvdM> Ok
[08:57] <GaryvdM> vila: but the question is what external app can do this for me
[08:58] <vila> GaryvdM: several are mentioned in the mp, that's why I cited it :-p
[08:58] <GaryvdM> oh - ok - I'll take a look
[08:58] <vila> GaryvdM: *I* use emacs smerge-mode for that ;)
[09:01] <GaryvdM> vila: ok - I've never used emacs before, but I'm going to give it a shot - thanks
[09:02] <fullermd> Ogod, now look what you've done...   corrupting an innocent soul   :(
[09:02]  * Tak tsk
[09:03] <vila> mwhahaha
[09:30] <GaryvdM> I ended up hacking bzrlib.merge.Merge3Merger.get_lines to return words, not lines.
[09:30] <GaryvdM> (emacs still downloading...)
[09:33] <GaryvdM> I'm using pipeline for the first time. I like it :-)
[10:07] <gthorslund> jelmer: saw your comment on https://code.launchpad.net/~gthorslund/bzr-bisect/539937-subtree/+merge/39785 . want me to fix it for all doc strings or just for my additions? (it's just " everywhere from what I can see)
[10:08] <jelmer> gthorslund: Ah, you were being consistent with the rest of the file.  I hadn't realized that.
[10:09] <gthorslund> jelmer: yes, but I can fix it for all of the file if you like. or you could do it after. don't know what looks best.
[10:10] <jelmer> gthorslund: It'd be nice if you could fix the rest of that file to use the """-style as well.
[10:10] <gthorslund> jelmer: ok. I'll do that.
[10:10] <jelmer> gthorslund: I'd also be fine with merging your current docstrings as is since they're consistent with the existing style.
[10:11] <jelmer> but fixing the file to use the right style would have my preference of course :-)
[10:11] <gthorslund> jelmer: so let's just keep it simple and not create a new bug + merge request for the change of docstrings :)
[10:16] <loldrup> hi, I have a serious problem.. I get error 13 when trying to download code from my repository: sftp://brok.diku.dk/usr/local/projects/disk07/dirdiffsim/repo/trunk
[10:16] <loldrup> bzr checkout sftp://brok.diku.dk/usr/local/projects/disk07/dirdiffsim/repo/trunk
[10:16] <loldrup> bzr: ERROR: Permission denied: "/usr/local/projects/disk07/dirdiffsim/repo/trunk/.bzr/branch-format": [Errno 13] Permission denied
[10:21] <Tak> your user needs read access to the contents of the .bzr dir
[10:22] <loldrup> ah ok, will check that
[10:34] <sladen> bzr branch lp:ubuntu-font-family-website    generates lots of warnings:
[10:34] <sladen> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
[10:34] <sladen> ...is that a feature, or a bug?
[10:55] <spiv> sladen: bug
[10:56] <spiv> sladen: https://bugs.launchpad.net/launchpad-code/+bug/668176 I think; needs bzr upgraded on codehosting to current lp:bzr/2.2
[11:00] <maxb> Hmm. hg 1.7 is out and current bzr-hg debs claim non-compatibility with that
[11:02]  * sladen dupes  https://bugs.launchpad.net/bzr/+bug/671351
[11:06] <jelmer> bzr-hg is in need of some attention :-/
[11:38] <sladen> spiv: who do I knack to get it fixed.  Broken code-hosting is a bit useless
[11:39] <sladen> spiv: and I've staggered at how that got paste unit/regression testing
[11:39] <sladen> spiv: and I'm staggered at how that got past unit/regression testing
[11:44] <spiv> sladen: the launchpad-code team; thumper is the lead there
[11:45] <spiv> sladen: it got past because it involves a pretty unusual scenario that triggers an unexpected interaction between codehosting and bzrlib
[11:46] <spiv> sladen: and AFAIK it's not a regression, it's always been lurking, so regression testing by definition wouldn't have caught it :P
[11:47] <sladen> spiv: okay, I've re-read the bug, but can't see the cause/interaction listed, can you outline it so that I can add it to the bug report
[11:47] <sladen> spiv: oh right, yikes
[11:47] <spiv> Hmm, maybe it technically is a regression.
[11:47] <spiv> But anyway,
[11:49] <spiv> IIRC it's basically that some sort broken/unusual bzrdir on the remote side can cause codehosting's VFS to raise a slightly odd error (from bzrlib's perspective at least) in response to an open_branch request from the client.
[11:50] <spiv> Arguably codehosting's VFS should be more careful to only raise filesystem errors from its functions, and arguably bzr should be more robust against unexpected errors.
[11:50] <spiv> I've fixed the bzr side in lp:bzr/2.2 to be more robust.
[11:51] <spiv> (i.e. not get stuck in an infinite loop of error handling callbacks)
[11:51] <spiv> At this late hour I don't quite recall what the precise circumstances are.
[11:51] <spiv> You can probably workaround it by using sftp or nosmart+lp URLs.
[11:52]  * spiv -> zzz
[12:09] <gthorslund> jelmer: pushed docstrings fix now.
[12:09]  * gthorslund going for lunch
[12:16]  * jelmer also goes to lunch
[14:08] <jelmer> gthorslund: Thanks, btw!
[14:10] <gthorslund> jelmer: you too! if I make another merge proposal, should I add you as reviewer instead of bazaar devs as default now? (guess I could ping you or someone here first too)
[14:12] <jelmer> gthorslund: please use bazaar devs so any of us can review. You're always welcome to ping me individually in case nobody replies.
[14:14] <gthorslund> jelmer: fine. I'll do so. do you see a work queue for everyone in the group to review?
[14:41] <jam> gthorslund: stuff like: https://code.edge.launchpad.net/bzr/+activereviews
[14:42] <jam> that, and we all get an email when a request for bazaar-dev is made
[14:44] <jam> anyway, be back later
[14:46] <gthorslund> thx jam (who left). https://code.edge.launchpad.net/bazaar/+activereviews was probably what I was looking for (since it was for plugins like bzr-bisect too)
[16:08] <DonDiego> moin
[16:09] <DonDiego> why does 'bzr version-info' require network connectivity?
[16:09] <vila> DonDiego: probably because you use a checkout so the history is not available locally
[16:09] <DonDiego> i have it stalling and erroring out on me when my laptop has no inet
[16:10] <DonDiego> hmmmm
[16:10] <vila> DonDiego: use bound branches and unbind when you don't have net access
[16:11] <vila> DonDiego: 'bzr info' will tell you what your configuration is and 'bzr reconfigure' will help you adapt it to your needs
[16:12] <DonDiego> ah, that's a good hint, thank you, i will investigate tonight
[16:14] <Bernardo> :)
[16:24] <gthorslund> DonDiego: I like keeping a local repo doing something like "bzr init-repo foo; cd foo; bzr branch <location of foo>; bzr branch foo foo-with-my-edits; cd foo-with-my-edits" start hacking... "bzr commit -m "fixed bar". then you'll need to merge the changes into <location-of-foo> if someone else have done updates.
[16:25] <DonDiego> so far i have done 'bzr init-repo hipl; cd hipl; bzr co lp:hipl'
[16:25] <DonDiego> but i think i will switch to bzr branch lp:hipl
[16:26] <gthorslund> DonDiego: s/co/branch/ then
[16:26] <DonDiego> yes, like i wrote, thx :)
[16:32] <jml> mgz: hey, yesterday you were talking about being blocked on lifeless to get some testtools stuff done
[16:32] <jml> mgz: afterwards, it occurred to me to ask, "how can we change things so that you are blocked neither on lifeless nor myself?"
[16:37] <mgz> jml: on that particular issue with the pqm setup I'm not really sure, it's a canonical infrastructure thing. In general on code things, dvcs and really pretty good responsiveness from you two means I don't really get blocked on coding things except by myself
[16:37] <jml> mgz: thanks for saying so :)
[16:37] <jml> mgz: on the pqm thing, maybe there is something we can do to unblock you. Have you sent mail about it?
[16:38] <mgz> I've not, as I'm not sure where it should be going. I know of the existence of an rt, and found out yesterday the problem was lack of a debian package.
[16:40] <maxb> mgz: For testtools? The problem is not the lack of a Debian package because there is one in the ~bzr PPA. Unless the Canonical sysadmins dislike that?
[16:41] <maxb> Or did you need a newer version of testtools? In which case I can update the ~bzr PPA easily enough
[16:41] <ScottK> maxb: For a lot of people it only counts if it's in $DISTROOFCHOICE.
[16:42] <mgz> ScottK, I'd really hope they're using Ubuntu :)
[16:42] <ScottK> bzr PPA isn't Ubuntu.
[16:43] <mgz> maxb, your PPA would do, and I think jam said he mentioned it in the rt?
[16:43] <maxb> The Canonical sysadmins use extra packages all the time. I imagine they'll just need to copy it into their private archive
[16:43] <mgz> I'm not really in the right position to coordinate this.
[16:43] <maxb> I have no visibility over the RT, but I'd like to hear any reasons why the PPA isn't an instant solution
[17:24] <vila> mgz, jml, maxb: the magic word is: losa
[17:25] <jml> vila: no it's not.
[17:25] <mgz> I always thought it was please.
[17:26] <vila> jml: well, that's where it's blocked so far AIUI
[18:18] <Buttons840> i remember hearing that a uncommit doesn't actually remove the commit?  can someone explain this better, and does it really matter to me?
[18:18] <GaryvdM> Buttons840: uncommit moves the branch tip back.
[18:19] <GaryvdM> It matters if you have confidential info you are trying to hide.
[18:19] <Buttons840> GaryvdM: so if i commit revision 5, and then uncommit it, revision 5 still exists but it's no longer know as revision 5 (as the next commit will become the new "revision 5")?
[18:19] <GaryvdM> Or if you have committed large files.
[18:20] <GaryvdM> Buttons840: Yes
[18:21] <GaryvdM> Buttons840: You are able to see uncommited revisions by running bzr heads --dead
[18:35] <Buttons840> GaryvdM: thank you
[18:52] <dlee> Got a project that includes some large binary files (not my decision) and which is based in Subversion.  I mirror it in bzr, but on an old FreeBSD machine with (I think) 512 meg RAM.  I get a MemoryError in .bzr.log on some pushes containing large binary file updates.  Python 2.4 (hard to upgrade that box).  Anything I can do to avoid the memory errors?
[18:52] <dlee> So far I've been rsyncing the shared repo from a box without such problems, then pushing the branch itself without incident.
[18:53] <dlee> but rsync is way slower than push...
[19:13] <vila> dlee: yup, rsync is way slower indeed...The trick you can try is:
[19:13] <vila> 1) bzr pack the local repo
[19:14] <vila> 2) rsync
[19:14] <vila> 3) push
[19:14] <vila> get some stats from rsync to get a feeling about when you need to repack,
[19:15] <vila> dlee: I suspect the memory errors occur when you have to repack on the FreeBSD machine (smart server there ?)
[19:16] <vila> dlee: If you avoid the remote repack (by repacking locally), you *may* workaround the problem then
[19:16] <dlee> Not sure, it happens at the end of a long push... but the error does point to groupcompress.py if that helps
[19:16] <vila> dlee: no, a full backtrace is needed to identify repack
[19:17] <vila> dlee: but you use a smart server there ?
[19:17] <dlee> So next time I can do local bzr pack and then retry bzr push, only rsyncing if that fails?  Oh yes, bzr+ssh protocol.
[19:18] <dlee> Not all pushes fail, just the ones that seem large.
[19:18] <MvG> vila: Bug #638451 seems to be caused by your commit http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4597.7.11 . Do you have an idea where this goes wrong, just from looking at it again? Might save us a lot of time, as I'm pretty much fishing in the dark here.
[19:18] <vila> dlee: look into .bzr/repository/packs on the remote server, dates and sizes should make it clear when the repacks occurs
[19:19] <vila> MvG: Is it the one where you added a reproducing recipe ?
[19:19] <vila> yup
[19:20] <vila> It's very high in my todo list (as in: can't be higher)
[19:20] <vila> my *current* task is re-building a loom lost after a pull from a wrong source (yes, it hurts)
[19:21] <MvG> vila: In that case I'll leave it to your competent hands, and stop trying to understand stuff that feels quite a bit over my head.
[19:21] <MvG> also added a branch with a blackbox test, by the way.
[19:22] <vila> MvG: welcome to my world :-} I haven't paged back the context yet, but this fix was.... tricky ? painful ? frustrating ? A bit of each...
[19:22] <dlee> vila: I'm seeing a number of messages like this just before the backtrace:
[19:22] <dlee> 728.556  Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at 0x8b574ac>, 2467090, 34026528) to an LRUSizeCache failed. value 68764346 is too big to fit in a the cache with size 41943040 52428800
[19:23] <vila> MvG: Wow ! You rock ! Link it to the bug ! Pretty please ?
[19:24] <MvG> vila: Done so already, but I know those links are prety small, so I mention it here.
[19:24] <vila> dlee: hmm, still not definitive, but you certainly have enough infos to file a bug from where we could either give you a workaround or a fix (but don't hold your breath on the later :-/)
[19:25] <vila> MvG: Oh, sorry, I was on the bug #531967 page, silly me
[19:26] <vila> MvG: Excellent ! You did the part that is the most painful for me :) That will make my heart even lighter while fixing the bug :)
[19:26] <dlee> vila: Ah, autopack spotted, so yes, packing.  And I doubt this is a bug; it works on reasonably up-to-date hardware/OS combinations
[19:26] <vila> dlee: I meant a bzr bug :)
[19:27] <vila> dlee: so, great, the workaround then is to avoid the remote repack
[19:27] <dlee> vila: Me too :)  I mean I doubt it's a bzr bug because it only fails on really old stuff.
[19:27] <vila> dlee: which means you should encounter it less and less
[19:28] <dlee> vila: I bet bzr pack + bzr push makes push much slower, but I'll still take it, as it's also more atomic than rsync
[19:28] <vila> dlee: requiring too much memory is the kind of bug I was referring to, 512M is significant, I don't know the size of the pack files involved, but *in theory* we could limit the size of the pack files (with an impact on performance)
[19:29] <vila> dlee: no, it will be useless to repack without rsync, the remote repo doesn't care about how pack files your local repo has
[19:29] <vila> the local and remote repos have separate lives
[19:29] <dlee> Any helpful stats from server I can give you now?  And ah ok.
[19:30] <vila> even using rsync can be dangerous if you don't check that you're the only one to use the remote repo
[19:30] <dlee> right
[19:31] <dlee> vila: rsync does atomically replace the dest files, but local commits during rsync would be a Bad Thing...
[19:31] <vila> dlee: yup
[19:31] <lifeless> dlee: other pushing during rsync would be bad
[19:31] <dlee> lifeless: touche
[19:31] <vila> well, exactly what lifeless said
[19:31] <lifeless> dlee: because atomicicity matters at the repo level, not at the file level.
[19:33] <vila> dlee: are you the only one using the remote repo ?
[19:34] <dlee> In case it helps, .bzr/repository/packs contains 35 files, all but one 225 meg or less, but one 2.9 gig!
[19:34] <vila> dlee: the question is: was it created locally or rsynced ? :D
[19:35] <dlee> That was rsynced recently but then successfully pushed to a time or three.
[19:35] <vila> dlee: look at the dates and you will see that the small ones are more recent than the old ones
[19:36] <vila> dlee: each one is either a commit or a push (it may contain one or several revisions)
[19:38]  * dlee realizes he didn't put --delete on his rsync command... and only 4 packs locally, but one is that big here too.  And yes, I see the point on dates/sizes.
[19:38] <vila> lifeless: by the way, pulling a loom from an older version of itself => data loss (the pull updated my last-loom file)
[19:38] <vila> lifeless: of course I didn't record...
[19:38] <vila> lifeless: I'll file a bug
[19:40] <lifeless> vila: you can recover via heads and -r, I expect
[19:40] <vila> lifeless: that's what I'm doing, but my created threads are lost
[19:40] <vila> lifeless: well, I'm grepping .bzr log right now so I may recover more this way
[19:40] <lifeless> vila: they'll be in the repo; create-thread and a dance with a temp branch and pull
[19:40] <vila> lifeless: yup
[19:41] <vila> lifeless: no revisions lost (and I shelved before the pull), so no uncommitted changes lost either, just mentioning because you popped out ;)
[19:42] <vila> lifeless: a bit freaky way to end my week ;)
[19:44] <maxb> The main problem with looms, to me, is it took reading the sourcecode of bzr-loom for me to figure out what a loom actually was
[19:49] <lifeless> maxb: thats a shame; had you read the docs [in-tree] ?
[19:50] <maxb> Yes. Those docs are remarkably silent on what a loom *is*, and what on earth "bzr record" actually meands
[19:51] <lifeless> k
[19:54] <fullermd> 'bzr record' is like 'bzr cd', except it spins slower and hisses more.
[19:57] <dlee> fullermd: Aren't we lucky it's bzr shelve and not bzr table...
[20:25] <seiflotfy> hey guys
[20:25] <seiflotfy> I am here because I have questions regardding the employment position
[20:25] <seiflotfy> who can i contact
[20:37] <thumper> seiflotfy: poolie is the hiring manager
[20:39] <seiflotfy> thanks
[20:39] <seiflotfy> i will need to wait form him to come onlne then
[20:39] <seiflotfy> thumper, any idea when he is on
[20:39] <seiflotfy> ?
[20:40] <thumper> seiflotfy: poolie is in AU, and it is Saturday there
[20:40] <thumper> I'm not sure if he is on often over the weekend
[20:44] <seiflotfy> its ok
[20:48] <jam> thumper, seiflotfy: he was also on vacation in the US this week, so he is likely still travelling/recovering from a flight.
[20:48] <jam> I wouldn't expect an update before Mon AU time.
[20:48] <jam> Probably best to email him
 thx jam (who left). https://code.edge.launchpad.net/bazaar/+activereviews was probably what I was looking for (since it was for plugins like bzr-bisect too)
[21:06] <jam> gthorslund: np. yeah  "bazaar" is the meta-project "bzr" is the actual vcs code.
[21:19] <vila> lifeless: just a thought about looms: I understand why record is not called automatically on all operations like (commit, create-thread, combine-thread, switch), *yet* recording all changes to last-loom and *throwing* them away when record'ing would have save my ass today
[21:29]  * gthorslund hopes vila got a backup of his ass somewhere...