[00:06] hey #bzr [00:06] is 'bzr branches' supposed to work on remote svn repositories? [00:06] I ran it on my SVN repo's /branches directory, and it's been going for about an hour now. [00:10] I'd guess that if it does, it has to do all the work of converting the repo to do it... [00:13] glyph: hmm [00:14] glyph: 'bzr branches' is pretty simple-minded, I wouldn't be surprised to discover it is pathologically slow with an SVN repo. [00:14] spiv: well, consider yourself having discovered it :) [07:13] hi all ! [07:13] Eep! [07:13] :) [07:14] spiv: Right, so, what *do* you think we should use then ? only regexps ? [07:25] vila: something that feels the same as ignore rules, bzrmeta/rules, locations.conf wildcards..? Not sure. [07:27] 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] ignores can use regexps but you have to explicitly ask for them [08:52] Hi all [08:54] 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] GaryvdM: hi ! [08:55] Or is there maybe some external app that I can pass THIS, BASE, OTHER to? [08:55] Hi vila! [08:55] GaryvdM: In theory, yes, in practice.. I don't think you can achieve that without coding something ;) [08:56] GaryvdM: there is a mp from doxxx about that [08:56] (about invoking external tools that is) [08:56] Ok [08:57] vila: but the question is what external app can do this for me [08:58] GaryvdM: several are mentioned in the mp, that's why I cited it :-p [08:58] oh - ok - I'll take a look [08:58] GaryvdM: *I* use emacs smerge-mode for that ;) [09:01] vila: ok - I've never used emacs before, but I'm going to give it a shot - thanks [09:02] Ogod, now look what you've done... corrupting an innocent soul :( [09:02] * Tak tsk [09:03] mwhahaha [09:30] I ended up hacking bzrlib.merge.Merge3Merger.get_lines to return words, not lines. [09:30] (emacs still downloading...) [09:33] I'm using pipeline for the first time. I like it :-) [10:07] 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] gthorslund: Ah, you were being consistent with the rest of the file. I hadn't realized that. [10:09] 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] gthorslund: It'd be nice if you could fix the rest of that file to use the """-style as well. [10:10] jelmer: ok. I'll do that. [10:10] gthorslund: I'd also be fine with merging your current docstrings as is since they're consistent with the existing style. [10:11] but fixing the file to use the right style would have my preference of course :-) [10:11] jelmer: so let's just keep it simple and not create a new bug + merge request for the change of docstrings :) [10:16] 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] bzr checkout sftp://brok.diku.dk/usr/local/projects/disk07/dirdiffsim/repo/trunk [10:16] bzr: ERROR: Permission denied: "/usr/local/projects/disk07/dirdiffsim/repo/trunk/.bzr/branch-format": [Errno 13] Permission denied [10:21] your user needs read access to the contents of the .bzr dir [10:22] ah ok, will check that [10:34] bzr branch lp:ubuntu-font-family-website generates lots of warnings: [10:34] Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ignored [10:34] ...is that a feature, or a bug? === Guest26427 is now known as jelmer [10:55] sladen: bug [10:56] sladen: https://bugs.launchpad.net/launchpad-code/+bug/668176 I think; needs bzr upgraded on codehosting to current lp:bzr/2.2 [10:56] Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop, development focus is empty bzrdir (affected: 1, heat: 11)" [Undecided,New] [11:00] 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:02] Launchpad bug 671351 in Bazaar "bzr branch: "maximum recursion depth exceeded in __subclasscheck__" (dup-of: 668176)" [Undecided,New] [11:02] Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop, development focus is empty bzrdir (affected: 3, heat: 19)" [Undecided,New] [11:06] bzr-hg is in need of some attention :-/ [11:38] spiv: who do I knack to get it fixed. Broken code-hosting is a bit useless [11:39] spiv: and I've staggered at how that got paste unit/regression testing [11:39] spiv: and I'm staggered at how that got past unit/regression testing [11:44] sladen: the launchpad-code team; thumper is the lead there [11:45] sladen: it got past because it involves a pretty unusual scenario that triggers an unexpected interaction between codehosting and bzrlib [11:46] 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] 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] spiv: oh right, yikes [11:47] Hmm, maybe it technically is a regression. [11:47] But anyway, [11:49] 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] 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] I've fixed the bzr side in lp:bzr/2.2 to be more robust. [11:51] (i.e. not get stuck in an infinite loop of error handling callbacks) [11:51] At this late hour I don't quite recall what the precise circumstances are. [11:51] You can probably workaround it by using sftp or nosmart+lp URLs. [11:52] * spiv -> zzz [12:09] jelmer: pushed docstrings fix now. [12:09] * gthorslund going for lunch [12:16] * jelmer also goes to lunch [14:08] gthorslund: Thanks, btw! [14:10] 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] 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] jelmer: fine. I'll do so. do you see a work queue for everyone in the group to review? [14:41] gthorslund: stuff like: https://code.edge.launchpad.net/bzr/+activereviews [14:42] that, and we all get an email when a request for bazaar-dev is made [14:44] anyway, be back later [14:46] 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) === Meths_ is now known as Meths === beuno is now known as beuno-lunch === 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: jam | Release Manager: vila | 2.3b3 has gone gold, time to build the installers ! | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/ [16:08] moin [16:09] why does 'bzr version-info' require network connectivity? [16:09] DonDiego: probably because you use a checkout so the history is not available locally [16:09] i have it stalling and erroring out on me when my laptop has no inet [16:10] hmmmm [16:10] DonDiego: use bound branches and unbind when you don't have net access [16:11] DonDiego: 'bzr info' will tell you what your configuration is and 'bzr reconfigure' will help you adapt it to your needs [16:12] ah, that's a good hint, thank you, i will investigate tonight === vila is now known as Bernardo [16:14] :) === Bernardo is now known as vila [16:24] DonDiego: I like keeping a local repo doing something like "bzr init-repo foo; cd foo; bzr branch ; 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 if someone else have done updates. [16:25] so far i have done 'bzr init-repo hipl; cd hipl; bzr co lp:hipl' [16:25] but i think i will switch to bzr branch lp:hipl [16:26] DonDiego: s/co/branch/ then [16:26] yes, like i wrote, thx :) [16:32] mgz: hey, yesterday you were talking about being blocked on lifeless to get some testtools stuff done [16:32] 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] 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] mgz: thanks for saying so :) [16:37] mgz: on the pqm thing, maybe there is something we can do to unblock you. Have you sent mail about it? [16:38] 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. === deryck is now known as deryck[lunch] [16:40] 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] Or did you need a newer version of testtools? In which case I can update the ~bzr PPA easily enough [16:41] maxb: For a lot of people it only counts if it's in $DISTROOFCHOICE. [16:42] ScottK, I'd really hope they're using Ubuntu :) [16:42] bzr PPA isn't Ubuntu. [16:43] maxb, your PPA would do, and I think jam said he mentioned it in the rt? [16:43] The Canonical sysadmins use extra packages all the time. I imagine they'll just need to copy it into their private archive [16:43] I'm not really in the right position to coordinate this. [16:43] I have no visibility over the RT, but I'd like to hear any reasons why the PPA isn't an instant solution === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [17:24] mgz, jml, maxb: the magic word is: losa [17:25] vila: no it's not. [17:25] I always thought it was please. [17:26] jml: well, that's where it's blocked so far AIUI === beaumonta is now known as abeaumont_ === zyga is now known as zyga-food [18:18] 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] Buttons840: uncommit moves the branch tip back. [18:19] It matters if you have confidential info you are trying to hide. [18:19] 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] Or if you have committed large files. [18:20] Buttons840: Yes [18:21] Buttons840: You are able to see uncommited revisions by running bzr heads --dead [18:35] GaryvdM: thank you [18:52] 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] So far I've been rsyncing the shared repo from a box without such problems, then pushing the branch itself without incident. [18:53] but rsync is way slower than push... === zyga-food is now known as zyga [19:13] dlee: yup, rsync is way slower indeed...The trick you can try is: [19:13] 1) bzr pack the local repo [19:14] 2) rsync [19:14] 3) push [19:14] get some stats from rsync to get a feeling about when you need to repack, [19:15] dlee: I suspect the memory errors occur when you have to repack on the FreeBSD machine (smart server there ?) [19:16] dlee: If you avoid the remote repack (by repacking locally), you *may* workaround the problem then [19:16] Not sure, it happens at the end of a long push... but the error does point to groupcompress.py if that helps [19:16] dlee: no, a full backtrace is needed to identify repack [19:17] dlee: but you use a smart server there ? [19:17] 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] Not all pushes fail, just the ones that seem large. [19:18] 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] Launchpad bug 638451 in Bazaar " bzr resolve --take-other bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)] (affected: 4, heat: 20)" [Medium,Confirmed] https://launchpad.net/bugs/638451 [19:18] dlee: look into .bzr/repository/packs on the remote server, dates and sizes should make it clear when the repacks occurs [19:19] MvG: Is it the one where you added a reproducing recipe ? [19:19] yup [19:20] It's very high in my todo list (as in: can't be higher) [19:20] my *current* task is re-building a loom lost after a pull from a wrong source (yes, it hurts) [19:21] 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] also added a branch with a blackbox test, by the way. [19:22] 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] vila: I'm seeing a number of messages like this just before the backtrace: [19:22] 728.556 Adding the key (, 2467090, 34026528) to an LRUSizeCache failed. value 68764346 is too big to fit in a the cache with size 41943040 52428800 [19:23] MvG: Wow ! You rock ! Link it to the bug ! Pretty please ? [19:24] vila: Done so already, but I know those links are prety small, so I mention it here. [19:24] 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] MvG: Oh, sorry, I was on the bug #531967 page, silly me [19:25] Launchpad bug 531967 in Bazaar "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted (affected: 1, heat: 0)" [High,Fix released] https://launchpad.net/bugs/531967 [19:26] 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] 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] dlee: I meant a bzr bug :) [19:27] dlee: so, great, the workaround then is to avoid the remote repack [19:27] vila: Me too :) I mean I doubt it's a bzr bug because it only fails on really old stuff. [19:27] dlee: which means you should encounter it less and less [19:28] 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] 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] 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] the local and remote repos have separate lives [19:29] Any helpful stats from server I can give you now? And ah ok. [19:30] even using rsync can be dangerous if you don't check that you're the only one to use the remote repo [19:30] right [19:31] vila: rsync does atomically replace the dest files, but local commits during rsync would be a Bad Thing... [19:31] dlee: yup [19:31] dlee: other pushing during rsync would be bad [19:31] lifeless: touche [19:31] well, exactly what lifeless said [19:31] dlee: because atomicicity matters at the repo level, not at the file level. [19:33] dlee: are you the only one using the remote repo ? [19:34] In case it helps, .bzr/repository/packs contains 35 files, all but one 225 meg or less, but one 2.9 gig! [19:34] dlee: the question is: was it created locally or rsynced ? :D [19:35] That was rsynced recently but then successfully pushed to a time or three. [19:35] dlee: look at the dates and you will see that the small ones are more recent than the old ones [19:36] 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] lifeless: by the way, pulling a loom from an older version of itself => data loss (the pull updated my last-loom file) [19:38] lifeless: of course I didn't record... [19:38] lifeless: I'll file a bug [19:40] vila: you can recover via heads and -r, I expect [19:40] lifeless: that's what I'm doing, but my created threads are lost [19:40] lifeless: well, I'm grepping .bzr log right now so I may recover more this way [19:40] vila: they'll be in the repo; create-thread and a dance with a temp branch and pull [19:40] lifeless: yup [19:41] lifeless: no revisions lost (and I shelved before the pull), so no uncommitted changes lost either, just mentioning because you popped out ;) [19:42] lifeless: a bit freaky way to end my week ;) [19:44] 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] maxb: thats a shame; had you read the docs [in-tree] ? [19:50] Yes. Those docs are remarkably silent on what a loom *is*, and what on earth "bzr record" actually meands [19:51] k [19:54] 'bzr record' is like 'bzr cd', except it spins slower and hisses more. [19:57] fullermd: Aren't we lucky it's bzr shelve and not bzr table... [20:25] hey guys [20:25] I am here because I have questions regardding the employment position [20:25] who can i contact === zyga_ is now known as zyga [20:37] seiflotfy: poolie is the hiring manager [20:39] thanks [20:39] i will need to wait form him to come onlne then [20:39] thumper, any idea when he is on [20:39] ? [20:40] seiflotfy: poolie is in AU, and it is Saturday there [20:40] I'm not sure if he is on often over the weekend [20:44] its ok [20:48] thumper, seiflotfy: he was also on vacation in the US this week, so he is likely still travelling/recovering from a flight. [20:48] I wouldn't expect an update before Mon AU time. [20:48] Probably best to email him [20:52] 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] gthorslund: np. yeah "bazaar" is the meta-project "bzr" is the actual vcs code. [21:19] 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...