| mwhudson | beuno: i should say that it's not just performance we'd be looking for with genshi, but also memory usage | 00:00 |
|---|---|---|
| mwhudson | beuno: if you change the limit for 'fancy' diffs up to say 10000 and view a big diff and watch loggerhead's memory usage in top you'll get a fright :) | 00:00 |
| beuno | right, I tend to see memory as a part of performance, but, of course, you're not in my head. | 00:01 |
| beuno | cool, I'll create a branch with a big diff and use that | 00:01 |
| beuno | that helps :) | 00:01 |
| beuno | I'd also like to do something about setup.py sooner than later, so we don't break people's computers to install loggerhead | 00:02 |
| mwhudson | beuno: well, you were ambiguous enough for me to want to check | 00:02 |
| beuno | mwhudson, the more explicit, the better, so thanks for clearing that up | 00:02 |
| mwhudson | beuno: when we first identified the problem with big diffs the irc transcript went like this: | 00:03 |
| mwhudson | <mwh> right, i have the branch set up, let the machine crushing begin! | 00:03 |
| mwhudson | *** mwh has quit (remote closed the connection) | 00:03 |
| beuno | lol | 00:03 |
| mwhudson | *** mwh has joined the channel | 00:03 |
| mwhudson | * mwh didn't expect that to work so well | 00:03 |
| mwhudson | the OOM killer got involved and killed x | 00:04 |
| dlee | lol | 00:04 |
| * beuno starts setting up a test enviroment in a different PC | 00:04 | |
| mwhudson | beuno: another bit of advice: | 00:04 |
| mwhudson | don't use firefox to test the url, use curl or something instead :) | 00:04 |
| beuno | ah, makes a lot of sense | 00:06 |
| dlee | If I could dare one more question: Is cvsps-import still the most preferred way of importing CVS to Bazaar (one-way, one-time should be all I need, but for a lot of projects, again with mixed case and Windows line endings)? | 00:06 |
| beuno | two memory hoggers at once won't help | 00:06 |
| mwhudson | dlee: yes | 00:06 |
| dlee | I even have one project that ues vendor branches :P (Tailor doesn't handle those too well) | 00:07 |
| mwhudson | dlee: another sane option aiui is to use cvs2svn's 'fastexport' stream and bzr-fastimport | 00:07 |
| dlee | Ah thanks! I looked at that but missed how to get it all put together. | 00:07 |
| dlee | looked at fastexport I mean | 00:08 |
| beuno | ok, well, mwhudson, jam, many thanks for all the input/patience, I'll get back to coding for a while | 00:08 |
| beuno | mwhudson, I'll move _strip_NULL_ghosts into loggerhead so we're on the safe side for now | 00:08 |
| mwhudson | beuno: thanks | 00:09 |
| beuno | mwhudson, just to recap, for the new theme for files, it's generally OK as-is, or is there something you want changed before we move on? | 00:12 |
| mwhudson | beuno: it's ok with me, we should probably give some other people a chance to respond :) | 00:12 |
| beuno | mwhudson, heh, yeah, probably. *Some* work has been done on the diff view already, so I hope to get that out soon too. | 00:13 |
| mwhudson | great | 00:14 |
| beuno | awilkins, related to the eclipse cache, the XMLRPC should solve the need for one. I know Verterok had played around with it, but it's a heap of work, so I'm not sure when that will land. | 00:21 |
| thumper | spiv: ping | 00:25 |
| thumper | now, I think I know what it is doing, but pushing to bzr+ssh it is sitting at Copying signature texts 4/5 for ages, could this be doing a repack (locally) | 00:29 |
| spiv | thumper: check the ~/.bzr.log | 00:30 |
| spiv | thumper: as it happens, I have a branch I made yesterday that does the autopack server-side. | 00:30 |
| thumper | spiv: nothing in there | 00:30 |
| thumper | spiv: since the last success anyway | 00:31 |
| spiv | thumper: use | 00:31 |
| spiv | "bzr -Dhpss ..." | 00:31 |
| spiv | in future, and then the .bzr.log will tell you much more. | 00:31 |
| thumper | spiv: should I kill my push or not? | 00:31 |
| spiv | I'm fairly sure that an autopack does get logged, though. | 00:31 |
| thumper | hmm.. | 00:31 |
| spiv | So it's probably "normal" operation. | 00:31 |
| spiv | I suspect it's too late to kill the push and redo the identical push. | 00:32 |
| spiv | You could try it, though. | 00:32 |
| thumper | ??? | 00:34 |
| thumper | it said created new branch | 00:34 |
| thumper | when the branch was already ther | 00:34 |
| thumper | e | 00:34 |
| spiv | The branch probably wasn't already there. | 00:36 |
| spiv | If you had a -Dhpss log, we could confirm this :) | 00:36 |
| awilkins | beuno: Why would the XMLRPC solve the need to cache? | 00:50 |
| awilkins | beuno: Does it implement a server which itself caches? | 00:51 |
| awilkins | Bah, anyway, it's late, beddy-byes time, gnight | 00:55 |
| beuno | awilkins, for starters, you stop paying the cost of starting bzr everytime. And, eventually, if needed, you will be able to cache, yes | 00:55 |
| awilkins | beuno: I've already mitigated the cost of starting bzr somewhat by integrating the "service" plugin into bzr-eclipse | 00:55 |
| awilkins | beuno: But on my target working tree of 3700 files the performance still leaves a lot to be desired. | 00:56 |
| beuno | awilkins, right, well, I don't know any specifics, but I suppose you can cache with the XMLRPC, and avoid re-writing it within eclipse | 00:56 |
| awilkins | The problem is mostly uncached log hits for decorators | 00:57 |
| beuno | but Verterok is the man to talk to | 00:57 |
| awilkins | Yes, I correspond with him. | 00:57 |
| beuno | awilkins, anyway, just though I'd comment. I'll let you sleep already, g'night :) | 00:59 |
| awilkins | The performance of "log" on a single file for bzr is not what it is for SVN/CVS | 00:59 |
| awilkins | Gnight chaps, until tomorrows first coffee..... | 00:59 |
| * igc medical appointment - bbl | 01:17 | |
| halstead | How do I cause bzr to forget an improperly set submit branch as listed in bzr info? | 01:18 |
| fullermd | I don't think there is a UI to 'forget'. You can overwrite with a --remember. | 01:18 |
| fullermd | Only way to forget is just whack it out of the branch.conf manually. | 01:19 |
| halstead | Thanks. | 01:22 |
| beuno | code scanner just came back from the dead! | 01:23 |
| mwhudson | indeed | 01:24 |
| beuno | it's lying in some cases though :/ | 01:24 |
| mwhudson | ? | 01:24 |
| beuno | it says a branch was modified "50 minutes ago", when it clearly hasn't | 01:25 |
| mwhudson | it's still catching up on a pretty huge backlog | 01:25 |
| mwhudson | oh right, it probably sets the modified time to NOW when the scanner runs | 01:25 |
| mwhudson | we don't usually expect that to be several days after the change... | 01:25 |
| beuno | ah, that doesn't seem like the right thing to do at all :) | 01:25 |
| === samurai_ is now known as samiam | ||
| thumper | lifeless: ping | 01:51 |
| === mw is now known as mw|out | ||
| beuno | mwhudson, my firsts tests with genshi don't show a big improvement over kid :( | 02:17 |
| mwhudson | beuno: bah! | 02:17 |
| Peng | Big improvement in what? Performance? | 02:18 |
| beuno | mwhudson, in fact, kid takes less time | 02:18 |
| mwhudson | beuno: and RAM? | 02:20 |
| beuno | mwhudson, looking for a good way to test it, but looking at top, it seems about the same or more even | 02:21 |
| mwhudson | oh well | 02:21 |
| mwhudson | it was a nice idea | 02:22 |
| mwhudson | beuno: can you push your code? | 02:22 |
| beuno | I'm testing this with annotate, as it was the simplest template to test it with | 02:22 |
| beuno | mwhudson, sure, let me clean up, and I'll push it to LP | 02:23 |
| beuno | I just converted the annotate template, so it's all mixed up between kid and genshi | 02:23 |
| mwhudson | jam: still here? | 02:23 |
| mwhudson | heh | 02:23 |
| mwhudson | that's fine | 02:23 |
| mwhudson | i'm not sure item_keys_introduced_by really helps loggerhead | 02:23 |
| mwhudson | we want to know which fileids changes between two mainline revisions | 02:24 |
| beuno | mwhudson, do you have a good way to test memory usage? | 02:26 |
| beuno | (I can google around, but might be good to be using the same tools) | 02:26 |
| mwhudson | you can find all the fileids changed by all revisions introduced between two given revisions, but that's not really correct | 02:27 |
| mwhudson | beuno: i don't have any sophisticated tests, no :/ | 02:27 |
| mwhudson | beuno: i do know that builtins.py is the largest file in bzr.dev :) | 02:27 |
| beuno | mwhudson, I went for NEWS, which takes 13-16 seconds to annotate | 02:31 |
| mwhudson | ok | 02:31 |
| Peng | I think http://wingolog.org/archives/2007/11/27/reducing-the-footprint-of-python-applications might be good, or one other page I can't think of. | 02:31 |
| beuno | anway, I'll take a few more minutes to convert all templates to Genshi, and push | 02:31 |
| beuno | so you can go crazy on it :) | 02:31 |
| beuno | Peng, thanks, I'll take a look at that | 02:32 |
| poolie | igc, ping? | 02:34 |
| poolie | spiv: will leave soon | 02:47 |
| spiv | poolie: ok | 02:48 |
| mwhudson | mmm, graph.py is getting pretty deep | 02:49 |
| mwhudson | gar, revision numbers are pain | 02:56 |
| beuno | mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/loggerhead.genshi | 02:58 |
| beuno | I'm off for dinner | 02:58 |
| beuno | only annotate was converted | 02:59 |
| mwhudson | beuno: enkpy your dinner | 02:59 |
| mwhudson | jo | 02:59 |
| beuno | I ran into a few quirks with the kid<>genshi conversion on the other templates, so I'll just leave it alone unless you find it's actually useful | 02:59 |
| beuno | I'll be back in a couple of hours, and thanks :) | 03:00 |
| mwhudson | hm | 03:06 |
| mwhudson | my turbogears isn't finding my genshi | 03:06 |
| mwhudson | oh look https://bugs.edge.launchpad.net/ubuntu/+source/genshi/+bug/226285 | 03:07 |
| ubottu | Launchpad bug 226285 in genshi "Due to packaging changes, Genshi no longer works with TurboGears" [Unknown,Fix committed] | 03:07 |
| jam | mwhudson: I'm back for a bit | 03:09 |
| jam | what's up? | 03:09 |
| jam | ah, fileids... | 03:09 |
| jam | yeah, I can see the problem | 03:09 |
| mwhudson | jam: it's not really any faster anyway, on launchpad | 03:09 |
| jam | versus doing a diff? | 03:09 |
| mwhudson | yeah | 03:09 |
| igc | poolie: pong | 03:09 |
| jam | hmm... a bit surprising, but you did the test | 03:10 |
| mwhudson | jam: let me pastebin the code | 03:10 |
| jam | mostly because the item_keys_introduced code can work on the deltas directly | 03:11 |
| mwhudson | jam: http://pastebin.ubuntu.com/15215/ | 03:11 |
| jam | without going up to full texts | 03:11 |
| jam | well, r2r = b.get_revision_id_to_revno_map() is going to dominate your time | 03:12 |
| mwhudson | vs http://pastebin.ubuntu.com/15216/ | 03:12 |
| mwhudson | jam: oops | 03:12 |
| mwhudson | i tested without that line | 03:12 |
| mwhudson | (and indeed it's pretty slow, get_revision_id_to_revno_map takes ~5 seconds) | 03:12 |
| mwhudson | but the fileids_from... takes ~1 second | 03:13 |
| jam | what about the find_unique_ancestors line? | 03:13 |
| mwhudson | eh, not long, a few tenths | 03:13 |
| jam | yay | 03:14 |
| jam | that's been my work for the last while | 03:14 |
| mwhudson | not even that | 03:14 |
| mwhudson | 0.003 | 03:14 |
| mwhudson | which is pretty neat :) | 03:14 |
| jam | though if it is a simple graph, that isn't saying a huge amount | 03:15 |
| jam | but I'm glad it is fast | 03:15 |
| jam | it is a way forward | 03:15 |
| mwhudson | running this between the last 100 mainline revs of launchpad has one revision where it takes 3.5 seconds | 03:16 |
| mwhudson | and a couple where it's 0.7 or so | 03:17 |
| jam | yeah, those are the ones I'd like to work on | 03:17 |
| jam | shortcuts cause some problems | 03:17 |
| jam | because you have to search that far on the other side | 03:17 |
| jam | which gets you into revs with lots of ancestors, etc | 03:17 |
| mwhudson | ah dammit, what's the package name for R again? | 03:17 |
| mwhudson | r-base-core | 03:18 |
| jam | :) | 03:18 |
| jam | one of the problems with extra simple names | 03:18 |
| jam | how do you google for R ? | 03:19 |
| mwhudson | indeed | 03:19 |
| pickscrape | With great difficulty :) | 03:19 |
| mwhudson | command-not-found to the rescue here | 03:19 |
| mwhudson | the other problem with R is that i always forget how to use it | 03:21 |
| pickscrape | Is R used in bzr? | 03:23 |
| mwhudson | no | 03:24 |
| mwhudson | jam: heh, log(time-to-run g.find_unique_ancestors(last, [last_but_one])) is ~normally distributed when run over the 1000 most recent mainline revisions of launchpad | 03:26 |
| jam | interesting, what is the mean and stddev? | 03:27 |
| jml | KnitCorrupt raises a stack trace | 03:28 |
| jml | It probably shouldn't? | 03:28 |
| mwhudson | jam: the mean is about -4 | 03:31 |
| jam | negative 4? | 03:32 |
| jml | spiv: so it's like this. | 03:32 |
| jml | spiv: I pushed up a branch into a shared repo, someone tried to branch it standalone and then they got a massive KnitCorrupt traceback | 03:33 |
| mwhudson | jam: the mean of the non-log data is 0.03 | 03:33 |
| jml | spiv: I'm following the instructions on the traceback now (bzr check, bzr reconcile) | 03:33 |
| mwhudson | though this is for 6000 revs now, | 03:33 |
| jml | spiv: but it seems a bit buggy that Bazaar should show a traceback here. | 03:34 |
| spiv | jml: Hmm. So you think it should just give the KnitCorrupt error without a traceback? | 03:34 |
| jml | spiv: yes. | 03:34 |
| mwhudson | 0.05 for the first 1000 | 03:34 |
| spiv | Well, that's easy to fix (it's just a flag on the KnitCorrupt class). | 03:35 |
| mwhudson | 3.5 for the worst case though | 03:35 |
| spiv | jml: I'll talk it over with poolie when he gets here. | 03:35 |
| spiv | jml: out of interest, what's the full traceback in this case? | 03:35 |
| jml | spiv: cool. thanks. | 03:35 |
| spiv | I'm a bit hesistant about suppressing the traceback there, because KnitCorrupt almost always so far is a bzr bug. | 03:36 |
| spiv | And showing the traceback makes it more likely that we get the traceback in the bug report. | 03:37 |
| mwhudson | jam: the 3.5 second case is for a moderately but not ridiculously complicated merge | 03:38 |
| spiv | But possibly we should just be making sure we have enough context in the text of the KnitCorrupt message rather than relying on the traceback. | 03:38 |
| mwhudson | jam: want more details? | 03:38 |
| jam | mwhudson: there are ones in bzr.dev, too | 03:38 |
| jam | generally the problem is that it is long enough to cause the *other* side of the search to wander a lot | 03:38 |
| mwhudson | jam: heh, the worst case in bzr.dev seems to be "pack repositories!" | 03:40 |
| mwhudson | jam: 'number of revisions introduced' seems only very loosly correlated with running time | 03:45 |
| jml | ok. | 04:34 |
| jml | so, now when I run "reconcile" on the repo that was causing the KnitCorrupt error, I also get a KnitCorrupt error | 04:34 |
| jml | Can I do anything about this? | 04:34 |
| jml | (it's a little worrying) | 04:34 |
| Peng | Bwahaha. | 04:37 |
| Peng | I just finally counted how many requests it took bzr.dev to branch that one branch. 765! | 04:37 |
| poolie | Peng: over http? | 04:55 |
| poolie | is this a pack branch? if so that's a bit bad | 04:56 |
| poolie | igc, ping? | 04:56 |
| Peng | poolie: No, knits. | 04:56 |
| igc | hi poolie | 04:56 |
| poolie | Peng: you should really upgrade it... | 04:56 |
| Peng | poolie: I was checking how much it had improved since 1.3. About -600%, I think? | 04:56 |
| poolie | knits have? | 04:57 |
| Peng | Pulling with no changes has. | 04:57 |
| Peng | 1.3 accesses the repo, but bzr.dev doesn't, I think. | 04:57 |
| poolie | ok | 04:57 |
| poolie | that's kind of interesting, but we really want people to move from that format | 04:58 |
| Peng | Yeah. | 04:58 |
| poolie | in fact in this release we should add a warning about it | 04:58 |
| Peng | Also, bzr+http is quite good. | 04:58 |
| poolie | igc, could you call me at andrew's house when convenient? | 04:58 |
| igc | sure | 04:58 |
| igc | how's now poolie? | 04:59 |
| poolie | now would be great | 04:59 |
| Peng | I haven't upgraded because upstream still hasn't. | 05:01 |
| Peng | re bug 234748, so is bzr.dev eating old revisions? | 05:30 |
| ubottu | Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Confirmed] https://launchpad.net/bugs/234748 | 05:30 |
| uniscript | given a file is it possible to print out the weave? | 05:32 |
| spiv | Peng: yes, bzr:// and friends should make pulling knits approximately as good as pulling packs. | 05:37 |
| spiv | Peng: bzr.dev isn't damaging old revisions as far as I know. i.e. I don't think this is a dataloss issue. | 05:38 |
| spiv | Peng: My guess is it's just being a little more pedantic with the metadata, and then not gracefully coping when it sees this inconsistency. | 05:39 |
| * igc pick up kids | 05:39 | |
| poolie | uniscript: can you explain more what you mean? | 05:39 |
| uniscript | I'm trying to debug a merge problem so want to look at the weaves | 05:40 |
| uniscript | so given a file test.txt is there a command that prints the weave for test.txt in my branch? | 05:40 |
| poolie | uniscript: i think 'bzr weave-plan-merge' will do it | 05:41 |
| poolie | uniscript: note that we don't actually store texts in weaves anymore for performance... | 05:41 |
| spiv | AIUI the weave itself is not really relevant, just the shape of the graph. | 05:41 |
| uniscript | the bzr weave-* take a weave file | 05:42 |
| poolie | well, that will show you the line-by-line annotations of the merge | 05:42 |
| poolie | oh i see | 05:42 |
| poolie | are you giving any options to the merge command to choose an algorithm? | 05:42 |
| uniscript | OK. well conceptually to dumb users like me you are :) | 05:42 |
| uniscript | --weave | 05:42 |
| spiv | uniscript: --lca is almost always better or at least as good as --weave, btw | 05:43 |
| uniscript | for criss-cross merging? | 05:43 |
| spiv | (possibly s/almost// in current versions) | 05:43 |
| spiv | Yep. | 05:43 |
| uniscript | OK thanks, I'll try that | 05:43 |
| poolie | uniscript: it would be nice to expose some debugging info to help in cases like this | 05:45 |
| poolie | bye... | 05:46 |
| Peng | spiv: Ok. Not being a data loss issue is good. | 05:50 |
| poolie | Peng: yeah definitely not, a bug in check i think | 06:27 |
| Peng | poolie: Good. :) | 06:28 |
| Peng | Wasn't check's performance improved a while ago? | 06:32 |
| beuno | mwhudson, did you get a chance to verify Genshi's performance? I'm not sure if I should try and see if we can tweak that, or go down a different path... | 06:33 |
| mwhudson | beuno: no, sorry :/ | 06:34 |
| beuno | mwhudson, no worries. I'm going to look into it a bit further and make sure we're not improving in any way | 06:34 |
| mwhudson | beuno: cool | 06:35 |
| beuno | maybe the bottleneck is in turbogears? | 06:35 |
| mwhudson | i'm about to stop work for today, so talk to you tomorrow! | 06:35 |
| beuno | right, almost 3am, I'm getting used to that :) | 06:36 |
| beuno | thanks, and cya tomorrow | 06:37 |
| mwhudson | night | 06:37 |
| === doko_ is now known as doko | ||
| poolie | 234378 should be fixed now... | 07:42 |
| poolie | jml, re that bug, you said you could reproduce it just branching out of your repository? | 07:46 |
| poolie | i can't, even with the unfixed version | 07:46 |
| jml | poolie: what URL are you using? | 07:46 |
| poolie | i was branching my bzr trunk to /tmp/ | 07:47 |
| jml | poolie: oh. maybe try branching from my repo? | 07:48 |
| poolie | jml, where is that? | 07:53 |
| jml | poolie: devpad. | 07:54 |
| spiv | jml: which branch? Were you branching over bzr+ssh? | 08:01 |
| spiv | jml: I can't reproduce by branching locally on devpad from your repo to /tmp | 08:01 |
| spiv | jml: I tried both your bzr.dev branch and your most recently touched branch. | 08:01 |
| jml | spiv: bzr+ssh. | 08:01 |
| jml | spiv: stacking-policy | 08:01 |
| spiv | "most recently touched" :) | 08:02 |
| jml | spiv: oh. well. | 08:04 |
| jml | spiv: which version of bzr were you using? | 08:04 |
| jml | spiv: and was it into a standalone branch? | 08:04 |
| spiv | jml: I get a different KnitCorrupt over bzr+ssh... | 08:05 |
| spiv | Which tells you to run check and/or reconcile. | 08:05 |
| jml | spiv: right. | 08:05 |
| jml | spiv: then if you run check and/or reconcile... | 08:05 |
| spiv | jml: ok, I didn't realise it was two different KnitCorrupts. | 08:05 |
| jml | spiv: mea culpa | 08:05 |
| poolie | it is a kind of vague error that sounds like it's specific | 08:09 |
| poolie | um | 08:09 |
| poolie | i should stop complaining and just send a patch to change it | 08:09 |
| * igc dinner | 08:35 | |
| siretart | would someone please care to update bzr-svn in the PPA for hardy? | 08:37 |
| gambler | is there a document anywhere explaining how to use bazaar with git? | 09:06 |
| lifeless | dunno, but bzr-fastimport is a good conversion tool | 09:07 |
| * gour recommends tailort | 09:08 | |
| gour | *tailor | 09:08 |
| gambler | i must be mistaken because i heard someone say that there was some capability for bazaar to speak directly to git repos | 09:09 |
| gambler | eg. use them natively | 09:09 |
| gour | gambler: maybe https://launchpad.net/bzr-git | 09:10 |
| Jc2k | it looks somewhat dead? | 09:10 |
| Odd_Bloke | bzr-git is still in its formative stages, I think, so isn't really a priority for whoever was working on it (jam, I think). | 09:24 |
| awilkins | I think we'll all eventually end up with a common VCS backend API, and a small selection of cliens. | 09:25 |
| awilkins | And different implementations of the backend depending on requiremenbts | 09:25 |
| awilkins | And the ability to type may atrpohy as we use our mind control interfaces | 09:26 |
| * awilkins goes to fetch coffee to improve his synapse lag | 09:26 | |
| gambler | instead of a wetwire, how about an electronic vagina that I can control with my penis? | 09:27 |
| * vila wonders how this relate to git, but English is not his native language... | 09:28 | |
| gambler | vila: #bzr | 09:29 |
| gambler | no pun intended | 09:31 |
| vila | gambler: the wetwire bits ? | 09:32 |
| vila | gambler: sry, then :) | 09:32 |
| gambler | lol gold | 09:33 |
| gour | one question...i defined alias: checkout=checkout --lightweight and bzr help checkout says: 'bzr checkout' is an alias for 'bzr checkout --lightweight'. otoh, 'co' is alias for 'checkout', so i'd expect that invoking: bzr co would does: bzr checkout --lightweight, but it doesn't :-/ | 09:55 |
| gour | is it a bug or a feature? | 09:55 |
| james_w | gour: not sure, I have seen that behaviour before, but I used it as a feature. | 10:01 |
| uniscript | are there any plans to 'fix' --lca to mark delete + change as a conflict? | 10:06 |
| gour | james_w: hmm, i'd expect that user's alias is last in effect, i.e. 'co' should expand to 'checkout' and then *my* checkout should expand to defined alias | 10:06 |
| * gour will submit a bug report | 10:07 | |
| gour | using mail-client = emacsclient does not invoke Gnus. anyone using Gnus with 'bzr send' ? | 10:18 |
| james_w | uniscript: is there a bug report filed for that? I'm not familiar with the problem you mention. | 10:19 |
| * gour would like to use gpg-sign when sending bundles around | 10:19 | |
| uniscript | see the developer notes on the lca merge algorithm where it states that currently lca silently does delete+change->change with no conflict report as does --weave | 10:20 |
| uniscript | and that this needs to be fixed to conform to --merge3 | 10:20 |
| uniscript | and I would agree with that :) | 10:20 |
| james_w | ah, I hadn't seen that. | 10:21 |
| uniscript | so I guess there are no plans then? | 10:34 |
| gour | hmm, problems with 'bzr send' and emacs...invoking bzr send gives http://rafb.net/p/ZXRhFV94.html | 10:39 |
| gour | any hint? | 10:39 |
| james_w | uniscript: no idea I'm afraid | 10:39 |
| uniscript | OK I'll raise a bug | 10:40 |
| james_w | gour: that looks like an emacs problem, is it? | 10:40 |
| james_w | or an emacs error rather, not necessarily its fault | 10:41 |
| gour | james_w: well, emacs is invoked and i can fill out the To/From...but i'd like Gnus to be invoked and wonder about the error(s) | 10:42 |
| james_w | I'm not familiar with emacs, sorry. | 10:42 |
| gour | ok, i'm asking in #emacs | 10:43 |
| lamont | given a .git repo with several branches, is there a trivial bzr import process for that? | 14:03 |
| lamont | of course, in my fantasy land, I'd wind up with one bzr directory in which I could switch between all the diff views. | 14:03 |
| lamont | and would be able to bzr push changes back to the git repo | 14:04 |
| lamont | and fetch and/or merge from said git repo | 14:04 |
| Jc2k | not yet | 14:07 |
| Jc2k | there is one way git -> bzr import | 14:07 |
| Jc2k | i don't know the state of bzr-git... but that will allow what you speak of one day.. | 14:07 |
| === jelmer is now known as jelmer__ | ||
| === jelmer__ is now known as jelmer | ||
| gour | heh, solved my 'bzr send' & Gnus problem...the solution was to set mail-user-agent in emacs. fortunately, i also got nice reply on the ml. nice to have such info in the docs | 15:08 |
| === weigon_ is now known as weigon | ||
| gour | someone was today explaining me how he likes that with git he can create several branches in one working dir and switch between them by checkout-ing them. i replied that bzr can do almost the same buy using e.g. treeless shared repo and doing lightweight checkout & switch in some working repo | 15:22 |
| gour | his remark was that he does not like one directory per branch, but i do not see logic what would be advantage of sticking many branches in one folder except more hassle when one wants to access them remotely. anyone can shed some light if there is some? | 15:23 |
| asabil | gour: the 1 folder per branch works better with IDE and various external tools | 15:25 |
| asabil | on the other hand the git model work better when you want to checkout all the branches of a repository at the same time | 15:26 |
| LarstiQ | asabil: well, having 1 tree works better when building is expensive, say, C. | 15:26 |
| asabil | I tend to prefer the bzr model myself | 15:26 |
| LarstiQ | but branches don't suffer from the same problem | 15:27 |
| asabil | hmm, what do you mean ? | 15:28 |
| asabil | which problem ? | 15:28 |
| gour | asabil: is it easy with git to fetch just one branch? | 15:29 |
| LarstiQ | asabil: if you have a project where a full build takes in the tens of minutes, you really want to reuse your intermediate objects | 15:29 |
| asabil | yeah, but that's a build system issue | 15:29 |
| asabil | not a revision control issue | 15:30 |
| LarstiQ | asabil: also, things like Eclipes don't deal too well with suddenly having to look somewhere else for the code. | 15:30 |
| LarstiQ | asabil: it is an important use case for `bzr switch` | 15:30 |
| demod | hi | 15:30 |
| LarstiQ | asabil: it's git's native way of working | 15:30 |
| asabil | LarstiQ: people can still use out of tree build | 15:31 |
| * gour likes bzr switch mechanism | 15:31 | |
| asabil | I never used bzr switch myself | 15:31 |
| asabil | but I do see your point | 15:32 |
| gour | asabil: it's handy being in one working dir and just switching between the branches you're working on | 15:32 |
| fullermd | Having the repo be the functional unit makes it much easier to do multi-branch syncs. | 15:32 |
| fullermd | Can only fake up parts of that capability with bzr. | 15:33 |
| gour | fullermd: with shared repos? | 15:33 |
| asabil | gour: cd ../foo-branch works | 15:33 |
| fullermd | Shared repos don't change anything. | 15:33 |
| === jamesh_ is now known as jamesh | ||
| gour | asabil: i mean using --ligthweight checkouts and --no-trees repo, then you can stay in one folder | 15:34 |
| asabil | gour: personally I prefer seeing 1 branch == 1 folder | 15:35 |
| gour | i do not see big advantage of git's model, especially considering its complexity over bzr | 15:35 |
| asabil | I used to like the git model (when using monotone), it is just a matter of habit | 15:35 |
| gour | asabil: me too, but in shared repo without working-trees | 15:35 |
| gour | asabil: how is monotone these days? i looked at it in the past, but didn't like database dep | 15:36 |
| fullermd | I sure wouldn't want to be stuck with one tree for all my branches; it's almost necessary to see multiple branches side by side. | 15:36 |
| asabil | gour: didn't use it for 2 years now | 15:36 |
| fullermd | But I wouldn't dream of pretending it doesn't come with drawbacks. | 15:36 |
| gour | :-) | 15:36 |
| asabil | fullermd: I agree | 15:36 |
| fullermd | I use it very occasionally. It's always fighting an impedance mismatch. | 15:36 |
| fullermd | Ex: How, using bzr, do I get a local copy of all your branches, keep them up to date, and automatically get new branches when you create them? | 15:37 |
| fullermd | Oh, that's right; I DON'T! | 15:37 |
| asabil | the only drawback about 1 branch/folder that I see, is the lack of ability to pull/merge multiple branches | 15:37 |
| asabil | (multi-pull sort of solves it, but ...) | 15:37 |
| fullermd | Part of that is "nobody's written it", but writing it is some nontrivial amount of work with dir-per-branch architecture. With the repo being the primary functional unit, it comes for free. | 15:39 |
| gour | asabil: multi-pull is not quite interesting here | 15:41 |
| awilkins | jelmer: So, this thing where the revision-id changes when you change branching-schemes.. is it not possible to use a different ID generator that is consistent regardless of branching scheme? | 15:42 |
| fullermd | multi-pull saves doing a `for i in *; do ....` construct. I use it mostly for ~/.bazaar/plugins/. It's handy. | 15:42 |
| awilkins | (I realise this would break all existing code, blech) | 15:42 |
| jelmer | awilkins: this is bug 130372 | 15:42 |
| ubottu | Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372 | 15:43 |
| awilkins | Groovy ; what would you use instead ; SHA of the changeset? Something like that? | 15:43 |
| awilkins | Incidentally, that patch I sent you was applied against the current tip of the 0.4 branch, I'm not so sure it's fixed (maybe it's another instance of the same thing?) | 15:47 |
| awilkins | Unless you've just not pushed for a week :-) | 15:50 |
| nnutter | Good morning. I have a question that I wasn't able to clearly find an answer for. I'm just getting started using Bazaar (all VCS for that matter) and I'm confused about how to merge two branches together on different machines. | 15:53 |
| * awilkins notices a new push | 15:54 | |
| jelmer | awilkins: what bzr-svn branch are you using? | 15:54 |
| awilkins | nnutter: start in the branch you are merging TO, and do a "bzr merge <mrege from>" | 15:54 |
| awilkins | jelmer: 0,4 | 15:54 |
| jelmer | awilkins, we won't be making the branching scheme part of the revid anymore | 15:55 |
| awilkins | I've just noticed you pushed this morning sometime | 15:55 |
| jelmer | I didn't do any bzr-svn stuff this morning | 15:55 |
| awilkins | jelmer: There was a push 7 hours ago according to LP | 15:55 |
| * awilkins refreshes cache | 15:55 | |
| jelmer | awilkins: are you using the launchpad mirror of 0.4 or 0.4 directly? | 15:56 |
| nnutter | awilkins: Can it be done the other way. I'd like to start in the branch you are merging from and send the changes to another person. BTW the workflow I'm following is what the Bazaar docs called "Decentralized with Shared Mainline". | 15:56 |
| jelmer | 7 hours ago I was sound asleep :-) | 15:56 |
| awilkins | jelmer: code.launhpad.net - this page claims 7 hours 50, the actual revision is from the 23rd | 15:57 |
| awilkins | https://code.launchpad.net/bzr-svn/ | 15:57 |
| awilkins | nnutter: If you want to send the changes to another, make a bundle using either bzr send or bzr bundle - they then treat that bundle as the "from" branch | 15:57 |
| jelmer | awilkins, not sure what's going on then | 15:57 |
| james_w | nnutter: you have to be in the branch the you are merging to. If you don't control that branch then you can use "bzr send" to send the change as a text file. | 15:57 |
| jelmer | awilkins, the 0.4 branch isn't hosted on launchpad so maybe the launchpad mirrorring is just slow | 15:58 |
| james_w | nnutter: if it is the shared mainline you are trying to merge to then "bzr checkout" the remote branch to your local machine, and then run "bzr merge" in that. | 15:58 |
| awilkins | jelmer: Says it last mirrored 1 hour ago ; it's usually something like that. But there is some misrepresentation about timestamps going on there, or it's cacheing a generated page too lon | 15:59 |
| awilkins | Or my obnoxious ISP are | 15:59 |
| awilkins | Nope, same from a different proxy | 15:59 |
| nnutter | james_w: ok, thank you. I'll look at that. | 16:00 |
| james_w | nnutter: if you haven't already I would recommend setting up a "shared repository" on your local machine before the "bzr checkout" if that is the way you are going, we can help you set that up if you like. | 16:01 |
| nnutter | james_w: I'd appreciate that, I think I may have. | 16:03 |
| nnutter | james_w: I made a dir in /var called repos, then made a project directory, e.g. /var/repos/him. I did bzr init in that directory and then added all the source files (bzr add). | 16:04 |
| nnutter | Now it seems to work if I do bzr checkout bzr+ssh://whatever/project. | 16:05 |
| nnutter | Is a "shared repository" more than that? | 16:05 |
| james_w | yep that will work. | 16:05 |
| asabil | awilkins: lp is sort of broken these days | 16:05 |
| asabil | awilkins: branch scanning has been very very slow | 16:05 |
| awilkins | asabil: That's software for you. I bet it's something to do with not using shared repos. | 16:06 |
| james_w | a "shared repository" allows several branches to share revision data, and as your mainline and the feature branch will have mostly the same revision data it will save you having to download so much data when you pull. | 16:06 |
| asabil | hmm ? | 16:06 |
| asabil | awilkins: what do you mean ? | 16:06 |
| nnutter | james_w: OK, cool. :-) New question. With the shared mainline method. Should I be using co, update, and ci (similar to how I think SVN works?). You mentioned merge but I got a message about location not being specified remembered. | 16:06 |
| awilkins | asabil: If you branch on LP, you take a full copy of the branch - there are no shared repos on LP (except perhaps official ones) | 16:06 |
| asabil | awilkins: on LP all branches within a project are part of a shared repo iirc | 16:07 |
| asabil | so 1 project == 1 shared repo iirc | 16:07 |
| asabil | awilkins: and how is that related to what I was telling you ? | 16:07 |
| awilkins | asabil: Slow? Lots of branches to scan? Without repo sharing? | 16:08 |
| james_w | nnutter: so if you "bzr init-repo repo; cd a; bzr init mainline" mainline will store it's revision data in "repo/.bzr" instead of "repo/mainline/.bzr", now if you "bzr branch mainline feature", feature will also store it's data there, and so won't need to copy anything | 16:08 |
| james_w | nnutter: you need to specify a location to the merge command the first time, it will remember it after that. | 16:08 |
| asabil | awilkins: nevermind | 16:09 |
| nnutter | james_w: cd a? | 16:09 |
| james_w | nnutter: sorry, typo, "cd repo" | 16:10 |
| nnutter | ok | 16:10 |
| james_w | so it doesn't sound like your branch at "/var/repos/him" uses one. You can change this by doing "bzr init-repo /var/repos; bzr branch him temp; rm -rf him; mv temp him", but make sure there are no uncommitted changes in "him" first. | 16:12 |
| nnutter | so if I do that I could have repo/main repo/user1 repo/user2 where repo/userX was a branch of main. The users would co repo thereby downloading each user's personal branch as well as main. And then each user could commit to their own branch and periodically merge back to main? | 16:13 |
| awilkins | nnutter: They'd make their own local repo, and branch or co main into it, then branch main from there to their feature branch | 16:13 |
| nnutter | I think I'm getting a bit confused. branch and co are not synonymous right? Could you clarify the difference? | 16:16 |
| awilkins | nnutter: "co" creates a "bound" branch ; this acts much like an SVN "working copy" only it has a full revision history not just a base copy of the last update from HEAD | 16:17 |
| awilkins | nnutter: "branch" makes an unbound branch ; identical, but commits do NOT automatically get pushed back to the parent branch | 16:17 |
| gour | nnutter: branch creates a new copy of branch | 16:17 |
| awilkins | "co --lightweight" is even more like an SVN WC and only has revisions in the master branch | 16:18 |
| nnutter | Maybe I can/should explain my project and you guys can tell me if I'm totally off then? | 16:19 |
| nnutter | I thought I had it mostly figured out, but now I'm confused about how to do what I want. | 16:20 |
| nnutter | I'm trying to setup a repo for a computer model. This model has several components to it, some that handle basic physics, some that handle chemical processes, and some that trace the movement of chemicals. Each component is a different person's specialization. | 16:22 |
| nnutter | What I wanted to do was have a main copy (I think would be called a trunk) which has the "stable" version of the code. | 16:22 |
| nnutter | And for people to get a copy of that, make changes to the component they specialize in, while being able to commit revisions locally, and at some point when they are satisfied merge those changes back into the main source tree. | 16:23 |
| gour | nnutter: see http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=%28layout%29 | 16:24 |
| gour | nnutter: as well as http://bazaar-vcs.org/SharedRepositoryTutorial?highlight=%28layout%29 | 16:24 |
| nnutter | gour: thank you, looking. | 16:25 |
| gour | nnutter: so, every user have write-access to the central repo? | 16:26 |
| nnutter | yeah | 16:26 |
| gour | ok, then it's just question how you want to layout central-repo...see the above urls | 16:27 |
| nnutter | Yeah, looks like the first method of Simple Developer Naming is what I want. | 16:28 |
| gour | nnutter: you probably can use tree-less shared repo on the 'central server' | 16:28 |
| nnutter | There will only be 3-4 developers. | 16:28 |
| nnutter | ok, looking... | 16:29 |
| nnutter | Ah! | 16:30 |
| nnutter | "he word shared in shared repository refers to branches sharing a repository for revision storage, not to users sharing the same branch for publishing revisions. They can be used used for that purpose, however. " | 16:30 |
| nnutter | That clarifies a lot :-p | 16:30 |
| gour | nnutter: whatever you choose, enjoy with bzr ;) | 16:30 |
| nnutter | which is what james_w: met by "shared repository" earlier. I was thinking shared as in more than one user, but he was thinking of it as described there | 16:30 |
| gour | heh, i also had some glitches in understanding the lingo and submitted bug report to write some part of the docs more clearly | 16:31 |
| nevans | I'm having worse memory problems than ever before with bzr-svn... :( | 16:31 |
| jelmer | hi nekohayo | 16:31 |
| jelmer | *nevans | 16:31 |
| nevans | new install of hardy on a new laptop, upgraded to bzr 1.5 and bzr-svn 0.4.10 | 16:31 |
| gour | nnutter: right. branches can share repo and therefore you can save some space | 16:31 |
| jelmer | nevans, the memory leaks are in the subversion python bindings | 16:32 |
| awilkins | jelmer: Did you ever get those Pyrex bindings working? | 16:32 |
| nevans | and when I try to do anything with the svn repo, it locks up at determining changes 0/41590 | 16:32 |
| gour | jelmer: svn-1.5 fixes it? | 16:32 |
| nevans | jelmer: yeah... but I was at least able to checkout this repository before... | 16:33 |
| nevans | now it just grows to fill up my 3GB of memory in under a minute | 16:33 |
| nevans | alse before the memory would grow as it moved through the revisions, so I could terminate and try again (starting at a higher revision), and it would eventually complete | 16:34 |
| nevans | now it sticks at 0. :( | 16:34 |
| jelmer | awilkins: Haven't worked on them in a while | 16:35 |
| nevans | also... I've got another computer which is currently working | 16:35 |
| awilkins | jelmer: They were frustrating but promising... | 16:35 |
| nevans | I'm going to try copying over the cache from that other computer... and if that doesn't work, then I'll downgrade to the versions used on that other computer | 16:35 |
| nevans | jelmer: sorry to bring up the same-old bug again... but before I could always work around it. | 16:36 |
| nnutter | OK, so if I'm doing this Simple Developer Naming method I'd have him/trunk and him/nnutter/feature1, for example. | 16:37 |
| jelmer | nevans: afaik nothing has changed that could've affected the memory usage | 16:37 |
| nnutter | Would him/nnutter be a branch, i.e. would I need to bzr init him/nnutter or just him/nnutter/feature1? | 16:37 |
| nevans | interesting... then I wonder if something in the repository has changed which would trigger the memory bug worse than before | 16:38 |
| nnutter | Or wait. | 16:38 |
| gour | nnutter: "Another possibly layout is to give each developer a directory, and then have a single sub-directory for branches. " | 16:39 |
| gour | nnutter: do you want option a) or b) ? | 16:40 |
| nnutter | a | 16:40 |
| nnutter | what you just quoted. | 16:40 |
| nnutter | err | 16:40 |
| nnutter | yeah | 16:40 |
| nnutter | When I wear out my welcome just tell me :-p | 16:41 |
| gour | nnutter: ok, then create 'project' shared repo | 16:42 |
| nnutter | k | 16:42 |
| gour | nnutter: with 'trunk' branch | 16:42 |
| gour | nnutter: and joe/foo jim/bar ... branches | 16:42 |
| nevans | jelmer: FYI: copying over the cache from another computer fixed it. | 16:43 |
| gour | nnutter: does it make sense? | 16:43 |
| nnutter | I think so. Let me see if I can translate it... | 16:43 |
| nnutter | bzr init-repo project; bzr init project/trunk; cd project/trunk; bzr add; bzr ci -m 'Initial.' | 16:44 |
| nnutter | bzr branch project/trunk project/nnutter/feature1 | 16:44 |
| gour | nnutter: yep. take care if you want --no-trees option for shared repo and about repo format | 16:45 |
| nnutter | ok | 16:46 |
| nnutter | So that gets the shared repo setup on the "mainline server". Now User2 wants to get a copy and start his own branch, etc. | 16:47 |
| nnutter | So User2 does 'bzr branch prot://address/path/project'? | 16:48 |
| jelmer | nevans: so this would just be the same problem as originally | 16:49 |
| awilkins | User2> mkdir repo ; cd repo ; bzr init-repo . ; bzr branch <main_branch_uri> project.trunk | 16:49 |
| awilkins | User2> bzr branch project.trunk project.mine | 16:49 |
| awilkins | User2> # hacks | 16:49 |
| gour | nnutter: branches are the 'deepest' folders in 'project' hierarchy | 16:50 |
| jelmer | nevans, except that the caching format has changed recently | 16:50 |
| nevans | jelmer: I suppose so. But it feels a lot more severe than the previous problem that I've had... since it completely hangs and sucks up memory, rather than slowly leaking as it moves through revisions | 16:50 |
| nnutter | gour: ok, gotcha there | 16:51 |
| jelmer | nevans: The generating of the cache takes the most memory | 16:51 |
| jelmer | nevans, and since the format had changed it had to regenerate that cache | 16:51 |
| nnutter | awilkins: then User2> bzr commit -m 'User2 hacked file A.' | 16:51 |
| nevans | it changed between 0.4.9 and 0.4.10? | 16:51 |
| nnutter | awilkins: then User2> # Hacks | 16:51 |
| jelmer | nevans: yeah | 16:51 |
| nnutter | awilkins: then User2> bzr commit -m 'User2 hacked file B.' | 16:51 |
| gour | awilkins: why not: bzr init-repo project; cd project | 16:51 |
| nnutter | awilkins: then User2> bzr push? | 16:51 |
| awilkins | nnutter: bzr push <my_new_branch_uri_on_server> | 16:52 |
| nevans | so when I copied over the cache (which was built/used by version 0.4.9 and prior), it was still able to use that cache... did it transform it to the new style cache? | 16:52 |
| awilkins | nnutter: Although they don't *have* to have a branch on the server | 16:52 |
| nnutter | they could push it to <trunk_uri_in_server> or something instead right? | 16:53 |
| awilkins | gour: *shrug* that's just how I tend to do it ; I also tend to share repos between multiple projects | 16:53 |
| awilkins | nnutter: Yes, they can push to <trunk> but that disrupt others work | 16:54 |
| nnutter | right | 16:54 |
| nnutter | ok, getting really close to understanding whole process :-) | 16:54 |
| nnutter | so last step | 16:54 |
| gour | awilkins: i mean, bzr init-repo project saves one step, i.e. it creates repo & dir in one step | 16:54 |
| awilkins | nnutter: What is best is to pull changes from server:trunk to your local branch of trunk, then merge your changes into that, and push when you've resolved any conflicts (and tested the crap out of things, natch) | 16:54 |
| nnutter | User2 now wants to merge his branch into trunk, which you just explained :-p | 16:55 |
| awilkins | gour: True, but I don't do that very often so I suppose it never occurred to me how much time I was wasting :-P | 16:55 |
| gour | awilkins: ok. np ;) | 16:55 |
| nnutter | so to merge to trunk... | 16:55 |
| awilkins | cd ../project.trunk | 16:55 |
| awilkins | bzr merge ../project.mine | 16:55 |
| awilkins | until (branch.has_no_conflicts) { resolve conflicts } | 16:56 |
| gour | nnutter: User2 wants to have his local branch 'up to date' and then push to the server | 16:56 |
| awilkins | bzr commit -m "Merged my astounding new feature" | 16:56 |
| awilkins | bzr push | 16:56 |
| gour | (having, ass awilkins wrote, all conflicts resolved) | 16:56 |
| gour | s/ass/as | 16:57 |
| nnutter | OK, excellent. | 16:57 |
| gour | awilkins: excuse me for the typo :-( | 16:57 |
| nnutter | Oh, is there any difference between bzr+ssh:// and sftp://? | 17:00 |
| gour | nnutter: iirc, bzr+ssh requires bzr on the server-side | 17:00 |
| nnutter | oh ok | 17:01 |
| * awilkins goes to catch train | 17:01 | |
| LeoNerd | sftp just uses sftp. bzr+ssh ssh's into the target machine and runs a bzr command on the far end | 17:05 |
| LeoNerd | sftp will work with any sftp server. bzr+ssh needs bzr installed there | 17:05 |
| LeoNerd | bzr+ssh can be more efficient in network transfer, because the bzr command on the far end can precalculate things | 17:06 |
| gour | with LP one uses bzr+ssh? | 17:06 |
| nnutter | ty LeoNerd | 17:06 |
| pickscrape | Anyone here use the Colored Diffs extension for Thunderbird? | 17:10 |
| jml | abentley: do you know why bzrlib/transport/sftp.py url escapes and unescapes paths? | 17:13 |
| abentley | jml: That aspect of the API is rather underspecified. | 17:13 |
| jml | abentley: I was afraid of that. | 17:14 |
| abentley | It's never been crystal-clear whether it's using url segments or path segments. | 17:14 |
| abentley | jml: It does seem to be pretty consistent in treating its input and output as url segments. | 17:18 |
| jml | abentley: I think I see now. The interface takes url segments, but the internal sftp stuff doesn't, so the sftp transport escapes and unescapes. | 17:23 |
| === yacc__ is now known as yacc | ||
| abentley | Right. The sftp protocol itself is all about path segments, so the transport is our translation point. | 17:23 |
| Pilky | Just out of interest, has anyone looked into why bzr ignored is so slow? I don't know much about the internals of bzr but I would've thought that being slow to compute which files are ignored would slow quite a few other operations down a fair bit | 17:27 |
| fullermd | Well, what else cares what files are ignored? add, status... that may be it. | 17:30 |
| Pilky | yeah, but they aren't exactly rarely used operations | 17:32 |
| === mw__ is now known as mw | ||
| barretj | hello | 18:40 |
| barretj | the revno command tells me what revision i'm at, is there a way to show that i'm at a revision plus some changes? | 18:41 |
| barretj | i know i can use the status command to see what the changes are, but i just want to see that there are changes | 18:42 |
| LeoNerd | bzr st >/dev/null and use the exit code? | 18:43 |
| gour | lol | 18:44 |
| barretj | umm, i dont think that works | 18:44 |
| barretj | i'm getting a 0 status code | 18:45 |
| barretj | echo $? | 18:45 |
| barretj | and i have changes | 18:45 |
| LeoNerd | Ah.. boo | 18:45 |
| barretj | unless 0 means there are changes | 18:45 |
| fullermd | bzr version-info --customer --template="{clean}" | 18:46 |
| fullermd | Er, --custom | 18:46 |
| barretj | fullermd: thanks! | 18:49 |
| === BasicPRO is now known as BasicOSX | ||
| awmcclain | Any ideas on status of https://bugs.launchpad.net/bzr/+bug/173002? | 20:19 |
| ubottu | Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,Confirmed] | 20:19 |
| awmcclain | There's no way to convert my existing repository out of RichRootPack, is there? | 20:20 |
| jelmer | awmcclain, the idea at some point was to make richrootpack the default for 1.6 | 20:31 |
| awmcclain | jelmer: So, at some point, if I just wait, the problem will fix itself? :) | 20:31 |
| awmcclain | (I'm just getting tired of having to a) create a repository for my branch or b) download a revision via sftp and then switching to bzr+ssh | 20:32 |
| jelmer | awmcclain: there's no way of downgrading from rich-root-pack root pack-0.92 | 20:33 |
| jelmer | what you can do is replay all of the changes in a pack-0.92 branch but that will obviously change the revision ids | 20:33 |
| awmcclain | jelmer: Okee doke. But the idea is that the default branch-type in 1.6 will be rich-root-pack, right? | 20:33 |
| jelmer | awmcclain: that's the idea, yes | 20:34 |
| jelmer | abentley: is that going to make 1.6 ? | 20:34 |
| abentley | jelmer: no | 20:35 |
| gour | is there any other 'development' format cooking under the hood promising even better performance? | 20:35 |
| jelmer | abentley, :-( any chance for 1.7 ? | 20:35 |
| abentley | jelmer: quite likely. | 20:36 |
| gour | after 1.9 there will be 1.10 ? | 20:36 |
| awmcclain | :( | 20:36 |
| jelmer | abentley, thanks | 20:37 |
| awmcclain | Is there any way to squeeze in a fix for 173002 then? | 20:37 |
| jelmer | ubottu, bug 173002 | 20:37 |
| ubottu | Launchpad bug 173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [High,Confirmed] https://launchpad.net/bugs/173002 | 20:37 |
| === mw is now known as mw|food | ||
| awmcclain | basically, you can't branch existing repository that are in rich-root-pack over bzr+ssh | 20:38 |
| awmcclain | you have to do one of the workarounds i mentioned before | 20:38 |
| awmcclain | *repositories | 20:38 |
| jelmer | awmcclain, I haven't ever had problems with that | 20:39 |
| jelmer | maybe it's just checkouts that don't work | 20:39 |
| jelmer | branching works fine afaik | 20:39 |
| awmcclain | nope | 20:39 |
| awmcclain | oh | 20:39 |
| awmcclain | ok, just ignore me then. | 20:40 |
| awmcclain | :) | 20:40 |
| awmcclain | rooting out cobwebs in my brain | 20:40 |
| jelmer | so you should be able to "bzr branch ..." and then "bzr bind" | 20:40 |
| awmcclain | ... of course. | 20:42 |
| * awmcclain smacks himself in the head | 20:42 | |
| awmcclain | Ok, lastly, any ETA on https://bugs.launchpad.net/bzr/+bug/211967? | 20:46 |
| ubottu | Launchpad bug 211967 in bzr "bzr smart server should support hooks" [Medium,Confirmed] | 20:46 |
| gour | there are 1395 bugs in LP. any statistics of the general trend? | 20:48 |
| fullermd | 1395 is a good number. | 20:57 |
| fullermd | Its prime factors are 3, 3, 5, and 31. Multiple the 3's and you get 9, so you're left with 9531, which is the same digits swapped around. | 20:57 |
| fullermd | Obviously, we can never open or close another bug, or we'll decrease our perfection. | 20:57 |
| gour | :-) | 20:57 |
| === mw|food is now known as mw | ||
| mwhudson_ | beuno: hello | 22:06 |
| === mwhudson_ is now known as mwhudson | ||
| beuno | mwhudson, mornin' | 22:06 |
| mwhudson | beuno: i just remembered that i converted all the loggerhead templates to zpt a good while ago | 22:07 |
| mwhudson | i guess that would be something else to test :) | 22:07 |
| beuno | mwhudson, there is a branch for that somewhere? | 22:08 |
| mwhudson | https://code.edge.launchpad.net/~mwhudson/loggerhead/zpt-templating | 22:08 |
| mwhudson | it is a bit out of date | 22:08 |
| beuno | mwhudson, ok, cool, I'll update it and test it | 22:09 |
| beuno | I've been thinking about doing tests with Genshi, but avoiding turbogears | 22:09 |
| mwhudson | that would be cool | 22:09 |
| beuno | just so we can discard that turbogears is the real problem | 22:09 |
| beuno | ok, only 4 conflicts merging trunk into that branch, not as bad as I expected | 22:11 |
| mwhudson | yeah, but the templates will be a bit out of date | 22:11 |
| beuno | they seem good enough to test performance, and if we get promising results, I'll work on updating them | 22:12 |
| mwhudson | oh cool | 22:13 |
| mwhudson | beuno: are you on hardy? | 22:13 |
| beuno | mwhudson, yeap | 22:14 |
| mwhudson | beuno: what did you do about https://bugs.edge.launchpad.net/ubuntu/+source/genshi/+bug/226285 ? | 22:16 |
| ubottu | Launchpad bug 226285 in genshi "Due to packaging changes, Genshi no longer works with TurboGears" [Unknown,Fix committed] | 22:16 |
| mwhudson | breakfast, brb | 22:16 |
| beuno | mwhudson, "easy_install Genshi" did the trick | 22:16 |
| === gotgenes_ is now known as gotgenes | ||
| mwhudson | beuno: hmm, i'm not sure i want to disrespect my packaging system that much :) | 22:26 |
| * mwhudson goes to look for a newer debian deb | 22:26 | |
| beuno | mwhudson, well, it seems you haven't run loggerhead's setup.py then :p | 22:27 |
| mwhudson | only for sdist | 22:27 |
| === gotgenes_ is now known as gotgenes | ||
| === gotgenes is now known as gotgenes_ | ||
| === gotgenes_ is now known as gotgenes | ||
| mwhudson | sweet, i managed to build a fixed deb for genshi | 23:17 |
| beuno | sounds like something that should go into your PPA :) | 23:18 |
| mwhudson | yeah, if i had a ppa | 23:19 |
| mwhudson | (i haven't signed to CoC yet for one thing...) | 23:19 |
| beuno | ah, so you're expecting to mis-conduct? :) | 23:20 |
| mwhudson | no, just lazy | 23:22 |
| === kiko is now known as kiko-afk | ||
| beuno | jelmer, btw, the bzr-gtk BB has been down for a good 24 hours at least | 23:39 |
| mwhudson | hmm, zpt-templating does seem to perform better | 23:52 |
| beuno | significantly so? | 23:53 |
| poolie | hello | 23:56 |
| beuno | hey poolie | 23:57 |
| poolie | beuno: hey it looks like the loggerhead theming is going well | 23:58 |
| beuno | poolie, yeap, I managed to speed it up a bit. All mockups are finished, just need feedback from everyone, and I'm ready to start applying it to the template | 23:59 |
| mwhudson | beuno: yeah, about twice as fast about half as much ram | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!