| 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:00 |
|---|---|---|
| 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:01 |
| 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:02 |
| Peng_ | Good luck with that. :P | 00:03 |
| spiv | Hmm, now that LP supports 1.9 branches, someone needs to upgrade our PQM's bzr... | 00:05 |
| === jamesh_ is now known as jamesh | ||
| awilkins | Hmm. When are we removing non-rich root formats ;-) | 00:29 |
| 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:33 |
| garyvdm | Thanks | 00:34 |
| spiv | garyvdm: yeah, the interesting comparison is old code vs. new code on the exact same repo. | 00:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:53 |
| 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:54 |
| spiv | jml: it does. | 00:56 |
| 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:58 |
| spiv | And asked for more information. | 00:59 |
| jml | thanks. | 00:59 |
| cody-somerville | komputes, Hey David | 01:46 |
| 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:49 |
| 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:50 |
| komputes | cody-somerville: tried to tell you but you were fast asleep | 01:51 |
| cody-somerville | lol | 01:52 |
| igc | hi all | 03:37 |
| markh | g'day ian! | 03:52 |
| 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:06 |
| 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! | 04:07 |
| vila | hi all | 07:03 |
| igc | hi vila | 07:33 |
| === doko_ is now known as doko | ||
| 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:34 |
| fm | this is solved as in http://doc.bazaar-vcs.org/bzr.dev/developers/authentication-ring.html | 08:40 |
| 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 | 08:58 |
| vila | urgh, looks like my DNS serverS are down :-( Can someone read me here ? | 09:06 |
| Jc2k | vila: yeah, but i suspect my pong took so long it doesnt matter | 09:15 |
| awilkins | CTCP PING reply from vila: 0.585 seconds | 09:16 |
| fm | vila: i am perfectly fine with storing in authentication.conf | 09:18 |
| loxs | folks, how can I ignore the whole contents of a folder? (what is the .bzrignore directive for that?) | 09:21 |
| bob2 | the dirname | 09:23 |
| LeoNerd | An ignored directory automatically ignores all the contents within it | 09:27 |
| loxs | bob2, LeoNerd you mean ONLY the dirname (without a relative path to it?) | 09:36 |
| LeoNerd | E.g. echo "tmp/" >>.bzrignore | 09:37 |
| LeoNerd | Or even without the trailing / | 09:37 |
| 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:39 |
| bob2 | have you tried it? | 09:40 |
| bob2 | (full path relative to the root) | 09:40 |
| loxs | yes, then it includes that directory | 09:40 |
| loxs | (the ignore doesn't work) | 09:41 |
| bob2 | ./ | 09:42 |
| loxs | yes, this works, thanks | 09:45 |
| 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 | 10:03 |
| === `6og is now known as Kamping_Kaiser | ||
| vila | Jc2k, awilkins : thanks, things are back to normal... | 10:43 |
| === andreas__ is now known as ahasenack | ||
| Necoro | is it possible to convert a branch from some rich-root-format into into one w/o? | 12:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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. | 12:59 |
| 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:00 |
| 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:01 |
| jelmer | Necoro: no, this is not possible | 13:04 |
| Necoro | jelmer: ah ok -- what is the reason by the way to still differentiate between these two? | 13:05 |
| Necoro | has rich-root some issues? | 13:06 |
| 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:11 |
| Necoro | good :) | 13:12 |
| Necoro | thx for the info | 13:12 |
| * Necoro heads to class | 13:12 | |
| === jelmer is now known as Guest73702 | ||
| === Guest73702 is now known as jelmer | ||
| 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:20 |
| * 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:24 |
| jelmer | it's probably a bug | 14:25 |
| Peng_ | Peng_'s first experience with stacking is very disappointing. :\ | 14:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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. | 14:29 |
| === sdboyer-laptop__ is now known as sdboyer-laptop | ||
| 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:52 |
| 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:53 |
| Peng_ | jelmer: Oh, never mind, you were referring to one of the other things. | 14:54 |
| * Peng_ is confusing himself now. | 14:54 | |
| 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:55 |
| 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:56 |
| Peng_ | jelmer: Yes. | 14:57 |
| jelmer | MvG, other than that, it's certainly doable I think for smaller wikis | 14:57 |
| Peng_ | jelmer: Why do you format bzr-svn's __version__ yourself instead of using bzrlib._format_version_tuple or something? | 15:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| vila | ..and finally address that 401 notorious bug :-/ | 15:23 |
| * 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:25 |
| vila | jelmer: hmm, so far we support Digest and Basic and try Digest first, what's the need ? | 15:27 |
| jelmer | vila: it's required for Kerberos authentication | 15:28 |
| vila | Do you have some docs describing that for the http part ? | 15:29 |
| awilkins | vila: Yes, just that one earlier | 15:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| awilkins | Theres a bundle in there I fixed it with too ; but as noted, rather naive | 15:36 |
| vila | awilkins: ha ! That one ok, but that's not the right approach, bug #...wait a minute | 15:37 |
| 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:38 |
| 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 :) | 15:40 |
| === 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 | ||
| 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? | 18:08 |
| 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:01 |
| 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:02 |
| AmanicA | I think you should keep your main code in one branch and you custom code in a seperate branch | 19:03 |
| 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:04 |
| AmanicA | then you have 2 separate directories for you code | 19:05 |
| Thomas_Zahreddin | ok, | 19:05 |
| Thomas_Zahreddin | done | 19:06 |
| Thomas_Zahreddin | AmanicA: ok, next step? | 19:07 |
| AmanicA | ehm | 19:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| AmanicA | so if yo uwant to update both, you'll need to cd into both directories and do update | 19:12 |
| AmanicA | Thomas_Zahreddin: I confused you with tseliot | 19:14 |
| 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:17 |
| 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:18 |
| Thomas_Zahreddin | Peng_: normaly the conflict are the default values in the config files of new versions from the main branch | 19:20 |
| === asac_ is now known as asac | ||
| Keybuk | I'm having some difficulties with bzr fast-import, who would know how to help? | 20:37 |
| LarstiQ | phrased like that, I'm not sure I know enough of it | 20:41 |
| 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:42 |
| Keybuk | and looking at the git export, lots of the older tags are missing them | 20:44 |
| 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:45 |
| LarstiQ | I assume git can fast-import it? | 20:46 |
| Keybuk | yeah | 20:47 |
| LarstiQ | igc would know more about bzr fast-import, but he's probably asleep | 20:48 |
| tseliot | AmanicA: my branches would share some big binary blobs and I would like to avoid uploading the same binaries to different branches | 20:49 |
| 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:50 |
| Keybuk | mwhudson: hmm | 20:52 |
| mwhudson | Keybuk: have you asked google about it? | 20:52 |
| 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? | 20:53 |
| === abadger19991 is now known as abadger1999 | ||
| * LarstiQ wonders how related http://n2.nabble.com/git-fast-export-|-git-fast-import-doesn't-work-td1577096.html is | 20:56 | |
| 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:57 |
| * Keybuk comments out the offending bit of code :p | 20:58 | |
| Rolly | http://pastie.org/private/b7ynvru1g3luksvykadaxw | 20:58 |
| LarstiQ | Rolly: is your filesystem healthy? | 21:03 |
| 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:04 |
| Rolly | same problem. bzr check doesn't report anything bad, either | 21:06 |
| AmanicA | tseliot: I wouldn't know I've never used bzr-buildpackage | 21:11 |
| tseliot | AmanicA: no problem. Thanks for your time | 21:12 |
| AmanicA | cool | 21:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| Rolly | would upgrading python help? I have 2.5.1 | 21:18 |
| * LarstiQ doesn't expect so | 21:18 | |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:25 |
| 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:26 |
| Rolly | Is is possible to downgrade a repo to an older format? bzr upgrade --default won't let me | 21:29 |
| 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:31 |
| 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:42 |
| Rolly | or maybe it does. anyways, back to trusty 'ol pack-0.92 :) | 21:45 |
| Rolly | my .bzr/repository/upload folder was missing, now it works. | 21:52 |
| Rolly | No idea how that happened | 21:52 |
| Rolly | I never even entered this particular .bzr directory, never deleted anything, and I don't have an antivirus | 21:54 |
| spiv | Rolly: backup program? | 22:03 |
| Rolly | I don't have one | 22:05 |
| mwhudson | spiv: make pull faster pls | 23:01 |
| mwhudson | oh it's the diverged branches thing again, i think | 23:04 |
| === abadger19991 is now known as abadger1999 | ||
| 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:22 |
| nDuff | hmm; I've seen pyflakes around, but haven't actually tried it yet | 23:23 |
| nDuff | thanks for the pointer | 23:23 |
| === Hydrogen is now known as Hiderogen | ||
| === Hiderogen is now known as Hydrogen | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!