[00:07] <beuno> lifeless, http://ftp-master.debian.org/new/bzr-search_1.6.0~bzr49-1.html
[00:09] <Leefmc> If i ignore a folder, it will ignore the contents aswell, correct?
[00:09] <beuno> Leefmc, yeap
[00:09] <Leefmc> k, thanks
[00:10] <poolie> hello beuno,
[00:10] <poolie> spiv, ping?
[00:11] <spiv> poolie: hi, doing a standup with lifeless atm
[00:11] <poolie> np
[00:12] <beuno> poolie, mornin'
[00:13] <mwhudson> hi poolie
[00:13] <LeoNerd> 'bzr branches' seems to eat up massive amounts of RAM on my system....
[00:14] <LeoNerd> I've caught it eating 45% of 512MiB. I killed firefox by mistake thinking it was that
[00:19] <tacone> poor firefox :(
[00:20] <lifeless> poolie: hi
[00:20] <lifeless> poolie: we started at 9 :)
[00:20]  * spiv grabs some breakfast
[00:20] <poolie> :-P
[00:20] <lifeless> poolie: I'd like to chat with you about .bzrrules in 1.6
[00:21] <lifeless> poolie: I think this is an urgent-to-have chat because 1.6 is looming
[00:22] <lifeless> also
[00:22] <lifeless> http://abstrusegoose.com
[00:26] <poolie> lifeless, sure
[00:27] <lifeless> should I ring?
[00:27] <lifeless> or irc or ...
[00:28] <poolie> wait a bit
[00:28] <lifeless> ok :)
[00:34] <poolie> lifeless, just doing a brief mail pass, then will be with you
[00:44] <poolie> lifeless, now?
[00:44] <poolie> here, or phone?
[00:44] <lifeless> phones easier
[00:45] <markh> less fun for us though ;)
[01:05] <spiv> markh: just because you can't hear them doesn't mean you can't heckle ;)
[01:05] <markh> :)
[01:08] <poolie> abentley, BB seems to be down
[01:10] <abentley> poolie: BB's Back up
[02:04] <lifeless> markh: maybe less fun, but a lot quicker
[02:04] <lifeless> markh: your question last night ...
[02:04] <markh> yah...
[02:04] <lifeless> markh: try merge --lca
[02:04] <lifeless> or --reprocess
[02:06] <markh> ok, thanks - I'll try that next time I merge.  I think its a matter of getting into the mindset and understanding what is really going on
[02:06] <markh> my mind makes certain assumptions about the models, then struggles to fit reality with that flawed model :)
[02:07] <markh> oh - roght - wrong question :)  You are referring to the conflict markers question
[02:08] <markh> what does "reprocess" do? - help isn't very illuminating...
[02:10] <markh> and if it magically prevents spurious conflicts, why isn't it the default? ;)
[02:13] <lifeless> it reduces the region of a conflict
[02:14] <lifeless> our conflicts are often better than difflib would create
[02:14] <lifeless> but it keys on unique lines; and in some files that can make things worse rather than better
[02:15] <lifeless> its a 3-way merge of base, other, this, with common regions determined by doing patience-sorting on unique lines then expanding out from there along common lines
[02:16] <lifeless> this is a bit strange to think about at first - but important: repeated lines are never the reason for a common region to be identified; they are found by being adjacent to a common unique line
[02:20] <markh> right - interesting.
[02:21] <markh> is there any scope for detecting conflicts and attempting different strategies to come up with the smallest amount of conflicting text?
[02:21] <lifeless> sure, though that may not be the most useful thing for the user :)
[02:22] <markh> no - so the merge options would allow that control.  But in the general case, I'd say giving the smaller the conflicts, the happier the user :)
[03:13] <markh> spiv: should I add a patch for the docstring to that bundle even though it isn't directly related to making a test pass?  Or a separate one bundle?
[03:13] <markh> s/one bundle/bundle/
[03:16] <spiv> markh: which ever you prefer, I don't mind.
[03:17] <markh> same bundle is easier :)
[03:17] <spiv> I thought that might be the case :)
[03:24] <markh> spiv: to save email ping-pong: at the end of the first para in the docstring body (ie, line 6) of transport.local.abs_path, I'm appending "The returned path will always contain forward slashes as the path separator, regardless of the platform."  Sound OK?
[03:25] <markh> oopa - local_abspath
[03:25] <markh> *sigh* - transport.local.local_abspath
[03:25] <lifeless> I don't really see why thats needed; we do that *everywhere*
[03:26] <lifeless> I mean, perhaps there is some other doco that should be made stronger rather than playing whack-a-mole with developer confusion?
[03:26] <spiv> lifeless: well, I guess perhaps I was reading too much into that docstring's mention of realpath
[03:26] <markh> the "abspath" in the name mislead Andrew and me
[03:26] <markh> and that :)
[03:26] <lifeless> vs \ is orthogonal to "/" and "C:"
[03:26] <markh> the "local" kinda implied "native" too
[03:27] <spiv> I'd be equally happy with the docstring emphasising that it's an internal path rather than specifically the \ vs. / issue.
[03:27] <markh> and the author of the test seemed to assume native seps too
[03:28] <spiv> markh: right
[03:28] <lifeless> I just want to ensure we've covered enough bases that in 2 weeks we don't get another such patch for transport.other_foo
[03:29] <lifeless> given that *everywhere* except _perhaps_ display functions we use /
[03:29] <spiv> lifeless: I'm open to alternative suggestions for avoiding the confusion that happened here.  (Including "it's good enough as is" if you think so)
[03:29] <markh> the patch wasn't to change the transport - the intent of the tests wasn't clear
[03:29] <lifeless> its clearly not good enough; markh got confused
[03:30] <markh> well - to be fair, I assumed the test author knew what they were testing ;)
[03:30] <lifeless> so if you guys think the specific function is all that needs tweaking, I'm +1
[03:30] <markh> the test used realpath, and the function name implied "realpath", and the docstring *said* realpath :)
[03:30] <lifeless> but please do consider checking we have some overall statement (perhaps in the HACKING-collection) about / vs \
[03:31] <spiv> lifeless: well, this is the only Transport method with a "local_" prefix, so I think there's a good chance that it's just this method.
[03:32] <spiv> e.g. Transport.abspath already clearly returns a URL, so we don't have this confusion there.
[03:33] <spiv> There's a "Filenames vs URLs" section in HACKING, but it doesn't seem to address this point.
[03:33] <markh> OK, I'll mail a bundle with the doc change I mentioned, and leave the HACKING doc change to another day when I'm *supposed* to be working on bzr ;)
[03:34] <spiv> Ok.  I'll whip up a quick addition to HACKING after lunch.
[03:34] <lifeless> spiv: YHBTHANDHTH (re monkey patching)
[03:34] <spiv> lifeless: I know :)
[03:34] <spiv> lifeless: but it *is* tempting, regardless :)
[03:35] <lifeless> could do one that checks the stack
[03:35] <spiv> (The problem with making silly suggestions is occasionally people implement them!)
[03:35] <spiv> lifeless: That's less tempting :P
[03:35] <spiv> Lunch is more tempting.
[03:37] <markh> the ".replace("/", os.path.sep)" change in the tests is pushing those lines to 90 chars.  I see a couple of others in that file at 89 ;)  Should I split the lines?
[03:37] <markh> s/should/must/ ;)
[03:39] <lifeless> hmmm
[03:39] <lifeless> 1m51 to pull 3 days changes to bzr.dev :(
[06:02] <spiv> Hmm, a schooltool user is getting a MemoryError doing an upgrade from knits: https://bugs.edge.launchpad.net/bzr/+bug/256757
[06:15] <lifeless> yes, I'm wondering if its a bug in VFs
[07:23] <spiv> markh: see mailing list, your test_plugins changes fail for me
[07:23] <markh> spiv: yeah, saw that - thanks.
[07:24] <markh> it only fails for me in a .exe - so I might just take the easy option and disable it there :)  I'll have one more stare at it though, but probably not for a day or 2...
[07:25] <markh> or just revert that part of the patch - with 100+ failing it doesn't really matter.
[07:25]  * markh will think about it ...
[08:52] <lifeless> spiv: FYI: 58 seconds to pull one change from bazaar-vcs.org  :/
[08:52] <lifeless> spiv: I haven't analysed why yet
[08:55] <spiv> lifeless: :(
[09:49] <gnomefreak> is it still posssible to remove a bzr branch with the beta launchpad?
[09:52] <thekorn> gnomefreak, there is a delete icon right to the branch title
[09:53] <thekorn> it points to <branch-url>/+delete
[09:53] <gnomefreak> https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu
[09:53] <gnomefreak> i dont see it
[09:54] <gnomefreak> oh damn the red X
[09:54] <gnomefreak> sorry
[10:06] <poolie> night all
[10:27] <robsta> hi, could someone help me out with a bzr error?
[10:28] <robsta> bzr commit says "bzr: ERROR: Working tree is out of date, please run 'bzr update'."
[10:28] <robsta> then update hits an internal error
[10:28] <robsta> bzr: ERROR: exceptions.TypeError: 'NoneType' object is unsubscriptable
[10:29] <robsta> it all started with the following, committing a change involving lots of file renamings:
[10:29] <robsta> bzr: ERROR: An inconsistent delta was supplied involving 'libccd/examples/internal.c', 'drawing.c-20080703141534-hfdtbme1gtdl6g10-1'
[10:29] <robsta> reason: basis tree does not contain removed entry
[10:30] <Peng_> This isn't very helpful, but are you using the latest version of bzr (1.5 or 1.6rc1)? This may have been fixed.
[10:30] <Peng_> Other than that, I have no idea. Sorry.
[10:33] <robsta> apparently stable ubuntu has 1.3.1-1ubuntu0.1
[10:34] <AfC> robsta: that's pretty old, but as Peng_ noted, that may ore may not have anything to do with your problems.
[10:36] <robsta> any chance that the upgraded version will automatically fix the state of my repo?
[10:37] <robsta> or any general recommendation of what to do in such a case?
[10:39] <mwhudson> 'bzr check' and 'bzr reconcile' might be worth trying
[10:41] <luks> heh, I love benchmarks, somebody compares bzr/hg/git branch and then bzr/hg/hit clone
[10:42] <luks> and then have different values for bzr branch and bzr clone, when it's in fact the same command
[10:42] <robsta> mwhudson: no improvement, unfortunately
[10:43] <Peng_> Worst case, "bzr remove-tree" or "rm -rf .bzr/checkout" to delete the working tree, throwing out your changes, then use "bzr co" to recreate it.
[10:46] <robsta> will that help?
[10:46] <robsta> the file that made it bail was bzr moved like 20 commits ago
[10:46] <luks> 'Cherrypicks are just "merges" that are not tracked (cf. Git)'
[10:46] <luks> people really shouldn't be allowed to write about anything they don't know well :(
[10:47] <robsta> Peng_: now renaming the dir that holds it broke things
[10:47] <AfC> robsta: the other outside possibility is that if you can branch from that repo at an older revision into an entirely new tree, then you may or may not be able to extract the branch (at that point) safely. That works surprisingly often, using -r -5 or something
[10:49] <robsta> well
[10:49] <AfC> (or -1 or -10 or 570 or whatever you need to do to get before the borked state, assuming that there is some interaction between your working tree and your branch that is confused. If the repository is corrupted, then of course it won't work, but that is *exceedingly* rare)
[10:50] <AfC> [and you reporting that `bzr check` passed makes it sound like the repo is ok]
[10:50] <robsta> er, bzr check
[10:50] <robsta> bzr: ERROR: Revision {('rstaudinger@meqbuq-20080704140118-zfu9ft5a61y34252',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x85d99ac>".
[10:51] <AfC> oh goodie
[10:52] <robsta> this is pre 0.1 stuff anyways, maybe i should just move from bzr-playground to gnome svn and start over
[10:53] <AfC> robsta: Are you just using Bazaar or are you simultaneously also trying to use Subversion?
[10:53] <robsta> just bazaar
[10:53] <robsta> this is bzr-playground only
[10:54] <AfC> robsta: that' constrains things, at least. Ok, so you said you were renaming things. You didn't go and do something like manually move a top level directory tree out from underneath one shared repository to another or something like that, did you?
[10:55] <robsta> heh, no
[10:55] <lifeless> hi
[10:55] <AfC> robsta: [there's a revision no present in whatever repository that branch is using. This tends not to happen because of something bzr did wrong. /me knows this from having shot himself in the foot once]
[10:56] <robsta> AfC: i'm the only person who ever committed to that repo
[10:56] <AfC> lifeless: dunno if you can help this fellow, but robsta has a bzr 1.3.1 reporting a missing revision.
[10:56] <AfC> robsta: fine
[10:57] <lifeless> robsta: when did it start giving this problem?
[10:57] <robsta> lifeless: 10min ago
[10:57] <lifeless> robsta: and had you been working normally up to then ?
[10:58] <lifeless> robsta: is this a pure-bzr tree, or one of the bzr-svn imports on the playground?
[10:58] <robsta> lifeless: bzr + add, mv, commit, push; guess that's pretty much all i did
[10:59] <robsta> lifeless: pure bzr
[10:59] <lifeless> robsta: if you haven't done something obviously wrong like 'mv branch /outside/repo' or 'bzr init-repo path-between-branch-and-repo'
[10:59] <lifeless> ?
[10:59] <AfC> lifeless: (that's kinda what I suspected)
[10:59] <robsta> really just the above set of most plain commands
[11:00] <lifeless> robsta: ok
[11:00] <lifeless> then its time for a bug report with a back trace
[11:00] <robsta> https://bugs.launchpad.net/bzr/+bug/256865
[11:00] <lifeless> I may lag a little bit from time to time, I'm in a wow raid; but bear with me and I'll check on stuff after deaths :)
[11:01] <AfC> robsta: can you at least recover with `cd /tmp ; bzr init rescue ; cd rescue ; bzr pull -r -1 ~/path/to/branch` ?
[11:01] <lifeless> robsta: ah, inconsistent delta
[11:01] <lifeless> there is another bug on this
[11:03] <lifeless> so
[11:03] <AfC> bah, duh, `cd /tmp ; bzr branch -r -1 ~/path/to/branch`. There's good old Andrew, over complicating things as usual.
[11:03] <lifeless> AfC: :) theres more than one way to do things :O
[11:03] <AfC> (or revno -5 or 57 or whatever)
[11:03] <robsta> AfC: this gives a new error: bzr: ERROR: Revision {robsta@gnome.org-20080723094759-xjsiakuuex5nhc2b} not present in "cbdunused.sgml-20080723094649-6cdasqyczacflh6z-2".
[11:04] <AfC> lifeless: /me is surprised to hear the Perl motto coming from such a dedicated Pythoner :)
[11:04] <lifeless> AfC: my favourite language flips between smalltalk and erlang
[11:04] <AfC> robsta: ok, so you may need to twidle with a different revspec
[11:05] <robsta> well, the history is not so important for me
[11:05] <robsta> so if the problem is known and i can not provide new insight to the bzr devs i can as well start over brute force
[11:05] <AfC> robsta: judging by the dates in those revids, I'd also guess that something like `bzr branch -r date:2008-07-02` might work
[11:06] <AfC> robsta: (mostly I was emphasizing a) get somewhere not that current branch+repo, and b) reach back [some arbitrary amount)
[11:06] <robsta> ya, gotcha
[11:07] <robsta> no problem if i nuke it, really
[11:07] <AfC> robsta: loss "not so important"; fair enough, but I am also interested in people being able to recover as much as possible. Perhaps no big deal for an project early days, but if this was 2 years on there would be bitterness
[11:07] <AfC> robsta: hard to be believed to be unbiased in this channel, but this really is quite rare around here.
[11:08] <lifeless> robsta: I think bug 256409
[11:08] <lifeless> same thing
[11:08] <lifeless> bumping to crit
[11:10] <AfC> lifeless: (if so, perhaps add into that quiet little list of things that might need to be back ported to 1.3.2 or whatever you are doing for the Ubuntu mob. Just a thought)
[11:10] <robsta> does "bzr remove-tree" touch my files?
[11:11] <AfC> yes
[11:25] <lifeless> robsta: ok
[11:26] <lifeless> robsta: is your project big ?
[11:26] <robsta> no
[11:26] <lifeless> take a backup
[11:26] <lifeless> if you can tar up your tree and repository I'll use that for diagnostics
[11:27] <lifeless> separately here is what I think is going on
[11:27] <lifeless> you've found a serious bug
[11:27] <lifeless> until I do a root cause diagnosis I can't say for sure exactly what is occuring
[11:27] <robsta> lifeless: email, bug attachment, web download?
[11:28] <lifeless> bug attachment is fine
[11:28] <lifeless> what I think you'll have to do is probably discard those 10 commits
[11:29] <lifeless> so, in a backup copy initially, just copy out using cp your entire source
[11:30] <lifeless> then use bzr uncommit to pop off all the commits since the one that errored
[11:30] <robsta> lifeless: attach to duplicate or original
[11:31] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/256409
[11:32] <lifeless> having done uncommit
[11:32] <lifeless> you should be able to just bzr commit again and have it work
[11:33] <lifeless> if it errors we'll look at workarounds, getting you to use 1.6rc1 etc
[11:42] <lifeless> robsta: how has that worked for you?
[11:43] <robsta> still on it, i'm so cackhanded with VCS
[11:43] <lifeless> this isn't your fault :)
[11:44] <lifeless> by uncommit I mean something like
[11:44] <lifeless> bzr uncommit -r -10
[11:44] <robsta> just did that
[11:45] <robsta> lifeless: now should i just do the same renamings again?
[11:47] <robsta> or do you mean in a single commit, rather?
[11:54] <robsta> in any case, my working tree after uncommit seems to be different from what it really was at that point
[11:54] <robsta> the deleted dir is not restored
[12:01] <lifeless> robsta: uncommit won't change your working tree
[12:01] <lifeless> robsta: 'revert' changes your working tree
[12:02] <lifeless> robsta: so your edits etc - including renames - are still in the working tree
[12:02] <robsta> lifeless: oh, so i just commit all at once
[12:02] <lifeless> yes
[12:02] <lifeless> and we cross fingers that it won't blow up again
[12:03]  * robsta a bit slow-witted
[12:04] <robsta> ok, thanks lifeless
[12:07] <lifeless> did that work ?
[12:08] <robsta> the commit went thru
[12:09] <lifeless> does 'bzr st' etc work ?
[12:09] <robsta> oh, check still bails
[12:09] <lifeless> where does it bail ?
[12:10] <lifeless> because the damaged commits are still in your repo
[12:10] <lifeless> so I would expect a fail; but the tree should be alright
[12:10] <lifeless> just pastebin the output ?
[12:11] <robsta> way back at one of the initial commits
[12:11] <robsta> did another renaming back then
[12:11] <lifeless> same issues?
[12:11] <robsta> looks like
[12:11] <lifeless> do you remember if it errored ?
[12:12] <lifeless> renames per se are actually trivial inside the code base
[12:12] <robsta> no error back then, AFAIR
[12:12] <lifeless> I'd like to see the error
[12:12] <robsta>  bzr check
[12:12] <robsta> bzr: ERROR: Revision {('rstaudinger@meqbuq-20080704140118-zfu9ft5a61y34252',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x85fa58c>".
[12:13] <robsta> shall i uncommit til then?
[12:14] <lifeless> that looks like the original error up above
[12:15] <lifeless> hang on a sec
[12:37] <cyberco> hi, I've accidentilly commited sensitive data. How can I undo that?
[12:38] <lifeless> bzr uncommit
[12:38] <lifeless> then tweak your tree as needed
[12:38] <AfC> (assuming you didn't also push those revisions outside of your immediate control)
[12:38] <cyberco> hi, thanks, but i've commited another revision afterwards (in which I removed the sensitive data)
[12:39] <cyberco> can I uncommit 2 revisions?
[12:39] <AfC> cyberco: yes
[12:40] <cyberco> I've pushed those revisions to a remote repository, but I can access that as well
[12:41] <AfC> cyberco: `bzr uncommit` twice, (or `bzr uncommit -r -3` which I just learned about 2 minutes ago :))
[12:41] <AfC> cyberco: that gets more serious
[12:42] <cyberco> can I just uncommit on the remote repository and pull in the changes locally again?
[12:42] <AfC> cyberco: you'll have to re-create the branch(es) in a new repository remotely, delete the original, and then replace it with the new one.
[12:43] <AfC> cyberco: uncommitting will merely change the state of your current branch. It will not remove revisions from the repository (as I understand it)
[12:43] <cyberco> maybe I can uncommit twice on both the remote and the local repositories?
[12:43] <lifeless> cyberco: for the remote repo, the easiest thing is to just remove the repo and repush
[12:43] <lifeless> robsta: revision 11 seems to be the issue
[12:43] <AfC> cyberco: you need to differentiate between "Branch" and "Repository" here.
[12:44] <cyberco> afc: sorry, you're right
[12:44] <AfC> cyberco: (if you understand the difference, then I don't need to go on. If you don't, then we need to go over it, as in this case it is important)
[12:44] <cyberco> afc: repushing will keep the history in tact (on the remote repository)
[12:45] <AfC> cyberco: so, for that side of things, a branch is a branch is a branch; all branches are ultimately peers
[12:45] <cyberco> ok, thank you very much, I'll try that
[12:46] <AfC> cyberco: so the answer to your question is "if you have the history locally (and of course you do) then [re] pushing to a new remote branch (more to the point, a branch in a new repository, shared or otherwise)  will transport that history"
[12:47] <cyberco> afc: great help! Thanks again
[12:49] <AfC> cyberco: as an example, I have a bunch of branches under one [shared] repository; the 'mainline' branch is revno 538 (though actually composed of 1358 revisions); however, if I do `bzr info -v` I see that the [shared] repository [at ..] has 1674 revisions in it. Some of that is other unmerged branches, but I bet most of it, though is uncommits :)
[12:53] <AfC> Hm. Is there a proper way to find out the number of revisions (ie, not revno) on a _branch_? I just did `bzr log | grep timestamp | wc -l` but that seems a bit hacky
[12:54]  * AfC has always thought that `bzr info -v` could do better to report this number under "Branch history" rather than the current left hand revno, which most of us are fairly abreast of
[12:55] <lifeless> robsta: so the added cbd directory in revision 11 is dud
[12:56] <lifeless> robsta: if you can sit tight for a day, I'll see if all the issues are on directories (fingers crossed) and if so write a fixup for you
[12:56] <robsta> lifeless: that'd work, much appreciated
[12:57] <lifeless> robsta: its 10pm here though
[12:57] <lifeless> so I don't recommend me doing it right now :)
[12:57] <awilkins> Not with your head full of Night Elf Mohawks
[12:57] <lifeless> :P
[12:57] <robsta> lifeless: nah, this is just a fun project
[12:57] <awilkins> Sucka!
[12:58] <lifeless> awilkins: actually, we just downed archimonde, now getting some BT done
[12:58]  * awilkins ducks as the WOW terms whoosh over his head
[12:59] <lifeless> don't start something you can't finish :)
[12:59] <awilkins> I finished playing EVE ages ago...
[13:00] <awilkins> No more MMORPG for me. Some Battlefield 2142 occasionally
[13:00] <rocky> yeah i recently gave up wow myself... mmorpg's are serious time sinks
[13:00] <rocky> lifeless: we just finished killing second boss in hyjal ... only been in BT once ;)
[13:00] <lifeless> gotta be careful
[13:01] <lifeless> balance in all things :)
[13:01] <spiv> AfC: "bzr ancestry | wc -l"
[13:01] <rocky> well... if you're raiding BT and finished up archimonde that takes serious dedicated raiding time... so balance... hmmm.... ;)
[13:02] <lifeless> rocky: dedicated aggregate time
[13:11] <lifeless> anyhoo
[13:11] <lifeless> night!
[13:11] <robsta> cheers lifeless
[13:15] <lifeless> oh one thing
[13:16] <lifeless> if you can figure out what bzr commands / shell commands you did on revision 10->11
[13:16] <lifeless> that might help me reproduce tomorrow
[13:16] <lifeless> cheers!
[13:16] <beuno> g'night lifeless
[13:37] <AfC> spiv: neat
[14:17] <awilkins> Anyonw know of an OSS UML modeller for Eclipse where 1 class == 1 file ?
[14:47] <ahasenack> beuno: hi, ar you planning on uploading bzr 1.5 for hardy to the ppa anytime soon?
[14:47] <ahasenack> are, sorry
[15:09] <beuno> ahasenack, it can't be uploaded due to a problem that occured. 1.6 will be uploaded as soon as it's released
[15:10] <ahasenack> beuno: can't you just bump the release number?
[15:10] <beuno> ahasenack, 1.6b2 was uploaded already
[15:10] <beuno> so we can't upload 1.5
[15:10] <ahasenack> ah, it sticks
[15:10] <ahasenack> even if there is no 1.6b2 there
[15:10] <beuno> yeah, sorry  :/
[15:10] <beuno> ahasenack, yeah, you can use the bzr beta ppa
[15:10] <beuno> lemme get the URL
[15:11] <dato> beuno: sometimes in debian we do stuff like 1.6b2.really.1.5-1
[15:11] <ahasenack> beuno: thanks
[15:11] <dato> (I'm guessing in ubuntu too :P)
[15:12] <ahasenack> beuno: I don't see bzrtools in the bzr beta ppa
[15:12] <beuno> ahasenack, https://launchpad.net/~bzr-beta-ppa/+archive
[15:12] <beuno> ahasenack, poolie is the one uploading currently
[15:13] <ahasenack> beuno: ok, so I should wait
[15:13] <beuno> dato, that would make sense, but the rc has popped up already, so it gog superceded, and moved, etc
[15:14] <ahasenack> dato: debian doesn't have something similar to "epoch" in rpm?
[15:14] <ahasenack> dato: deb, I mean
[15:14] <dato> beuno: yeah, at this stage is probably not worth it anymore.
[15:15] <dato> ahasenack: yes, it does have them, but we tend to dislike them if the issue can be solved with a (very) temporary hack.
[15:15] <dato> (because the hack disappears, but you carry the epoch forever)
[15:16] <ahasenack> I guess it's valid for beta and rc releases
[15:16] <ahasenack> the temporary hack, I mean
[15:17] <ahasenack> the wrong upload was on   	2008-05-17 though, quite temporary ;)
[15:17] <ahasenack> no, wait, 07-17
[15:17] <ahasenack> well, something like that
[16:34] <quicksilver> FYI, ghc considered bzr but opted for git
[16:34] <quicksilver> http://www.haskell.org/pipermail/glasgow-haskell-users/2008-August/015134.html
[16:38] <Toksyuryel> :(
[16:38] <luks> I'm glad I choose bzr before the trend of benchmarking VCS tools started :)
[16:46] <awilkins> The bzr benchmarks on the wiki are rather old
[16:46] <awilkins> I'm sure the performance has improved since then
[16:52] <evarlast> I find bzr to be easiest to use. It is also plenty fast.
[16:53] <awilkins> I agree ; the last release has got much faster on Windows too. It's rather embarassing when you switch to Linux though and find that some things literally occur before you lift your hands form the keyboard
[16:54] <evarlast> i've only used it on windows. :(
[16:55] <liw> while I rarely notice that bzr is slow, I am always happy to get more speed
[16:55] <liw> even when I'm not importing 60 gigs of source into one repository
[16:57] <awilkins> The new _win32_fast_walkdirs extension makes it whistle along on trees with lots of files
[16:57] <awilkins> I think that's in 1.6rc1 now
[16:58] <awilkins> A couple of core devs are now using windows so it's getting some sugar :-)
[16:58] <awilkins> Anyhow, train time
[17:07] <PeanutHead> Hey everybody, I need some help installing the bazaar's eclipse plugin
[17:09] <PeanutHead> I already ran "python setup-py build_ext -i"
[17:09] <quicksilver> we've been using bzr for two years
[17:09] <quicksilver> and yes, I do find it slightly slow for some things
[17:09]  * beuno pokes Verterok 
[17:09] <quicksilver> our repo has about 700 revisions in
[17:09] <quicksilver> probably about 1200 including merged revisions, actually.
[17:09] <quicksilver> and is rather small.
[17:09] <quicksilver> I can imagine it might be annoyingly slow for projects the size of GHC.
[17:09] <quicksilver> I love using it, though.
[17:10] <PeanutHead> it says that it is running the build_ext
[17:11] <PeanutHead> but then when I tried to run the bzr plugins, its says Unable to load plugin u'xmloutput_0_5_0' from u'C:/Program Files/Bazaar/plugins'
[17:11] <PeanutHead> does anyone know what is going wrong with that?
[17:12] <evarlast> quicksilver: did you upgrade to the newer bzr repo formats?
[17:13] <quicksilver> evarlast: yes
[17:13] <quicksilver> evarlast: and, that certainly improved things.
[17:13] <quicksilver> let me check.
[17:13] <PeanutHead> quicksilver: could you help me installing the bzr plugin for eclipse??
[17:13] <quicksilver> sorry, I've never tried that.
[17:13] <quicksilver> eclipse makes me feel queasy.
[17:13] <quicksilver> evarlast: Checkout (format: pack-0.92) apparently
[17:14] <PeanutHead> alright
[17:17] <evarlast> quicksilver: yes, pack-0.92 improved things greatly.
[17:18] <quicksilver> evarlast: bzr log still takes longer than I want it to.
[17:21] <pickscrape> There are plans afoot to speed those up though
[18:16]  * emmajane waves and has a question.
[18:16] <emmajane> I'm trying to get bzr up and running on dreamhost. I would have thought it'd be a very simple matter based on the instructions I found ( http://joshstaiger.org/archives/2007/01/bzr_on_dreamhos.html ), but when I try to run it, I get bzr: command not found.
[18:17] <emmajane> (i.e. after implementing the instructions)
[18:17] <Peng_> If you just want to push and pull to and from DreamHost, you don't need to install bzr..
[18:17] <emmajane> I have three machines that are all vaguely synced and which I log into directly on occasion to make fixes.
[18:18] <emmajane> (i.e. updates are made from three machines: sandbox (will become dev), dev (will become production) and laptop)
[18:18] <emmajane> I think it'll be easier if I have bzr on two of the three machines for what I want to do?
[18:21]  * emmajane goes back to figuring it out. :)
[18:22] <emmajane> Peng_: but thanks for the suggestion. I actually already have the push to dreamhost working.
[18:23] <Peng_> FWIW, I have bzr running on DreamHost successfully (last I checked -- I don't use it on DH much anymore). I'm using virtual-python.
[18:26] <emmajane> do you have one of the VPS machines, or just a standard account?
[18:27] <Peng_> Standard account.
[18:28] <emmajane> ah. I've got a VPS. Oh well. I'm sure I'll figure it out. :)
[18:28] <beuno> pickscrape, howdy
[18:31] <pickscrape> beuno: Good afternoon :)
[18:32] <beuno> pickscrape, how are you?
[18:32] <pickscrape> beuno: tired, but getting by. Yourself?
[18:33] <beuno> pickscrape, trying to get everything setup for my first day at Canonical, so a bit hectic  :)
[18:33] <beuno> I didn't get to your branch on saturday
[18:33] <beuno> did you do any further work on it?
[18:34] <Peng_> emmajane: The PSes are still the same environment, right? You don't have root access..
[18:34] <pickscrape> No. I had a quick look at the revno link thing, decided it was going to take longer than the time I had
[18:34] <pickscrape> But then thought about it again later and think it might be easier than I first thought
[18:34] <emmajane> peng_ it's fine, I've submitted a ticket to tech support. no worries. :)
[18:34] <Peng_> emmajane: A ticket about what?
[18:34] <beuno> pickscrape, cool. I'm going to work on it now, I just wanted to make sure I wasn't duplicating work
[18:35] <pickscrape> I think it might depend on the branch root thing too though, so it works in both cases.
[18:35] <emmajane> peng_ the fact that the install isn't working the way it ought to.
[18:35] <pickscrape> No, unfortunately I'm doing real work right now so I can't really work on it. Happy to talk though.
[18:35] <Peng_> emmajane: Err, wait, you probably just need to set your $PATH..
[18:35] <emmajane> peng_ I did that.
[18:35] <beuno> pickscrape, ok, I'll figure it out and re-ping you.  It
[18:35] <emmajane> peng_ I'm pretty good at following instructions...
[18:35] <beuno> pickscrape, it's part of my *real* work now  :)
[18:35] <emmajane> peng_ and that was part of the instructions.
[18:35] <pickscrape> Yeah, lucky you :)
[18:36]  * pickscrape is currently buried in PHP code
[18:36] <Peng_> emmajane: Those instructions only mention PYTHONPATH, not PATH.\
[18:37] <emmajane> peng_ it's fine, you can stop worrying about it. :)
[18:37] <Peng_> What if I don't want to stop worrying? :P
[18:38] <Peng_> emmajane: $ export PATH="~/bin:$PATH"
[18:38] <Peng_> emmajane: (or wherever you installed it)
[19:50] <beuno> mwhudson, ping
[22:47] <mwhudson> pickscrape, beuno: hi
[22:49] <pickscrape> mwhudson: hello
[22:50] <beuno> hi
[22:50] <beuno> mwhudson, did you take a peak at pickscrape's branch>
[22:50] <beuno> ?
[22:50] <mwhudson> yeah
[22:51] <mwhudson> so my first comment is that i think the breadcrumbs should probably be on all pages, not just the inventory page
[22:51] <beuno> I quite liked it
[22:51] <beuno> ah, interesting
[22:51] <mwhudson> i do like the basic idea, yes!
[22:51] <beuno> I can do that
[22:51] <mwhudson> i'm also not quite sure that the last 'crumb' should be a link
[22:51] <pickscrape> mwhudson: I noticed that while I was playing around. I was going to add it to them but didn't see the point until it was working properly on the inventory page first
[22:52] <mwhudson> pickscrape: fair enough
[22:52] <beuno> mwhudson, can you think of a good way to solve the I'm-serving-from-root problem?
[22:52] <pickscrape> As for the last crumb being a link, that's just laziness really :)
[22:52] <mwhudson> beuno: an if name == '/' in an appropriate place?
[22:53] <mwhudson> beuno: i haven't really looked at it though
[22:53] <beuno> mwhudson, name being?
[22:54] <mwhudson> i also worry slightly what this will do to non-serve-branches uses of loggerhead
[22:54] <mwhudson> like that launchpad thing i keep hearing about :)
[22:55] <beuno> mwhudson, I suppose we will have a hierarchy for that too
[22:55] <beuno> based on the config
[22:55] <pickscrape> mwhudson: name == '/' is all I thought it needed at first
[22:56] <mwhudson> pickscrape: oh, how does that go wrong?
[22:56] <pickscrape> There is an if statement in inventory_ui.py at line 80 that basically need to be filled in. It needs to know if loggerhead's root is a branch
[22:57] <pickscrape> Because if it is, the link to the root needs to be different.
[23:00] <mwhudson> so if the name of the branchwsgiapp object is '/', then the root is a branch
[23:00] <mwhudson> i think
[23:03] <pickscrape> By name do you mean 'friendly_name'?
[23:04] <mwhudson> maybe :)
[23:05] <mwhudson> on the phone now, biab
[23:06] <pickscrape> I just tried outputting that with a branch as the root and got the branch's nick
[23:10] <mwhudson> hm
[23:22] <mwhudson> right, i should look at the code again and stop speculating!
[23:23] <beuno> mwhudson, should pop up quickly, pickscrape even added a "if False" statement as a placeholder
[23:23] <mwhudson> i saw that much :)
[23:37] <gimaker`> Does anyone have a recipe for how to use rebase to shave off, say, the hundred first revisions of a branch? I haven't used rebase before and after reading the docs and fooling around with it I still don't understand how to do it.
[23:38] <lifeless> gimaker`: the first hundred?
[23:38] <lifeless> gimaker`: you'll need to init a new repository, then do rebase -r 100.. ../otherbranch
[23:41] <gimaker`> lifeless: bzr init purged, cd purged, bzr rebase -r100..<lastrev> /path/to/before/purge ?
[23:43] <lifeless> gimaker`: offhand, yes
[23:43] <lifeless> gimaker`: I'd need to give it a spin to tbe sure
[23:43] <gimaker`> lifeless: I'll try it out, hold on a sec
[23:45] <gimaker`> That didn't work, I get this error: bzr: ERROR: Requested revision: u'100' does not exist in branch: BzrBranch6('file:///tmp/purge/')
[23:46] <lifeless> oh, take a new branch, and do 'rebase --onto=100 -r 100.. .'
[23:46] <lifeless> I think that will do it
[23:49] <gimaker`> lifeless: should I do that from the empty (new) branch, or the original one?
[23:50] <lifeless> gimaker`: from a backup of the original one, I would say
[23:50] <lifeless> gimaker`: I never use rebase myself, so I'm just reading the docs and hoping :)
[23:51] <gimaker`> lifeless: well, we're in the same position then - except that maybe you have an ever so slight edge in interpreting the docs ;)
[23:53] <gimaker`> lifeless: I'm getting the same error again, no matter if I execute the command from the empty or the original branh
[23:55] <gimaker`> lifeless: I'm giving up for the moment, but thanks a lot for the help! Re-reading the docs after a good night's sleep might help in cracking this nut :)
[23:55] <lifeless> gimaker`: good luck