[00:00] <spiv> jml: no, I'm thinking it'd be good enough if we could tell Launchpad to mirror a branch in (just) the latest format.
[00:01] <jml> spiv: hmm.
[00:01] <spiv> In this case, people that need the older format could use the non-Launchpad URL.
[00:01] <jml> spiv: that feels really clunky to me.
[00:01] <spiv> I mean, if LP wants to keep multiple copies for maximum convenience, that's fine with me too ;)
[00:01] <spiv> Yeah, it would be a bit.
[00:02] <spiv> It was just a random to push the work onto you rather than us ;)
[00:02] <spiv> s/random/random idea/
[00:02] <jml> spiv: I can't help feeling that the real solution is for Bazaar to settle down a little with its formats :)
[00:02] <spiv> Well, yeah.
[00:03] <Peng_> Good luck with that. :P
[00:05] <spiv> Hmm, now that LP supports 1.9 branches, someone needs to upgrade our PQM's bzr...
=== jamesh_ is now known as jamesh
[00:29] <awilkins> Hmm. When are we removing non-rich root formats ;-)
[00:33] <garyvdm> spiv: I think you were right about my test repo's not been packed the same.
[00:33] <garyvdm> I did some more testing - an I'm now seeing faster results with 1.6 repos :-).
[00:34] <garyvdm> Thanks
[00:35] <spiv> garyvdm: yeah, the interesting comparison is old code vs. new code on the exact same repo.
[00:36] <spiv> garyvdm: 1.9 should be faster than 1.6, for instance, although packing has a significant impact.  A fully packed repo will be much better than a repo with 10s of pack files (unless you're extremely lucky), etc.
[00:36] <garyvdm> spiv:I've still got a repo that is faster on the old code - but packed repos are faster on the new code.
[00:37] <spiv> garyvdm: (although as I improve the smart server the number of pack files is increasingly unimportant when using the smart server (to the client anyway))
[00:37] <spiv> garyvdm: ah, hmm.  That's interesting.  1.6 format?
[00:38] <spiv> garyvdm: "interesting" as in "not what I think should happen" :)
[00:38] <garyvdm> spiv: Yip - which made me think it was to do with the format.
[00:38] <garyvdm> But after I copied an packed it the new code is faster than the old code.
[00:39] <spiv> garyvdm: would you mind pastebinning the new code?
[00:39] <garyvdm> I'm busy pushing the branch - Will let you know when it's finished.
[00:39] <spiv> It's good that it's faster on a fully packed repo, but I'm quite surprised that it's worse on a not fully packed repo.
[00:42] <garyvdm> spiv: http://bazaar.launchpad.net/~qbzr-dev/qbzr/threadless-throbber/annotate/567?file_id=liblogmodel.py-20080624153442-csesbwmxg0s8db2x-1
[00:42] <garyvdm> line 959
[00:44] <spiv> garyvdm: you never update keys!
[00:44] <spiv> garyvdm: you remove found keys from revision_ids, but you're calling get_record_stream with (keys,)
[00:44] <garyvdm> Ah
[00:44] <spiv> garyvdm: that explains the performance oddities perfectly :)
[00:45] <spiv> garyvdm: when there's only one pack file that doesn't matter, and when there are multiple it'll do too much work.
[00:45] <garyvdm> Ok - Let fix that and test it.
[00:46] <spiv> Make keys a set(), and use .difference_update is my recommendation :)
[00:46] <spiv> Oh, hmm, you're doing one at a time.  Just calling .remove seems reasonable, then.
[00:53] <garyvdm> spiv: That would not affect the performance if you are only opening 1 repository.
[00:53] <garyvdm> It
[00:53] <garyvdm> It
[00:53] <garyvdm> It only loops if you have more than one repo.
[00:53] <spiv> garyvdm: oh right, that's what I meant.
[00:54] <spiv> garyvdm: hmm, you're testing against a single repo?
[00:54] <garyvdm> Yes
[00:54] <spiv> Weird.
[00:54] <garyvdm> But thanks for picking up the error.
[00:54] <jml> spiv: this looks like a bzr bug... https://answers.edge.launchpad.net/launchpad-bazaar/+question/54791
[00:56] <spiv> jml: it does.
[00:58] <jml> spiv: can you help them out?
[00:58] <jml> (I can't see how to move questions to other projects)
[00:58] <spiv> jml: it turns out that "Edit question" can do that, so I did it.
[00:59] <spiv> And asked for more information.
[00:59] <jml> thanks.
[01:46] <cody-somerville> komputes, Hey David
[01:49] <komputes> cody-somerville: hey man, how is it to be back home?
[01:49] <cody-somerville> Not too shabby.
[01:49] <cody-somerville> Glad to be back in Canada
[01:49] <komputes> true. true.
[01:49] <cody-somerville> btw, I heard that the USB plugs WILL be used for game controllers in the future :]
[01:50] <komputes> cody-somerville: I forsaw it
[01:50] <komputes> cody-somerville: and the screens probably run on windows since it took like 30 minutes to boot up
[01:50] <komputes> cody-somerville: so you were right ;)
[01:51] <komputes> cody-somerville: tried to tell you but you were fast asleep
[01:52] <cody-somerville> lol
[03:37] <igc> hi all
[03:52] <markh> g'day ian!
[04:06] <garyvdm> Hi markh
[04:06] <garyvdm> I've been very busy with lp:~qbzr-dev/qbzr/threadless-throbber
[04:06] <markh> hi garyvdm - awesome :)
[04:07] <garyvdm> I'll write a nice email about what I've done. But right now I need to go to sleep - it 5am....
[04:07] <markh> eeek :)  I'll look forward to it - I'll try and pull it later this arfternoon
[04:07] <markh> sleep well!
[07:03] <vila> hi all
[07:33] <igc> hi vila
=== doko_ is now known as doko
[08:34] <fm> is bzr able to save http passwords by now?
[08:34] <fm> see https://bugs.launchpad.net/bzr/+bug/103029
[08:34] <ubottu> Launchpad bug 103029 in bzr "use .netrc" [Medium,In progress]
[08:40] <fm> this is solved as in http://doc.bazaar-vcs.org/bzr.dev/developers/authentication-ring.html
[08:58] <vila> fm: saving http passwords is not implemented but I'm about to submit a patch to use .netrc as read-only credentials store
[08:58] <vila> Anyway, you can already put your http passwords into authentication.conf *today*, in clear
[09:06] <vila> urgh, looks like my DNS serverS are down :-( Can someone read me here ?
[09:15] <Jc2k> vila: yeah, but i suspect my pong took so long it doesnt matter
[09:16] <awilkins> CTCP PING reply from vila: 0.585 seconds
[09:18] <fm> vila: i am perfectly fine with storing in authentication.conf
[09:21] <loxs> folks, how can I ignore the whole contents of a folder? (what is the .bzrignore directive for that?)
[09:23] <bob2> the dirname
[09:27] <LeoNerd> An ignored directory automatically ignores all the contents within it
[09:36] <loxs> bob2, LeoNerd you mean ONLY the dirname (without a relative path to it?)
[09:37] <LeoNerd> E.g.   echo "tmp/" >>.bzrignore
[09:37] <LeoNerd> Or even without the trailing /
[09:39] <loxs> LeoNerd, well, I have two directories that have the same name (they are in different places of the tree). how do I tell it to ignore one of them, but include the other?
[09:40] <bob2> have you tried it?
[09:40] <bob2> (full path relative to the root)
[09:40] <loxs> yes, then it includes that directory
[09:41] <loxs> (the ignore doesn't work)
[09:42] <bob2> ./
[09:45] <loxs> yes, this works, thanks
[10:03] <LeoNerd> loxs: If an ignore pattern contains a / it is matched against the full path from the root. If not, it matches just the basename
[10:03] <LeoNerd> So 'tmp' matches tmp wherever it is found, but './tmp' matches only on the tree root
=== `6og is now known as Kamping_Kaiser
[10:43] <vila> Jc2k, awilkins : thanks, things are back to normal...
=== andreas__ is now known as ahasenack
[12:52] <Necoro> is it possible to convert a branch from some rich-root-format into into one w/o?
[12:54] <MvG> Hi! I've got a branch of a project's trunk here, and a feature branch up to date with the tip of trunk. I would like to generate a patch matching the latest release of the trunk. How would I do this? Do I have to branch corresponding versions from each into new branches for this purpose?
[12:55] <MvG> By the way, is there a feature to take a working tree back in history? the update command doesn't seem to do this, as I'd have expected from svn.
[12:55] <bob2> 'bzr send -o your.patch' in the feature branch
[12:56] <bob2> assuming it was branched from trunk
[12:56] <MvG> bob2: Patch won't apply due to changes made to trunk after the release.
[12:57] <bob2> ?
[12:57] <bob2> bzr send /generates/ a patch (well, bundle) between the two branches
[12:57] <AfC> MvG: `bzr pull -r` will take you back. You may need --overwrite. BE WARNED that you'd better have the branch elsewhere if you do this, otherwise you will shoot yourself in the foot (and have to go hunting for the tip).
[12:59] <MvG> AfC: Thanks. So this not only takes the working tree back, but the branch as well. I guess in that case I'd rather checkout an older revision into a new dir.
[12:59] <AfC> MvG: that's what you're encouraged to do, yes
[12:59] <AfC> but s/checkout/branch/
[12:59] <AfC> or same problem
[12:59] <MvG> bob2: Yes, but the patch generated won't apply against the released copde and is thus not much use.
[12:59] <MvG> AfC: OK.
[13:00] <MvG> Is there a way to create a branch without working tree? bzr branch doesn't seem to have an option for it.
[13:00] <bob2> MvG: what do you want it against?
[13:01] <bob2> oh, some revno
[13:01] <MvG> bob2: Against a given revision in trunk, and probably from a given revision in my feature branch that is closest to this, so as to avoid collisions.
[13:04] <jelmer> Necoro: no, this is not possible
[13:05] <Necoro> jelmer: ah ok -- what is the reason by the way to still differentiate between these two?
[13:06] <Necoro> has rich-root some issues?
[13:11] <jelmer> Necoro: rich root is newer and contains more information (versioning information for the branch root)
[13:11] <jelmer> it will become the default at some point in the future
[13:11] <Necoro> ok - so no disadvantage (except having to type -rich-root when upgrading repo-format) :)
[13:11] <AfC> Necoro: correct
[13:12] <Necoro> good :)
[13:12] <Necoro> thx for the info
[13:12]  * Necoro heads to class
=== jelmer is now known as Guest73702
=== Guest73702 is now known as jelmer
[14:20] <Peng_> Is it just me, or does doing "bzr init-repo --1.9-rich-root && bzr init --1.9-rich-root" in a directory create a branch 6 branch, when it should be branch 7?
[14:20] <Peng_> Is that wrong?
[14:24]  * Peng_ kicks branch --stacked.
[14:24] <Peng_> Is it possible to create a stacked branch without a working tree?
[14:24] <Peng_> And why won't it use a shared repo?
[14:25] <jelmer> it's probably a bug
[14:25] <Peng_> Peng_'s first experience with stacking is very disappointing. :\
[14:26] <Peng_> Actually, I have a habit of accidentally creating working trees anyway (I did it three times once!), but this time I really don't want to. My disks have suffered enough.
[14:27] <Peng_> And it also used --1.6.1-rich-root instead of --1.9-rich-root.
[14:27] <Peng_> Which isn't surprising since it ignored the repo..
[14:28] <Peng_> Augh! Now I got "BzrCheckError: Internal check failed: record_stream refers to compression parents not in KnitVersionedFiles" again!
[14:28] <Peng_> This is all just to work around that stupid corrupt repo anyway.
[14:29] <Peng_> I'm going to go watch TV. /me glares at bzr.
[14:29] <Peng_> And this is reminding me that I _still_ haven't filed a bug about that corrupt repo in the first place. Coughcough.
=== sdboyer-laptop__ is now known as sdboyer-laptop
[14:52] <awilkins> There's support for http passwords in authentication.conf, but I think it's a bit broken
[14:52] <awilkins> Oops, old line
[14:53] <Peng_> jelmer: Oh, it's bug 274021, which you filed. :P I noticed bug 292553 too, but I'm not sure I think it's a bug.
[14:53] <ubottu> Launchpad bug 274021 in bzr "bzr init ignores format argument when creating branch inside of shared repository" [Undecided,Confirmed] https://launchpad.net/bugs/274021
[14:53] <ubottu> Launchpad bug 292553 in bzr "Format "unnamed" when creating "default" branches in newer repository formats" [Medium,Triaged] https://launchpad.net/bugs/292553
[14:54] <Peng_> jelmer: Oh, never mind, you were referring to one of the other things.
[14:54]  * Peng_ is confusing himself now.
[14:55] <Peng_> Wny don't stacked branches use shared repos? Is that intentional?
[14:55] <MvG> Just a crazy idea: has anyone thought of implementing a bzr plugin to treat mediawiki setups as foreign branches? There are files that get modified, there is a revision history with authors, dates, comments, ... I don't think I'd have actual use for this, and I won't implement it myself, but still I think the idea is funny enough to share.
[14:56] <jelmer> MvG, the tricky bit is the history
[14:56] <jelmer> MvG, since you need the history of the full mediawiki "branch", not just of some files
[14:56] <NfNitLoop> does the shared repo format have some requirement that all history be present?
[14:56] <NfNitLoop> aah.
[14:56] <jelmer> Peng_, Is the shared repo in a stacked-compatible format?
[14:56] <MvG> jelmer: I believe deleted articles might proove tricky as well, as wikis can actually loose information.
[14:57] <Peng_> jelmer: Yes.
[14:57] <jelmer> MvG, other than that, it's certainly doable I think for smaller wikis
[15:18] <Peng_> jelmer: Why do you format bzr-svn's __version__ yourself instead of using bzrlib._format_version_tuple or something?
[15:19] <jelmer> _format_version_tuple is not part of the public bzr api
[15:19] <Peng_> Oh, good point.
[15:19] <jelmer> and I need this before I actually check compatibility
[15:20] <Peng_> Currently _format_version_tuple doesn't like your version_info (because it uses "rc" instead of "candidate"), which makes tracebacks messy.
[15:20] <Peng_> But if bzr-svn's version_info was changed to use "candidate', that would make the __version__ really long.
[15:20] <Peng_> (Well, not tracebacks, just the .bzr.log of tracebacks.)
[15:20] <vila> awilkins: If you know about bugs in authentication.conf not filed in lp now is a good time to file them :)
[15:21] <jelmer> vila: Hi!
[15:21] <jelmer> Peng_, I'll try to remember to use 'candidate' next time
[15:21] <vila> jelmer: hey ! Long time we weren't in the same TZ it appears :) Or at least online at the same time :)
[15:22] <jelmer> vila: yeah, indeed. How's it going?
[15:22] <vila> jelmer: I'm preparing a patch that should make it easy to create pluggable credential stores (read-only as a first step)
[15:22] <jelmer> vila: Ah, cool
[15:22] <vila> That should make it possible to write one for svn able to provide user/passwords to bzr
[15:23] <vila> ..and finally address that 401 notorious bug :-/
[15:25]  * jelmer is looking forward to seeing the last of that :-)
[15:25] <jelmer> Once some of this http auth stuff has been improved, I'd like to have a look at supporting WWW-Authenticate: Negotiate
[15:27] <vila> jelmer: hmm, so far we support Digest and Basic and try Digest first, what's the need ?
[15:28] <jelmer> vila: it's required for Kerberos authentication
[15:29] <vila> Do you have some docs describing that for the http part ?
[15:31] <awilkins> vila: Yes, just that one earlier
[15:32] <awilkins> vila: I made a crude hack for it and you mentioned that you'd be fixing related things
[15:32] <jelmer> vila: http://www.apps.ietf.org/rfc/rfc4559.html
[15:32] <awilkins> vila: I don't necessarily like it provoking a 401 before it will try to find cached authentication
[15:33] <vila> jelmer: thanks, bookmarked
[15:33] <jelmer> vila: We only would have to care about WWW-Authenticate: Negotiate if the server sends it to us in a 401 reply
[15:34] <vila> jelmer: sure, the infrastructure is in place for new http auth schemes in _urllib2_wrappers.py
[15:34] <vila> awilkins: sorry what bug are you referring to ?
[15:35] <awilkins> vila: I'm not sure I had a bug for it, hold on
[15:35] <awilkins> https://bugs.launchpad.net/bzr/+bug/300347
[15:35] <ubottu> Launchpad bug 300347 in bzr "HTTP transport does not use authentication.conf unless you supply a user name." [Medium,Confirmed]
[15:36] <awilkins> Theres a bundle in there I fixed it with too ; but as noted, rather naive
[15:37] <vila> awilkins: ha ! That one ok, but that's not the right approach, bug #...wait a minute
[15:38] <vila> A patch has been proposed for bug #256612 on the list, a bit closer but still incomplete
[15:38] <ubottu> Launchpad bug 256612 in bzr "should handle 401 (unauthorized) response" [High,Triaged] https://launchpad.net/bugs/256612
[15:40] <vila> I have patch above that one that will make http accept authentications sections *even* if no user is specified in the url, that's a silly limitation I never realized was there and the patch for #256612 gave me one of those wtf, I'm soo stupid moment :)
=== sabdfl1 is now known as sabdfl
=== enigm1 is now known as enigma42
=== kfogel is now known as ns2
=== ns2 is now known as kfogel
=== abadger19991 is now known as abadger1999
[18:08] <tseliot> hi all, I would like to keep my packages in separate branches which would share everything but the debian/ directory. Is there a way to do this?
[18:08] <tseliot> stacked branches, perhaps?
[19:01] <Thomas_Zahreddin> hi, is somebody able to help me with bazaar? I've created a repo with 14 commits, this is the main branch. I have some source code i want to make a branch, this code is most similiar to revision 11 of the main branch. This code i want to update (suppose merge is the right command) to the actual version of the main branch, but also want to keep the specialities of this customiced source code.
[19:02] <Thomas_Zahreddin> I've been sitting long with some tutorials and the handbook page - the examples do not realy fit for me since I'm working solo :-)
[19:03] <AmanicA> I think you should keep your main code in one branch and you custom code in a seperate branch
[19:04] <Thomas_Zahreddin> AmanicA: exactly that is my plan, but i don't know how to do this
[19:04] <AmanicA> bzr init main_code; bzr init custom_code
[19:05] <AmanicA> then you have 2 separate directories for you code
[19:05] <Thomas_Zahreddin> ok,
[19:06] <Thomas_Zahreddin> done
[19:07] <Thomas_Zahreddin> AmanicA: ok, next step?
[19:07] <AmanicA> ehm
[19:08] <Thomas_Zahreddin> shall i make a checkout of revision 11 to the custom branch?
[19:08] <AmanicA> that wasn't actually a 'step'
[19:08] <AmanicA> if you only want to version /devian seperately, you can make it a branch
[19:09] <AmanicA> but I dont think there will be an easy way to retain history for that directory
[19:09] <Peng_> "bzr branch main_code custom_code", and merge frequently?
[19:10] <AmanicA> i.e. remove it from your main branch and create a new branch for /debian
[19:10] <AmanicA> make backup first
[19:10] <AmanicA> then you can try:
[19:10] <Thomas_Zahreddin> the diff between main and custom are most config-data (backup is done ;-) )
[19:10] <AmanicA> bzr rm --keep /debian; bzr init /debian;
[19:11] <AmanicA> cd /debian
[19:11] <AmanicA> bzr add <the stuff you want int>
[19:11] <AmanicA> and then bzr ci -m "message"
[19:11] <AmanicA> but the drawback of this approach is they will be seperate branches
[19:11] <AmanicA> so yo uwill need to keep them in sync seperately
[19:12] <AmanicA> so if yo uwant to update both, you'll need to cd into both directories and do update
[19:14] <AmanicA> Thomas_Zahreddin: I confused you with tseliot
[19:17] <Thomas_Zahreddin> AmanicA: and Peng_: i need to update the custom code once a month and have to preserve the config files (and custom data in them) but the config files are a subject of change too, since new options can arise - this is the task and i want to use bazaar and a kind of merge for the update of the custom code
[19:18] <Thomas_Zahreddin> now clear what i have in mind?
[19:18] <Peng_> Thomas_Zahreddin: Depending on how many conflicts merging would cause, what I said still stands.
[19:20] <Thomas_Zahreddin> Peng_: normaly the conflict are the default values in the config files of new versions from the main branch
=== asac_ is now known as asac
[20:37] <Keybuk> I'm having some difficulties with bzr fast-import, who would know how to help?
[20:41] <LarstiQ> phrased like that, I'm not sure I know enough of it
[20:42] <LarstiQ> Keybuk: but maybe I can act as a therapeutic dummy? :)
[20:42] <Keybuk> it's erroring because a commit is missing a from: line, fwict
[20:44] <Keybuk> and looking at the git export, lots of the older tags are missing them
[20:45] <LarstiQ> hmm
[20:45] <Keybuk> I also get a different Assertion inside bzrlib later (if I skip tags), because something is missing a children member
[20:46] <LarstiQ> I assume git can fast-import it?
[20:47] <Keybuk> yeah
[20:48] <LarstiQ> igc would know more about bzr fast-import, but he's probably asleep
[20:49] <tseliot> AmanicA: my branches would share some big binary blobs and I would like to avoid uploading the same binaries to different branches
[20:50] <mwhudson> the children thing sounds vaguely like it could possibly be a plugin/bzrlib version incompatability
[20:50] <AmanicA> cant you keep the shared part in one branch, and the non-shared part in another?
[20:52] <Keybuk> mwhudson: hmm
[20:52] <mwhudson> Keybuk: have you asked google about it?
[20:53] <Keybuk> difficult to construct a search query
[20:53] <tseliot> AmanicA: and would it be possible to use one branch as the original tarball (tar.orig.gz) when using bzr-buildpackage?
=== abadger19991 is now known as abadger1999
[20:56]  * LarstiQ wonders how related http://n2.nabble.com/git-fast-export-|-git-fast-import-doesn't-work-td1577096.html is
[20:57] <Rolly> bzr pull is giving me errors :(
[20:57] <Rolly> bzr: ERROR: No such file: 'w8128h2vbkpc42mfx49c.fetch': [Errno 2] No such file or directory
[20:58]  * Keybuk comments out the offending bit of code :p
[20:58] <Rolly> http://pastie.org/private/b7ynvru1g3luksvykadaxw
[21:03] <LarstiQ> Rolly: is your filesystem healthy?
[21:04] <Rolly> yeah, it is
[21:04] <Rolly> I can try running the command from a different hard drive to make sure
[21:04] <LarstiQ> then I'm out of clue. Seems to happen a lot today.
[21:06] <Rolly> same problem. bzr check doesn't report anything bad, either
[21:11] <AmanicA> tseliot: I wouldn't know I've never used bzr-buildpackage
[21:12] <tseliot> AmanicA: no problem. Thanks for your time
[21:13] <AmanicA> cool
[21:14] <Rolly> Another different type of error, this time with bzr init: "The system cannot find the path specified"
[21:14] <Rolly> http://pastie.org/342656
[21:14] <LarstiQ> Rolly: that too me looks as if the path is too long
[21:14] <Rolly> it's a long pathname, but Windows doesn't have a problem working with that file
[21:15] <Rolly> I can move the file, edit it, etc
[21:15] <LarstiQ> see it in Explorer?
[21:15] <Rolly> yep
[21:15] <jelmer> perhaps one of the underlying functions python / bzr uses doesn't handle long filenames
[21:16] <Keybuk> ugh, actually, this fast-import really does go horribly wrong
[21:16] <Keybuk> I end up with extra files in bzr that were deleted in git
[21:16] <LarstiQ> I'm rather sure of that being the case for the win32 api.
[21:16] <Rolly> I am having a lot of problems, I think I might try downgrading my bzr
[21:18] <Rolly> would upgrading python help? I have 2.5.1
[21:18]  * LarstiQ doesn't expect so
[21:19] <LarstiQ> Rolly: but you could try
[21:19] <LarstiQ> Rolly: is there a chance you could uses shorter paths?
[21:19] <Rolly> Not really, this is the folder structure that Zend Eclipse installs
[21:19] <LarstiQ> k
[21:20] <Rolly> it doesn't seem to be a deal-breaker, the repo is created and I can commit to it
[21:20] <enigma42> What does it mean to have "inconsistent parents"?
[21:20] <Rolly> I'm more worried about that other error about my inability to pull a repo
[21:20] <enigma42> After doing a "bzr check"
[21:21] <enigma42> I have:
[21:21] <enigma42>     1 ghost revisions
[21:21] <enigma42>      1 revisions missing parents in ancestry
[21:21] <enigma42>      2 inconsistent parents
[21:21] <enigma42> I'm not sure if any of those are problems.
[21:21] <LarstiQ> the first two certainly aren't
[21:25] <Rolly> Hm, I got rid of the "No such file: 'foo.fetch'" error
[21:25] <Rolly> It seems the problem is related to the repository format
[21:26] <Rolly> If I pull into a pack-0.92, no problems. If I pull into a 1.9-rich-root, I get the error
[21:29] <Rolly> Is is possible to downgrade a repo to an older format? bzr upgrade --default won't let me
[21:31] <mwhudson> generally yes
[21:31] <mwhudson> you can also bzr init an empty branch of the desired target format and pull into that
[21:31] <Rolly> I'll do that, thanks
[21:42] <Rolly> actually it doesn't have anything to do with repo format. I can init an empty 1.9-rich-root branch, pull into it locally, then pull from the remote branch and it completes without errors
[21:45] <Rolly> or maybe it does. anyways, back to trusty 'ol pack-0.92 :)
[21:52] <Rolly> my .bzr/repository/upload folder was missing, now it works.
[21:52] <Rolly> No idea how that happened
[21:54] <Rolly> I never even entered this particular .bzr directory, never deleted anything, and I don't have an antivirus
[22:03] <spiv> Rolly: backup program?
[22:05] <Rolly> I don't have one
[23:01] <mwhudson> spiv: make pull faster pls
[23:04] <mwhudson> oh it's the diverged branches thing again, i think
=== abadger19991 is now known as abadger1999
[23:22] <nDuff> Anyone have hitns for making bzrlib's lazy_import play more nicely with pychecker?
[23:22] <nDuff> s/hitns/hints/
[23:22] <bob2> there's a pyflakes branch which supports it
[23:23] <nDuff> hmm; I've seen pyflakes around, but haven't actually tried it yet
[23:23] <nDuff> thanks for the pointer
=== Hydrogen is now known as Hiderogen
=== Hiderogen is now known as Hydrogen