[00:00] <poolie> well
[00:00] <poolie> i'm not sure 'common' is the right measure, compared to
[00:00] <spiv> Maybe there's something involving graph logic that already would help bzrlib?
[00:01] <spiv> I mean,
[00:01] <poolie> if there are cases where we need it, how much trouble or friction or
[00:01] <spiv> maybe there's already an operation bzrlib does, or would like to do, that could benefit from this?
[00:02] <lifeless> sory about interruption
[00:02] <lifeless> hardy is not _that_ stable
[00:03] <lifeless> I'm saying that the structure I understand you to be heading towards is hand coded
[00:03] <lifeless> but needs on the wire the exact same degree of encapsulation
[00:04] <lifeless> so why not just define the encapsulation, then let the client and server use them as desired
[00:09] <spiv> Basically, the tradeoff is at the moment the encapsulation encoder/decoder has a pretty simple interface with the objects that use it, and there's a single place that knows things like "this message part is a body".  If we generalise, we push that work to the individual message handlers.
[00:09] <spiv> I guess that's manageable, but I'm also not sure it's work that we'll get much benefit from.
[00:10] <lifeless> well
[00:11] <lifeless> you could make sure the wire protocol is generalised
[00:11] <lifeless> and then only add api complexity as needed
[00:11] <spiv> Hmm.
[00:11] <lifeless> long as the error-handling cases the protocol object knows how to eat the entire entity we're good to extend it later.
[00:11] <lifeless> (extend in the python code I mean)
[00:12] <lifeless> so START, TUPLE|BODY+, END
[00:12] <spiv> Right, similar to the container format...
[00:12] <lifeless> where TUPLE and body are both self delimited
[00:12] <lifeless> and BODY is able to be ended_complete and ended_incomplete
[00:13] <lifeless> lol https://pqm.bazaar-vcs.org/ refuses to show in ff3
[00:14] <spiv> And if a body is ended_incomplete, then it can be followed by another TUPLE?
[00:14] <spiv> (as a convention)
[00:14] <lifeless> right
[00:14] <lifeless> but even if not we'll know it was incomplete
[00:15] <lifeless> and can error regardless
[00:15] <spiv> Well...
[00:15] <spiv> that's the sort of thing that bugs me :)
[00:15] <spiv> More options == more cases == more tests & work :P
[00:16] <lifeless> ok
[00:16] <lifeless> up to you
[00:17] <lifeless> I've exhausted my ideas on this, but it seems pretty clear to me that there are different layers here
[00:17] <spiv> It's not so much that that one part is a big concern, but it's the sort of thing that we're enabling with this plan.
[00:17] <jelmer> lifeless: wtf
[00:17] <jelmer> lifeless: maybe it was just bad timing
[00:18] <jelmer> but going to pqm.bazaar-vcs.org just crashed my kernel :-)
[00:18] <lifeless> jelmer: LOL
[00:18] <poolie> !!
[00:18] <spiv> Wow.
[00:18] <lifeless> jelmer: get a new kernel
[00:18] <poolie> Before You Die, You See...
[00:18] <jelmer> maybe it'll work better if I run a kernel out of bzr instead of out of git...
[00:19] <poolie> lifeless, i think it's a good point about the protocol
[00:53] <poolie> spiv, lifeless, i think we should allow for it in the protocol doc
[00:53] <poolie> the actual encoding iirc would already support this
[00:57] <spiv> brb, fixing a KnitCorrupt in Mary's PhD branch...
[00:58] <mwhudson> ouch
[01:16] <spiv> Newlines in filenames leads to broken inventory.knit...
[01:16] <radix> it seems the dapper packages of bzr on ppa don't work? they're complaining about not having python2.5 when I try to install them
[01:20] <poolie> radix, yes, it's bug 189915, i'm working on it
[01:21] <radix> poolie: cool, thanks
[01:23] <radix> fwiw, the reason it's not working for me is   bzr: Depends: python (> 2.5) but 2.4.2-0ubuntu3 is to be installed or
[01:23] <radix>                 python-celementtree but it is not installable
[01:24] <radix> which doesn't seem to be exactly what bug #189915 is talking about
[01:24] <ubotu> Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress] https://launchpad.net/bugs/189915
[01:46] <poolie> lifeless, what is the best address for the bzr packaging team?
[01:46] <poolie> ^branch
[01:46] <poolie> http://bzr.debian.org/pkg-bazaar/bzr/ubuntu/ ?
[01:48] <lifeless> http://bzr.debian.org/pkg-bazaar/bzr/unstable/
[02:11] <poolie> ok
[02:11] <poolie> the changelog for the pakcage i took from bazaar-vcs.org is somewhat diverged from that
[02:11] <poolie> starting with your "New bazaar-vcs.org build" on 3 dec
[02:22] <lifeless> poolie: yes, merged numerous times; but theres nothing in the bazaar-vcs.org devel-distro-release packags that wasn't sent back to bazaar-vcs.org
[02:22] <lifeless> possibly some dependency differences
[02:23] <lifeless> and the dapper package has the patch from the bzr list
[02:30] <lifeless> abentley: ping
[02:30] <lifeless> abentley: I'm looking for the branch nick on bb, I can't see it
[03:28] <LaserJock> anybody around who has experience using the cvs plugin for bzr?
[03:30] <abentley> lifeless: I think it's not there.
[03:30] <lifeless> LaserJock: do you mean cvsps-import ?
[03:30] <abentley> I assume you want the branch nick from the last-committed revision?
[03:30] <LaserJock> yes I guess that's the one
[03:31] <abentley> We do have the source branch location, if the user provides it.
[03:32] <LaserJock> lifeless: I'm assuming I can use cvsps-import to track a CVS repo
[03:33] <lifeless> abentley: yes, I'd like it to be visible
[03:34] <lifeless> LaserJock: I don't know if it can do incremental or not; it certainly doesn't have the logic to handle all the idiocies people can do to cvs like cscvs does
[03:35] <LaserJock> well, I've been using git-cvsimport and it seems to be working well
[03:35] <LaserJock> I'm just trying to figure out the bzr equivalent
[03:38] <lifeless> LaserJock: well cvsps-import is the plugin to examine
[03:39] <lifeless> I've used it for one-shot conversions very successfully
[03:39] <LaserJock> k
[03:45] <LaserJock> I have about 14 different VCS repos in CVS, SVN, bzr and I thought I might give it a go at trying to just use bzr for everything
[03:45] <LaserJock> Riddell keeps saying it's the only way to go :-)
[03:50] <lifeless> LaserJock: riddel is right :)
[03:51] <lifeless> bzr-svn will get your svn stuff beautifully
[03:51] <lifeless> for CVS, just one-shot convert and never look back
[03:51] <LaserJock> well, I don't own the CVS repos so I'll have to keep updating periodically
[03:51] <lifeless> ok
[03:51] <lifeless> have a look at it; or use the launchpad cvs service
[03:52] <LaserJock> hmm
[03:52] <LaserJock> actually one of them is already in launchpad
[04:11] <abentley> I wonder how hard it is to 0wn a CVS repo
[04:12] <lifeless> its ok security wise, if you like crunchy shell
[04:29] <thumper> what's a better merge type to use for criss-cross merges (in bzr 1.1) ?
[04:30] <spiv> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01212.html
[04:30] <spiv> thumper: --lca
[04:30] <thumper> spiv: so `bzr remerge --lca`?
[04:31] <spiv> thumper: yeah.
[04:32] <thumper> 7 conflicts -> 2 conflicts \o/
[04:33] <thumper> both of which were entirely valid
[04:33] <thumper> when is --lca becoming the default?
[04:33] <spiv> abentley: ^
[04:36] <poolie> lifeless, how can i avoid dpkg-source complaining about the binaries in the debian/.bzr directory?
[04:36] <lifeless> -x .bzr
[04:36] <poolie> ok, i have to give that every time?
[04:36] <lifeless> or use bzr builddeb to do most of the machiner for you
[04:37] <lifeless>    bzr builddeb --working --builder="pdebuild-$distro --override-config"
[04:37] <lifeless> thats how I built the packages
[04:38] <poolie> so to do that i should have the source in one branch, and the debian/ directory in another branch checked out below it?
[04:40]  * poolie reads the maunal
[04:42] <poolie> lifeless, so it looks like people are using it in "merge mode", since the packaging is alone in a branch?
[04:45] <abentley> thumper: I would give it another release cycle.  See I got this new job, and it's been a lot to learn all at once...
[04:46] <abentley> Unfortunately, there's some work needed before it's a complete replacement for merge3.  It doesn't do reverse-cherrypicks, and there's an edge case where it doesn't give a conflict when it should.
[04:57] <lifeless> later all
[04:57] <poolie> have a good weekend
[04:58] <abentley> lifeless: later
[04:59] <lifeless> poolie: you have mail; if you want a call ring now :)
[05:00] <poolie> thanks
[05:00] <poolie> no i don't think so
[05:00] <poolie> am just learning more about builddeb
[07:58] <appcine> hi! getting "bzr: warning: unknown encoding . Continuing with ascii encoding." every time I call bzr.
[07:59] <appcine> echo $LANG reports C
[07:59] <appcine> LC_ALL is not set
[07:59] <appcine> tried exporting LANG as sv_SE.UTF-8 too, still the same message
[07:59] <appcine> Mac OS X 10.5.2
[08:05] <Debolaz> Eww, UTF-8
[08:05] <Debolaz> Latin1++
[08:21] <ubotu> New bug: #188058 in bzr-gentoo-overlay "Launchpad transport error installing bzr-vimdiff-0_pre17 (dup-of: 181945)" [Medium,Incomplete] https://launchpad.net/bugs/188058
[08:34] <appcine_> So, I've pushed my source to my server -- bzr update doesn't work, what do I run to initialize?
[08:44] <kedmccabe> What's the best/recommended way to install bzr on OS X; easy_install or macports?
[08:51] <appcine> kedmccabe: Probably what you're most used to working with
[08:51] <appcine> I used ports .. because, well I use it for lots of things and it's easy to keep stuff updated.
[10:55] <rotty> how's the support for cherry-picking these times? bzr still does not track them, right?
[10:59] <dato> nope
[11:01] <rotty> :-/
[11:20] <lifeless> rotty: will be discussing this in the up coming sprint
[11:23] <rotty> so it could be implemented in the foreseeable future?
[11:38] <appcine_> How do you ignore all files in a certain directory? Like bzr ignore dir/*, but that adds all specific files to the .bzrignore file .. should I manually edit the file?
[11:38] <appcine_> :)
[11:39] <luks> I think bzr ignore 'dir/*' should work
[11:39] <luks> or "dir/*" on windows
[11:39] <luks> (to disable the * in the shell)
[11:40] <appcine_> sweet
[11:40] <appcine_> worked, thanks :)
[11:48] <appcine> can you remove all ".svn" directories from your project somehow?
[11:48] <appcine> I added them, and the ingored them .. now I want to remove them :P
[12:16] <Peng> appcine: If you're on *nix or something, that would be easy. 'find -name .svn -execdir bzr rm {} +' or something.
[12:28] <rotty> lifeless: I have an ideas for a new feature: tracking the currently-checked-out revision, so when you do "bzr get -r FOO", a subsequent "bzr status" will compare against the revision FOO and not HEAD
[12:28] <rotty> does that make sense?
[12:30] <dato> jelmer: ping?
[12:30] <jelmer> dato: pong
[12:31] <dato> jelmer: I have a situation, and I'd like to know whether rebase could help. well. situation. I commited some stuff over a revision that I didn't thought it was there...
[12:31] <dato> how much would I need to write to make rebase re-commit the good ones on top of $BAD-1
[12:31] <dato> I don't mind a dirty+ad-hoc solution
[12:32] <jelmer> well, there's also the "replay" command that's part of rebase
[12:32] <dato> oh
[12:32] <dato> ooh
[12:32] <jelmer> if you check out $BAD-1 then you can just run "bzr replay -r<revision-to-replay>"
[12:33] <dato> right
[12:33] <dato> thank you
[12:33] <jelmer> for $BAD+1
[12:38] <dato> I get a conflict, whereas I think I shouldn't get one
[12:38] <dato> $BAD touches foo1.py
[12:39] <dato> and $BAD+1 is a merge that does not touch foo1.py
[12:39] <dato> ?
[12:40] <dato> jelmer: ^
[12:46] <fullermd> rotty: Err?  get == branch; it does do that...
[12:47] <rotty> fullermd: but "revert -r" doesn't, does it?
[12:48] <hallu> hello, i'm running into a repository compatibility problem with bzr hosted on launchpad.
[12:48] <fullermd> Well, what you'd want for that use case isn't revert, it's "update -r".
[12:48] <hallu> i used svn-import to create a new branch on my machine.
[12:48] <fullermd> Which comes with a minor hitch.
[12:48] <hallu> then i push it onto launchpad
[12:49] <hallu> but bzr co complains that KnitPackRepository is not compatible with RemoteRepository...
[12:49] <rotty> fullermd: according to "bzr update --help", update doesn't have that option "-r"
[12:49] <fullermd> rotty: That's the minor hitch   8-}
[12:50] <hallu> i should say: I push it *first* and that works, then I try *bzr co* and that fails.
[12:51] <dato> oh well, I used WorkingTree.commit for $BAD+1. replay did $BAD+2,3 fine
[12:52] <rotty> fullermd: is this implemented in bzr HEAD?
[12:52]  * fullermd shakes his head.
[12:56] <fullermd> rotty: https://bugs.launchpad.net/bzr/+bug/45719
[12:56] <ubotu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed]
[13:18] <appcine> Peng: Ah, yes. I'm on unix. Something like the find-command might work, but {} doesn't print the path to the file .. know how to do that? :)
[13:20] <Peng> appcine: It doesn't? What? Depending on your shell, you might need to escape it.
[13:20] <appcine> find . -name .DS_Store -execdir echo {} +
[13:20] <appcine> prints: .DS_Store .DS_Store .DS_Store
[13:20] <appcine> bash on os x
[13:21] <appcine> ah
[13:21] <Peng> appcine: Yeah, exactly. execdir 'cd'es to the directory and then executes it.
[13:21] <Peng> appcine: It's supposed to be safer. Shrug.
[13:21] <appcine> Peng: Hmm, hehe.. let me try again .. bzr reported that .DS_Store didn't exist
[13:22] <appcine> with --exec it worked
[13:23] <appcine> Peng: Nevermind me. I'm just sloppy. It works just fine.
[13:23] <appcine> Thanks for the tip
[13:32] <rotty> fullermd: where can I get a recent version of this patch?
[13:33] <rotty> (the repos mentioned in the report don't apply to current HEAD anymore)
[13:34] <fullermd> I don't think there is one.
[13:35] <rotty> :-(
[14:01]  * fullermd ponders.
[14:02] <fullermd> I guess poolie's long since gone for the night...
[14:09]  * lamont wonders when bzr 1.2.0 will hit the ppa
[14:10] <LarstiQ> lamont: it did yesterday
[14:10] <LarstiQ> or well, the buildds and then failed
[14:10] <lamont> it's not there....
[14:10] <LarstiQ> so eh yeah, can't use it yet :)
[14:12]  * lamont notes the lack of a debian directory in the tarball, too
[14:14] <LarstiQ> lamont: which one, upstream?
[14:14] <lamont> launchpad.net/bzrtools/...
[14:15] <LarstiQ> I'm not clear on what you mean, but fwiw there are something like 4 different debian dirs needed
[14:15] <LarstiQ> since dapper/etch/sid are all different enough that there is no universal packaging (yet?)
[14:16] <lamont> most people tend to package something that's the latest...
[14:17] <LarstiQ> as the Bazaar project, debs for all those distributions need to be made
[14:18] <LarstiQ> anyway, I haven't been involved in that area for a while now
[14:42] <lamont> heh.  it took longer to test the backport to dapper/edgy than it did to do it.
[15:14]  * fullermd wonders whether 1.2 is officially released.
[15:15] <fullermd> I see the file, but I haven't seen any announcements.
[15:16] <ubotu> New bug: #145811 in nautilus-python "python-nautilus: Feisty: Python script's methods seem to be not called by extension." [Undecided,Fix released] https://launchpad.net/bugs/145811
[15:18]  * rotty is annoyed that the "update -r" patch has been abandoned
[15:19] <fullermd> Here's your number; there's the line   :p
[15:19] <rotty> unfortunatly, I'm not able to forward-port the patch, as I don't have knowledge of bzr internals
[15:20] <Peng> I have an entirely off-topic quandary: I created a GPG key for myself 5 days ago. I had a copy of my private key on a server I don't own the whole time. Should I be paranoid and revoke it or not? I'm not using it for much so it would be no big deal if I did revoke it.
[15:22] <fullermd> I s'pose it depends on how much you trust whoever has root on it.
[15:24] <Peng> Also, if I ever got a VPS, I might need to put the private key on it, which would be just as bad...
[15:25]  * fullermd shrugs.
[15:25] <fullermd> Any hardware that anybody else ever has physical access to is insecure and untrustworthy if you're paranoid enough.
[15:26] <Peng> I'm trying to find the right level of paranoia.
[15:30] <johnny> and the changelog needs to be updated for 1.2 too..
[17:50] <radix> is there any recent .deb of bazaar that works on dapper?
[17:55] <Peng> radix: https://launchpad.net/~bzr/+archive ?
[17:55] <Peng> Huh, Hardy and Dapper are the only ones that have had their 1.2rc1 debs built.
[17:55]  * Peng wanders off.
[17:57] <radix> Peng: the dapper debs from ppa are broken
[17:57] <radix> they depend on python2.5
[18:00] <Peng> Oh.
[18:00] <Peng> Nice.
[18:00] <Peng> I dunno nothin' then.
[18:00]  * Peng wanders off.
[18:00] <Peng> Sorry I couldn't help.
[18:32] <jdong> Are the bazaar-vcs.org branches going to be packs?
[18:32] <jdong> I notice that they're still dirstate/knits currently
[18:34] <beuno> jdong, bzr.dev has been in packs for a while now
[18:34] <beuno> beuno@beuno-laptop:~/bzr_devel/bzr.dev$ bzr info http://bazaar-vcs.org/bzr/bzr.dev/
[18:34] <beuno> Standalone branch (format: pack-0.92)
[18:35] <jdong> beuno: what? no way
[18:35]  * jdong questions his sanity
[18:36]  * beuno questions it too  :p
[18:36] <jdong> beuno: oh I see my idiocy
[18:36] <jdong> beuno: I looked at bzr.1.2
[18:36] <jdong> not bzr.dev
[18:36] <beuno> jdong, I think 0.92 and on have been in packs on bzr.dev. Especially since at that poing packs<>knits operations where painfully slow
[18:37] <jdong> WOW the performance difference with packs over HTTP is very noticeable
[18:38] <beuno> jdong, yeap, lifeless and jam did an amazing job at it  :D
[18:38] <beuno> and I understand the smart server has improved greatly too
[18:38] <jdong> yeah I'm impressed at dumb http alone
[18:38] <jdong> I haven't branched something big from HTTP since packs came about
[18:39] <beuno> I think the "less amounts of round-trips" was the key
[18:39] <jdong> right, that's always been the case
[18:39] <beuno> gazillion knits vs a dozen packs
[18:40]  * beuno wonders why the 1.2 branch is in knits...
[18:40] <beuno> and no poolie around...  :/
[18:41] <jdong> beuno: yeah the 1.2 branch took nearly 5 minutes to get, while I just grabbed dev in under a minute
[18:41] <jdong> and looking @ how it's 85MB, most of that time would've been simply network transfer
[18:42] <beuno> jdong, I'll send an email to the list and see if it just got forgotten or if there is a good reason for it
[18:42] <jdong> beuno: cool
[18:42] <beuno> thanks for the heads up!
[18:42] <jdong> anytime
[18:51]  * jdong reconciles bzr.dev for fun
[18:52] <beuno> jdong, if it's in packs, it should be fairly fast. Knits, on the other hand, might take a while. I have 3gb branch that took 40+ hours to reconcile on a AMD 4000+ dual core
[18:53] <jdong> beuno: yeah right now the packs are taking over 10 min to reconcile, looks CPU bound
[18:53] <jdong> oh well, i twas for fun anway
[18:54] <beuno> jdong, you can also run "bzr check" if you feel like making the CPU sweat a while  :p
[20:00] <mw> someone should change the topic to mention 1.2
[20:02] <johnny> and add a changelog entry
[20:02] <johnny> on the site
[20:06] <mario_limonciell> is there no way to pass bzr through an authenticating proxy?
[20:09] <mario_limonciell> it would seem according to bug 83954 that the support should be there
[20:09] <ubotu> Launchpad bug 83954 in bzr "Error while using "bzr branch" through proxy" [Undecided,Fix released] https://launchpad.net/bugs/83954
[20:20] <ubotu> New bug: #156299 in bzr "bzr bash completion error (compgen: --: invalid option)" [Wishlist,Confirmed] https://launchpad.net/bugs/156299
[21:09] <mtaylor> GARRRRR
[21:10]  * mtaylor hates that Branch.open_containing() returns a tuple and not a branch. 
[21:10] <mtaylor> just FWIW
[21:59] <treeform_> hey my network is just awful but i need to copy a big bzr repo (300mb) to a server it always disconnect while doing it
[22:00] <treeform_> is there a way to zip up the repo and rsync it there?
[22:02] <beuno> treeform_, "pull" has resume integrated
[22:02] <beuno> you can of course just rsync the folder
[22:02] <beuno> and/or zip it
[22:02] <beuno> you don't need anything special
[22:03] <treeform_> beuno, does push has resume integrated?
[22:04] <beuno> treeform_, I'm not 100% sure, but I don't see a reason why not
[22:04] <treeform_> it always errors out with a python stack trace so i think it bzr just crashes
[22:04] <beuno> treeform_, what version of bzr are you using?
[22:05] <beuno> if it's spitting out a traceback it should be a bug
[22:05] <treeform_> 1.1
[22:05] <treeform_> sorry i would post the trace back but i dont have it
[22:05] <beuno> treeform_, would you happen to have a traceback handy that you can paste somewhere?
[22:05] <beuno> ah, right
[22:05] <treeform_> i will run it again just wait about 10 min
[22:05] <beuno> well, just plain rsyning the dir will work just fine
[22:06] <treeform_> but the dir is about 600mb
[22:06] <treeform_> with the .bzr 300mb and the contents is 300mb
[22:06] <beuno> treeform_, can you run "bzr info" and see what repository type it is?
[22:06] <beuno> treeform_, I suppose you can rsync the .bzr directory and then just do "bzr revert"  (which is sort of what bzr branch would do)
[22:07] <beuno> zip up .bzr, rsync that, unzip, "bzr revert"
[22:07] <beuno> (I'm sure there are better solutions though)
[22:07] <treeform_> as long as that works
[22:08] <treeform_> "Standalone tree (format: pack-0.92)"
[22:08] <treeform_> oh my format is lower version
[22:09] <beuno> treeform_, that's the latest version
[22:09] <treeform_> i been using bzr since .14 and never had reasons to upgrade but it looks like i did at .92
[22:09] <treeform_> oh ok
[22:10] <treeform_> i think i needed to upgrade it because some one could not read it
[22:10] <fullermd> That seems unlikely...
[22:10] <beuno> treeform_, if they have a pre 0.92 version than they might not be able to read packs
[22:10] <treeform_> ok but i am up todate?
[22:11] <beuno> treeform_, if you have bzr 1.1 and are using the packs repository, yes
[22:11] <treeform_> ok thanks
[22:11] <beuno> np
[22:12] <fullermd> 1.1?  Jeez, that's SO yesterday...
[22:13] <treeform_> fullermd, i should upgrade?
[22:13] <beuno> fullermd, :p
[22:13] <beuno> treeform_, 1.2 is out _today_
[22:14] <beuno> so 1.1 is _yesterday_
[22:14] <beuno> upgrading is always recommended, but you're good at 1.1
[22:14] <treeform_> oh i just installed 1.2 on the server
[22:14] <treeform_> that is how it crashes http://dpaste.com/35397/
[22:15] <beuno> treeform_, it says you're using bzr 1.0
[22:15] <beuno> and, a release candidate
[22:15] <treeform_> ok 1.2 it is
[22:16] <beuno> I'd recommend upgrading to at least 1.0 final
[22:16] <beuno> treeform_, your traceback says: bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (linux2)
[22:17] <treeform_> yes it does
[22:17] <treeform_> i am sure i am wrong
[22:19] <treeform_> grr installing it also fails http://dpaste.com/35399/
[22:22] <treeform_> i got my current bzr is the latest in my repos
[22:24] <rthalley> Assume we have a centralized shared repository for product foo.  directory "foo" has been bzr init-repo'd.  we then make branch "foo/head", and do work.  Now, getting reading for a release, we bzr branch foo/head foo/release-1.0.  Question: is there any way to see what branches are available within foo?  (within bzr, that is...)
[22:28] <mtaylor> rthalley: not that I know of
[22:28] <mtaylor> rthalley: but a simple ls of foo will give you some idea
[22:29] <vin> how does the bzr_access script work? I've added set up the .ssh/authorized_key file. Do I just invoke the script with the appropriate parameters?
[22:29] <abentley> rthalley: bzrtools provides a "branches" command that lists the branches under a given location
[22:37] <rthalley> thanks, that's handy.  now a "best practices" question...  let's say we now finish foo-1.0 and ship it.  do I tag foo/release-1.0 to indicate the version that was released?  Do we worry about people still being able to commit to foo-release-1.0?
[22:52] <jdong> is it clean to clean .bzr/repository/upload by hand or is there a tool for it?
[22:52] <jdong> s/clean/safe/
[22:53] <mneptok> jdong: sounds like my dating career
[22:54] <jdong> mneptok: that probably explains the global shortage of nitrile gloves :)
[22:55] <jdong> some little developing conscience in my head is telling me I shouldn't go into .bzr with /bin/rm and whack out things I don't think belong :D
[23:01] <foom> whatcouldpossiblygowrong
[23:02] <jdong> lol well ASS-U-ME-ing that nothing is uploading to the location, I would expect the 35MB of packs in upload to be simply in-transit cut-connection junk
[23:03] <abentley> jdong: you can't break your repository by removing the contents of upload.
[23:03]  * jdong saves this chat log ;-)
[23:03] <abentley> If someone was in the middle of uploading, you might cause their upload to fail with a nasty error.
[23:04] <jdong> awesome
[23:04] <jdong> this one branch I have, I regularly commit to it via a crappy connection... it's nearly double its pristine size because of cruft in upload
[23:05] <jdong> I'm wondering if bzr should have a command for dealing with cruft like that?
[23:05] <abentley> Well, perhaps robert can fix that, but it's not an open-and-shut case like obsolete-packs.
[23:06] <jdong> granted, else it would've been naturally fixed already
[23:06] <jdong> btw if you haven't heard yet, packs rock :)
[23:06] <jdong> I am astounded by the performance difference over plain HTTP
[23:07] <jdong> now if there's only a way for LP to upgrade all branches to packs rather than me having to sftp them.
[23:07] <abentley> Yeah, I did see your talk in the scrollback.
[23:08] <jdong> yeah, you guys really came through for me. That was just about the last complaint I had about bzr :)
[23:08] <abentley> jdong: You would not believe how snowed-under the launchpad-bazaar team is.
[23:08] <abentley> I don't think we'll have time for nice-to-haves in the near future.
[23:08] <jdong> I can imagine :(
[23:08] <jdong> oh well scrape-and-loop time :)
[23:09] <jdong> if there's one skill I've learned in my time around Ubuntu, it's how to abuse Launchpad :)
[23:09] <abentley> But create a blueprint, and then we'll at least have it in the system.
[23:09] <jdong> yeah, I'll do so in a sec
[23:10] <fullermd> Seems like "smart server upgrade verb" would fill that niche pretty well.
[23:10] <jdong> well the thing is...
[23:10] <jdong> I don't think $average_lp_user knows or cares what the heck a pack is.
[23:11] <jdong> and I don't think people are aware in general of this massive speedup. LP should be more active in telling owners of branches to upgrade to packs
[23:22] <abentley> Where would you suggest we tell people about packs?
[23:27] <mtaylor> when was rich-root-packs added?
[23:28] <lifeless> jdong: yes it should and I think there is a bug open for htat
[23:28] <lifeless> mtaylor: 1.0 IIRC
[23:29] <lifeless> mtaylor: bzr help formats or so should say
[23:29] <lifeless> also bzr should start nagging soon
[23:29] <mtaylor> lifeless: thanks
[23:49] <beuno> anyone up to helping me brainstorm what tests I should include with the automatic plugin thingie?   I've got working code and would like to strap on the tests and send to the list for initial review
[23:53] <abentley> beuno: You should test all the commands you add, and the major functions you add.
[23:53] <abentley> I'm not sure whether you're doing network stuff.  That can be annoying, but you should be able to run your own server if necessary.
[23:53] <beuno> abentley, the problem is that I'm not actually adding any commands at this point, just catching unknown commands and checking to see if another plugin provides it
[23:54] <abentley> Okay, so you should be testing the command-line functionality you've added.
[23:58] <beuno> abentley, right, I got that far. The question is a bit more specific. I should make the test execute a command that I know will be caught as a plugin and test if the output is correct?  Maybe also commands that I know will be unknown and make sure they are still unknown?
[23:58] <abentley> Yes.
[23:59] <abentley> You don't necessarily have to do exhaustive tests of the commandline.
[23:59] <abentley> But that's pretty key functionality.