markhjam: the win32 binaries I'm putting together will have at least a couple of patches from 1.6 (setup.py/inno) - how do you feel about me also keeping those other test suite changes in?  But if you think its important we only apply strictly necessary patches I'll back them out of my local tree.00:02
jamhi markh00:03
markhhi john00:03
jamI'd rather have it be stock 1.6 if at all possible00:03
jamFor example, getting those patches in, would be something to get into 1.6 final00:04
markhI guess you'd say that, which is why I thought I better ask ;)  np00:04
jamAnd would have been something I would have liked mentioned earlier....00:04
jamSupporting multiple versions is a real pain whenever there is skew00:04
markhwhat would you have liked mentioned earluer?00:04
jammarkh: that you are going to need the setup.py/inno patches for the win32 release00:04
jamSo I would rather bring in something with a bit of cruft if it is going to be the *official* version anyway.00:05
jamThough I'd really rather not bring in cruft :)00:05
markhthese are the same patches I've previously sent for the build process.00:05
spivjam: here00:05
jamSo... standup meeting for 2008-08-1300:06
markhwith yet more tweaks as I find issues in testing, such as uninstall problems, etc00:06
jamspiv: what are you working on today and yesterday00:06
jammarkh: I understand the patches you are describing, I wish you had nominated them as 1.6 patches.00:06
jamSince you are going to use them for a 1.6 release00:06
jamhence.... they need to be in 1.600:07
markhthey aren't complete - I last made a change 3 days ago to it00:07
spivYesterday I got the improved testing docs merged, reviewed some of lifeless's stuff, and made a bit of progress on the HPSS effort tests.00:07
spivToday I'm going to focus on the effort tests, plus mentally willing 1.6 to get released ;)00:07
jammarkh: I would rather you focused on getting something complete, that can be a 1.6 release, than having it perfect.00:07
jamWe can make it perfect for 1.700:08
spiv1.7 isn't very far away, after all.00:08
jammarkh: I'll be the 1.7 manager, and if I have any say about it, we'll follow a strict timetable00:08
jamso pushing 1.6 back00:08
jammeans that 1.7 will release the next day00:08
jamspiv: ok, today was focused on getting 1.6rc2 out the door00:09
jamwhich was successful00:09
markhI don't see a huge issue in me releasing my "bzr + tortoise" binaries called "1.6" when they are infact 1.6 + 2 build/installer related patches00:09
markhwith zero changes to bzr itself00:09
spivjam: hooray!00:09
jammarkh: Because I can't do "bzr co http://bazaar-vcs.org/bzr/bzr.1.6" and get what we released as bzr-1.6-win3200:09
jammarkh: aka, I can't easily *reproduce* your work00:10
jamIt is all on *you*, and I'd rather have it in the system00:10
jammarkh: If you feel it isn't really worth merging, perhaps it could be a bzr-1.6-win32 branch or something00:11
jambut I'd really rather avoid that.00:11
markhif I publish those 2 patches, and those patches are only related to the binaries built that include tortoise, then I really don't share your concern.  Release a stand-alone binary without tortoise using the existing setup.py if it bothers you that much00:11
jamI *really* want a snapshot we could use.00:11
jammarkh: I don't want you to be the only person who can make a release of the official binaries. I think that is a valid concern.00:12
jamI think for development processes00:12
jamhaving the release be00:12
jamtag the branch00:12
jam'make dist'00:12
jampublish results00:12
jamis a wonderful workflow00:12
jamHaving it be00:12
jammake dist00:12
jamthen apply 3 patches00:12
jamthen make win32-installer00:12
jamis not a good *process*00:13
jamwhich is what I'm trying to avoid.00:13
jamspiv: Tomorrow is more triaging to make sure we are ready for 1.6-final, as well as getting my stuff together for 1.7 Metronome emails00:13
jam(something we have also been missing)00:13
jamTWiB should also be happening tomorrow00:13
jamas I've missed it for 2 weeks now.00:13
jamrockstar: ^^00:14
jamAnd I'd *like* to get to bringing the btree code into core bzr00:14
jamI may not get that far.00:14
jamlifeless: speaking of which, I'd like to hear your thoughts on a 1.6-final that had the log regression.00:15
jamMartin seemed to feel it was a critical blocker00:15
jambut he's not here to expand on that00:15
spivOh, right00:15
jamThis Week in Bazaar00:15
markhyes, I agree its not a good workflow and I don't propose it as an ongoing process.  Regardless, I consider myself appropriately scolded00:15
jammarkh: So make them public, I'll merge them for 1.6-final00:15
jamand the problem is solved :)00:15
jamAs long as they are *usable*00:16
jamYou've convinced me about bundling TBZR00:16
jamAnd you've almost convinced me about paramiko00:16
markhthat wasn't your approach when you reviewed them last time!00:16
jammarkh: I need a release00:16
jamthat causes friction :)00:16
* awilkins can build the win32 stuff (up to the python installers so far)00:16
jamI don't want to use an ad-hoc release unless we must.00:16
jamawilkins: I can build the installers, but I would like to have our "official" build, which will be TBZR + qbzr, etc.00:17
jamEither we get it for 1.600:17
jamor it gets delayed to 1.7 IMO00:17
markhI'll get it to you in an hour00:17
jamI'd rather not have an ad-hoc build for 1.600:17
awilkinsIs qbzr better than Olive?00:17
jammarkh: If they are as unintrusive as you say, I'll be okay bringing them in for 1.700:17
johnfanyone about that can help me track down #254797, _read_bytes not defined when using smart protocol00:17
jamawilkins: It is more Windows-like00:17
jamas it is built on QT00:18
jamthere are tradeoffs between the two00:18
jamqlog is better than bzr viz (IMO)00:18
jambut gannotate is better than qannotate00:18
awilkinsbzr viz is what I use most00:18
jamawilkins: qlog allows folding merges00:18
awilkinsHows the conflict dialog?00:18
jamwhich is *huge* for me.00:18
spivjohnf: I can00:18
jamawilkins: I don't know that qbzr has conflict handling yet.00:18
spivjohnf: in a few minutes00:18
johnfspiv: cheers00:19
jamspiv: I ran into that for _urllib when BB was not giving proper 404's by the way.00:19
awilkinsI have a patch to the bzr-gtk conflict window for starting my favourite win32 merge tools00:19
jamspiv: anything else?00:19
jam(for standup)00:19
markhawilkins: wrt qbzr and tortoise, its probably fair to say we see better potential in qbzr, rather than thinking qbzr is already more "complete"00:19
jammarkh: Sounds good. I'll look forward to reading them tomorrow. If you are up late, I'd love to chat with you a bit00:19
jamboth about the locking issues you were seeing00:19
markhand more potential specifically in the context of tortoise!00:19
jamand about your development, etc.00:19
awilkinsAnyway, bed time00:20
jamBut now is family time00:20
markhnp - thanks00:20
jamI might also be around in a couple hours depending on when everyone sleeps.00:20
markhThe good thing is that all these branches is actually giving me real experience doing non-trivial merges :)00:20
* jam => away00:20
spivjam: interesting00:20
spivjml: no, not for the standup, thanks!00:21
n[ate]vwis there any way to copy/move a file WITH HISTORY between projects?00:22
jmlspiv: not for what standup?00:22
n[ate]vwI'm developing an app with components I'd like to eventually move into separate libraries00:22
lifelessjam: reply, with worked example, which I think is what you wanted00:25
n[ate]vwbzr move cannot move between branches, which would be where I'd expect to see that, but was wondering if projects within a combined repo gave any benefits like that00:25
lifelessjam: catch you later00:25
lifelessjam: I know that martin would really like to avoid the log regression00:26
lifelessI'm not sure how to do that :P00:26
james_wn[ate]vw: that's not possible as far as I know00:26
* markh wonders what will happen if he sneaks in a transparent version of bzr.ico rather than the one that is in the branch...00:26
n[ate]vwjames_w: so no plugins could either? basically, I'd be nice to take files like MyFloatStuff.c and MyMathStuff.c and put them into a separate "NumberLibrary" project without losing the histories00:28
james_wn[ate]vw: not possible. You could take a branch and delete everything else from the branch and just have the two files from that point on00:29
n[ate]vwthat might work alright, especially if bzr ever gets horizons (?) or whatever they call branching just a recent history00:31
james_wstacked branches are in 1.6, history horizon is a way off00:32
lifelessbzr split00:33
james_wlifeless: your rules patch still has "respectively" in the docs, now for a singular item00:34
n[ate]vwjames_w: seems like I just skimmed something about stacked branches, but do you have a link?00:35
n[ate]vwlifeless: excellent, thanks00:35
lifelessjames_w: thanks00:36
markhI gotta love "merge --reprocess" - it took a 74 line conflict region down to the 1 line it really is :)00:36
spivjml: your nick is too close to jam's :(00:37
spivjml: at least for these pre-coffee fingers.00:37
jmlspiv: you know the solution to that!00:37
lifelesscut off the fingers!00:38
n[ate]vwjames_w: n/m found http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html which was enough of a memory jog, I think I saw that in the checkouts help or something00:38
n[ate]vwoh, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-stacked-branches is where I saw it, FTR00:39
lifelessabentley: are you around ?00:39
lifelessabentley: my fix to iter_changes to be consistent has found a bug in diff that would show up on non-dirstate trees00:40
lifelessabentley: but I'm not sure of the right behaviour00:40
rockstarjam, TWiB is acknowledged, with high priority.00:47
lifelessmarkh: what does bundling mean?00:49
lifelessmarkh: I hoep it doesn't mean 'import into trunk' ?00:49
markhone sec...00:49
johnfspiv: so it looks like medium.py is calling read_bytes on HTTPTransportBase but it's only implemented in SmartClientHTTPMediumRequest so maybe the read bytes should be on getsmartmedium??00:49
johnfI'm totally poking in the dark here of course since I have no understanding of how this all fits together :)00:50
mwhudsonlifeless: i don't think abentley is aroudn00:50
lifelessjohnf: what bzr version?00:51
johnflifeless: 1.6rc2 and  bzr.dev seems to exhibit the same bug00:52
spivjohnf: Ok, I'm looking into this one now.01:02
johnfspiv: let me know if I can help at all01:02
johnfspiv: I'm happy to look into it if pointed in the right direction01:02
spivjohnf: I think I have an idea about what's going on01:04
spivjohnf: I landed a change in 1.6 that tidied up a bunch of the logic around _read_bytes in bzrlib/smart/medium.py01:04
spivjohnf: part of that I think was moving methods from the mediumrequest into the medium01:05
johnfspiv: that makes sense01:05
spivIt wouldn't surprise me if the HTTP code didn't quite keep up.  I thought I had fixed it (I definitely remember touching the HTTP code during that work), but I guess our test coverage is a bit lacking here.01:05
spivAh, I think SmartClientHTTPMediumRequest needs to implement read_line01:11
markhlifeless: the bzr binary will bundle a few other binaries too (bzr-svn, qbzr, tortoise).  The bzr.dev trunk's setup.py will get that capability, but no other code will be imported.  Is that what you were asking?01:11
spivOtherwise the default implementation falls back to calling that method on the medium, which is unimplemented in this case.01:11
lifelessmarkh: cool; I was wondering if you intended to drop a copy of paramiko into the trunk etc01:12
lifelessmarkh: that would have been concerning01:12
markhlifeless: nope - just setup.py will kinda assume it is in-place when you make binaries01:13
lifelessmarkh: windows binaries right ?01:14
markhfrom a QA POV, we probably need to get the the point where setup.py nominates *exactly* what is bundled and fails if anything isn't there.  It shouldn't be possible to "forget" to include something - but that can wait...01:15
lifelessspiv: bug 25773001:21
ubottuLaunchpad bug 257730 in bzr "bzr crashes during bzr pull" [Undecided,New] https://launchpad.net/bugs/25773001:21
spivjohnf: ok, I have a probable fix in hand01:22
spivjohnf: http://rafb.net/p/XvhCPc82.html01:23
spivlifeless: that looks like the same bug, thanks01:23
spivjam: I'm going to ask for the fix I'm doing for #254797 to go in 1.601:26
rick_h_lifeless: ping01:32
rick_h_hey, first, thanks for the help on the article. The feedback from the head editor was great and it'll be out in pymag in sept01:33
rick_h_got bumped up a month01:33
rick_h_I got asked to do a follow up article and I was thinking of covering a couple of workflows. Mainly a centralized (for the svn folks) and decentrailzed with share mainline01:34
rick_h_as I think those two are pretty common/useful for a large group out there01:34
lifelesssounds good01:34
rick_h_is that your take or would another workflow better show off bzr or anything?01:34
lifelessI think you should write about things you've experienced or played with01:35
lifelessor helped people with01:35
rick_h_ok, definitely01:35
spivIt doesn't help that pycurl tests give (55, 'select/poll returned error') on my laptop.01:37
johnfspiv: that did the trick. Thanks01:41
=== beuno is now known as beuno-dinner
=== beuno-dinner is now known as beuno
spivjohnf: it has a bug, though :)01:48
spivjohnf: you may also be able to work around it by prefixing "nosmart+" to the http:// URL.01:48
spivjohnf: I'll send a polished patch to the list fairly shortly.01:49
=== kiko-afk is now known as kiko-zzz
johnfspiv: except I'm using a smart server bzr+https://01:49
spivAh, in that case not so much :)01:49
spiv(The buglet is that there's a "return bytes" line in the _get_line function that needs to be "return bytes, ''"01:49
spiv(Probably not significant in normal use)01:50
Peng_Whoever just branched from my server (LP?) managed to download half of a 2 MB pack once, then the entire pack twice. Good going, bzr.02:01
* Peng_ is away now.02:01
lifelessPeng_: bleep02:01
lifelessPeng_: same IP ?02:02
spivPeng_: That would be me and my squid proxy I think.02:05
spivPeng_: sorry!02:05
lifelessspiv: upgrade it :)02:06
spivlifeless: get it backported to hardy (or point me to a PPA I guess...)02:06
lifelessspiv: feh02:06
spivlifeless: that's my attitude too ;)02:07
lifelessspiv: need a review for that patch"02:07
lifelessalso, my rules one needs a review02:07
lifelessand I'm wondering if we should file a bug on python for that 'cant write 80MB on smb reliably' bug02:08
spivlifeless: I will need a review soon, not quite yet.02:08
spivlifeless: hmm, probably.  what happens exactly?  Large writes get an EINVAL sometimes?02:09
lifeless22 whatever that is02:09
lifelessbug 25565602:10
ubottuLaunchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/25565602:10
spivlifeless: yeah, I'd bugger a file02:12
spivlifeless: I wouldn't be very optimistic about it getting fixed, but you never know...02:12
jonnydeelifeless: hi, regarding your solution to bug 255656: I was told here that the solution is considered to be just a workaround for a bug in python....02:15
jonnydeeand that workarounds are not likely to be merged into bzr 1.602:16
Peng_Ah, Squid. That would explain it.02:16
* Peng_ goes back to being away.02:17
jonnydeewhat do you think? will there be a achance to get it merged into future revision (for the case python's bug doesn't get fixed)02:17
Peng_spiv: You owe me $0.003 in wasted bandwidth!02:17
spivPeng_: I'll have to buy you 1 mL of beer sometime...02:18
lifelessjonnydee: its a bug02:28
lifelessjonnydee: bzr supports python 2.4, so we have to fix it in bzr02:29
jmlrockstar: btw, did you end up doing much with that plugin you were writing in Dunedin?02:39
rockstarjml, yes, but I haven't polished it.  I didn't think there was much interest in it, so it got to my needs, and I quit.  :)02:40
rockstarWould you like me to make an official lp project for it?02:40
warrenhmm, is there a way for me to edit the checkin message after it was committed?02:41
jmlrockstar: do you have a published branch at least?02:41
rockstarjml,  no02:41
* rockstar is ashamed02:41
jmlrockstar: +junk!02:43
rockstarjml, yea yea...02:43
Peng_warren: If you haven't pushed yet, and it's the most recent revision, you can uncommit and recommit.02:43
warrensomeone else committed it, but I want to edit the commit message before pushing it to the real trunk02:44
* Peng_ goes back to being away.02:45
mwhudsonPeng_: you don't seem to be very good at being away02:47
jmllifeless: so, we still hacking on Saturday?02:51
jmlif so, where, when and can RAOF come too?02:51
lifelessI want to buy lingua latina02:53
lifelessI think lynne would probably appreciate a little space, so not here02:53
lifelesssure RAOF would be good company too02:53
RAOFMy place _could_ work.  Possibly.  There's a table and couch and stuff.02:54
lifelessRAOF: where is your place?02:55
RAOFKensington.  That makes it quite some way from both you and jml02:55
lifelessjml: whats your place like?02:56
lifelessjml: where are you now?02:56
jmllifeless: spiv & Mary's place02:56
lifelessand next week ... ?02:56
jmlprobably still up at Andrew & Mary's -- I've got a key.02:57
lifelesswell, there is a possibility. If spiv and mary would be happy with that.02:59
lifelessI'll check in with Lynne when she gets home about doing it here02:59
jonnydeelifeless: ahh, ok -- thanks, taht's good news :)03:01
=== mw is now known as mw|out
LeefmcQuestion: Does bzr have any problem with many commits? Ie, are tiny commits about fixing little bugs, etc, acceptable in BZR?03:13
james_wLeefmc: absolutely03:14
Leefmcjames_w: K03:14
pickscrapeAnyone else used "Editra" before? I just learned of it today and it appears to have bzr support out of the box.03:15
jmllifeless: Kensington isn't that far away.03:18
markhwhere has spiv gone?03:20
markhor going? :)03:21
markhoh bugger - I see I should have put a 1.6 in the subject line for BB to see it targets 1.6...03:22
spivlifeless: if it means the plants get watered, then we can probably cope with that...03:23
spivmarkh: I'll be spending a couple of weeks in the South Island of NZ03:24
markhahh, nice :)03:24
spivmarkh: and trying not to cut my head open with a snowboard ;)03:24
markhoh that's right - you do that regularly?03:24
spivNot very, which is probably the problem...03:25
spivlifeless: fix for #254797 sent to the list, btw03:27
lifelessspiv: cool03:27
lifelessjml: I know where spivs place is better03:29
markhlet's all party at spiv's while they are gone!03:30
lifelessjam: welcome back :)03:53
jamlifeless: well, for a bit at least03:53
lifelessso I sent in a patch, its really quite tiny03:53
fullermdMmph.  Has check gotten slower?03:56
jamlifeless: so you basically just changed it so there are *no* per-branch config items?03:56
ToyKeeperHmm, I thought there was some easy, obvious way to split a subdir with history into a new branch, but I don't see it.03:56
jamI thought the point was to not version them03:56
jamnot to disable them completely03:56
lifelessjam: Martin's request was to disable it rather than not-version03:57
lifelessas he says:03:57
lifelessIf this is not baked yet then I think it would be cleaner to remove03:58
lifelessthe feature of reading from this file, rather than specially blocking03:58
lifelessit out from being committed.  We could still perhaps allow a branch or03:58
lifelessplugin for trying filters to turn it back on.03:58
jamah, I do remember that.03:58
jamGood enough I guess.03:58
jamI still disagree with it, and I don't quite feel that Ian agrees, but I can accept the "lets postpone for now"03:58
lifelessthank you03:58
lifelessI'll merge that patch to trunk now then?03:59
jamlifeless: please don't tie up the pqm yet :)03:59
jamIf I'm lucky, I'll get the 1.6 stuff merged that people want03:59
jamand we can do a rc3 by tomorrow03:59
jamso -final doesn't have to be delayed.03:59
lifelessthat would be good04:03
lifelessI'll merge the rules after you go then04:03
jamlifeless: It seems your patch is built on bzr.dev, not bzr 1.604:04
lifelessdo you want me to merge it to trunk and 1.6, or you'll do the cherrypick ?04:04
jamSo I'll cherry pick it04:04
jamand you can merge it directly to trunk04:04
beunomwhudson, hi04:04
beunoI just addressed your review on my diff branch04:04
lifelessjam: on inventories; does my worked example demonstrate the things you were concerned about ?04:04
mwhudsonbeuno: hi04:04
fullermdlifeless: Did you ever get a chance to look back at bug 255155 (knit file permissions)?04:05
ubottuLaunchpad bug 255155 in bzr "bzr doesn't use the repository directory for permissions" [Medium,Confirmed] https://launchpad.net/bugs/25515504:05
mwhudsonbeuno: oh right04:05
lifelessfullermd: no, I haven't04:05
mwhudsonbeuno: i still think the diff should be against compare_revid if there is one04:05
lifelessfullermd: can you upgrade to packs ?04:05
beunomwhudson, and see 2 remaining bugs. The javascript one, I can squash tomorrow. bug #243415, not so sure about where to start04:05
jamlifeless: Well you mention "minor variations" which doesn't seem to fit well with validators and "deterministic" values04:05
ubottuLaunchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/24341504:05
lifelessjam: I say that if we *don't do X* there would be04:05
lifelessjam: the sentence before described X04:06
beunomwhudson, aaaaaaaaaaaah, I see.  I understand what you meant now.  I tend to ignore the fact that we have compare_id, since the UI for it is so ugly04:06
fullermdlifeless: Well...   _can_.  would rather not, for non-technical reasons.04:06
mwhudsonbeuno: yeah, but ...04:06
lifelessfullermd: you have users using bzr < 0.92 ?04:06
fullermdlifeless: No, but it means a soft-flag day of making everyone upgrade their branches (or swallow abysmal performance).  And there'll be a hard flag coming up shortly when the next and rich-root-capable standard format comes along (in 1.2 or something soon like that)04:07
lifelessfullermd: the problem with permissions is they don't really work well enough04:07
lifelessfullermd: huh? why would there be a performance hit?04:08
fullermdI'd rather only ram that through once.04:08
fullermdBecause pulling from packs into knits was life-threateningly slow, at least last time I tried.04:08
fullermdRe-annotating and all.04:08
lifelessfullermd: please try again, it should not be04:08
lifelessfullermd: make sure you have the C extensions04:08
beunomwhudson, I'll address the compare_id bit. Any ideas for #243415?04:09
fullermdHm.  I'll try to fiddle with that tonite...04:09
mwhudsonbeuno: well, serve-branches still doesn't actually have a logging section, does it?04:09
lifelessfullermd: slower-than-normal yes, life threatening slow - no, jam fixed that weeks ago04:09
beunomwhudson, it looks like it does, yes04:10
markhjam: thanks for the approval.  Shall I upload my current rc2 binary directly to launchpad for the project and mail the bzr list, to try and get some feedback in time for a final?  Or would you prefer more controlled testing by people first?04:11
mwhudsonbeuno: well, not one that sets up logging to a file ... ?04:11
lifelessjam: this was the quote I think:"If we add a04:11
lifelessconstraint to the usual LPC rules that we must bubble compression04:11
lifelessopportunities as high up the tree as possible, then yes. If we don't, I04:11
lifelessthink it is possible to have minor variations."04:11
jamspiv: ugh... I just hit something nasty04:11
lifelessjam: I was trying to be complete, possibly adding confusion.04:11
jamI'm using bzr-email on a bound branch over bzr+ssh04:11
jamand it seems to be doing the log on the bzr+ssh branch04:11
jamand taking *forever*04:11
jammarkh: well, if beuno is up for it, we may have a 1.6rc3 tonight/tomorrow early04:12
jamwith your changes in it04:12
beunomwhudson, doesn't line 48+ do that?   http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/210?file_id=servebranches.py-20080618011543-s6ydx5c3bl38zap6-104:12
markhmy rc2 binary has only those changes you just approved.04:12
markh(oh - and an icon with a transparent background ;)04:12
beunojam, I can do rc3 tomorrow morning, sure  (~10hs)04:13
beunomwhudson, ignore me, it seems it doesn't04:13
jammarkh: ... what did I just mention about having the official build as part of core? :)04:13
beunomwhudson, I'm tired  :)04:13
mwhudsonbeuno: fair enough :)04:13
beunomwhudson, so, not for 1.6?04:13
mwhudsonbeuno: so loggerhead _should_ have logging and the logging _should_ capture tracebacks...04:14
mwhudsonbeuno: but yeah04:14
beunomwhudson, ok, different bug to address04:14
beunomwhudson, how does releasing 1.6 this week sound?04:15
mwhudsonbeuno: awesome!04:15
beunojelmer even packaged it, so I can probably upload it to PPA04:15
beunopickscrape, how's your branch coming along?  can you make it this week?04:17
jamlifeless, spiv: I would really like to include a NEWS entry with your changes.04:22
jamEspecially for "reasons why we went past an rc" I feel each commit should have a NEWS entry.04:22
jamCould you write up a simple one for me?04:23
lifelesssure, I guess04:23
mwhudsonbeuno: that's a point04:23
mwhudsonbeuno: how is loggerhead's NEWS doing?04:23
beunomwhudson, well, it's...  uhm...  we try not to push it too hard04:23
* beuno adds another task to his ToDo list04:24
mwhudsoni guess we should write some stuff04:24
mwhudsonbeuno: oh, also, we have the issue that if i merge the current loggerhead trunk to launchpad's codebase04:24
mwhudsonbeuno: it will go blue04:24
mwhudsonwe should, um, do something about that04:24
beunomwhudson, ah, yeah, I'd have to merge && revert && commit. If you point me at the branch tomorrow, I'll merge it in04:25
mwhudsonbeuno: ah yeah, that'll work04:25
Jucatogood day/evening. is there a logout equivalent to bzr launchpad-login?04:31
lifelessJucato: I don't think so04:31
lifelessjml: ^04:31
jamlifeless, markh, beuno, spiv: Well, after just submitting all 3 patches to the wrong branch (and having them all merged), I'm re-submitting them to the correct branch, and going to bed. I'll work on 1.6rc3 tomorrow.04:31
RAOFJucato: What would it do?04:31
lifelessjam: :P04:31
lifelessjam: what branch did they land on ?04:32
markhjam: ack - thanks!04:32
jamlifeless: bzr.dev04:32
lifelessjam: also, re - log04:32
Jucatobefore I used bzr launchpad-login <username>, this command worked: bzr checkout lp:~ubuntu-core-doc/ubuntu-doc/kubuntu-intrepid. after logging in, I get this error04:32
Jucatobzr: ERROR: Repository KnitPackRepository ('file:///home/jucato/kubuntu-intrepid/.bzr/repository') is not compatible with repostiory RemoteRepository(bzr+ssh://jucato@bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/kubuntu-interpid/.bzr/)04:32
lifelessjam: do you have a minute before you go, I can work on it over your night04:32
spivjam: hmm, bzr+ssh should be unaffected by my changes04:32
spivjam: so I'm not sure why bzr-email would be slower...04:32
spivjam: good night.04:32
jamlifeless: I've got a bit04:32
lifelessRAOF: I think it would remove your credentials04:32
jamjust don't expect high quality discussions :)04:32
lifelessjam: so, AIUI we previously called 'file_vf.versions()' which did the _prefix iteration triggering a full read04:33
jamlifeless: something like that, yes04:33
lifelessI propose a patch to do the following:04:34
Jucatohm.. I just nuked ~/.bazaar and it works now again.. but the reason I logged in was because I got the note "You have not informed bzr of your launchpad login. If you are attempting a write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.04:34
lifelesstwo things04:34
jamspiv: I don't know that you specifically effected it, or if it just that 'bzr log bzr+ssh' is really poor04:34
lifelessif the regions-unparsed ever reaches zero, convert the in memory structure to a full-buffered one.04:34
lifelessactually no, rephrasing04:35
RAOFJucato: That error looks like you've got an already-existing directory?  Does it work trying to checkout to a new directory?04:35
lifelessthere is an open bug spiv was looking at on kubuntu-docs04:36
JucatoRAOF: nope. I even rm -rf'ed the contents of that directory04:36
lifelessI think its something what vis-a-vis repo format preservation04:36
JucatoRAOF: I got it working for now by nuking ~/.bazaar. I'll wrestle with the problem again when I need to push something :/04:37
lifelessjam: actually, scratch that - you go to bed, I'll get some stats together04:38
jamlifeless: I think there are 2 performance bugs04:38
lifelessjam: any particular size repo you were testing on?04:38
jam1 is that we don't trigger buffering04:38
jamlifeless: http://people.ubuntu.com/~jameinel/mysql-unpacked.tar.bz204:38
lifelessthats going to hurt me isn't it04:39
jamlifeless:  a mysql repository, with an "optimally unpacked" layout04:39
jamits 652 MB04:39
lifelessonly got 700M free on disk04:39
jamlifeless: It shows up with bzr.dev04:39
lifelessI can't even download an untar it ;)04:39
jamlifeless: so there is the "if we hit all of history, buffering is faster" bug04:39
jamlifeless: and there is the "requesting all (file_id, revision_id) tuples" from a knitpack repo issue.04:40
jamI don't know which is the bigger issue04:40
lifelesswhats the second one?04:40
jamlifeless: misses in the knitgraphindex04:40
jamit has to bisect search for every non-existing key, into every pack file04:40
jamso 20 pack files, require 2 bisect searches * N missing keys04:40
jam'require 20 * N'04:41
lifelessits the same problem04:41
lifelessgo sleep, I'll see if I can generate a hack for 1.6/.dev04:41
jamI suppose a dict lookup miss is significantly faster04:41
jamlifeless: just don't over-engineer it for a regression quickfix :)04:41
lifelessjam: we need to fix it04:42
lifelessI jave 4 and a bit hour until I raid, so there is time04:42
beunomwhudson, pushed the changes with compare_revid.  I'm heading to bed now, and start tomorrow with the remaining bug + NEWS updates04:43
mwhudsonbeuno: excellent04:43
beuno(what I did feels a bit hackish though)04:43
jamlifeless: I just feel that if we could get a peak into the per-file graph, we could do it a lot cheaper by walking the ancestry04:44
jamwithout having to buffer_all.04:44
lifelessjam: but we do that04:44
jamlifeless: by grabbing every possible key, which is bad for KnitGraph.04:44
lifelesswe do modified_text_versions = branch.repository.texts.get_parent_map(text_keys)04:45
lifelessjam: the thing is, we've already walked the graph once to do the revision sorting04:45
jamlifeless: different graph04:45
lifelessjam: I know04:45
lifelessjam: its much better on IO to do what we do today, simply sorting by size to have the largest index first would probably reduce most of the pain04:46
jamcertainly loading all .tix indices is bad when you want just a single file_id04:46
jamI don't know that _iter_prefix is smart enough about how it does it, though.04:46
lifelessjam: its better on IO compared to just walking, because just walking is steps latency04:46
lifeless_prefix is dumb but fixable04:46
lifelessbut we're not using _preix now04:47
jam_prefix is dumb, but fixable, and 3x faster than get_all() :)04:47
lifelessis NEWS, or builtins.py better you think ?04:47
lifelessjam: uhm, prefix is basically get_all04:47
jamlifeless: actually, you want something that changes relatively little versus the whole tree04:47
lifelessrules.py? :P04:48
jamlifeless: but done *in order* (I meant to say get_parent_map(all))04:48
lifeless_prefix is better because it reads the whole .tix04:48
jamlifeless: _prefix is better because it does 1 linear read into a dict cache, serves results from there (though we may not actually hit the per-file graph much after that point)04:49
jamrather than bisecting an in-memory structure 10,000 *20 times04:50
JonCruzPerforce revision graph... http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html04:50
lifelessjam: yes, and it does those details because it reads the whole tix04:50
jamI think we both have a feel04:50
jamI'll welcome a patch04:50
lifelessjam: I'm talking big picture, you're talking fine detail04:50
lifelessI'll see if I can get something sensible for you to consider04:50
jamJonCruz: you might take a look at the "qbzr" plugin and "bzr qlog". It allows you to collapse and expand branches, which works a lot better when you have the 100s of branches that we have with bzr04:53
jam(i'm personally responsible for >200 feature branches of bzr)04:53
JonCruzthe functionality is one of the nicer parts.04:53
JonCruzjam: it's a little hard to explain without actually using it04:53
jamJonCruz: I didn't mean to start much of a conversation, I'm really tired and heading to bed04:54
jamI just thought I'd point you to something.04:54
JonCruzI'd checked them out a while back04:54
james_whey JonCruz04:55
jamlifeless: ?04:55
jamJonCruz: it does look interesting, but I don't see it scaling above 4 or so branches04:55
jamcertainly, above 3 the lines start having to cross somewhere04:55
JonCruzOh, it scales easily to dozens of branches04:55
JonCruzI've used it with some large enterprises04:56
lifeless22 seconds with that patch04:56
james_wI asked JonCruz to step in, as he was saying that this perforce viewer is great, and so I wanted to find out why so that the bzr gui tools could improve04:56
lifelesstesting without04:56
* beuno is off to bed. night everybody!04:56
JonCruzone aspect is that navigator window in the corner. Allows for zooming in and out04:56
lifeless34 without04:56
lifelessso its possibly sufficient04:56
jamlifeless: looks interesting, unfortunately rafb.net doesn't let me copy and paste easily, I'll test on my mysql repo04:57
JonCruzthe shapes also show merge, copy, branch start, branch end, etc.04:57
JonCruzpick-any-two-and-diff is also handy04:58
james_wthe navigator is interesting04:58
james_wah, it's not file based as I thought, it's just perforce being different04:58
spivjam: firefox/epiphany copy & pastes from that rafb.net page just fine for me...04:58
JonCruzit's a bit file oriented... but it would be nice to track code blobs in a similar fasion.04:59
JonCruzthat tool helps significantly when tracking down bugs in software that's been around for a bit04:59
james_wit's more of a canvas this I think, which would be a bit of work, but if the benefits are there and rely on that then it may be necessary04:59
JonCruzalso it focuses things for those with a spacial way of thinking, as opposed to the list-based approach of http://qbzr.googlegroups.com/web/qlog.png05:00
JonCruzlist-based is also good05:00
james_wdiff between any two is something that I know is missing in bzr-gtk, and there is an open bug I think05:01
jamspiv: I seem to get a consistent "malformed patch" with my cut-and-paste attempts05:01
JonCruzso in that p4v view the revision numbers are across the top. In the QBzr one they are down the left05:01
spivjam: huh, weird.05:02
abentleylifeless: pong05:02
lifelessI mailed the list05:02
lifelessjam: was it faster?05:02
jamlifeless: still copying the repo to this disk05:02
lifelessoh heh05:02
JonCruztheir "blame" tool is also nice live  http://www.perforce.com/perforce/products/tours/p4v/p4v_time_lapse_view_7.html05:03
jamlifeless: and, of course, getting distracted trying to actually 'patch' rather than do it manually.05:03
lifelessrafb used to allow text access05:03
lifelessI wonder why they don't anymore05:03
james_wjelmer: http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html <- you can ask me to explain tomorrow if you don't have the scrollback05:03
mwhudsonhm, somewhere to steal loggerhead ideas from!05:04
JonCruzOooh. their main page has some videos  http://www.perforce.com/perforce/products/p4v.html05:05
JonCruzI guess I should check if those are helpful05:05
jamlifeless: "time bzr log" goes from 40s => 28s, versus 28.8 for bzr.1.305:07
lifelessjam: so its a win ?05:07
jamlifeless: "time bzr log file" seems to be around 43s, which would be a definite win over the 2m+ from before05:08
jamI'll finish testing, but yeah, it looks like a big win05:08
lifelessit may not be sufficient05:08
jamso, for bzr1.3 it was 35s for 'bzr log file' versus 43s.05:08
lifelessbut as its implementing a TODO from the original design :)05:08
jamSo you aren't *quite* there05:08
lifelessmysql is a very big tree05:09
jambut I'm willing to take 43s versus 2min +05:09
lifelessits likely that if you print05:09
jamand accept a small regression05:09
lifelesslen(key), self.key_count()05:09
lifelessyou'll see a ration below 2005:09
jamlifeless: sure, and the code you wrote doesn't take into account how much you've already read, right?05:11
JonCruzjames_w: yes. It appears that their screencast video on the revision graph is helpful  http://filehost.perforce.com/downloads/media/rg/rg.html05:11
lifelessjam: right05:11
jamlifeless: but it is 2 min 27s without your patch05:11
lifelessjam: I aimed for quick05:11
jamfor 'bzr log file'05:11
james_wJonCruz: cool, thanks, I'll take a look tomorrow05:11
mwhudsonheh heh, diff -r <revno of the last loggerhead release> is bigger than diff -r 1 for loggerhead currently :)05:11
jamlifeless: So I think it passes my thresholds05:11
lifelessdoes it help annotate?05:11
james_wJonCruz: thanks for the pointers, I've got to sleep now, I'll swing by if I have any more questions05:13
jamlifeless: so for the *big* packs, I see 59632 35579 0.6005:16
jamaka, the 60,000 revisions are always >1/20th of the size of a text index05:16
lifelessthat will do _buffer_all :P05:16
jameven optimally packed05:16
lifelessI'm not sure why its staying slower then05:17
markhhrm - its seems that pycurl will wait up to 15 minutes before deciding a read had died and retrying it?05:17
jamlifeless: there are other queries that aren't triggering it, but I'm not going to dig into it all. I'll check annotate.05:17
markhs/up to//05:17
lifelessmarkh: that smells like tcp05:18
markh2 errors pulling from bzr.dev so far == 30 mins05:18
jamlifeless: well, first hand says "within the noise"05:18
jam7.8 for bzr 1.3, 7.9 with your patch, 8.3 for bzr.dev05:19
jamso likely it helps05:19
jambut the margins are pretty small05:19
jamlifeless: ATM, I would give BB:approve, but I think I should sleep first :)05:19
* jam => to bed05:20
lifelessjam: gnight05:20
lifelessabentley: I think bb is talking to itself05:27
lifelessabentley: :P05:27
abentleylifeless: joy.05:28
lifelessabentley: what do you think about the diff 'added but missing' issue?05:37
abentleylifeless: Dunno.  i've been fixing BB.05:38
lifelesscan I run it past you ?05:38
abentleyThis the iter_changes bug?05:40
lifelessfixing dirstate to do what inventory based ones does made a diff test break05:41
lifelessthe diff test did05:41
lifelessdiff -> wanted no outout, status 005:41
lifelessnow it shows garbage -05:42
lifelesskind change, mode change05:43
lifelesswhich is strictly correct but not very useful05:43
lifelessI think 'added' with no content would be a better display for diff05:44
abentleylifeless: So the iter_changes behavior sounds correct.  The diff behavior sounds whack.  We've usually treated missing files as though they had been removed.05:45
abentleySo I would expect diff to produce no output.05:46
abentley"added with no content" might be more sensible if you land a patch requiring files to be manually removed.05:47
abentleyBut diff has never tried to be as informative about file status as "status".05:47
lifelesswell, such a patch seems to be contentious :)05:47
lifelesssure, I can make it do nothing05:48
lifelessI know diff != status05:48
lifelessbut deliberately hiding seems a little strange to me05:48
lifelessI'll get on hiding it though05:49
abentleyWhat would you expect the behavior to be for "removed-but-not-deleted" files?05:50
abentleyIIRC it's the same as "removed-and-deleted".05:50
lifelesswell diff shows a full content removal05:51
lifelessand assumes no content change05:51
lifeless=== modified file 'bzrlib/diff.py'06:07
lifeless--- bzrlib/diff.py      2008-06-11 03:56:46 +000006:07
lifeless+++ bzrlib/diff.py      2008-08-14 05:07:18 +000006:07
lifeless@@ -874,7 +874,9 @@06:07
lifeless                 return path.encode(self.path_encoding, "replace")06:07
lifeless         for (file_id, paths, changed_content, versioned, parent, name, kind,06:07
lifeless              executable) in sorted(iterator, key=changes_key):06:07
lifeless-            if parent == (None, None):06:07
lifeless+            # The root does not get diffed, and items with no known kind (that06:07
lifeless+            # is, missing) in both trees are skipped as well.06:07
lifeless+            if parent == (None, None) or kind == (None, None):06:07
lifelessseem reasonable ?06:07
abentleylifeless: Yes, that seems fine.06:08
abentleylifeless: is \> a special string in regexes?06:09
lifelessin some engines yes06:09
lifeless\<foo\> is 'match the word foo06:10
abentleyI'm trying to decode what '\[MERGE\>' would match using python's engine.06:10
abentleyI would expect it to match only "[MERGE>"06:11
lifelesstry \\> ?06:12
lifelessno, thats wrong06:12
lifelessbut I mean, perhaps the \ is being caught by python06:12
lifelessr'\[MERGE\>' vs u'...'06:12
lifelessabentley: do I have bb:approve from you for that little patch?06:15
lifelessif so, I can land the iter_changes fix06:15
abentleylifeless: Could you pastebin it so I can see it in context?06:15
lifelessthat was the entire thing06:16
abentleylifeless: I figured, but I wanted to see where it fit in the existing file.06:16
lifelessI mean, its independent of the iter_changes fix, because its already broken for WT3 trees06:16
lifelessbut I can pastebin the whole branch if thats what you mean06:17
abentleyI meant just pastebinning the patch, so that it's in a form I can appy.06:18
mwhudsonetag support for loggerhead in about 10 minutes06:22
mwhudsonah, not quite06:24
lifelessnot really an either-or thing is it ?06:25
mwhudsoni guess supporting etags isn't06:26
mwhudsonbut it's not much use unless i generate some too :)06:26
abentleylifeless: bb:approve06:26
mwhudsonand the changelog view's isn't quite brain-dead simple06:27
mwhudsonand actually, i only did the templated stuff so far06:27
lifelessabentley: thanks!06:27
jmllifeless: so, Hornsby's out. Let's go to Kensington (or alternatively go Internetless at mine, pending confirmation with flatmate.)06:33
mwhudsonlifeless: can you point me to something that explains what a 'weak etag' is?06:38
mwhudsoni guess i should generate weak etags, as my tags won't change on template upgrades06:40
lifelessa datestamp is a weak etag06:44
lifelessa hash is a strong one06:44
mwhudsonlifeless: ta, i found an rfc which made some kind of sense06:47
mwhudsonlifeless: should i support if-modified-since and so on, or would you say etags suffice?06:48
lifelesswhy are you doing this?06:48
lifeless13.3.3 rfc 2616 btw06:48
mwhudsonso we can usefully put squid in front of it06:48
lifelessoh right06:48
lifelessIMS yes, definitely06:49
lifelesssquid will probably be sending IMS06:50
lifelessrather than IAM06:50
lifelesssorry, IM06:50
jmllifeless: is there a reason why TestCase.make_branch and friends don't accept URLs?06:51
lifelessjml: yes06:51
jmllifeless: what is it?06:51
jml(because it's making my life hard)06:52
lifelessbecause we want one test to run on different transports06:52
lifelesswhat do you need to do that you are having trouble doing ?06:52
jmllifeless: I want to make a branch at a specific URL.06:52
jmllifeless: I can do this, but it would be more convenient if I could use make_branch.06:53
lifelessjml: obviously; I was being a bit more general06:53
jmllifeless: oh, ok.06:53
jmllifeless: so, I want to make a branch in a test in a place that Launchpad will find it.06:53
mwhudsonlifeless: right, that's what i was reading, good to have it confirmed though06:54
mwhudsonnice timing, freenode06:55
lifelessjml: go on06:55
jmllifeless: I am writing an acceptance test to show that Launchpad stacks branches that it mirrors.06:56
lifelessjml: I can tell you what I would do06:57
lifeless(other than making lp less picky for testing) :)06:57
jmlgo ahead06:57
lifelessI would set self.transport_readonly_server to HttpServer06:57
lifeless(as ChrootedTestCase does)06:58
lifelessbut uncondiitonally06:58
lifelessand the url to give lp is06:58
lifelessit will be an http url06:58
jmlthat's not the branch I'm worried about creating.06:59
jmlthe branch I want to create is the stacked-on branch.06:59
lifelessthis is an acceptance test right?06:59
lifelessso why isn't make_branch(foo), make_branch(bar), lp.mirror(foo), lp.mirror(bar) reasonable?07:00
jmlthere are reasons.07:02
lifelessohohoh I just had a thought07:27
spivlifeless: those can be dangerous07:27
lifelessif we used another char07:27
lifelessor perhaps two columns07:27
lifelesswe can sensibly do diff after a merge07:27
lifelesssay two chars07:28
lifeless+ gam07:28
lifeless(parent 1 had foo, parent 2 had bar, we have gam)07:28
lifeless- foo07:29
lifeless+ gam07:29
lifelessbasis has foo07:29
lifelessthe merge had bar07:29
lifelesswe have gam07:29
lifelessI think the former is more useful, because unchanged local lines from the merge can just not be shown07:30
spivSounds interesting.07:31
spivSo, a slightly richer diff format, essentially?07:31
spivThat can represent more than just texts from {old,new}07:31
lifelessspiv: yeah07:44
lifelessI often want to know 'did I resolve this well'07:45
lifelessand I think this would let me figure that out07:45
spivI often want to know that too.07:46
lifelessdid my rm patch get reviewed?07:46
spivI did review it.07:47
* spiv checks the email escaped the laptop07:48
spivjam and I both voted tweak.07:48
spiv(for different issues :)07:48
lukshm, what about using the diff's merge format?07:49
luksI mean git's merge format07:49
spiv(And yes, my mail escaped)07:49
lifelessspiv: 'deletes' is wrong07:50
spivlifeless: huh?07:55
lifelessyour tweak, my mental grammar filter is objecting to using deletes07:56
spivlifeless: I just checked, jml's mental grammar matches mine07:56
lifelessI think you're both wrong.07:57
lifelessnow I need to go looking for singular verbs with plural subjects07:58
spivlifeless: Shall I ask my linguist? :)07:58
lifelesssure, though I'm looking for rationale not assertion07:58
lifelessand she may not have time/interest to dig up a explanation07:58
spivI'll find out if she does.07:59
lifelessbzr is singular08:00
lifelessdelete is the verb08:01
lifelessbzr is doing the deletion08:01
jmllifeless: it's just a bad sentence.08:01
spiv(that's the official diagnosis ;)08:01
lifelessso bzr is the subject, and thus subject-verb agreement ->08:01
lifelessjml: so lets reword id08:01
jml"Break any of these rules sooner than say anything outright barbarous." etc08:02
lifelessit will have to wait, I have things to do before 608:03
spiv    This makes bzr stop tracking changes to the specified files.  It will also08:03
spiv    delete them if they can easily be recovered using revert.08:03
spiv(That's my quick attempt at improving it)08:04
lifelessanyhow, suject-verb agreement is why 'bzr delete' is correct, IMO08:04
spivYeah, I eventually managed to parse it the way necessary to see that.  My very strong intuition was otherwise.08:05
spivDo you like my rewrite?08:05
lifelessso, 'bzr will also delete them ..' would work better in your restated sentence; using 'it' means more backtracking08:05
lifelessother than that its fine.08:05
spiv+1 on that.08:05
compubombquestion, does bzr have issues with version control involving binary versions ?08:16
compubombas opposed to say text.08:17
compubombspiv: so it just stores the entire file of the binary right ?08:17
compubombi believe with txt files version control apps generally use diff / patches right ?08:17
spiv"bzr diff" will decline to show you anything useful, but it'll store the versions just fine.08:17
spivbzr's internal storage format isn't patch files.08:18
spivThat said, it is currently optimised for text files with newlines bytes.08:18
compubombspiv: but you can use it with binaries though right ? i'd imagine it does some kind of hash to determine modification.08:19
spivSo it won't (currently) store them very efficiently.  Depending on the way the file changes it could easily just store the whole file for each new version.08:19
compubombspiv: okay, that was what i was wondering on.08:20
Peng_Nonetheless, it's not like it's broken, it's just somewhat inefficient.08:21
gouri'd like to use bzr-svn to fetch some svn repos. what is the current situation if one wants to use it with svn-1.4.6?08:26
gour(without patching svn)08:26
spivI believe the current bzr-svn trunk (and most recent beta release?) doesn't need any patching of svn08:29
spivCheck the README I guess.08:29
gourrelease is supposed to happen soon?08:39
Peng_gour: Yeah, pretty soon. See the mailing lsit.08:40
Peng_(I think)08:40
=== salimander is now known as Sepheriel
ubuntu_hi, why should I choose bazaar over git?10:45
gourubuntu_: simpler UI and safer10:46
gourubuntu_: that's why i migrated from darcs to bzr instead to git. ymmv10:46
ubuntu_what do you mean by simpler UI and safer?10:46
gimakerubuntu_, and it works with Launchapd (if you do open source stuff) :)10:46
gourubuntu_: just count how many commands are there in git, read about its model and see how can you shoot yourself in the foot ;)10:47
gimakerubuntu_, why not try both out and choose the one which you're more comfortable with? I tested mercurial and bzr, and bzr just felt a lot more smooth to work with.10:48
ubuntu_i use git at the moment. it's fast and actually it's quite easy to use.10:48
ubuntu_i heard of bzr not being as fast as git.10:48
gourtrue. but i do not work on linux kernel :-)10:48
gimakerubuntu_, it's not. how big is your source tree?10:48
gimakerand how many revisions does it have?10:48
ubuntu_well my source tree is like one rails project, so it wouldn't matter i guess.10:49
gourubuntu_: with darcs i started using it after 5mins. bzr is similar - check http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html10:49
gimakerubuntu_, It's pretty snappy with a ~1000 file 1200 revisions repository, so you should be okay too.10:50
gourubuntu_: nice and orthogonal command set supporting many different workflows...(d)vcs should be a tool i do not have to think to much, but just use it10:50
ubuntu_but another thing is, that just what i read and heard is that git is used by far more projects than bzr...10:51
gimakerI thought all the concepts was a bit confusing at first - shared repos, checkouts, lightweight.. ahh!10:51
gourubuntu_: that's also true. m$ windoze is used by far more users than linux, but i don't care :-)10:51
ubuntu_i love my mac.10:52
ubuntu_another thing: is it possible in bazaar to "change" the history? overwrite a commit, change the commit message etc.10:54
gimakerubuntu_: one selling point for bzr is its plugin system - rumor has it git doesn't support plugins?10:54
gimakerubuntu_: it's possible... afaik, it's not super-simple in the general case10:55
ubuntu_ok. thanks to all! i'll give bzr a try.10:56
gimakerubuntu_: in the common case ("doh, i forgot to add file X" or "man, that commit message was really retarded") it's very simple: just "bzr uncommit", fix what went wrong and re-commit10:57
ubuntu_yeah that's the simple case. but if it's "doh, that commit message is retarded" on commit 16 and we're at 24?10:58
luksthen you will have to rewrite the history, which will screw everybody who branched from you10:59
gimakerubuntu_: it's doable, but a bit more involved.10:59
luksrevision history in bzr is immutable10:59
ubuntu_is it documented on bazaar-vcs.org ?10:59
luksif you need to do a change like this, you need to make a new history10:59
gimakerubuntu_: not that I know.11:00
gimakerubuntu_: one (painful) way to do it is to "bzr uncommit" repeatedly11:00
gimakerubuntu_: another way is to use the rebase plugin11:00
gimakerit should be pretty simple, something along these lines ;) bzr branch -r 16 some_branch fix_msg; bzr uncommit; bzr ci -m "New and improved commit message"; cd some_branch; bzr rebase -r17.. ../fix_msg11:02
gimakerbut since you're a git-guy I guess you all about rebasing already?11:03
luksrebase wouldn't help you in this case11:03
luksthe replay command from the rebase plugin would11:04
gimakerright, where replay command = bzr rebase :p11:05
gimakerhmm.. this is interesting. what's the difference between replay and rebase?11:05
luksmaybe I misunderstand what bzr rebase -r does, but I really hope it does not drop revisions11:06
luksreplay is mass cherrypicking11:07
luksrebase replays your local commits on top of a specified branch11:07
gimakerluks, it doesn't. AFAIK, rebase does the same thing.11:08
luksthe same thing as what?11:08
gimakeras replay11:08
gimakerso what's the difference?11:09
luksdidn't I just say it?11:09
luksbut as I said, I'm not sure what `bzr rebase -r` does11:09
gimakerluks: Maybe, but I'm not exactly sure what "mass cherrypicking" means..11:10
luksbzr merge -c X OTHER_BRANCH; bzr ci -m COMMIT_MESSAGE_OF_X11:10
gimakerreplay seems  to be undocumented (bzrtools 1.3 something) so it's kind of hard to tell if the difference :)11:10
luksbzr merge -c X+1 OTHER_BRANCH; bzr ci -m COMMIT_MESSAGE_OF_X+111:10
luksehm, and what does bzrtools have to do with this? :)11:11
gimakereh, sorry.. rebase 0.3 :)11:11
luksrebase, by definition, should change the base of your local commits11:11
luksthat means it would not drop the revision with incorrect message11:12
gimakerI *think* I see the difference now. It seems it's just a matter of syntax/workflow."11:14
gimakerreplaying revisions A..B from branchA onto branchB <=> rebasing branchB on branchA11:15
lukswell, you are wrong, but I'm not going to argue :)11:15
luksthat is true in some specific case, not in general11:15
gimakerluks: ok, I'll take your word for it - I'm a rebase noob.11:16
gimakermaybe, in the future, there will be documentation to enlighten me on the difference ;)11:18
luksgimaker: http://rafb.net/p/ZfTkuu17.html11:21
luksis this more clear?11:21
luksor http://rafb.net/p/jE4zBV41.html to be more precise11:22
luksas the new revision just look like the originals, they are not identical11:23
gimakerwouldnt "(in branch B) bzr replay -r 3..4 A" be the same as "(in branch B) bzr rebase -r3.. branchA" ?11:25
gimaker 11:25
gimakersorry, I meant (in branchA) bzr rebase -r3.. branchB11:26
gimakerthat should also yield A->B->E->F->C'->D' ?11:27
ubuntu_definitely too much rebasing here ;)11:28
gimakeragreed ;)11:28
luksI don't know what -r in rebase does11:30
gimakerluks: rebase -rA..B OTHER will replay A..B from the current branch on OTHER.11:33
luksgimaker: just tried it, /tmp/branchB$ bzr rebase -r3.. ../branchA/ still results in A - B - C - D - E' - F'11:33
luksso, no, it doesn't :)11:33
luksand it will definitely not apply it on OTHER11:33
lukshm, I honestly don't understnad `rebase -r`11:35
luksbzr rebase -r4.. ../branchA is A -> B -> C -> D -> D' -> E' -> F'11:36
luksbut E was never a parent of D, so I don't know what's going on11:36
lukser, I mean D parent of E11:37
luksoh, sorry, ignore me, I did something wrong11:39
luksbzr rebase -r4.. ../branchA will drop the revision E, and the result will be A -> B -> C -> D -> F'11:39
luksI'm surprised it drops the revision so easily though11:40
gimakerluks: yes, but rebase -r3.. should give you A->B->C->D->E'->F', no?11:40
luksgimaker: yes, as I said above11:40
gimakerluks: but after playing a bit with it i can see that you're right...11:41
luksso -r in rebase basically means that you can manually specify the 'common anccessor'11:41
lukswhich can be destructive11:41
luks(really destructive, not just rewriting history)11:41
gimakeryou can also use the --onto argument to specify where A..B should be rebased11:42
gimakerluks: thanks for clarifying the replay command! it might provide quite useful indeed11:44
luksgimaker: well, in the end it looks like you can get the same result using rebase, so technically you don't need it :)11:45
luksbut for the original question I'd still prefer the (for me) more obvious way: bzr branch -r X A B; cd B; bzr uncommit; bzr commit; bzr replay -R X+1 ../A11:46
luksbzr replay -R X+1.. ../A11:46
gimakerluks: hehe yeah, that was my point all along :)11:46
gimakerbut it's more involved, so I think I'll prefer the replay-way in the future :)11:46
luksyeah, I didn't realize rebase can drop revisions in the process11:46
gimakermaybe these things should be documented somewhere - how to change an old commit message, or how to collapse/remove the first X revisions of the history (which is something I recently did, and it wasn't very obvious)11:57
luksyeah, most bzr people don't agree with history modifications, but if users do it according to a document at they won't screw up so badly :)12:00
gimakerluks: after trying it, I can see why they don't agree with it :) But it's useful in some cases, e.g. if you're just making a personal project public and want to remove the first 100 commit messages which just says "lol butts" or similar nonsense.12:02
* Kinnison recommends not being daft enough to commit with that kind of message :-)12:03
gimakerKinnison: it's bound to happen. Put a VCS in the hands of couple of fresh students and there you go!12:06
KinnisonThey'll learn12:07
KinnisonAnd having the mistake immortalised for all time will help them to learn that just because you were a numpty at one time, doesn't mean you can't improve12:07
KinnisonYou can't change the fact that at one point you were idiotic enough to think that "lol butts" was a sensible commit message, so why encourage people to hide it like it's a dirty secret or something?12:08
gimakerKinnison: Here's a better reason: http://wiki.freebsd.org/VCSFeatureObliterate12:10
Kinnisongimaker: Legal encumberances are about the only reason I can see to change history. Also, in a DVCS, I firmly believe that once you have allowed a revision to reach the wild, attempting to disavow its existence is counterproductive.12:14
LeoNerdEven Arch/TLA had a long discussion on the website about why changing history is bad12:16
gimakerKinnison: Not every DVCS is employed "in the wild", e.g. usage in closed-source shops. There was another case where an employee had put some improper comments about a (female) coworker in a commit message. It went to court ... and the company ended up wanting the commit message removed.12:16
gimakerI can agree that it's usually a bad idea, but as someone else put it "when you need it, you really need it".12:17
KinnisonI guess. I'm still against promoting the concept though.12:17
luksgimaker: if the coworker has a local branch, there is no way to remove it from there12:17
=== `6og is now known as Kamping_Kaiser
gimakerluks: That's not the point, the point is that the company "did their duty" (and I think it was a centralized VCS).12:18
luksgimaker: sure, but with DVCS it's not so easy to do such a change globally12:19
lukse.g. in case of FreeBSD, everybody in the world would had to redownload the whole history and destroy all old copies12:20
lukswhich seems almost impossible thing to do12:20
gimakerThere's still a difference... I'm not a lawyer, but if you illegally provide some content you probably get a "take down notice", and not a demand to erase all copies of that file.12:23
lukshm, right12:24
gimakerit's also useful if you have sensitive business secrets somewhere in your repository (commit messages or not), and then want to distribute the repository to a third party12:27
gimakere.g. "Added feature X. This will enable us to easily implement secret feature Y in product Z later on."12:28
KinnisonThat's what non-disclosure and similar agreements are for12:29
gimakerKinnison: That does help if you decide to open-source parts of your codebase12:30
gimakerGPL and NDAs don't mix and match :)12:31
TemplePrimei have a bazaar repo set up on my work computer, however after work i wanna export my work into a tar so I can take home and continue at home. Problem is, starting a new repo at home to host my files would erase my rev logs. Is there a way to transfer repos from one PC to another?12:49
gimakerTemplePrime: if you copy the .bzr directory as well you'll get the rev logs too12:50
luksthe preferred way is to use a computer to which you can connect from both places, and use 'bzr push'12:50
LarstiQTemplePrime: branch or repository? In the first case, `bzr push`.12:51
luksbut if you don't have such a server, just making a tarball of the directory should be fine12:51
TemplePrimecomputers are not connected, so making a tarball then, but I have to have even the same user on both machines?12:51
TemplePrimewow, bzr is flexible12:52
LeoNerdcp -r one of them (you only need the .bzr directory within it), shove it on e.g. a USB stick, then   bzr merge /path/to/usbstick12:52
luksdo both run the same operating system?12:52
TemplePrimeluks, yeah12:52
luksthe only problem would be moving windows working tree to linux or vice versa12:52
luksthen it's not a problem12:52
TemplePrimeno, they both have linux12:52
LeoNerdSo.. don't move the working tree :)12:53
LeoNerdAnd use the merge/push trick so you can deal with divergent history and whatnot...12:53
luksyeah, repository on a usb stick is a good idea12:53
uwsHey guys. I want to share a bzr branch with a colleague12:53
uwswe're both in the same unix group12:53
LarstiQuws: umask?12:53
uwscan I somehow make sure all the files are  foo:ourgroup  ug+rwX,o+rX   when I push?12:53
TemplePrimeLeoNerd, I tarball the whole repo and extract it in my home directory, that's it?12:53
LeoNerdTemplePrime: No need even there. cp -r it to the USB stick. Take it home. Do not move it off.. instead, run   bzr merge /path/to/the/USB/repo  from your home machine's workdir12:54
LeoNerdLet bzr pull the changes out from the USB stick, don't you manaully trash it12:54
LeoNerd(merge or pull or whatever is required)12:55
LeoNerdIn fact.. when at work, don't cp -r, that's silly.. bzr push it :)12:55
luksusually pull, since he can't work on both places at the same time :)12:55
uwsLarstiQ: How would that work with bzr+ssh or preferably sftp:// ?12:55
LeoNerdDepends.. sometimes I forget12:55
TemplePrimeLeoNerd, on my home machine I dont have even bazaar installed, after I install it dont I need to whoami and init stuff?12:55
LeoNerdTemplePrime: Oh probably, yes...12:55
luksTemplePrime: you do need bzr whoami, but not bzr init12:56
TemplePrimethe init and the whoami need to be the same right?12:56
luksinit creates a new branch, but you already have one12:56
luksno, they don't12:56
TemplePrimetrue, so only whoami12:56
luksbzr push/pull from an usb stick is really the best option12:57
TemplePrimei'll tarball it an email it to myself, dont have usb ports on the server12:57
luksyou can use `bzr send` too12:57
luksif you already have the branch on both computers12:57
TemplePrimeluks, they are not connected to each other12:57
luksoh, right12:58
ToyKeeperDoes bzr have a way to split a subdir into a new branch, retaining only that subdir's history?13:08
ToyKeeperI haven't found one...  the 'split' command seems to basically rename subdir => . and delete everything else, but doesn't change the history at all.13:09
ToyKeeperI'm basically looking for the opposite of the 'merge-into' command.13:10
=== mark2 is now known as markh
mhelddoes anybody know of any frontends for bzr like http://www.versionsapp.com/ ?14:34
beunomheld, bzr-gtk?14:35
mheldfor OS X?14:35
mheldwithout using fink/macports14:35
james_wthere's bzrx or something14:35
james_wbazaarx maybe14:35
james_whey beuno14:36
* beuno waves at james_w14:37
mheldi like the concept of bazaarX, but I don't really see how I could install this on 20 computers easily/quickly14:39
=== mw|out is now known as mw
=== kiko-zzz is now known as kiko
fbondIs this a problem?  "Standalone tree (format: unnamed)"15:01
fbondThis is a loom.15:01
strk/usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py:57: DeprecationWarning: bzrlib.branch.BranchHooks.install_hook was deprecated in version 1.5. Branch.hooks.install_hook('post_commit', branch_commit_hook)15:07
strkjust upgraded bzr to Bazaar (bzr) 1.6rc215:07
fbondOh, I guess all of my looms claim to have format "unnamed".15:08
fbondstrk: I don't think you need to worry about deprecation warnings.15:09
fbondstrk: They can safely be ignored, unless you are the author of the plugin using the deprecated API.15:09
=== kiko is now known as kiko-phone
jamstrk: When we get to a full release, we suppress deprecation warnings15:33
jamit is just for developers and people running bleeding edge15:33
jamso that the authors know they need to fix stuff for the release15:33
jamstrk: and 'bzr-email' has a fix if it releases a new version.15:33
jam(the code is done and in trunk, it just needs to be packaged.)15:34
=== kiko-phone is now known as kiko
strkAttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'15:58
strkbzr viz ...15:58
awilkinsstrk: Sounds like you need to update your bzr-gtk plugin to a more recent one16:04
strkI'm using the custom repository16:06
strkhttp://ppa.launchpad.net/bzr/ubuntu hardy main16:07
strkgot prompted to upgrade bzr but not bzr-gtk16:07
jvloothuisI am trying to merge two unrelated branches with; bzr merge -r 0..-1 ../unrelated-branch      unfortunenately I get an error about Repository KnitPackRepository not being compatible with the other (both are knitpack's), any tips?16:11
luksare you sure one of them isn't rich-root-pack?16:14
jvloothuisluks: thanks for the tip, you are right16:16
jambeuno: ping, I'm submitting the 1.6rc3 to PQM now, it will be a bit and I'll have a 1.6rc3 tarball to package.17:08
beunojam, cool. I'll try and get to that ASAP17:09
jambeuno: I'll make sure to ping you again when I've uploaded the tarball17:09
luksis this the last 1.6 RC?17:09
jamI just wanted to alert you that it was coming soon17:09
jamluks: With any luck17:09
beunojam, thanks  :)17:09
jamI wanted to do it quickly to give an rc a bit of time before -final17:09
jamabentley: do you have a 1.6 release of bzrtools that we can get packaged?17:17
abentleyjam: I released bzrtools 1.6 in June17:21
jamabentley: is it still compatible with 1.6rc?17:21
jamIt at least seems that ~bzr/ppa only has the 1.5 packages17:22
jamand ~bzr-beta doesn't have any bzrtools17:23
jambeuno: any chance you would feel comfortable packaging bzrtools as well?17:23
abentleyjam: yes.17:23
beunojam, yeah, I did it last time too.  Just need time.  I'll upload it around 1.6 for sure17:25
jambeuno: k. I would put it in the beta-ppa for now to go along with the 1.6 releases. This will also let us easily copy it into the official repo when 1.6 is final17:26
jamIf you could do bzr-gtk as well, it would be nice, but I'm not going to make you do *everything* :)17:26
jamDid Martin usually do bzr-gtk?17:26
beunono, jelmer did17:26
beunoand, bzr-gtk may be trickier as it may have varied dependencies17:27
beunoI'd rather we try and trick jelmer into doing that one17:27
=== kiko is now known as kiko-fud
bzrhi, is it possible in bazaar to checkout to the working directory (like in git)?18:01
jambeuno: 1.6rc3 upleading now18:33
=== mw is now known as mw|brb
beunojam, great, I have some stuff to finish, and then I'll get to that18:41
jambeuno: it is at http://edge.launchpad.net/bzr/1.6/1.6rc3/+download/bzr-1.6rc3.tar.gz for your downloading convenience18:43
=== jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc3! / http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
* beuno conveniently downloads it18:44
=== mw|brb is now known as mw
compubombhow do i tell bzr to ignore a group of folders involved a directory structure ?18:46
compubombi have a bunch of source, but also a lot of images, the images are not important.18:46
cody-somervillebzr ignore18:47
compubombcody-somerville: so > bzr ignore foldername1/ foldername2 /foldername3 filename4 etcnum18:48
cody-somervillecompubomb, you can also use patterns18:50
cody-somerville"bzr help ignore" <-- great info about it18:50
compubombcody-somerville: every time i accidentially do commit without giving it a message, it loads up a text editor on my system that i don't use(not important) but what is pissing me off is i don't know how to save the information that is in this box in order to execute the full commit.18:52
compubombdo i save a file or something ?18:52
compubombi don't see a filename.18:52
cody-somervilleYes, save without modifying the filename18:53
compubombyup, didn't work18:53
cody-somervilleYou can change the editor by changing the EDITOR environment value18:53
compubombwhat is annoying me is it's using jed18:53
compubombcody-somerville: i did env | grep "EDITOR" and it's not even in there.18:54
compubombwtf would bzr use jed ?18:54
cody-somervilleThere are several commands in debian based distributions use the "alternatives" system so that scripts and what not can run them and it'll use the preferred alternative.18:55
cody-somervilleThis may be the case with bazaar. I'm not a bazaar developer so I don't know :P18:56
jamcompubomb: we use VISUAL, EDITOR, and BZR_EDITOR18:58
jamOtherwise we fall back to "/usr/bin/editor" which is in the alternatives system18:58
jamthen vi, pico, nano, joe18:58
hsn_how to check plugin version?18:58
jamI'm guessing your distribution has "jed" set as the default editor18:58
jamwhen you run "/usr/bin/editor"18:58
jamhsn_: If they export it, just do "bzr plugins"18:58
jamhsn_: Not all plugins give a version string, though18:59
hsn_is there way to check if i have one plugin in path multiple times?19:00
jamhsn_: If the plugin is available via different names, it will probably give a conflict at import time19:00
jamif it is the same name19:00
jamwe have specific precedence19:00
jam~/.bazaar/plugins takes precedence over system-installed plugins19:01
luksbtw, why is bzr loading plugins from /usr/lib/python2.5/site-packages/bzrlib/plugins if I don't use that bzrlib?19:01
luksit might have incompatible plugins, so it's probably not a good idea19:01
=== thumper_laptop is now known as thumper
compubombjam: ty, just removed the symlink to /etc/alternatives/editor and chnaged it to vim19:05
compubombanyone happen to know where i could find a tutorial on setting up bzr with trac on ubuntu ?19:06
compubombi installed the trac-bzr package but it just installed a folder on my system, didn't do any configuration to apache i believe.19:06
jamluks: IIRC, it is setup to search the "Arch independent plugin path" because some people install multiple architectures side-by-side. So you end up with bzrlib installed in /usr/lib-x86/python... and you need to import the python modules from /usr/lib/python...19:08
jamluks: otherwise, I agree that when running out of the source tree, it may be good/bad to import site packages.19:09
luksjam: yeah, I know it was introduced then, but it doesn't seem logical19:09
luksI have maybe 0.90 in /usr/lib/python and I use 1.6 from my homedir19:09
luksif I had a globally installed plugin for the 0.90 version, it would break my 1.6 local install19:09
compubombwhat interfaces other than trac are good for bazaar interfacing ?19:09
compubombbleh, i mean like bug/ticket systems etc.19:10
hsn_is there way to disable plugin for example by renaming its directory to something?19:10
luksjam: one thing, if I sent a patch to ignore plugins named __init__, is there a change of getting it approved? it currently fill .bzr.log because it tries to load bzrlib/plugins/__init__.py and bzrlib/plugins/__init__.pyc19:11
luksfor me actually twice, from my homedir and from /usr/lib/python...19:11
compubombis there like a launchpad for local systems ?19:11
=== kiko-fud is now known as kiko
lukscompubomb: I don't think there is anything integrated19:13
lukstrac is probably the best choice if you want all-in-one solution19:13
jamhsn_: I rename them into a subdir19:14
jam(happens to be called DEACTIVATED)19:14
jamluks: probably I'd review a patch19:15
compubombluks: i installed trac-bzr but i don't know how to access it online, i'm not used to working with python apps. i found the directory in "/usr/share/trac"19:15
jamI don't feel like 4 lines in .bzr.log is "filling the log" but it is a bit ugly19:15
compubombdo i have to do setup.py install ?19:15
compubombi'm not sure wtf i'm doing.19:15
luksjam: well, not really "filling the log", but for most commands it's the only output19:15
compubombtrac has these directories in it "cgi-bin/  conf/  htdocs/  plugins/  templates/  wiki-default/  wiki-macros/"19:15
luksevery time I look at bzr.log I see four "Plugin name __init__ already loaded" entries for each command19:16
lukscompubomb: sorry, I don't know19:16
compubombluks: np, i asked in #trac, hopefully they will be kind enough to help me and not be like rftm.19:20
compubombsometimes, you need floaties before you get your stride.19:20
compubombrtfm is the equivalent of learning how to read and someone hands you a dictionary and says go at it tiger, and people expect you to be superman off the bat.19:21
luksI think trac has some nice tutorials on their wiki19:22
luksfor all deployment methods19:22
compubombluks: yea, they have it for svn19:29
pickscrapecompubomb: http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/48?file_id=readme-20061211191445-unb1b1y5dhltbwy7-219:39
pickscrapeOnce trac and the plugin are both installed, look at line 56 of that file and apply the required changes to trac.ini19:40
pickscrapeThat tells trac to use the plugin for version control instead of its built-in svn layer19:40
rockstarjam, TWiB in 15?20:07
nixternaldoes bzr have a function similar to svn:externals? and if so, can it do files or multiple files instead of complete directories?20:12
jamrockstar: I'm syncing right now, then i'll reboot and we're on20:14
rockstarjam, sounds great20:14
nixternaljam: you still in Chicago?20:19
nixternalnever mind, I did a whois20:19
nixternalyou going to barcamp this weekend?20:19
jamnixternal: I didn't even know it was happening, and yes i'm still in Chicago.20:27
jamrockstar: rebooting20:30
jamnixternal: to your earlier question, bzr doesn't really have a replacement for svn:externals yet, and the proposed one would be at a directory level20:37
jamnot for individual files20:37
nixternalso that means I have more work in front of me here at work :)20:38
jamrockstar: ready? i'm starting up gobby now20:39
rockstarjam, I is ready20:39
nixternaljam: http://barcampchicago.com - Saturday and Sunday, all day and night, free food and beer, live music, good talks, and some hacking20:41
nixternallast year totally rocked and this year is looking good already20:41
nixternalit is over at UIC20:41
jamnixternal: sounds fun, hopefully I can make it around children's b-day parties20:41
nixternalheh, this is b-day party weekend in chicago...my neice's is saturday, but barcamp won there :)20:42
=== mw is now known as mw|food
beunothumper, ping20:51
Toraninwow, svn2bzr (dumpfile version) is slow on long histories.  Looks like it's going to run for about a week by the time it completes at this rate21:13
beunolifeless, interesting thing just now. I tried to index the launchpad branch, and it brought my core2duo to it's knees. I control+c'd, and it kept on going until I killed the PID manually.  Is that expected?21:30
phoenix3051Is there a way to removed ignored file patterns from the ignore file on a per project basis. For example in the default configuration bzr will ignore *.a & *.o but for a certain project I don't what this to happen.21:30
jamTWiB is available: http://jam-bazaar.blogspot.com/21:30
jamphoenix3051: you can edit ~/.bazaar/ignore, but that will change all branches21:31
jamphoenix3051: you can always specifically add files21:31
jamby doing "bzr add filename.a"21:31
jamit is just that "bzr status" won't show them, or "bzr add" won't add them automatically.21:31
phoenix3051Jam: adding them by hand would be a nightmare as there are approx ~10k files.21:36
jamphoenix3051: "find . -name '*.a' -print0 | xargs -0 bzr add"21:36
jamtakes a few seconds?21:36
phoenix3051oh never thought of that because I was running the test on a windows machine, of to get cygwin installed now :)21:38
jamphoenix3051: I think on windows you could still do "bzr add */*.a */*/*.a" etc21:43
jamI don't know if we support "**/*.a" on win3221:43
jamno we don't21:44
=== kiko is now known as kiko-afk
=== mw|food is now known as mw
awmcclainHrm... does 1.6 break tracbzr?22:18
pickscrapeNot that I've experienced22:20
awmcclainpickscrape: I'm getting a mysterious AttributeError: 'BzrDirNode' object has no attribute 'path'22:20
pickscrapeI'll try updating mine and see if I get anything similar22:21
awmcclainMy apt-fu is really bad. What's the easiest way to downgrade my bzr version? apt-get install bzr=1.5 doesn't work. I must be missing something obvious.22:24
LeoNerdThat should be sufficient22:25
LeoNerdWhen you say "doesn't work" - explain in more detail22:25
awmcclaine.g. E: Version '1.5' for 'bzr' was not found22:26
awmcclainoh let me try updating the cache22:26
awmcclainthough, if i have 1.6, you'd think it' be up to date22:26
pickscrapeawmcclain: what page gives you that error?22:27
awmcclainpickscrape: Going _into_ a branch.22:27
pickscrapevia the browser?22:27
awmcclainpickscrape: Browse source, yes.22:27
awmcclainI see the top level fine, but anything below. pfft.22:28
pickscrapeI'm getting a different error: "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"22:28
thumperbeuno: pong22:28
pickscrapeWonder if I'm using the right trac-bzr branch...22:29
lifelessbeuno: drop the group count down22:29
beunothumper, hi  :)   I just committed a fix for a bug in LH's search.  Is there anyway you can cherrypick that into the gnome playground, so I can make sure it fixes the problem?22:29
lifelessbeuno: the fail-to-close is the refcounter hunting up objects and touching them before free, so its thrashing22:29
beunolifeless, ah, right. So, "known issue"22:30
thumperbeuno: hmm.. we need to upgrade the branch almost wholesale anyway22:30
lifelessbeuno: so "python"22:30
thumperbeuno: it might be easier to reapply the theme to trunk and use that22:30
lifelessrobtaylor: which reminds me, the thing that concerns me about gobject is the ref counting; its really harsh on memory IO; can GObject run w/o it ?22:31
beunothumper, ok, do you want me to update the gnome branch to the new theme then?  I know you where already working on some of that....22:32
awmcclainNope. I've even tried sudo apt-get install bzr=1.5.0-1~bazaar1~gutsy1. I can't downgrade to 1.522:39
pickscrapeawmcclain: my problem appears to be when the branch isn't in a shared repository. If it is, I can browse into it fine22:42
pickscrapeWhich is odd.22:43
awmcclainpickscrape: I'm navigating into a shared repository. :(22:43
pickscrapeYes, and we aren't even getting the same error message :)22:43
awmcclainI'm just trying to downgrade now, but I'm having no luck.22:43
pickscrapeWhat version of trac and the trac-bzr plugin are you using?22:43
jamawmcclain: well, if you have 1.6, doesn't that mean you are using the ~beta-ppa which doesn't have 1.5 in it?22:46
jamdon't you need to use the ~bzr ppa instead?22:46
pickscrapeHah, just realised I've already raised a bug for my problem (bug #239591)22:46
ubottuLaunchpad bug 239591 in trac-bzr "traceback when browsing branch with history" [Medium,Triaged] https://launchpad.net/bugs/23959122:46
awmcclainjam: I have both in my sources list. Let me double check. Good point.22:46
awmcclainjam:  apt-get install bzr=1.5 "should" work, correct?22:47
awmcclaini just want to make sure my command looks right.22:47
jamawmcclain: I don't know apt22:47
awmcclainjam: Oh, son of a gun. I must have removed it.22:48
* awmcclain sighs22:48
jamI can "upgrade" "update" and "install foo" but I haven't tried a specific version.22:48
awmcclainIt's going to be a long day, i feel it.22:48
james_wawmcclain: what's the output of "apt-cache policy bzr"?22:50
awmcclainAh! got it.22:52
awmcclainsudo apt-get install bzr=1.5.0-1~bazaar1~gutsy122:52
awmcclainPerfect. Downgrading fixed it.22:54
awmcclainI should file bug in trac-bzr, yes?22:54
awmcclainfile a bugt22:54
james_wit looks like it, yes22:56
lifelessjam: hi23:08
jamhi lifeless23:20
weigon_what shall I do if I get: bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: revno does not match len(mainline) 13 != 619123:34
lifelessjam: what I"m trying to do with gc is get smooth integration with bzr23:35
lifelessjam: which is why sorting out fetch to be solid is important to me23:35
jamlifeless: I agree that fetch is important, I don't think the sort order is the most important part of it23:35
jam(gc => gc fetch is currently at 27 minutes and still on 0/4)23:36
lifelessjam: what do you think is the mort important part of fetch ?23:36
jamlifeless: getting it to fetch without recompressing everything23:36
lifelessjam: So the way that that will work will depend on the way gc->gc fetch is implemented23:37
lifelessI want to implement it via get_record_stream, which is what I'm working on, so I'm working towards that23:37
lifelessif it doesn't fit well via get_record_stream, then I'll do a custom thing like pack->pack does;23:38
jamlifeless: I feel like you are spending a lot of time getting the "optimal order when recompressing everything"23:38
jambut not skipping around it.23:38
jambecause it isn't ever going to scale.23:38
lifelesswell, AFAICT git recompresses everything on fetch23:39
lifelessit sends existing deltas but always decompresses on receipt23:39
lifelessI don't want to rush groupcompress, I want to take the time to get it well polished23:40
jamlifeless: gc is much more expensive then their compression strategy23:40
jamI'm not sure if we can improve it a lot or not.23:40
lifelessjam: its cheaper surely23:40
lifelessconceptually gc does less work23:40
jamI don't see it doing less work23:41
jamI suppose if you consider the cached hashes?23:41
jamAt a minimum creating deltas is more expensive than expanding them23:41
jamby about 10-100:1 ?23:42
lifelessgit does a xdelta (A, B), for a set of (B) to decide which B to insert next, and threads that23:42
lifelessit then reuses the one it chose.23:42
jamlifeless: I'm not positive, but I don't think it does that for transmission, only for "git pack"23:42
lifelessbut it generates matching ranges etc from scratch for at least N-1 pairs23:43
jam(or repack, etc)23:43
jamI agree that it does that for repack --window ....23:43
lifelesstransmission is less enthusiastic true23:43
jamI don't think it does that during "clone"23:43
lifelessbut its still at least N-1 pairs23:43
jamlifeless: except for the ones it can re-use (which is at least what you just said)23:44
jamand GC can't be reused except in bulk23:44
lifelesswe can just put the group on the wire intact23:44
jamlifeless: and doing that (IMO) is more important as a priority, and may preclude using get_record_stream23:45
jamlifeless: I'm *more* concerned about local branching than network, atm23:45
jamlifeless: because after you've gotten the wire stream, you still have to insert it into the local repo23:46
lifelessjam: well, if you're interested in scratching that part first, please do so :)23:47
lifelessI don't think that non-developer usage feedback is very useful at this stage for gc repos23:47
jamlifeless: I've got lots of other things on my plate before I can get to gc. Certainly you are welcome to scratch your itch. But it feels like you are trying to polish something that isn't *usable* yet.23:47
lifelessso I don't have any motivation to get the formats and compressor into bzr.dev per se23:47
lifelessI'm trying to get the *implementation of fetch usable*23:48
lifelessthat means either custom-coded, or using get_record_stream23:48
jamOk, I would suggest you are going about it in the wrong way.23:48
jamPerhaps not.23:48
lifelessyou're complaining that its slow using get_record_stream23:48
jamI feel like you are polishing the insertion order.23:48
lifelessjam: I'm working on the interface so that gc->gc using get_record_stream has the room to send an entire group and reuse it while still working correctly for knits23:49
lifelesswe're trying to squash all these different use cases into one interface23:49
lifelesswhich is fine, but it means polishing the interface to be really nice23:50
jamlifeless: sure, and my feeling is that get_record_stream isn't a good fit.23:50
lifelessjam: you do realise that you haven't said that at all23:50
lifelessuntil now23:51
jamlifeless: I've been saying using an api that requires recompressing everything isn't a good fit. which is basically how get_record_stream() is designed (atm).23:51
lifelessnot at all23:51
lifelessget_record_stream was designed explicitly to avoid recompressing23:51
jamAnd I don't see having: get_record_stream("gc-blobs")23:51
lifelessand knit->knit doesn't recompress23:51
jamlifeless: because the stream is designed as knit deltas.23:52
lifelessbecause the api is flexible23:52
lifelessit may not be flexible enough23:52
lifelesswhich is one of the possible outcomes of this discussion23:53
jamlifeless: well, at present it talks about everything 1-text at a time23:53
jamwhich isn't possible for "optimal GC transmission".23:53
jamSpecifically the "get_bytes_as()" portion.23:53
jamAnd 1 factory object per text23:53
lifelessI'm irritated because I feel like you are telling me I'm doing the wrong thing, but your objections have been about 'this bit over here is rough' not why the time is wasted23:54
lifelessjam: the API is stream->stream23:54
lifelessjam: the generic use of the stream is text->text23:54
jamlifeless: http://rafb.net/p/T8dpQb85.html23:56
jama stream is an "iterator of ContentFactory objects"23:56
jamwhich is a series of Content objects. I will agree that it doesn't give a definition of what Content is.23:57
jamBut if it is compatible with Knit23:57
jamthen it would be 1 Content for each text.23:57
jamlifeless: look, *you* wrote the api, and you have the best knowledge of how it can be modified to fit what you are looking for.23:57
jamI'm going off the level that I've been exposed to it to date.23:58
jamWhich isn't truly deep.23:58
jamThe only flag we have at the moment to indicate what type of stream to produce is "ordering".23:58
jamWhich doesn't really fit a "give a ContentFactory stream that is useful for knits" versus "give me a ContentFactory stream that is good for gc => gc".23:59
jamlifeless: I *do* see that the base-level ContentFactory object has a "self.key" member, rather than a "self.keys" parameter23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!