| 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:06 |
| fullermd | I'd guess that if it does, it has to do all the work of converting the repo to do it... | 00:10 |
| spiv | glyph: hmm | 00:13 |
| 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 :) | 00:14 |
| vila | hi all ! | 07:13 |
| fullermd | Eep! | 07:13 |
| vila | :) | 07:13 |
| vila | spiv: Right, so, what *do* you think we should use then ? only regexps ? | 07:14 |
| spiv | vila: something that feels the same as ignore rules, bzrmeta/rules, locations.conf wildcards..? Not sure. | 07:25 |
| 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:27 |
| vila | ignores can use regexps but you have to explicitly ask for them | 07:28 |
| GaryvdM | Hi all | 08:52 |
| 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:54 |
| 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:55 |
| vila | GaryvdM: there is a mp from doxxx about that | 08:56 |
| vila | (about invoking external tools that is) | 08:56 |
| GaryvdM | Ok | 08:56 |
| GaryvdM | vila: but the question is what external app can do this for me | 08:57 |
| 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 ;) | 08:58 |
| GaryvdM | vila: ok - I've never used emacs before, but I'm going to give it a shot - thanks | 09:01 |
| fullermd | Ogod, now look what you've done... corrupting an innocent soul :( | 09:02 |
| * Tak tsk | 09:02 | |
| vila | mwhahaha | 09:03 |
| GaryvdM | I ended up hacking bzrlib.merge.Merge3Merger.get_lines to return words, not lines. | 09:30 |
| GaryvdM | (emacs still downloading...) | 09:30 |
| GaryvdM | I'm using pipeline for the first time. I like it :-) | 09:33 |
| 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:07 |
| jelmer | gthorslund: Ah, you were being consistent with the rest of the file. I hadn't realized that. | 10:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:16 |
| Tak | your user needs read access to the contents of the .bzr dir | 10:21 |
| loldrup | ah ok, will check that | 10:22 |
| 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:34 |
| === Guest26427 is now known as jelmer | ||
| spiv | sladen: bug | 10:55 |
| spiv | sladen: https://bugs.launchpad.net/launchpad-code/+bug/668176 I think; needs bzr upgraded on codehosting to current lp:bzr/2.2 | 10:56 |
| ubot5 | Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop, development focus is empty bzrdir (affected: 1, heat: 11)" [Undecided,New] | 10:56 |
| maxb | Hmm. hg 1.7 is out and current bzr-hg debs claim non-compatibility with that | 11:00 |
| * sladen dupes https://bugs.launchpad.net/bzr/+bug/671351 | 11:02 | |
| ubot5 | Launchpad bug 671351 in Bazaar "bzr branch: "maximum recursion depth exceeded in __subclasscheck__" (dup-of: 668176)" [Undecided,New] | 11:02 |
| ubot5 | Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop, development focus is empty bzrdir (affected: 3, heat: 19)" [Undecided,New] | 11:02 |
| jelmer | bzr-hg is in need of some attention :-/ | 11:06 |
| sladen | spiv: who do I knack to get it fixed. Broken code-hosting is a bit useless | 11:38 |
| 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:39 |
| spiv | sladen: the launchpad-code team; thumper is the lead there | 11:44 |
| spiv | sladen: it got past because it involves a pretty unusual scenario that triggers an unexpected interaction between codehosting and bzrlib | 11:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| * spiv -> zzz | 11:52 | |
| gthorslund | jelmer: pushed docstrings fix now. | 12:09 |
| * gthorslund going for lunch | 12:09 | |
| * jelmer also goes to lunch | 12:16 | |
| jelmer | gthorslund: Thanks, btw! | 14:08 |
| 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:10 |
| 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:12 |
| gthorslund | jelmer: fine. I'll do so. do you see a work queue for everyone in the group to review? | 14:14 |
| jam | gthorslund: stuff like: https://code.edge.launchpad.net/bzr/+activereviews | 14:41 |
| jam | that, and we all get an email when a request for bazaar-dev is made | 14:42 |
| jam | anyway, be back later | 14:44 |
| 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) | 14:46 |
| === 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/ | ||
| DonDiego | moin | 16:08 |
| 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:09 |
| DonDiego | hmmmm | 16:10 |
| vila | DonDiego: use bound branches and unbind when you don't have net access | 16:10 |
| vila | DonDiego: 'bzr info' will tell you what your configuration is and 'bzr reconfigure' will help you adapt it to your needs | 16:11 |
| DonDiego | ah, that's a good hint, thank you, i will investigate tonight | 16:12 |
| === vila is now known as Bernardo | ||
| Bernardo | :) | 16:14 |
| === Bernardo is now known as vila | ||
| 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:24 |
| 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:25 |
| gthorslund | DonDiego: s/co/branch/ then | 16:26 |
| DonDiego | yes, like i wrote, thx :) | 16:26 |
| 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:32 |
| 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:37 |
| 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:38 |
| === deryck is now known as deryck[lunch] | ||
| 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:40 |
| 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:41 |
| mgz | ScottK, I'd really hope they're using Ubuntu :) | 16:42 |
| ScottK | bzr PPA isn't Ubuntu. | 16:42 |
| 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 | 16:43 |
| === 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 | ||
| vila | mgz, jml, maxb: the magic word is: losa | 17:24 |
| jml | vila: no it's not. | 17:25 |
| mgz | I always thought it was please. | 17:25 |
| vila | jml: well, that's where it's blocked so far AIUI | 17:26 |
| === beaumonta is now known as abeaumont_ | ||
| === zyga is now known as zyga-food | ||
| 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:18 |
| 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:19 |
| GaryvdM | Buttons840: Yes | 18:20 |
| GaryvdM | Buttons840: You are able to see uncommited revisions by running bzr heads --dead | 18:21 |
| Buttons840 | GaryvdM: thank you | 18:35 |
| 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:52 |
| dlee | but rsync is way slower than push... | 18:53 |
| === zyga-food is now known as zyga | ||
| vila | dlee: yup, rsync is way slower indeed...The trick you can try is: | 19:13 |
| vila | 1) bzr pack the local repo | 19:13 |
| 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:14 |
| vila | dlee: I suspect the memory errors occur when you have to repack on the FreeBSD machine (smart server there ?) | 19:15 |
| 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:16 |
| 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:17 |
| 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 |
| ubot5 | 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 |
| vila | dlee: look into .bzr/repository/packs on the remote server, dates and sizes should make it clear when the repacks occurs | 19:18 |
| vila | MvG: Is it the one where you added a reproducing recipe ? | 19:19 |
| vila | yup | 19:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| vila | MvG: Wow ! You rock ! Link it to the bug ! Pretty please ? | 19:23 |
| 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:24 |
| vila | MvG: Oh, sorry, I was on the bug #531967 page, silly me | 19:25 |
| ubot5 | 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| vila | dlee: are you the only one using the remote repo ? | 19:33 |
| 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:34 |
| 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:35 |
| vila | dlee: each one is either a commit or a push (it may contain one or several revisions) | 19:36 |
| * 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:38 |
| 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:40 |
| vila | lifeless: no revisions lost (and I shelved before the pull), so no uncommitted changes lost either, just mentioning because you popped out ;) | 19:41 |
| vila | lifeless: a bit freaky way to end my week ;) | 19:42 |
| 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:44 |
| lifeless | maxb: thats a shame; had you read the docs [in-tree] ? | 19:49 |
| maxb | Yes. Those docs are remarkably silent on what a loom *is*, and what on earth "bzr record" actually meands | 19:50 |
| lifeless | k | 19:51 |
| fullermd | 'bzr record' is like 'bzr cd', except it spins slower and hisses more. | 19:54 |
| dlee | fullermd: Aren't we lucky it's bzr shelve and not bzr table... | 19:57 |
| 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:25 |
| === zyga_ is now known as zyga | ||
| thumper | seiflotfy: poolie is the hiring manager | 20:37 |
| 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:39 |
| 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:40 |
| seiflotfy | its ok | 20:44 |
| 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 | 20:48 |
| gthorslund | <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) | 20:52 |
| jam | gthorslund: np. yeah "bazaar" is the meta-project "bzr" is the actual vcs code. | 21:06 |
| 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:19 |
| * gthorslund hopes vila got a backup of his ass somewhere... | 21:29 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!