| thebolt | ok, thanks for your help so far jelmer , suspect i might be back with more another day :) | 00:00 |
|---|---|---|
| === mw is now known as mw|out | ||
| kiko-afk | hey hey | 00:14 |
| kiko-afk | anyone have a moment to look at https://bugs.edge.launchpad.net/bzr/+bug/195217 | 00:14 |
| ubotu | Launchpad bug 195217 in bzr-lpreview "ReadOnly error when running bzr review-submit" [Undecided,Fix committed] | 00:14 |
| jam | nigth all | 00:15 |
| abentley | kiko-afk: What's to look at? I've already submitted a fix and attached it as a patch. | 00:22 |
| spiv | jam: good night | 00:26 |
| mwhudson | and i've merged and pushed said patch | 00:29 |
| abentley | mwhudson: So we can mark it fix released, then? | 00:32 |
| mwhudson | abentley: i guess so | 00:32 |
| spiv | abentley: bundle buggy is giving 'database is locked' errors for me | 00:33 |
| abentley | Or are there actual releases of that plugin now? | 00:33 |
| abentley | spiv: Apologies. It's having trouble digesting your patch. | 00:33 |
| spiv | abentley: ah | 00:35 |
| abentley | Of course, it *shouldn't* be. | 00:35 |
| spiv | abentley: I should have guessed that my patch-bombing had something to do with it :) | 00:35 |
| mwhudson | abentley: i certainly haven't released it | 00:40 |
| === BasicMac is now known as BasicOSX | ||
| abentley | mwhudson: Well, the bug statuses are problematic this way. If there's nothing left to do, we have to say it's at the end state, i.e. fix released. | 01:01 |
| spiv | abentley: getting connection failed from bb now -- is that a good sign or a bad sign? :) | 01:15 |
| abentley | Sign of desperation. | 01:15 |
| abentley | The last time it tried to handle your message, it got hung up on a lock error. | 01:16 |
| abentley | Which appears to be due to the visitor thread. | 01:16 |
| abentley | Which shouldn't run if there are no visitors. | 01:16 |
| spiv | Ah :) | 01:17 |
| spiv | A good sign then (in the short term). | 01:17 |
| abentley | Maybe. There's all kinds of things wrong here. | 01:18 |
| spiv | It seems odd that it would take so long to process my message. It's just a patch (not a merge directive w/ bundle). | 01:18 |
| abentley | Starting with my virtual server being so slow. | 01:18 |
| abentley | Yes, I agree wholeheartedly. | 01:18 |
| abentley | And there's also the issue that I can't reproduce these lock errors locally. | 01:19 |
| abentley | Well, it took 5 minutes, but it managed to process one of your messages. | 01:23 |
| spiv | abentley: hooray! | 01:24 |
| abentley | spiv: We now return you to your regularly-scheduled bundle buggy | 01:51 |
| spiv | abentley: thanks! | 01:51 |
| abentley | btw, why did you send those as patches? | 01:51 |
| spiv | Because they're in a great big branch, and I decided just slicing the final patch by file was a good way to break it up. | 01:53 |
| AfC | spiv: what, exactly, did you use to do that? `bzr merge --overwrite .../path/to/other/branch ? | 01:54 |
| abentley | Ah. I was thinking you'd done it as a loom and were firing off per-branch diffs. | 01:54 |
| spiv | abentley: I did, but I've already merged the other bits in the loom :) | 01:55 |
| spiv | I wasn't aggressive enough about making threads, perhaps. | 01:55 |
| spiv | AfC: Just "bzr diff -r submit: > everything.patch", then by hand broke it into pieces (pretty easy, given that I was just splitting by file rather than trying to edit hunks). | 01:57 |
| AfC | by hand? | 02:02 |
| AfC | Ah | 02:02 |
| * AfC was harbouring the hope that effective cherry picking support had arrived. | 02:02 | |
| spiv | "vim everything.patch", and remove everything except e.g. message.py + client.py, save as a new patch, send to the list. | 02:02 |
| spiv | And repeat until I've sent everything. | 02:03 |
| spiv | I was going to try break it down into a series of logical steps from the commit history until I realised that with this code, the individual files are actually pretty independently reviewable. | 02:03 |
| abentley | lifeless: around? | 02:08 |
| lifeless | abentley: hi | 02:16 |
| abentley | So I went to start adding the checks pack-1.5, so that it wouldn't accept a revision whose inventory SHA1 didn't match the actual inventory sha1. | 02:17 |
| abentley | And it seems that it was already clobbering the inventory sha1. | 02:17 |
| abentley | The one in the revision, I mean. | 02:17 |
| lifeless | *blink* | 02:17 |
| lifeless | I didn't think I merged anything to fix them up | 02:18 |
| abentley | repository.py:551 | 02:18 |
| lifeless | and checking bzr.dev it still looks to be missing any fixup | 02:18 |
| lifeless | abentley: ah yes, thats not the fetch code path :) | 02:19 |
| lifeless | abentley: I think jelmer fixed this a couple of releases ago | 02:20 |
| abentley | It's one of them. | 02:20 |
| abentley | This should be the codepath used when serializers differ. | 02:20 |
| abentley | And also for old bundles. | 02:21 |
| lifeless | abentley: so this function looks correct to me: supply an inventory and revision, and the inventory is serialised and its sha put into the revison | 02:21 |
| lifeless | supply just a revision and the revision is assumed to be fully populated | 02:22 |
| abentley | Well, it looks like it does what you think we should be doing. | 02:22 |
| lifeless | *IF* the plain to rich root fetch used this code path it would | 02:22 |
| lifeless | however, if you look at fetch.py | 02:23 |
| lifeless | Model1toKnit2Fetcher | 02:23 |
| lifeless | and Inter1and2Helper | 02:23 |
| lifeless | fetching does a regular join of all the file knits | 02:24 |
| abentley | They use GenericRepoFetcher, which uses the Store directly? | 02:24 |
| lifeless | then adds a empty text for the root directory for all revisions | 02:25 |
| lifeless | then reserialises the inventories (via iter_rev_trees) | 02:25 |
| lifeless | and finally bulk copies the revisions and signatures | 02:25 |
| abentley | So the thing I didn't understand until now is that we were already mutating revisions all over the place. | 02:27 |
| abentley | So you can easily have wrong SHA1s in a rich-root-repo, but you can also have right ones. | 02:29 |
| lifeless | yup | 02:29 |
| abentley | And when you create a bundle and send it to a friend, they may wind up with different SHA1s from you, even with the same inventory format. | 02:29 |
| abentley | So it seems like the referential integrity I was trying to preserve is already hopelessly lost. | 02:30 |
| mathrick | jam: sweet, I got it working, so now I have a status page with error reporting, and mostly reliably failing commits | 02:30 |
| mathrick | jam: http://sei.meidokon.net/ for a success page, http://sei.meidokon.net/status-fail.html for a fail page (except that it was deliberately triggered for non-diverged trees, so the revisions on both sides are the same) | 02:33 |
| mathrick | jam: I'm really happy now, thanks for your help :) | 02:33 |
| beuno | Verterok, :) | 02:34 |
| Verterok | beuno: Hi | 02:35 |
| lifeless | abentley: I think we're both trying to preserve a form of referential integrity | 02:36 |
| lifeless | abentley: but xml8 should make both of us happy | 02:37 |
| abentley | xml8 would, but I'm not sure I see the point anymore. | 02:37 |
| abentley | If we're already rewriting SHA1s all the time, why shouldn't reconcile do it? | 02:38 |
| lifeless | well, I don't really like the idea of reconcile doing it | 02:38 |
| lifeless | it just seemed expedient to have the ability to repair a repository | 02:39 |
| abentley | But if we did address that issue, you'd feel good about making rich-root-pack the default, right? | 02:39 |
| abentley | And since it's been supported since bzr 1.0, we could do that in the next release, right? | 02:40 |
| lifeless | I think we have a convesion bug | 02:40 |
| lifeless | but modulo that, yes | 02:40 |
| spiv | Should we rename 'reconcile' to 'repair'? | 02:41 |
| abentley | spiv: How about "refurbish"? | 02:41 |
| lifeless | spiv: possibly; I was thinking sha1 changes would need an option anyhow | 02:41 |
| spiv | abentley: renovate! | 02:41 |
| spiv | "bzr renovation-rescue" | 02:42 |
| abentley | Seriously, I'd prefer a term that connoted "maintenance" rather than "data recovery". | 02:43 |
| abentley | lifeless: I wish I'd understood in London that we were already rewriting SHA1s. | 02:44 |
| abentley | So much time and stomach lining wasted. | 02:44 |
| lifeless | abentley: :(. | 02:46 |
| lifeless | I clearly failed to communicate the knowledge I had effectively | 02:47 |
| abentley | Or maybe I didn't listen clearly. | 02:47 |
| abentley | Oh well. | 02:48 |
| abentley | lifeless: What's the current state of stacking? | 03:01 |
| lifeless | abentley: the prototype works on sftp only; | 03:01 |
| lifeless | I'm rapidly closing in on the migrated versionedfiles logic | 03:02 |
| lifeless | which enables making it work on bzr+ssh | 03:02 |
| lifeless | by breaking the dependency on format-matching | 03:02 |
| abentley | Do you plan to update the prototype? | 03:03 |
| lifeless | oh yes | 03:05 |
| lifeless | and polish it | 03:05 |
| lifeless | its just an ordering thing | 03:05 |
| abentley | The last version I have doesn't pass the test suite, and doesn't merge bzr.dev cleanly. | 03:05 |
| abentley | I'll send you my test suite fixes at least. | 03:06 |
| lifeless | please | 03:07 |
| jml | spiv, abentley: how about 'bzr defrag' | 03:13 |
| lifeless | yay, no more use of KnitVersionedFile.join() from within the knit internals | 03:14 |
| lifeless | jml: that is 'pack' | 03:15 |
| lifeless | jml: pack rearranges. reconcile cross-checks indices, graphs etc | 03:15 |
| mwhudson | hey guys, i can reproduce https://bugs.edge.launchpad.net/bzr/+bug/217701 with bzr.dev at both ends | 03:53 |
| ubotu | Launchpad bug 217701 in bzr "attempt to add line-delta in non-delta knit" [Critical,Fix committed] | 03:53 |
| mwhudson | i thought the fix was in bzr.dev by now | 03:53 |
| mwhudson | oh er, maybe not | 03:59 |
| mwhudson | hm | 03:59 |
| * igc lunch | 04:05 | |
| abentley | igc: Your vote on the send documentation wasn't captured by BB because you didn't reply to the right message. | 04:37 |
| lifeless | spiv: ping | 05:31 |
| lifeless | meh codeslinger is spamming a huge number of bugs with a fairly aggressive tone | 05:43 |
| thumper | Odd_Bloke: I'd like a chat at some stage when you're around | 05:44 |
| lamalex | What's the right way to fix files that bzr resolve put "<<<<<< tree" into? | 05:45 |
| bob2 | bzr resolve won't do that | 05:49 |
| bob2 | you run bzr resolve on the file once you remove those lines | 05:49 |
| lamalex | so is it a hand prune situation? | 05:50 |
| lifeless | yes, you get to choose which side you want to keep | 05:51 |
| lifeless | or if you want to merge the sides | 05:51 |
| lamalex | gotcha | 05:51 |
| bob2 | merge or pull produced conflicts (the command will tell you), then you edit the files to resolve it the way you want, either picking a side or combining them | 05:51 |
| igc | thanks abentley | 05:59 |
| === mbp_ is now known as poolie | ||
| lamalex | sorry for asking all of these questions, I've created a bundle, now what can I do with it if my project doesn't have an email associated with it | 06:34 |
| lamalex | can I assign one? | 06:34 |
| bob2 | you can send that to whoever would review and potentially merge your changes - the project author or the developers list or wherever | 06:35 |
| lamalex | A[A[A[Abzr: ERROR: No mail-to address specified. | 06:35 |
| lamalex | sorry for the preceding garbage | 06:35 |
| lamalex | how do I specify an email for the project? | 06:36 |
| bob2 | oh, right - you can use 'bzr bundle -o somefile.bundle' to get it into a file | 06:36 |
| lamalex | ah ok | 06:36 |
| Peng | You should use "bzr send -o foo.patch" instead of bundle now, I think. I dunno if there's a benefit... :P | 06:36 |
| bob2 | send takes a --mailto option | 06:36 |
| lamalex | I should really rtfm | 06:37 |
| bob2 | hrm, me too it seems | 06:37 |
| lamalex | hehe | 06:37 |
| lifeless | poolie: mail sent | 06:38 |
| lamalex | so that little hash is my patch? | 06:39 |
| lamalex | maybe I didn't do bundle right | 06:39 |
| lifeless | bob2: 'bundle' is not meant to be used these days | 06:40 |
| lamalex | what do we use today? | 06:41 |
| lifeless | bzr send | 06:41 |
| bob2 | send | 06:41 |
| lamalex | just send? it takes care of everything? | 06:41 |
| lamalex | including making the patch? | 06:41 |
| lifeless | yes | 06:41 |
| lifeless | you can give it various parameters | 06:41 |
| lamalex | So I just want to submit a patch for 1 file foo | 06:41 |
| bob2 | lifeless: ah, right | 06:42 |
| lifeless | lamalex: make the change, commit it, then run bzr send --mail-to=xxx | 06:42 |
| lifeless | lamalex: (or instead of --mail-to, you can use -o- to get it on the console) | 06:42 |
| lamalex | is there a way to say only make a patch for file X? | 06:43 |
| lifeless | yes | 06:43 |
| lamalex | do I just give it that file as an argument? | 06:43 |
| lifeless | 'bzr diff -r -X FOO' | 06:44 |
| lifeless | lamalex: but this discards your commit history | 06:44 |
| lamalex | hm, it doesn't like -X | 06:44 |
| lifeless | lamalex: well, the X should be a number for how far back in history to go | 06:45 |
| lamalex | ahh | 06:45 |
| lamalex | ok | 06:45 |
| lifeless | ou can use the send logic by doing 'bzr send -r submit: FOO' | 06:45 |
| lamalex | maybe I'll just do this the old fashioned way with GNU diff... | 06:45 |
| lifeless | lamalex: perhaps you could tell me the whole use case, I feel like I'm playing catchup here | 06:46 |
| lamalex | :) ok | 06:46 |
| lamalex | So I fixed a bug, I need to make a patch, but it's not the only file that changed in the tree | 06:46 |
| lifeless | did you commit the bugfix on its own? | 06:46 |
| lamalex | well the other files that changed are IDE files that we keep in the tree | 06:47 |
| lifeless | e.g. 'bzr commit -m 'fix bug' somefile.c' | 06:47 |
| lamalex | oh snap I had no idea you could commit a single file | 06:47 |
| lifeless | send can send a single commit | 06:47 |
| lifeless | or if you have just made a single local commit, just a normal send will do the right thing | 06:48 |
| lifeless | you can use 'bzr uncommit' to pop the most recent commit | 06:48 |
| lamalex | yeah | 06:48 |
| lifeless | this does not alter the files in your tree, it only changes a pointer to the history | 06:48 |
| lamalex | I know that one | 06:48 |
| lamalex | so I commited just that file | 06:48 |
| lamalex | now I want to bzr send --mail-to ... | 06:49 |
| lamalex | right? | 06:50 |
| poolie | oh suddenly it's a lot louder | 06:50 |
| lamalex | :P | 06:50 |
| lamalex | sorry for waking the baby | 06:50 |
| lamalex | (not calling you a baby, referring to an imaginary infant) | 06:50 |
| lamalex | ahh ok, this calls your mail client to send an email. hmm | 06:52 |
| lamalex | So how does a project do code review on this? It just looks like a hash and nothing else? | 06:54 |
| lifeless | lamalex: by default it should have the diff | 06:54 |
| lamalex | hrm | 06:55 |
| lamalex | I wonder what I'm doing wrong | 06:55 |
| lifeless | lamalex: what options did you give 'bzr send'? | 06:55 |
| lamalex | --mail-to -o | 06:55 |
| lamalex | with arguments | 06:55 |
| lifeless | what arguments | 06:55 |
| lamalex | what does it diff against? the version in the parent branch? | 06:55 |
| lamalex | bzr send --mail-to gnome-do@googlegroups.com -o RenameTo.patch | 06:56 |
| lifeless | it picks the least common ancestor to diff against | 06:56 |
| lifeless | --mail-to and -o are exclusive options I thought | 06:57 |
| lifeless | and by default (unless you have told bzr otherwise) it does that comparison against the parent branch | 06:58 |
| lamalex | bzr didn't give me any erros for using both | 06:59 |
| lifeless | indeed; we may have a bug there | 06:59 |
| lamalex | and it's not giving me any diff | 07:00 |
| lifeless | lamalex: so, lets do a quick diagnostic | 07:01 |
| lifeless | lamalex: what does 'bzr missing' tell you | 07:01 |
| lifeless | (just that, no options) | 07:01 |
| lamalex | my last commit of just the 1 file | 07:02 |
| lifeless | and it says you have that locally? | 07:02 |
| lamalex | http://www.paste2.org/p/22706 | 07:03 |
| lamalex | anything look out of place? | 07:06 |
| lifeless | lamalex: ok, thats good. Now lets check the commit | 07:07 |
| lifeless | lamalex: 'bzr diff -r -2' | 07:07 |
| lifeless | lamalex: does that show the expected diffs | 07:08 |
| lamalex | it shows more than it should actually | 07:08 |
| lifeless | lamalex: oh, do 'bzr diff -r -2..-1' | 07:08 |
| lamalex | looks ok | 07:11 |
| lifeless | ok | 07:12 |
| lifeless | now 'bzr send -o-' | 07:12 |
| === mtaylor is now known as mtaylor|zzz | ||
| lamalex | -o-? | 07:13 |
| lamalex | like a little airplane? | 07:13 |
| lifeless | :P | 07:13 |
| lifeless | yes | 07:13 |
| spiv | (holding your arms out and making "vrrrrm!" noises is optional) | 07:14 |
| poolie | lifeless: thanks, nice draft | 07:14 |
| poolie | you could send the whole thing with take 1 and take 2 | 07:14 |
| lifeless | :> | 07:14 |
| lamalex | haha | 07:14 |
| lifeless | lamalex: so did it look better? | 07:14 |
| lamalex | no! | 07:15 |
| lamalex | wtf | 07:15 |
| lamalex | http://www.paste2.org/p/22707 | 07:15 |
| lifeless | lamalex: looks like during learning about send you have overriden its heuristics | 07:16 |
| lifeless | lamalex: try | 07:16 |
| lamalex | ha | 07:16 |
| lifeless | 'bzr send http://bazaar.launchpad.net/~do-core/do/devel/ -o-' | 07:16 |
| lamalex | no that's an A+ | 07:17 |
| lamalex | so now I want to do bzr send .... -o RenameTo.patch | 07:17 |
| lifeless | if you add --remember it will remember that url for you | 07:17 |
| lamalex | great | 07:17 |
| lifeless | if you want to send it to the list, just replace -o- with --mail-to= ... | 07:17 |
| AfC | Oh, while you're on the topic of bundles, | 07:17 |
| AfC | I'm updating the HACKING instructions for the project I maintain, | 07:18 |
| AfC | and I'm trying to formulate a better description of the SUBMIT_BRANCH and PUBLIC_BRANCH arguments | 07:18 |
| AfC | ... I had been telling people to do | 07:18 |
| AfC | $ bzr bundle ../mainline | 07:18 |
| poolie | yeah that is a bit confusing | 07:18 |
| poolie | needs better names | 07:18 |
| AfC | which was working fine until one day I attempted to merge that bundle in a place that didn't _have_ a ../mainline | 07:19 |
| poolie | afc, i think they should set submit_branch in locations.conf rather than typing it every time | 07:19 |
| poolie | it can be remote | 07:19 |
| AfC | poolie: so, it seems to remember it | 07:19 |
| lifeless | AfC: their ../mainline should have a 'public_location' set | 07:19 |
| AfC | poolie: or sorry, rather, something (not necessarily bundle) sets it | 07:19 |
| lifeless | AfC: if it has that then the resulting bundle will reference http://..... | 07:19 |
| AfC | lifeless: that's what I figured, Rob, so what I was going to change it to was | 07:19 |
| dennda | Hi. I can't seem to get push to work to a remote server via ssh. Isn't 'bzr push bzr+ssh://user@server.tld/some/path correct? | 07:20 |
| AfC | bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline > /tmp/name-that-tune.patch | 07:20 |
| lifeless | dennda: that looks fine | 07:20 |
| dennda | hm | 07:20 |
| AfC | lifeless: ... but I wasn't sure if that was actually correct | 07:20 |
| lifeless | AfC: several things can be improved there | 07:20 |
| AfC | (in terms of me not getting a branch not found error at the other side) | 07:20 |
| lifeless | AfC: if you set the public location of ./mainline, then the user does not need to specify the full url | 07:21 |
| dennda | lifeless: I get this: | 07:21 |
| dennda | http://paste.pocoo.org/show/43412/ | 07:21 |
| lamalex | thanks a lot lifeless | 07:21 |
| lamalex | see you guys | 07:21 |
| dennda | (And yes, of course I got bzr installed) | 07:21 |
| spiv | dennda: that's correct, but note that "some/path" is relative to the root of the filesystem (not your home dir) | 07:21 |
| lifeless | AfC: if you use send, better data is chosen and sent. -o /tmp/name-that.patch will output to a named file | 07:21 |
| dennda | spiv: yes, I know | 07:21 |
| AfC | dennda: you know that /some/path is from system /, not some hypothetical DocRoot | 07:21 |
| spiv | dennda: ah, it seems "bzr" isn't on your path on the remote system | 07:21 |
| dennda | spiv: I need to install bzr remotely? | 07:22 |
| bob2 | dennda: to use bzr+ssh - alternatively you can use sftp://, which doesn't require bzr on the server | 07:22 |
| lifeless | AfC: lastly, send will remember the submit branch, and by default uses the parent branch. so generally 'bzr branch; bzr commit; bzr send --mail-to=xxxx' is all that is needed for correct operation | 07:22 |
| bob2 | confusingly, sftp urls are relative to your homedir, iirc | 07:22 |
| spiv | To use bzr+ssh, yes. bzr+ssh works by running bzr on the remote end and sending commands to it. | 07:22 |
| lifeless | bob2: they are not | 07:23 |
| lifeless | bob2: the expired I-D on sftp urls had them homedir relative, but its expired, and the gnome folk, like bzr, thought that that was crack | 07:23 |
| spiv | bob2: the difference you are thinking of is that our sftp URLs can have /~/ at the start of the path to make them relative to your homedir. | 07:23 |
| lifeless | AfC: I hope that helps | 07:23 |
| AfC | lifeless: investigating... | 07:23 |
| AfC | lifeless: (ie, comparing the various permutations) | 07:24 |
| AfC | lifeless: I supposed one assumption I should have stipulated is that the public URL isn't available (due to disconnected operation) at time of creating the bundle. | 07:24 |
| spiv | dennda: as bob2 says, you can use sftp:// instead of bzr+ssh://, and it works quite well | 07:24 |
| AfC | lifeless: else | 07:24 |
| AfC | bzr bundle bzr://research.operationaldynamics.com/bzr/java-gnome/mainline | 07:24 |
| AfC | alone would have done it | 07:25 |
| lifeless | AfC: thats why setting public_url is useful | 07:25 |
| lifeless | AfC: it just tells bzr the url to use when generating a reference to the branch | 07:25 |
| AfC | lifeless: which the full form _does_ seem to do.... | 07:25 |
| AfC | (even remembers on first use) | 07:26 |
| lifeless | most bzr commands that take optional urls remember them the first time they are supplied | 07:26 |
| AfC | yeah | 07:26 |
| lifeless | poolie: I think I'll just send take 2. | 07:26 |
| AfC | (one of the nice things about what you guys do) | 07:26 |
| bob2 | spiv: ah, oops | 07:27 |
| AfC | Anyway, that brings me back to thinking I should recommend the full form for first use. | 07:27 |
| lifeless | AfC: I would recommend that ../mainline have a public url set. And that users specify ../mainline on first use. | 07:28 |
| dennda | ah great, thanks lifeless, AfC, bob2 and spiv :) | 07:28 |
| dennda | installing bzr remotely would've been an issue... (debian etch with bzr 0.11) | 07:28 |
| AfC | lifeless: as in, me going to the server and hacking something into the branch.conf there? | 07:28 |
| dennda | but sftp works | 07:28 |
| lifeless | AfC: no | 07:29 |
| lifeless | bzr help configuration | 07:29 |
| AfC | dennda: installing bzr manually from source is quite trivial, so don't think there is a big barrier to getting current code. | 07:29 |
| lifeless | look for public_branch | 07:29 |
| bob2 | lifeless: I-D? | 07:29 |
| lifeless | bob2: Internet-Draft | 07:29 |
| spiv | dennda: (fwiw, having bzr 0.11 is technically new enough to work with bzr+ssh://, but it's not really any better than using sftp://) | 07:29 |
| AfC | AH that's what I was looking for the other day. Couldn't really sniff it out of the topic list. | 07:30 |
| bob2 | oh, right, that is cracktastic | 07:30 |
| dennda | AfC: as long as there's sftp:// I'm happy | 07:30 |
| dennda | no need to install it remotely | 07:30 |
| AfC | lifeless: ... right, but `bzr bundle ../local bzr://public` sets/remembers/whatever public_branch | 07:31 |
| AfC | lifeless: maybe we're violently agreeing with each other | 07:32 |
| lifeless | AfC: we're not | 07:33 |
| lifeless | AfC: I was saying that ../local needs *its* public branch set | 07:34 |
| AfC | lifeless: right. But I cannot impose that on someone who has already cloned. | 07:34 |
| lifeless | AfC: sure you can, its easy for them to do | 07:34 |
| AfC | _them_? You expect me to tell newbies to hand edit some internal configuration file? | 07:35 |
| lifeless | AfC: that said, the target branch shouldn't matter to you when you apply the bundle | 07:35 |
| AfC | lifeless: ... it did {somehow, due to my ignorance, my not doing something right, or my being able to do the wrong thing in the fists place), which is why I raise the topic | 07:36 |
| lifeless | AfC: if you expect them to have a local mainline mirror | 07:36 |
| lifeless | AfC: well, if you can reproduce it, I'll happily assist debugging it for you, or at least explaining it if its not a bug | 07:36 |
| AfC | lifeless: I imagine it'll happen each time I do a merge now, as I'm attempting to use checkouts and switch. | 07:37 |
| AfC | lifeless: I'll keep an eye out and report back. | 07:37 |
| lifeless | thanks | 07:37 |
| AfC | As for the other side of the coin, you are recommending that I _not_ adjust branch.conf on the publicly hosted branch? | 07:38 |
| lifeless | AfC: I don't think that setting it in the branch.conf of your public mainline would be a good idea. | 07:38 |
| AfC | Really. Huh. Puzzling. | 07:39 |
| AfC | I guess I'll go and see if I can figure out why not. | 07:39 |
| lifeless | AfC: either it won't propogate, in which case its pointless, or it will propogate, and all your new branches would claim to be your mainline. | 07:39 |
| AfC | Hm | 07:39 |
| AfC | Well, I was aware of the former. The later is a bit of a surprise, but ok. | 07:40 |
| AfC | Fair enough. | 07:40 |
| poolie | 29 errors to go... | 07:40 |
| lifeless | AfC: if it propogated, then each new branch would think that when its pushed, the regular url other folk should use would be your mainlines url. | 07:41 |
| AfC | lifeless: yeah, I get it now | 07:42 |
| AfC | lifeless: so is http://rafb.net/p/KxYMcB25.html wrong? [I realize you have better things to do be doing than reading stuff from me, sorry] | 07:42 |
| poolie | afc, that looks useful | 07:44 |
| poolie | i thought we were encouraging people to use send -o instead of bundle? | 07:44 |
| lifeless | AfC: the bundle command is problematic | 07:45 |
| lifeless | AfC: the 'public_url' parameter is the public url of the branch being submitted | 07:45 |
| poolie | and i think that patch would be even better with a sentence or tw oabout what the urls are for | 07:45 |
| lifeless | AfC: and in general you *don't have one* | 07:45 |
| AfC | So we had a big fight about this 6-8 months ago. I was on the side of "bundle is good" for numerous reasons, but | 07:45 |
| AfC | the one that remains a big factor for me is that I am really tired of people going to the trouble of sending emails with empty bundles in them | 07:46 |
| lifeless | AfC: irrespective of command used. 'bzr bundle ../mainline' is fine. | 07:46 |
| lifeless | 'bzr bundle ../mainline bzr://research.operationaldynamics.com/bzr/java-gnome/mainline' is wrong | 07:46 |
| AfC | by forcing them to glance at the file they _really_ review the diff they are proposing, and it avoids the "you didn't actually specify what branch you're comparing to" problem | 07:46 |
| lifeless | because the branch being submitted is *not* bzr://research.operationaldynamics.com/bzr/java-gnome/mainline | 07:46 |
| lifeless | if you want to force them to look at it, try 'bzr send ../mainline -o /tmp/name-the-patch.patch' | 07:47 |
| lifeless | personally, I use 'bzr diff -r submit:' to preview a submissiom | 07:47 |
| AfC | Not to mention using stdout is good™ | 07:48 |
| * spiv uses "bzr cdiff -r submit: | less -R" | 07:48 | |
| lifeless | bzr send -o- does that | 07:48 |
| AfC | Well, until you remove it from bzr, we'll keep using it. | 07:48 |
| lifeless | I'm not really interested in a debate about send vs bundle right now. I have a patch to finish. Helping you debug your docs is something I'm happy to do. | 07:49 |
| AfC | spiv: you're assuming that they have any clue what -r submit: is and why they should use it. That's a pretty advanced topic. | 07:49 |
| AfC | lifeless: I'm just explaining why it is that we're using bundle, since you noted it. | 07:49 |
| lifeless | AfC: fair enough | 07:50 |
| spiv | AfC: I'm not suggesting that you recommend it, just mentioning what I use in case it's of interest. | 07:50 |
| spiv | I'm willing to trust you know more about your community than I do :) | 07:50 |
| AfC | It doesn't really strike me as the sort of thing to suggest to people when I'm busy trying to encourage them to tolerate my using Bazaar at all in the first place. The whole repository setup malarkey is bad enoug. | 07:51 |
| poolie | afc, so if the core issue is that people should read their diff before sending it | 07:54 |
| AfC | poolie: indeed | 07:55 |
| poolie | that sounds like a pretty reasonable thing, and orthogonal to internal concerns about bundle vs send | 07:55 |
| lifeless | poolie: I've sent the bug-activity mail off | 07:55 |
| poolie | in the way i use send, i see the diff in the editor asking me for a description | 07:55 |
| poolie | however i think this won't happen if you're using an external mail client | 07:55 |
| lifeless | AfC: anyhow, my key point is that for someone that hasn't published their branch using the two-parameter form of bundle is *always* wrong | 07:56 |
| lifeless | AfC: and specifying a different branch as teh public branch is also always wrong/ | 07:56 |
| poolie | well, depending on the client it may or may not be able to open or see files attached to your draft | 07:56 |
| lifeless | AfC: it seems to be all your users will fail on both tests with the draft doco you pastebinned | 07:56 |
| lifeless | AfC: which is why I am saying use one-parameter form | 07:56 |
| AfC | poolie: judging by the fact that I got empty bundles, I'd have to say that's the case | 07:58 |
| poolie | ok | 07:58 |
| poolie | i would think we should not generate empty bundles without warning or forcing | 07:59 |
| poolie | but, it is exactly that kind of case that i think robert and aaron are saying is problematic in bundle | 07:59 |
| AfC | poolie: (it was send that was generating the empty merge requests) | 08:00 |
| AfC | lifeless: so, transposing what you're saying, I should revert to telling people to do `bzr bundle ../mainline` or whatever and do $something different when I merge to avoid the problem that _I_ have no ../mainline for it to refer to (assuming I can duplicate that scenario and that it is indeed a problem) | 08:02 |
| lifeless | AfC: *and*, have them set the public url for their copy of mainline | 08:02 |
| AfC | lifeless: Ok. One last question, then: how is that different than them inheriting public_branch from the internet hosted 'mainline' they branched from in the first place? | 08:04 |
| AfC | lifeless: which you indicated would result in all branches thinking they were 'mainline' (a statement I find weighty though, I must admit, a bit strange given all branches are peers more or less) | 08:05 |
| lifeless | AfC: because it doesn't propogate when set in ~/.bazaar/locations.conf | 08:09 |
| Odd_Bloke | thumper: Sure. I'm around now, if you still are. | 08:10 |
| fullermd | Well, I'm pretty sure it doesn't propogate when set in branch.conf either. | 08:10 |
| Odd_Bloke | (Morning all.) | 08:10 |
| poolie | AfC: one useful way to move this forward if you get a chance might be: | 08:11 |
| poolie | write the doc that you wish was in the manual | 08:11 |
| poolie | describing the hypothetical command | 08:11 |
| poolie | then we can work out how much of it is docs, how much is defaults, etc | 08:11 |
| AfC | fullermd: really? I thought that branch.conf _did_ propagate. | 08:12 |
| AfC | poolie: I'll see about heading in that direction, sure. | 08:12 |
| poolie | spiv, lifeless: every assert deleted, yay | 08:25 |
| poolie | quite a few were bogus | 08:25 |
| lifeless | spiv: the versioned_files branch has the absent record type we discussed | 08:27 |
| lifeless | night all | 08:27 |
| spiv | lifeless: hooray | 08:28 |
| spiv | poolie: I must admit the patches I sent this morning add a few, but that should be easy to correct | 08:28 |
| spiv | poolie: (they also remove some, though) | 08:28 |
| poolie | spiv: naughty, smart.py already has too many :) | 08:51 |
| poolie | spiv, as penance you can read my diff :) | 08:51 |
| poolie | night from me too | 08:51 |
| poolie | well done on sending yours | 08:51 |
| poolie | 5000-line diff sent, i'm done | 08:51 |
| spiv | poolie: I wrote the offending asserts before your rfc :P | 08:53 |
| spiv | Good night. | 08:53 |
| poolie | it's ok | 08:54 |
| poolie | night | 08:54 |
| spiv | Ooh, long weekend. I almost forgot. :) | 08:57 |
| igc | night spiv, poolie | 09:02 |
| * igc dinner | 09:02 | |
| spiv | igc: g'night | 09:10 |
| mathrick | how can I revert a pending merge, and only the merge (ie. without reverting the local changes)? | 10:46 |
| mathrick | ahh | 10:46 |
| mathrick | it says that in the help page, never mind | 10:46 |
| spiv | mathrick: :) | 10:50 |
| awilkins | How do you test a class instance to see what type it is? | 11:33 |
| * awilkins has found isinstance | 11:36 | |
| lifeless | assertIsInstance | 11:40 |
| awilkins | Do you just pass the class name to the second argument? | 11:41 |
| awilkins | (not as a string, as an identifier) | 11:41 |
| mathrick | uhh, how do I get a revno out of rev id and a branch? | 11:46 |
| mathrick | (I'd add that API docs are down again) | 11:46 |
| james_w | awilkins: I believe so, yes | 11:47 |
| james_w | mathrick: revid_to_revno_map, or something like that. | 11:48 |
| mathrick | ah, I just found branch.revision_id_to_revno | 11:48 |
| awilkins | james_w: Hmm ; i'm trying to write "added" support into bzr ls (mostly for fun), and I've so far settled on checking whether a thing is a TreeEntry or an InventoryEntry as a test ; but it's probably not the best test in the world. | 11:49 |
| awilkins | The only other test I can think of is checking hasattr(entry, 'has_text') ; otherwise you'd have to extend the "Entry" hierarchy a bit | 11:55 |
| james_w | what are you trying to achieve? | 11:55 |
| awilkins | bzr ls --added emitting a list of added files | 11:56 |
| james_w | yes, but why are you trying to find if it is a TreeEntry or InventoryEntry? | 11:57 |
| awilkins | james_w: Because the entry is an InventoryEntry if it's in the inventory, but a TreeEntry if it's just been added | 11:57 |
| james_w | ah, that doesn't sound like the right way to get the information | 11:58 |
| james_w | tree.changes_from(other_tree) is what I would reach for first. | 11:58 |
| awilkins | james_w: That would make the implementation of bzr ls a lot more complex, which is why I suspect this hasn't been done already | 11:59 |
| awilkins | The all comes out of me patching some hidden commands and submitting a merge for it... | 12:00 |
| james_w | it looks to me as though cmd_ls could use a refactoting | 12:00 |
| james_w | refactoring, sorry | 12:00 |
| james_w | Having all the logic in the command class isn't desirable to start with | 12:00 |
| awilkins | Some kind of tree iterator with filter chaining that yields the data? | 12:02 |
| james_w | but finding all this information isn't actually that easy with bzrlib currently. | 12:02 |
| james_w | that could be alright | 12:02 |
| james_w | tree.changes_from should have what you need for ls, | 12:02 |
| james_w | however there is an argument against having ls --added, as it is a state change thing, rather than a single state, and so is the domain of status. | 12:03 |
| awilkins | Which brings me full circle - I patched the hidden "added" and "modified" commands to be more consistent with "unknowns" | 12:04 |
| awilkins | Gah, I suppse patching "status" is actually what abentley recommended... | 12:06 |
| * awilkins beats self | 12:06 | |
| awilkins | Is there a tertiary operator in python ( false ? truthing : falsething ) ? | 12:24 |
| dato | awilkins: only in python 2.5 | 12:25 |
| dato | (x = 1 if foo else 2) | 12:25 |
| awilkins | Ok, I'll avoid that then | 12:25 |
| igc | dato: I was ill a few days this week so I never did get to look at that bzr-fast-export issue | 12:37 |
| igc | dato: did you get a chance to look into it any more? | 12:37 |
| dato | nop, sort of crazy busy here | 12:38 |
| igc | dato: np - I'll take a look next week | 12:38 |
| Mez | Is there any reason I need to specifically "upgrade" a branch to use tags? (and do I lose anythign in doing so?) | 12:39 |
| igc | Mez: some early branch formats didn't support tags | 12:39 |
| igc | unless you're using a special format (for bzr-svn say), should should'nt lose anything | 12:40 |
| Mez | igc, I understand that, however, do I lose anything from upgradeing from dirstate to dirstate-tags | 12:40 |
| igc | no | 12:40 |
| igc | it should be fine | 12:40 |
| Mez | Repository branch (format: dirstate or knit) = what it's showing for the remote branch | 12:41 |
| Mez | is that correct? | 12:41 |
| igc | Mez: do you control the format of the remote branch? | 12:42 |
| Mez | I hope so ;) | 12:42 |
| Mez | it's a bound branch, shouldn't it be updated automatically? | 12:43 |
| igc | Mez: good. In that case, you should seriously consider upgrading to pack-0.92 instead of dirstate-tags | 12:43 |
| Mez | igc, why? | 12:43 |
| igc | pack-0.92 performs better and is more space efficient | 12:43 |
| igc | it's the current default | 12:44 |
| igc | it supports tags as well | 12:44 |
| Mez | hmm - I'm on 0.9.0 | 12:44 |
| Mez | hmm - I'm on 0.90.0 * | 12:44 |
| igc | Mez: you'd need to upgrade bzr in that case as well :-) | 12:44 |
| Mez | igc - indeed... | 12:45 |
| * Mez waits for hardy | 12:45 | |
| igc | there's a 1.4rc2 currently out - 1.3.1 is the latest production release | 12:45 |
| igc | Mez: 1.3.1 is in hardy to my knowledge | 12:46 |
| Mez | 0.90.0 is in gutsy | 12:46 |
| Mez | hmmles.. | 12:46 |
| Mez | how do I make the tags push to the bound branch? | 12:47 |
| igc | Mez: not sure sorry. Did you try 'bzr push branch-url'? | 12:49 |
| james_w | Mez: I think it will happen on your next commit | 12:50 |
| === mrevell is now known as mrevell-lunch | ||
| Mez | ah, push works, but looks like a fail | 12:50 |
| Mez | igc, if a local branch and a remote branch don't have the same format, they'll still work together? | 13:03 |
| igc | Mez: I believe so | 13:04 |
| Mez | igc, cool - I expected errors ;) | 13:04 |
| igc | operations can be quicker though if the formats match because less conversion of data is required | 13:04 |
| Mez | yeah, can undersand that | 13:05 |
| Mez | I just expected it to throw an error, or upgrade the local branch or something | 13:05 |
| Mez | gotta get my other devs to re-checkout the branch (or upgrade it) | 13:05 |
| awilkins | Mez: Not all branches are compatible | 13:20 |
| awilkins | Mez: particularly branches that use rich roots | 13:20 |
| igc | night all | 13:42 |
| beuno | sleep well igc :) | 13:43 |
| igc | thanks beuno - public holiday here tomorrow so I'll see you next week | 13:43 |
| igc | and while I'm off topic - here's to hardy! The bird has now escaped it seems :-) | 13:44 |
| beuno | heh, I've already got the ISOs on my servers | 13:44 |
| beuno | I grabbed them before the server bashing started :) | 13:45 |
| === mw|out is now known as mw | ||
| abentley | spiv: Has this merge request http://bundlebuggy.aaronbentley.com/request/%3C20080220122210.GA29155@steerpike.home.puzzling.org%3E been superseded? | 14:10 |
| spiv | abentley: no, in fact I meant to land it today | 14:10 |
| abentley | Oh, I thought it might be part of your patchbombing. | 14:11 |
| spiv | No, the patchbombing was just code. | 14:12 |
| === mrevell-lunch is now known as mrevell | ||
| === bigdo4 is now known as bigdog | ||
| hno | A bit of panic here.. suddenly bzr says "bzr: ERROR: Unknown record type: '\r'" on pretty much any operation to the repository. | 15:35 |
| Odd_Bloke | hno: Could you look in ~/.bzr.log for the relevant error message? | 15:41 |
| hno | Odd_Bloke: Only a long python backtrace.. | 15:42 |
| Odd_Bloke | hno: Could you pastebin that backtrace somewhere, please? | 15:44 |
| hno | http://www.squid-cache.org/~hno/bzr.log | 15:44 |
| hno | the repository is at http://www.squid-cache.org/bzr/squid3/trunk | 15:44 |
| hno | the log is from a "bzr update" of a local checkout using file:///bzr/squid3/trunk as source. But same error is seen if I try to make a fresh checkout remotely over http. | 15:46 |
| Odd_Bloke | hno: What version of bzr are you using? | 15:47 |
| hno | Server is Bazaar (bzr) 1.3. The remote client is 1.3.1rc1 | 15:48 |
| Odd_Bloke | hno: When in the process to you get the error? | 15:51 |
| hno | Odd_Bloke: On checkout it sets up the .bzr directory and control files (including last-revision) but no sources.. | 15:52 |
| hno | Odd_Bloke: not sure if that answers your question. Not sure how to tell "when". | 15:54 |
| Odd_Bloke | Yeah, I'm not really sure what I was looking for in an answer. :p | 15:55 |
| Odd_Bloke | I'm not sure what's going on. | 15:56 |
| hno | My local mirror repository seems unaffected.. | 15:58 |
| * Odd_Bloke is trying to reproduce. | 15:58 | |
| hno | but I don't have all branches.. | 15:59 |
| Odd_Bloke | I'll leave that running and BBIAB. | 16:00 |
| hno | It's seen farily quick if using bzr co --lightweight. | 16:03 |
| === pygi is now known as pygi|away | ||
| hno | Hmm.. some process has also gone very wrong and set last-revision of one of the branches equal to trunk... | 16:13 |
| hno | Argh.. out of time. Have to go. If you figure something out please mail henrik@henriknordstrom.net. I'll continue looking at this later tonight. | 16:15 |
| === mtaylor|zzz is now known as mtaylor | ||
| === kiko-afk is now known as kiko | ||
| awilkins | Anyone else order a WiiFit? | 17:20 |
| pekuja | nope, I've got mass to conserve | 17:21 |
| korpios | awilkins: I've got a metal DDR pad :p | 17:24 |
| korpios | (I wish I could play more ... moved into a 2nd floor apartment) | 17:24 |
| ubotu | New bug: #221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,New] https://launchpad.net/bugs/221414 | 17:35 |
| fbond | Is there a way to rename threads? | 17:50 |
| NfNitLoop | threads? | 17:50 |
| fbond | In looms... | 17:50 |
| NfNitLoop | oh. Sorry, over my head. : ) | 17:51 |
| fbond | NfNitLoop: no problem | 17:51 |
| NfNitLoop | I was thinking a thread of execution. | 17:51 |
| NfNitLoop | and was a bit confused. ) | 17:51 |
| abentley | fbond: No, not really. | 17:51 |
| abentley | You can create a new thread with the desired name. | 17:52 |
| abentley | And then combine-thread the other one. | 17:52 |
| fbond | So create-thread, up-thread, merge -r thread:foo, combine-thread? | 17:59 |
| jam | fbond: just don't try to use 'bzr nick XXX' as it will break your loom :) | 17:59 |
| fbond | fbond: Already tried that :) | 17:59 |
| jam | (you can get back if you 'bzr nick OLD_NAME' though) | 17:59 |
| fbond | jam: Didn't seem to totally break things. | 17:59 |
| jam | maybe they fixed that | 18:00 |
| jam | when I did it, it would crash on every operation at 'unlock()' time | 18:00 |
| fbond | jam: Yeah, I think some operation I did following that fixed things. | 18:00 |
| fbond | abentley: Or, rather, create-thread bar, merge -r thread:foo, combine-thread should do it? | 18:01 |
| abentley | fbond: bzr switch OLD_NAME; bzr create-thread NEW_NAME; bzr down-thread; bzr combine-thread | 18:02 |
| abentley | jam: Not fixed yet, AFAIK | 18:03 |
| fbond | abentley: right, thanks | 18:03 |
| * NfNitLoop reads up on looms. | 18:10 | |
| NfNitLoop | Hmm, that's cool. | 18:10 |
| jam | abentley: doing a 'bzr up' seems to have the same "assume the nick is in the thread dictionary" so it sounds like you are right. | 18:11 |
| jam | I'm curious what "bzr nick 'name of another thread'" would do | 18:11 |
| awilkins | jelmer: I have a couple of merges languising in the bzr-gtk limbo, are you the list admin? | 18:11 |
| jam | I suppose it would be similar to a switch, just without all the merging | 18:11 |
| abentley | jam: Well, the main thing it would need to do would be to rename the thread entry. | 18:12 |
| jam | abentley: I'm saying that right now 'bzr nick other_thread' will implicitly jump you to that thread and record your state there. | 18:13 |
| jam | It probably *should* just rename the current thread, and fail if there is a name conflict. | 18:13 |
| abentley | Agreed to both. | 18:13 |
| === cpro1 is now known as cprov | ||
| trepca | hi | 19:11 |
| ubotu | New bug: #221461 in bzr "'bzr push --quiet sftp://host.com' is too chatty" [Undecided,New] https://launchpad.net/bugs/221461 | 19:46 |
| ubotu | New bug: #221465 in bzr "'bzr push sftp://host.com' does not use authentication.conf password setting" [Undecided,New] https://launchpad.net/bugs/221465 | 19:55 |
| === pygi|away is now known as pygi | ||
| === mw is now known as mw|food | ||
| jelmer | awilkins: yes | 20:46 |
| jelmer | awilkins: one sec, I'll see if I can find the password.. | 20:46 |
| === mw|food is now known as mw | ||
| Necoro | hmm ... is something like "bzr branch lp:portato lp:~necoro/portato/cache" supposed to work? | 21:44 |
| Necoro | hmm ... it works somehow but is reeeeeeally slooow | 21:45 |
| fullermd | I'd expect so. | 21:48 |
| Necoro | I aborted it ... it hang showing nothing ;) | 21:50 |
| fullermd | Well, transferring bunches of data twice is kinda slow :p | 21:51 |
| trepca | is shared repository meant for different branches of the same project or can it contain branches for different projects too ? | 21:53 |
| abentley | The smart server in general is slow on Launchpad today, because it shares a resource with servers affected by Hardy traffic. | 21:54 |
| abentley | The good news is that we've got a replacement good to go for our next release. | 21:55 |
| Necoro | abentley: launchpad is generally not the fastest server ;) | 21:55 |
| fullermd | Well, the SS doesn't support server-side branches like that anyway, does it? | 21:55 |
| fullermd | So you're still stuck with copy-all-down, copy-all-up | 21:56 |
| abentley | fullermd: No, it doesn't. I mention ss because he said lp:foo | 21:56 |
| abentley | trepca: It's fine to use it for different projects, but repositories do get slower the bigger they are. | 21:57 |
| jam | abentley: yeah, lool on #bzrlp was mentioning that bzr+ssh:// bazaar.launchpad is really slow today | 22:41 |
| jam | I know he was wondering why the resources weren't more separate | 22:41 |
| jam | I was also guessing it was a Hardy-release-day thing, but couldn't answer why the smart host shares resources with a download server | 22:42 |
| * awilkins downloaded Hardy via a torrent, it wasn't his fault | 23:41 | |
| elmo | jam: it doesn't | 23:42 |
| elmo | LP is on a completely separate link | 23:42 |
| elmo | if it uses the authserver on the otherhand.. | 23:42 |
| jam | elmo: well, that would effect the connect time, but I wouldn't expect it to effect every operation once connected | 23:44 |
| elmo | jam: well the LP link had no bandwidth problems today due to the release, trust me | 23:45 |
| jam | elmo: it seemed to be more CPU resources than bandwidth | 23:46 |
| jam | unless it was horribly bandwidth constrained | 23:46 |
| jam | (100s for 70KB) | 23:46 |
| jam | .7KB/s | 23:46 |
| elmo | err, well, yeah - the bzr LP server doesn't share CPU (modulo authserver contention with wiki.u.c) or bandwidth resources in any way that would make it be affected by today's release | 23:47 |
| jam | I guess we've had "super slow" days in the past | 23:47 |
| jam | I've only seen "we know it is slow and are working on it" posts | 23:47 |
| jam | Maybe the same thing struck again | 23:47 |
| jam | (but stuff like X over 'bzr+ssh' being 250s and 20s over http) | 23:48 |
| awilkins | jam: I found it much faster to branch a local project over file:// than bzr:// | 23:50 |
| awilkins | "local" means "across a LAN" | 23:51 |
| jam | awilkins: for a *new* branch, 'http://' is faster than 'bzr+' at the moment | 23:52 |
| jam | but it isn't 12x faster | 23:52 |
| === mw is now known as mw|out | ||
| jam | (that, and I was testing 'bzr log', which I haven't really compared, but it still shouldn't be *that* different) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!