[00:51] <Verterok> moin
[01:58] <lifeless> abentley: walked in the door this morning
[01:59] <abentley> I got back in Toronto last night.
[02:02]  * Odd_Bloke smells the beginnings of a lifeless/abentley duet.
[02:04] <abentley> Odd_Bloke: I actually do write songs.  If we're doing for an ABAB rhyme scheme, some possible rhymes are "warning", "scorning" and "a-borning"
[02:06] <lifeless> abentley: I think yawning
[02:16] <brink_> Time to turn off the light.
[03:29] <igc> bbiab
[03:51]  * igc lunch
[04:48] <abentley> jelmer: IMO, hard links are not a problem, even if the files they refer to are in the same directory.  Operations that change files through TreeTransform always perform a safe replacement-- they don't overwrite file contents.
[04:52] <abentley> So they automatically break hard links when the linked files are modified.
[04:59] <igc> bbl
[09:33] <piem> hi all
[09:33] <piem> how should i move a repository from my laptop to my server?
[09:36] <snod> with push
[09:37] <snod> the exact protocol depends how you can connect to your server (sftp, ssh, ftp)
[09:39] <piem> snod: so i should bzr push foo://, then rm local repo, and then bzr checkout foo:// ?
[09:39] <snod> öhm
[09:40] <snod> why do you want do delete your local repo?
[09:40] <piem> snod: because i want to move it, as in cp + rm :-)
[10:08] <piem> if i don't move the old branch away, i don't know how to merge from the updated branch i pushed earlier
[10:12] <lifeless> 'bzr merge'
[11:06] <snod> is it possible with bzr, to substitute some variables in a file you're commiting with the the revno for example?
[11:08] <Kinnison> https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion
[11:09] <snod> thank you
[11:10] <piem> Kinnison!! :)
[11:10]  * piem hugs Kinnison
[11:10]  * Kinnison hugs piem. Ça va?
[11:11] <piem> bien! and you?
[11:12] <Kinnison> pas mal.
[11:16] <quik__> hey folks
[11:16] <quik__> if I bzr push to an sftp location
[11:17]  * rjek awaits the rest of the question :)
[11:18] <quik__> I try to checkout from the location to grab the code ... I get "bzr: ERROR: Not a branch: "
[11:20] <quik__> how can I pull a copy of my code, similar to svn export in subversion?
[11:21] <quik__> and it puts bzr: ERROR: Not a branch: /home/ben/test/sftp:/myserver.com/projects/projectname
[11:21] <quik__> yet my command was
[11:22] <quik__> bzr checkout  -r 1 sftp://myserver.com/projects/projectname
[11:22] <quik__> rjek: any ideas?
[11:23] <snod> i think the path is wrong
[11:23] <quik__> I copied it from where I pushed the repo
[11:24]  * rjek is interested in why there's sftp:/myserver in the path in the error.
[11:24] <rjek> Which is entirely wrong.
[11:24] <quik__> how else would I check it out
[11:24] <quik__> ?
[11:25] <dato> is paramiko installed?
[11:25] <quik__> no.
[11:25] <dato> install it :)
[11:25] <dato> you need it to use sftp
[11:25] <quik__> I installed bzr with apt-get
[11:25] <snod> but how could you push it to a sftp location without the lib?
[11:25] <quik__> I guess it would help if it had it as part of the package
[11:26] <dato> snod: maybe he pushed from a different machine
[11:26] <quik__> correc
[11:26] <quik__> correct*
[11:28] <quik__> after installing paramiko I got "bzr: ERROR: unknown branch format: Bazaar Branch Format 6 (bzr 0.15)"
[11:28] <quik__> so I guess I have different versions..
[11:28] <quik__> that really blows
[11:28] <dato> you have < 0.15?
[11:29] <quik__> Bazaar (bzr) 0.92.0 and bzr (bazaar-ng) 0.8.2
[11:29] <quik__> between the two system
[11:29] <dato> 0.8 is very old
[11:30] <quik__> its ubuntu packages
[11:30] <dato> but if you really can't upgrade
[11:30] <quik__> I could install from source I guess
[11:34] <snod> na
[11:35] <quik__> snod: how can I skip the silly error?
[11:36] <Ng> fwiw, the bazaar website has packages for ubuntu of more recent versions
[11:37] <snod> quik__: triy one of these https://launchpad.net/~bzr/+archive/
[11:38] <snod> the repositories listed on the mainpage don't have the latest version
[11:38] <snod> (for ubuntu)
[11:38] <snod> there is backport for debian stable on backports too
[11:39] <quik__> yey
[11:39] <quik__> that worked.
[11:39] <quik__> I updated it to 1.0-rc1
[12:13] <mikl> What is the best web-frontend for bzr? Still loggerhead?
[13:40] <ubotu> New bug: #161082 in bzr-svn "very hard to get going on windows" [Medium,In progress] https://launchpad.net/bugs/161082
[14:19] <encompass> is there some documentation on how to setup your work to be ready to packaged?
[14:24] <encompass> sabdfl: greets
[14:25] <sabdfl> hey encompass
[14:29] <encompass> Have you seen my latest work?  http://launchpad.net/memaker
[14:29] <encompass> It's going to be a part of macslows brilliance
[14:29] <igc> night all
[14:30] <encompass> igc: gn
[16:06] <encompass> I want to build packages of memaker, and ubuntu-motu told me there was a way to easily beuild packages with bzr...
[16:06] <encompass> this sounds interesting, how is this done?
[16:08] <encompass> The reason I ask is that we have no packagers and it would be nice if we did, or had some way of doing it easily ourselves
[16:14] <jelmer> encompass: have a look at the bzr-buildpackage package
[16:14] <jelmer> sorry, bzr-builddeb
[16:20] <encompass> jelmer: thanks... that is a start :D
[16:35] <mtaylor> encompass: bzr-builddeb is the best thing in the world
[16:46] <mtaylor> abentley: you're running hardy, right? do you get segfaults when trying to run /lib/cpp ?
[16:47] <abentley> mtaylor: I'm running Gutsy.
[16:47] <mtaylor> oh
[16:47] <mtaylor> hrm
[16:47]  * mtaylor is going crazy
[17:08] <andersson> encompass: Make deb-template with command dh_make (Think you find it in package devscripts) Make the package "CDBS" = Common Debian Build System. Then you're on your way
[17:08] <andersson> + have a look at how to make a "native" package with bzr-builddeb as mtaylor said
[17:16] <Nice27> hi
[17:19] <slangasek> is it ok to ask questions here about bzr best practices wrt packaging branches on launchpad.net?
[17:22]  * slangasek skips a pebble across the placid IRC channel
[17:22] <jelmer> I think so, though launchpad-related things may be more appropriate in #launchpad
[17:25] <dato> oh, slangasek, heh
[17:25] <slangasek> jelmer: well, my question is in regards to https://wiki.ubuntu.com/BzrMaintainerHowto, which seems to somewhat punt on the question of using bzr-svn for registering packaging-only bzr branches
[17:26] <slangasek> I'm unsure whether this is worth the effort, vs. just maintaining an ubuntu branch if I don't expect to be merging much from debian (it's for a package that the debian maintainers consider obsolete)
[17:27]  * jelmer has a look at that wiki page
[17:28] <jelmer> slangasek: It shouldn't be much of an effort to start with a branch imported from svn
[17:28] <slangasek> well, ok
[17:28] <jelmer> I don't see why you would necessarily have to register the upstream debian branch
[17:29] <slangasek> but if I wasn't working with the packaging-only svn branch, I guess I would probably do a branch for the full source tree?
[17:29] <jelmer> you can just "bzr branch svn://url-to-debian-package/ ubuntu"; cd ubuntu; hackety-hack; bzr push lp:...
[17:29] <slangasek> right - but if I'm going to do that, maybe it's better to branch from the upstream source, do a one-time add of all the debian packaging, and bzr push?
[17:30] <slangasek> (I'm increasingly disenchanted with packaging-only branches myself)
[17:30] <jelmer> slangasek: There doesn't appear to be a consensus about whether to use packaging only bzr branches
[17:30]  * jelmer prefers the full tree, but I know various people here who use packaging-only branches
[17:30] <slangasek> jelmer: ok, setting aside the consensus -- are there good /tools/ for working with packaging-only branches? :)
[17:31] <slangasek> i.e., how does one handle patch systems within a packaging-only branch in a non-suck manner?
[17:31] <jelmer> well, you can use dpatch or quilt like you're used to
[17:32] <slangasek> yes, but to actually manipulate the patches within, the parent dir of your packaging branch needs to be a source tree
[17:33] <jelmer> You can rename the branch to "debian" and put it in the source tree and manipulate the patches that way
[17:33] <jelmer> I've never done that though, this is one of the reasons why full source trees work better
[17:34] <slangasek> right - I've done that in the past, I think it sucks because it means moving my checkout around every time I'm unpacking a new upstream version
[17:34] <slangasek> (hmm, not that there's likely to be a new upstream version of this package either, but still :)
[17:35] <jelmer> another way to use a full-source bzr branch and be able to merge from the debian packaging-only svn branch is to use "bzr join"
[17:36] <slangasek> o-ho
[17:36] <slangasek> that sounds like what I was just about to ask for :)
[17:37] <slangasek> so then I can bzr branch the upstream, bzr branch the debian subdir, and bzr join?
[17:38] <jelmer> yep, that's the idea
[17:38] <slangasek> awesome
[17:38] <slangasek> yes, /exactly/ what I was going to ask for :-)
[17:38] <jelmer> and "bzr merge <debian-svn-url>" will still work then and do the right thing
[17:39] <jelmer> you'll have to use the rich-root(-pack) format for this to work
[17:39] <slangasek> bzr branch seems to (reasonably) decline to branch from the debian subdir though
[17:39] <slangasek> bzr: ERROR: /grub/trunk/debian is not a valid Subversion branch path.
[17:39] <jelmer> try removing ~/.bazaar/subversion.conf and trying again
[17:40] <jelmer> that'll be fixed in bzr-svn 0.4.7
[17:40] <slangasek> cool, seems to be working
[17:41] <jelmer> abentley: Hmm, I just stated that merging will work here but I'm doubting now. Will it?
[17:42] <abentley> jelmer: haven't read the context.
[17:42] <jelmer> abentley: merging from a branch with a root id that is not a root id in the branch that we're merging into
[17:43] <jelmer> abentley: but is present (as regular directory)
[17:43] <abentley> That should work just fine.
[17:43] <jelmer> sweet
[17:48] <slangasek> ok, the join fails because of a wrong repo format...  bzr upgrade says I'm at the most recent... how do I get a tree that's dirstate-with-subtree as required by 'join'?
[17:49] <dato> upgrade --rich-root or --rich-root-pack (if you're on pack-0.92) would be best
[17:49] <dato> upgrade --dirstate-with-subtree is the other option, but it's experimental and shouldn't be needed, as per what jelmer said
[17:50] <slangasek> works, cheers
[17:50] <dato> (nb, rich-root requires >= 1.0, -subtree >= 0.15)
[17:59] <jelmer> time to make rich-root-pack the default..
[18:24] <abentley> It's a bit disturbing to see people using join, since that's a hidden command.
[18:24] <jelmer> abentley: I thought join was considered stable now
[18:25] <jelmer> abentley: and only join --reference was still experimental?
[18:25] <abentley> Join without --reference is the only thing that's experimental.
[18:26] <jelmer> but join --reference is only usable with with-subtree formats, no?
[18:26] <abentley> But I haven't made --reference hidden, so the whole command's hidden.
[18:27] <abentley> jelmer: true, it's only usable with -subtree.
[18:27] <jelmer> abentley: is there a negative missing in your previous line?
[18:27] <jelmer> s/without/with/ I mean
[18:28] <abentley> jelmer: no, but "it" refers to "--reference"
[18:28] <mtaylor> if I have a repo with tons of branches
[18:28] <mtaylor> and I want to upgrade to rich-root-pack
[18:28] <mtaylor> do I need to upgrade each branch, or will upgrading the repo do it?
[18:29] <jelmer> abentley: so which bit became stable when you added the rich-root format?
[18:29] <dato> mtaylor: just the repo, for this one upgrade
[18:30] <jelmer> abentley: I vaguely recall there as some nested-tree feature that became non-experimental
[18:30] <abentley> jelmer: join-by-value has been stable since before I implemented subtree formats.
[18:30] <abentley> join-by-reference is still experimental.
[18:30] <mtaylor> dato: awesome. thanks
[18:31] <jelmer> abentley: Ahh, so there was actually a negative missing
[18:31] <jelmer> abentley: thanks
[18:32] <abentley> A negative missing from what?
[18:32] <jelmer> "19:25 <abentley> Join without --reference is the only thing that's experimental."
[18:32] <abentley> Oh, yes, that should be "with"
[18:33] <jelmer> abentley: If we would hide --reference, would you be ok with making "bzr join" visible?
[18:33] <abentley> But when you mentioned my "previous line", I thought you meant 01:26:50 PM) (abentley: jelmer: true, it's only usable with -subtree.
[18:33] <abentley> jelmer: sure
[18:33] <jelmer> ahh, sorry
[18:33] <jelmer> I think slangasek's use case is one of the areas where by-value nested trees can be very useful
[18:34] <jelmer> s/areas/examples/
[18:35] <abentley> I haven't seen his use case, but I can well imagine there are uses for join.
[18:36] <abentley> It's just upsetting when people are just randomly using things you've hid to protect them.
[18:36] <jelmer> sorry, I didn't know join was still hidden
[18:36] <jelmer> I'll see if I make that patch to hide --reference
[18:37] <abentley> Cool.  I'm not sure whether Option supports a hidden flag.
[18:38] <abentley> Btw, the "split" command is not hidden now.  That may be what you were thinking of.
[18:38] <jelmer> ah - yep, that may be what confused me
[18:39] <jelmer> I tend to think of them as complementing each other
[19:01] <RainCT> Hi
[19:02] <RainCT> I need a fast way to know what the current revision of a local branch is (for a script). What do you recommend?
[19:04] <RainCT> cat .bzr/branch/last-revision   ?
[19:04] <aidos> hi everyone
[19:05] <aidos> i'm currently trying to switch from svn to bazaar, and i have a couple of questions
[19:06] <aidos> any bzr gurus around?
[19:06] <jelmer> aidos: hi
[19:06] <aidos> hi jelmer. can i bother you then? :)
[19:07] <jelmer> RainCT: "bzr revno" ?
[19:07] <jelmer> aidos: just ask your question, I'm sure there's somebody who can answer
[19:07] <aidos> jelmer: ok
[19:08] <RainCT> jelmer: Ah :). But cat + cut is faster, is there anything I should know that makes 'bzr revno' better?
[19:08] <aidos> so here's one of my main problem: I 've set up a bazaar repo with different project at the root, each of them with it's own /dev /trunk /merge as suggested in the bazaar documentation
[19:08] <jelmer> RainCT: it works across formats
[19:08] <dato> RainCT: it's resilient against branch format changes
[19:09] <aidos> how can i retrieve all the trunks of all the projects without having to do a branch for each project ? like a "bzr multi-branch"
[19:11] <RainCT> jelmer, dato: okay, thanks :)
[19:11] <aidos> because in SVN i had all these projects in the same repo, so a svn checkout got me all the sources I needed. but i figured it 'll be pretty stupid and broken to put all the projects in the same branch in bazaar, but now i kinda really annoyed....
[19:12] <aidos> sorry for the long reads :)
[19:12] <jelmer> aidos: I don't think there's any way to do that yet
[19:12] <jelmer> I've actually complained about that as well
[19:13] <RainCT> aidos: if you use Launchpad and Ubuntu, if all the branches are owned by the same team, I think there's a a script in package ubuntu-dev-tools that does this.. I'm not sure thought.. let me check
[19:13] <aidos> sadly my projet is not open source, so launchpad is not a option :)
[19:13] <RainCT> ah :(
[19:14] <jelmer> RainCT: that sounds interesting
[19:14] <aidos> yeah. but thanks. I guess i'll write my own script then
[19:14] <aidos> and is nested branch an option?
[19:14] <aidos> nested branchES*
[19:15] <RainCT> jelmer: it's there. get-branches (by dholbach) :)
[19:16] <jelmer> aidos: by-reference nested trees are still experimental
[19:16] <jelmer> RainCT: hmm, unfortunately I'm on Debian..
[19:17] <RainCT> jelmer: http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/
[19:19] <aidos> jelmer: have you come up with any other tricks to solve that?
[19:19] <jelmer> aidos: you can use something like rsync
[19:20] <lifeless> moin
[19:21] <aidos> jelmer: true. hadn't thought of that.
[19:22] <aidos> jelmer: or even simply sftp ? since that's what i'm using with bazaar.
[19:24] <dysinger> need to ask a question about shared repositories.  If I create one and then check some branches out into it and etc....  Should I do --no-trees or is that something for a shared repo on a server like git clone --bare ?
[19:25] <dysinger> I think that's right
[19:25] <asabil> dysinger: yes
[19:25] <dysinger> ok
[19:25] <asabil> the --no-trees is to be used on servers willing to save some disk space, by not having any tree in the repository
[19:26] <dysinger> So If I am going to push multiple sibling branches to a server via sftp, should I create a shared repo --no-trees on the server for them to leverage pack-sharing ?
[19:26] <jelmer> RainCT: the default ubuntu-dev-tools branch has syntax errors in get-branches
[19:27] <RainCT> really? xD
[19:27]  * RainCT never tried it..
[19:29] <asabil> dysinger: a shared repo yes, --no-trees should be ok to reduce the disk space usage
[19:29] <dysinger> kthx
[19:29] <asabil> dysinger: also maybe you want to push over bzr+ssh:// instead of sftp://
[19:29] <dysinger> ok
[19:29] <dysinger> As long as I have bzr on the server ssh is more efficient that way ?
[19:30] <asabil> that will require you to  install bzr on the server though, but will make the push damn faster
[19:30] <dysinger> isn't ssh:// the same ?
[19:30] <dysinger> (same as bzr+ssh:// ?)
[19:30] <asabil> not sure if ssh:// exists
[19:30] <dysinger> ok maybe I am thinking of git
[19:31] <lifeless> we don't support 'ssh://' urls, just bzr+ssh
[19:31] <lifeless> ssh:// indicates you want a terminal
[19:31] <lifeless> whereas we want a bzr process on the other end
[19:31] <dysinger> ok
[19:32] <jelmer> and it would be very confusing since we support bzr+ssh:// and svn+ssh:// :-)
[19:32] <jelmer> one day also git+ssh:// hopefully..
[19:32] <asabil> that's something I always liked about bzr : true extensibility
[19:34] <dysinger> I like the extensibility too - that and the windows compat are +2 for me - I use mac and linux but there is always one person on windows on my team.
[19:35] <dysinger> Jelmer - did you enter the bug on subversion for the certificate acceptance problem we found with subversion 1.5 / bzr-svn stable ?
[19:35] <dysinger> Could you send me the link so I can watch it?
[19:35] <dysinger> I am using a hacked bzr-svn stable with the provider commented out of transport.py
[19:36] <dysinger> It seems to work but I still get asked for authentication everytime even though "svn info xxxx" has already cached it (FYI)
[19:40] <dysinger> Another common problem I have been seeing is that some svn projects have a structure where the trunk is on trunk/projectname but then the branches are just named branches/this-or-that and tags tags/some-version.   It seems bzr-svn thinks trunk/project name is a single-trunk and can't deal with the tags or branches.  If I change it to be branching-scheme trunk then the branches and tags work but I cant update trunk ever again with it like tha
[19:41] <jelmer> dysinger: I've just fixed that in the 0.4 branch
[19:41] <dysinger> the provider thing?
[19:41] <jelmer> dysinger: No, the last problem you mentioned
[19:42] <dysinger> ah - do I need to change my subversion.conf ?
[19:42] <jelmer> dysinger: It'll allow you to branch in those situations but won't allow merging between those branches unless you explicitly set the branching scheme
[19:43] <jelmer> I haven't looked into the SSL certificate bug yet
[19:43] <dysinger> okthx
[19:52] <lifeless> jam: http://unicode.org/notes/tn5/#FCD may interest you
[19:52] <lifeless> jam: http://osdir.com/ml/network.gnutella.limewire.core.devel/2003-01/msg00000.html claims that FCD is what OS X use, all claims of NFD aside
[21:20] <jam> lifeless: thanks for the pointer, but I'm about 90% sure that Mac isn't FCD
[21:20] <jam> Specifically, the FCD link claims that:
[21:20] <jam> A-ring          (A)(ring)          NFC, FCD
[21:20] <jam> u'\xb5' is valid NFC and FCD, but I'm sure it isn't valid on Mac
[21:25] <foom> hfs+ hardcodes a table
[21:25] <foom> see http://developer.apple.com/technotes/tn/tn1150.html#UnicodeSubtleties
[22:08] <dysinger> Is there a gitk or tig -like program for bzr to review in detail each commit with a diff window?
[22:10] <jelmer> dysinger: bzr viz ?
[22:14] <bialix> jam: help needed
[22:14] <lifeless> hi bialix
[22:14] <bialix> hi lifeless
[22:15] <bialix> is it possible to cancel merge request in PQM queue?
[22:17] <bialix> lifeless: ^
[22:23] <bialix> too late. heh
[22:25] <dysinger> looks like my question was discussed here http://www.nabble.com/Gitk-for-Bzr--td14855458.html
[22:25] <dysinger> how would I grab bzr viz ?  home page ?
[22:26] <dysinger> I can't see much from google or search on bazaar's home page
[22:26] <bialix> dysinger: look for bzr-gtk
[22:27] <dysinger> ah
[22:27] <bialix> see http://bazaar-vcs.org/Plugins
[22:27] <bialix> it's called bzrk
[22:30] <dysinger> I know it's not important but I would like to see some sort of tig-like UI for the console.
[22:30] <dysinger> I don't want to install GTK / bzr-gtk with mac ports - mac ports sucks.
[22:30] <ubotu> New bug: #186829 in bzr-webserve "problem occurred in a Python script" [Undecided,New] https://launchpad.net/bugs/186829
[22:31] <dysinger> TIG is a ncurses interface to GIT that simple and easy - let's you browse branches / history / diffs etc.
[22:31] <dysinger> anyway
[22:31] <dysinger> Plus then I would have to run X just to fire up bzr-gtk on mac too
[22:32] <dysinger> I know you guys are on Ubuntu full time so my comments are not important.  :)
[22:32] <dysinger> But having a ncurses UI is awesome IMO
[22:33] <asabil> dysinger: yes it would be awesome, the issue is basically that ncurses is not that nice to program with
[22:33] <dysinger> I live in the terminal
[22:34] <asabil> dysinger: maybe you can try bzr-gtk in the mean time, or try qbzr
[22:34] <asabil> or you can install loggerhead on one of your servers and use the webview
[22:34] <dysinger> both of those have huge dependencies if you aren't already on linux
[22:35] <asabil> dysinger: osx ?
[22:35] <dysinger> y
[22:35] <asabil> macports works for me
[22:35] <dysinger> well half and half - I am on ubuntu on the other half
[22:35] <bialix> what about Urwid framework for this stuff?
[22:36] <asabil> dysinger: you can also try loggerhead
[22:36] <dysinger> ok
[22:36] <asabil> it is web based
[22:36] <dysinger> urwid looks good
[22:36] <dysinger> I wish I was a python guru - I'd try to whip something up
[22:37] <dysinger> but - *cough* - ruby, jruby, java, etc has me busy already.
[22:37] <bialix> I'm thinking about porting Urwid on Windows
[22:37] <bialix> because ncurses is not working on Windows
[22:38] <asabil> hmm urwid looks great
[22:39] <bialix> we try to use it in our linux project
[23:26] <igc> morning
[23:38] <beuno> lifeless, ping
[23:40] <beuno> well, anyone else who has a few minutes, I want to blog about how people should upgrade from knits > packs, to make it a bit more widespread and would like a review before I mis-inform planet ubuntu  :D   http://www.pastebin.ca/876675
[23:40] <beuno> igc, maybe you'd like to take a crack at it?  :D
[23:41]  * igc looks ...
[23:42] <beuno> (blog post has links to stuff and all that, just not sure how to make drafts visible for others)
[23:43] <Odd_Bloke> beuno: In (01), you effectively say 'while bzr devs know about packs'.  You probably want to add something to the effect of 'most normal users may not'.
[23:46] <Odd_Bloke> Also, some people using bzr-svn may be using rich-root-pack or somesuch and not realise that they're already using packs.  You may want to change "(or anything different than format: pack-0.92)" to "(or anything without 'pack' in the name)".
[23:46] <Odd_Bloke> Or just add a disclaimer somewhere about bzr-svn. :p
[23:47] <igc> beuno: the first sentence needs to be clearer I think
[23:47] <igc> I'm also not 100% sure about how to upgrade shared repos ...
[23:48] <igc> I think you need to upgrade each branch using the repo, not just run upgrade on the repo
[23:48]  * igc checks ...
[23:49] <beuno> right, first phrase needs clearing, yes. On it!
[23:49] <beuno> Odd_Bloke, yes, although I want to keep it as simple as possible, so I might have to add a warning for bzr-svn users
[23:50] <beuno> might end up being too confusing
[23:51] <lifeless> beuno: there is documentation about all this, in doc/developers/pack.txt or something like that
[23:51] <beuno> igc, according to the doc, shared repos are updated that way: http://doc.bazaar-vcs.org/latest/developers/packrepo.html#upgrading-an-existing-branch-or-repository-to-knitpack-format
[23:52] <igc> beuno: checking the doc, just upgrading the repo looks ok, at least if all branches are > 0.17
[23:52] <beuno> lifeless, I'll take a look at it now
[23:52] <beuno> does the text seem sane enough?   I'd also like to see if it can go on planet bzr and on planet debian  :D
[23:53] <igc> beuno: to get your blog included on Planet Bazaar, email or ping poolie
[23:53] <beuno> lifeless, seems that's where I got the information from already
[23:55] <igc> beuno: by "go to the branches folder", I assume you mean "go to the branch's folder", i.e. the folder for the branch
[23:56] <igc> otherwise sweet
[23:56] <beuno> igc, that's right. Fixed too
[23:56] <beuno> lifeless?  you're the pack-man :p
[23:59]  * beuno also knows lifeless is on planet debian, which would have it posted on all 3 major planets