| spiv | lifeless: pong; just figuring out my after-work commitments now so I can plan that. | 00:01 |
|---|---|---|
| Peng_ | mwhudson: Now with more evil and depravity :) http://bzr.mattnordhoff.com/loggerhead/loggerhead/yui-cdn/revision/324/loggerhead/templates/macros.pt | 00:06 |
| lifeless | spiv: kk | 00:14 |
| weigon | lp's ssh refuses to connect :( | 00:16 |
| Peng_ | weigon: LP's down for maintenance. | 00:16 |
| Peng_ | maintanence? Eh, whatever. | 00:16 |
| weigon | *doh* thx | 00:17 |
| jelmer | crap, revision properties contain arbitrary binary data? | 00:21 |
| mwhudson | jelmer: it's just {str:str} isn't it, so i guess so? | 00:22 |
| jelmer | mwhudson: what's the easiest way to escape arbitrary data in something representable in unicode? | 00:23 |
| Peng_ | jelmer: repr()? s.encode('unicode-escape')? base64? | 00:24 |
| mwhudson | jelmer: i guess it might be meant to be utf-8 or something | 00:25 |
| mwhudson | i guess i'm the wrong person to ask | 00:25 |
| lifeless | jelmer: why do you say they contain arbitrary data? | 00:26 |
| jelmer | Peng_: base64 is overkill, unicode-escape requires a unicode string (and I have no way of creating one) | 00:26 |
| mwhudson | Peng_: your increased depravity looks fine to me :) | 00:27 |
| Peng_ | mwhudson: Is that a bb:approve? :D | 00:30 |
| jelmer | lifeless: at least one of the tests tries to add "\xb5" as property value | 00:30 |
| jelmer | (in other words, a <str> object and invalid utf8) | 00:32 |
| lifeless | jelmer: ah interesting | 00:34 |
| lifeless | and we what, base64 enciode them ? | 00:34 |
| jelmer | it seems like it silently gets casted to unicode | 00:35 |
| jelmer | in the XML serializer | 00:35 |
| jelmer | so "\xb5" goes in, u"\xb5" comes out | 00:35 |
| lifeless | but you said \xb5 isn't valid unicode? | 00:36 |
| jelmer | lifeless: it's invalid utf8 | 00:37 |
| lifeless | jelmer: is the test testing that or is it a bug in the test? | 00:46 |
| jelmer | lifeless: the bug is in the test | 00:49 |
| MizardX | lifeless: "No shells on this server." ... Connecting with putty with same certificate seems to work. You said if that was so, then bzr didn't pick up Pageant. How would I fix that? | 00:49 |
| lifeless | MizardX: now we've reached the end of my knowledge :( I haven't used bzr on windows | 00:56 |
| MizardX | Ok. Thanks. | 00:56 |
| lifeless | MizardX: but we now know that your launchpad and putty stuff is setup | 00:56 |
| lifeless | uhm | 00:56 |
| lifeless | did you install using the windows binary, or the 'python installer' ? | 00:57 |
| MizardX | binary | 00:57 |
| lifeless | bzr --version will give you the path to a log file | 00:57 |
| MizardX | I think it's compiled with py2exe | 00:57 |
| lifeless | you might look in that log and see if there is anything about pagent/putty | 00:57 |
| MizardX | Just "ssh implementation is OpenSSH" and "ConnectionReset: Connection closed: please check connectivity and permissions" | 00:59 |
| lifeless | ok | 00:59 |
| lifeless | that suggests it found a ssh.exe on your machine and is using that | 01:00 |
| lifeless | there is an environment variable to control this I think, one sec | 01:00 |
| lifeless | do you have plink installed? | 01:01 |
| MizardX | yes | 01:02 |
| lifeless | ok | 01:02 |
| lifeless | try | 01:02 |
| lifeless | setting the BZR_SSH environment variable to 'plink' | 01:02 |
| MizardX | "FATAL ERROR: Disconnected: No supported authentication methods available", not it doesn't find the certificate | 01:04 |
| MizardX | now* | 01:04 |
| spiv | lifeless: I'll head to you. ETA is 11:50 by the time I buy my coffee :) | 01:06 |
| MizardX | Ah, pageant wasn't running... | 01:06 |
| MizardX | "Branched 8 revision(s)." :D | 01:07 |
| MizardX | Thanks, lifeless. | 01:07 |
| Peng_ | mwhudson: ping | 01:10 |
| Peng_ | mwhudson: Mind if I make an old-style class in Loggerhead new-style without getting it reviewed? (Well, asking is almost as inconvenient as a review...) | 01:10 |
| lifeless | MizardX: cool | 01:11 |
| nsh22 | what does this mean: error: unable to create symlink 'themes' on this platform | 01:16 |
| Snova | Would I be correct at guessing you're running Windows? | 01:16 |
| Snova | Also, how did this come about? What command caused it? | 01:16 |
| nsh22 | unfortuneatly yes | 01:16 |
| nsh22 | i was just getting a branch | 01:17 |
| Snova | Then I can only assume the branch contains symlinks, which have no equivalent on Windows... I dunno what else it could mean. | 01:17 |
| nsh22 | ugh, ok... the thing is is that it gave me any of the other files in the branch | 01:18 |
| jml | Launchpad is running bzr 1.13 on production now. | 01:20 |
| jml | ~18s & 21 hpss calls to push no revisions to a stacked branch. ~7s of that is SSH connection time. | 01:21 |
| jml | ~27s & 32 hpss calls to push one revision to a stacked branch. | 01:23 |
| lifeless | jml: is this better :) | 01:24 |
| jml | yes. | 01:24 |
| sm | g'day all | 01:27 |
| sm | how long should bzr selftest take on a macbook ? | 01:27 |
| sm | it has been running an hour and a hlaf | 01:27 |
| jelmer | sm: it takes about 20 minutes here | 01:28 |
| jml | lifeless: bzr pull is noticeably faster. | 01:28 |
| sm | jelmer: on a macbook ? | 01:28 |
| jelmer | sm: ah, no, sorry - linux | 01:28 |
| jml | lifeless, spiv: congratulations! | 01:29 |
| lifeless | thanks | 01:29 |
| jml | hmm. making a new stacked branch is still kind of slow. | 01:32 |
| jml | I wonder if bumping our format to 1.9 would change that. | 01:32 |
| lifeless | do you have the patches we landed yesteday? | 01:32 |
| jml | lifeless: only if they are in the nightly -- I'll update my bzr.dev and try pushing with that. | 01:33 |
| lifeless | well, whats your nightly version? | 01:33 |
| jml | lifeless: 1.14~bzr8.10-4223-1 | 01:34 |
| jml | lifeless: down from 81 -> 66 calls using bzr.dev. still the same elapsed time. | 01:35 |
| lifeless | jml: ok, thats interesting | 01:37 |
| lifeless | pop the log up somewhere | 01:37 |
| jml | lifeless: http://paste.ubuntu.com/142445/ -- first is using nightly, second is bzr.dev | 01:39 |
| jml | both are pushes of the same branch to Launchpad but to different locations. branch was made locally from a mirror of the default stacked-on branch. so no new revision data for either push. | 01:40 |
| Snova | What would be the best way to have a particular file updated every commit to include a revision number? I think I could use a hook for it, but it looks like I would have to require it be installed on all committer's computers. | 01:44 |
| Peng_ | Snova: Well, that's what the new keyword plugin is for, although it just applies to the working tree, not the history itself, like svn:keywords. | 01:45 |
| Peng_ | Snova: That'd mean you only need the people who actually need the revision numbers to install it. | 01:45 |
| Peng_ | Snova: Anyway, the usual workaround is to have your Makefile run "bzr version-info >whatever". | 01:45 |
| lifeless | Snova: what do you want to achieve with this? | 01:46 |
| Snova | lifeless: I'd like the server I'm writing to send the revision number along with the version. | 01:46 |
| lifeless | Snova: of the codebase its running? | 01:47 |
| Snova | Yes. | 01:47 |
| lifeless | as Peng says, invoking bzr version-info during server startup is probably better | 01:47 |
| Snova | I could, but then it assumes it's always in a branch... a source tarball or any form of distribution wouldn't... although I primarily want this during development, if I actually released it there wouldn't be much point. | 01:48 |
| === ja1 is now known as jam | ||
| Snova | I guess that works, and it's the simplest way. | 01:49 |
| lifeless | you can hook that into your tarball export logic too | 01:49 |
| spiv | lifeless: http://bugs.python.org/issue5660 | 01:55 |
| spiv | jml: well, we think we have stuff in the works that will cut another ~10s out of that fairly soon (needs new verbs, though). | 02:00 |
| spiv | jml: thanks for the log | 02:01 |
| AfC | Hooray for Bazaar! | 02:01 |
| jml | spiv: cool. | 02:01 |
| lifeless | jml: so if you're lucky, 1.14 on the server and client will fix it | 02:02 |
| lifeless | if you're not, it won't :) | 02:02 |
| jml | if I'm extra double lucky, we might get an edge codehosting service so we can run 1.14 on the server before the next LP release. | 02:02 |
| lifeless | when is the next release? | 02:04 |
| jml | lifeless: four weeks from today | 02:04 |
| Peng_ | What would the edge codehosting do? Have a second copy of everything? Would the main and edge instances both pull mirrored branches? | 02:09 |
| spiv | jml: btw, my locations.conf for my bzr branches now defaults to lp | 02:12 |
| jml | spiv: nice! | 02:14 |
| spiv | 67 HPSS calls, 48s (including SSH handshake) and 207k to push up a new branch with a new revision. Not too bad. | 02:14 |
| jml | Peng_: it would just be the SSH server & surrounds. There would be no edge puller. | 02:14 |
| jml | Peng_: it would use the same data and be in every way analogous to the edge web service | 02:14 |
| spiv | jml: uh | 02:15 |
| spiv | jml: bzr: ERROR: Server sent an unexpected error: ('error', '<ProtocolError for xmlrpc.lp.internal:8097/branchfilesystem: -1 >') | 02:15 |
| spiv | jml: that was on a Branch.unlock RPC on an empty push | 02:15 |
| jml | spiv: hmm. I bet it's an operational glitch. | 02:16 |
| spiv | jml: maybe the XML-RPC server was unreachable temporarily for the "hey please rescan this branch" ping? | 02:16 |
| spiv | jml: how hard would it be to get that message to a) have an OOPS code, and b) make it clear that LP is to blame, not the client? :) | 02:16 |
| jml | spiv: if you asked me, I would have thought that the OOPS was already in it. | 02:18 |
| spiv | jml: I see! | 02:18 |
| spiv | jml: So that means there is probably already an OOPS generated, at least? That's nice! | 02:19 |
| spiv | jml: btw, it does seem to be a transient issue, a second attempt at the empty push worked just fine, rather than erroring on the final (13th! spooky!) RPC. | 02:20 |
| spiv | jml: In my magical land of perfect software and ponies, and temporary inability to reach xmlrpc.lp.internal wouldn't break anything... | 02:21 |
| jml | https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/281042 | 02:21 |
| ubottu | Error: This bug is private | 02:21 |
| spiv | s/and/an | 02:21 |
| jml | describes such a land. except that it's private, for reasons that elude me at present. | 02:21 |
| spiv | jml: ah, yes, I guess it was a timeout, judging from the 20s + a bit it took between request and error response. | 02:22 |
| * spiv clicks the hard-to-find "me too" link. | 02:23 | |
| spiv | (Something seems wrong when it's easier to add a "me too" comment than use the "me too" feature...) | 02:23 |
| beuno | spiv, yes. Quite a few things, actually. Hopefully, we'll address that in 2.2.5 with the change in the bug lauout page | 02:26 |
| jml | spiv: fwiw, https://bugs.edge.launchpad.net/launchpad-bazaar/+bugs?field.tag=codehosting-ssh is actually a fairly complete list of bugs in the codehosting server | 02:27 |
| jelmer | spiv: btw, what's the status of your ~ patch? | 02:27 |
| spiv | jelmer: limbo; I need to find some spare time to rewrite along the lines poolie wanted to see if I'm happy with his approach | 02:28 |
| spiv | jelmer: I think I'll be fine with poolie's approach (although his approach does need a new server, which is a minor drawback), but it needs to be implemented... | 02:29 |
| jelmer | spiv: ah | 02:30 |
| spiv | (on the other hand my approach needs a new client and his doesn't...) | 02:31 |
| cody-somerville | Could someone take a look at lp:xubuntu-docs and see if there is anyway we can improve performance? Branching and pushing seems to take a very long time on it | 02:44 |
| lifeless | cody-somerville: use bzr 1.14 | 02:45 |
| lifeless | cody-somerville: and be sure you have done bzr launchad-login | 02:45 |
| cody-somerville | I have | 02:45 |
| cody-somerville | I'm using 1.13 | 02:45 |
| cody-somerville | is 1.14 in the ppa? | 02:46 |
| lifeless | in the nightly ppa yes | 02:46 |
| igc | jelmer: jam has suggested that the filter registration function just take a callable, not a dict and a callable | 02:46 |
| igc | jelmer: I think it's a good idea. OK with you if I put a patch up for that? | 02:46 |
| igc | we want the API stable for 1.14 | 02:46 |
| spiv | cody-somerville: also, have you tried branching and pushing since the lp rollout that happened an hour or so ago? | 02:47 |
| cody-somerville | I just branched | 02:47 |
| spiv | cody-somerville: I'm doing a branch now, and it's streaming to me here in Sydney at ~150K/s | 02:48 |
| spiv | (which I believe is the capacity of this ADSL link) | 02:49 |
| lifeless | (I have a 1.5MB connection, so thats 1.2MB used by bzr | 02:49 |
| lifeless | cody-somerville: and how long did it take to branch? | 02:50 |
| lifeless | cody-somerville: [you are aware you have 30Mb of history] | 02:50 |
| cody-somerville | Yea, I figure thats what the problem is | 02:51 |
| cody-somerville | I did some nasty stuff to get the revision history to show correctly | 02:51 |
| beuno | cody-somerville, and, you could use a shared repo, so you only download whatever revision once in a life time | 02:51 |
| cody-somerville | I am using a shared repo | 02:51 |
| lifeless | cody-somerville: "12:46 < lifeless> cody-somerville: and how long did it take to branch? | 02:52 |
| lifeless | " | 02:52 |
| beuno | so it should be very fast after you did it oncec...? | 02:52 |
| beuno | once even | 02:52 |
| cody-somerville | lifeless, about a minute | 02:52 |
| spiv | "time bzr branch lp:xubuntu-docs" here just took 4m23.953s, which seems to be about as fast as this ADSL link allows. | 02:52 |
| spiv | Given that it had to fetch ~36M | 02:52 |
| lifeless | cody-somerville: do another branch with -Dhpss please, and we can look at the network activity if you grab the log for that bzr command from your ~/.bzr.log | 02:53 |
| cody-somerville | okay | 02:53 |
| === timchen119 is now known as nasloc__ | ||
| lifeless | 60 seconds is long to figure out you have everything locally, unless you didn't branch into your shared repo | 02:55 |
| cody-somerville | I did and am again | 02:55 |
| lifeless | oh; also try 'time bzr checkout --lightweight $SOME_LOCAL_BRANCH /tmp/foo' | 02:55 |
| spiv | lifeless: FWIW, that takes less than 1s here. | 02:57 |
| lifeless | cody-somerville: ping; 1 minute should have finished ages back | 03:00 |
| cody-somerville | lifeless, It takes a long time to copy and paste the log :P | 03:00 |
| lifeless | cody-somerville: I'm kindof paying attention here to give you a fast turnaround; if you're going away to do stuff let me know and I'll get back to coding | 03:00 |
| cody-somerville | http://pastebin.ubuntu.com/142472/ | 03:00 |
| cody-somerville | No, just takes a long time to copy and paste 6078 lines | 03:01 |
| lifeless | you missed the top of the log even so :) | 03:01 |
| cody-somerville | Before that is log stuff about another command I did | 03:01 |
| cody-somerville | oh wait | 03:02 |
| cody-somerville | nvm | 03:02 |
| lifeless | cody-somerville: don't worry | 03:02 |
| lifeless | you're not using a shared repo | 03:02 |
| lifeless | so its copying everything | 03:02 |
| cody-somerville | http://pastebin.ubuntu.com/142475/ | 03:02 |
| cody-somerville | oh... I guess you're right | 03:03 |
| cody-somerville | I thought I had created that | 03:03 |
| cody-somerville | btw, I did bzr check and it said this: http://pastebin.ubuntu.com/142477/ | 03:04 |
| cody-somerville | Is an inconsistent parent bad? | 03:05 |
| lifeless | its something to fix | 03:05 |
| lifeless | bzr reconcile will fix it | 03:05 |
| cody-somerville | lifeless, So I moved a bunch of files - when I merge from the parent, which hasn't moved the files, will bzr do the right thing or will they go to the old location? | 03:06 |
| lifeless | cody-somerville: why don't you try ?:) | 03:07 |
| cody-somerville | lifeless, cause the branch is reconciling atm or I would ;) | 03:07 |
| cody-somerville | oh, that was quick | 03:07 |
| cody-somerville | lifeless, would a repack help make the branch smaller? | 03:09 |
| lifeless | cody-somerville: no | 03:10 |
| lifeless | bzr repacks itself as it needs to | 03:10 |
| cody-somerville | what about that obsolete_packs directory? | 03:12 |
| cody-somerville | is that maybe causing the download to be more than it needs to be? | 03:12 |
| spiv | No, it doesn't affect downloads at all. | 03:13 |
| cody-somerville | hmm... the branch seems to be bigger now than before | 03:13 |
| lifeless | cody-somerville: 1 minute is not long | 03:14 |
| spiv | You have 36M of actual revision history, which doesn't sound so unlikely for nearly 200 revisions of a 5.9M tree of files. | 03:14 |
| cody-somerville | Its 77M on disk | 03:14 |
| lifeless | cody-somerville: all seems to be working reasonably; its under a second to make a working tree, and with a shared repo new branches hsould be about 3 seconds or less | 03:14 |
| lifeless | cody-somerville: thats because of the reconcile; ignore it | 03:14 |
| lifeless | cody-somerville: housekeeping will take care of it | 03:15 |
| cody-somerville | lifeless, so will this reconcile get pushed to launchpad? | 03:15 |
| lifeless | cody-somerville: no | 03:15 |
| lifeless | launchpad needs to be reconciled separately | 03:15 |
| cody-somerville | should I do that? | 03:15 |
| lifeless | if you like | 03:16 |
| cody-somerville | what exactly am I fixing? | 03:16 |
| cody-somerville | Will it make merging easier or something? | 03:16 |
| lifeless | what revisions annotate will attribute content to | 03:16 |
| lifeless | cody-somerville: generally speaking you shouldn't need to worry or do anything special with bzr to make it perform well; the one key exception is shared repositories | 03:18 |
| lifeless | and the second key exception is using a smart server if one is available (which lp: does for you once you login, and bzr+ssh/bzr+http do elsewhere) | 03:18 |
| exarkun | Hey I discovered the super awesome "bzr join" command without any help from mwhudson but the only problem is that I can't figure out how to use it would anyone like to assist me | 03:26 |
| exarkun | I have two unrelated branches and I want to make one of them just be part of the other one. | 03:26 |
| cody-somerville | hmm... | 03:28 |
| cody-somerville | bzr doesn't seem to have done the right thing :( | 03:28 |
| cody-somerville | and ugh.. "1432 conflicts encountered". | 03:28 |
| lifeless | exarkun: use the bzr merge-into plugin; join is part of an as-yet unreleased feature | 03:29 |
| lifeless | cody-somerville: did it print 'criss cross merge' at the top ? | 03:29 |
| cody-somerville | no | 03:29 |
| lifeless | thats very odd then | 03:30 |
| lifeless | what are the conflicts? | 03:30 |
| lifeless | and when you say you did nasty things, could you be more specific | 03:30 |
| lifeless | I'm going to guess you've been doing history-glueing in some nasty manner, and it is [predictably] biting you | 03:31 |
| cody-somerville | Well, I took branch A and branch B | 03:31 |
| exarkun | lifeless: Oops! I figured out how to use bzr join while I wasn't looking at IRC. | 03:32 |
| cody-somerville | A wasn't based on branch B | 03:32 |
| exarkun | lifeless: Should I start over with merge-into? | 03:32 |
| cody-somerville | But really was | 03:32 |
| lifeless | exarkun: if it has worked, go for it. | 03:32 |
| exarkun | okay cool, thanks :) | 03:32 |
| cody-somerville | So I merged B into A using -c 1 | 03:32 |
| cody-somerville | That worked fine and I got what I wanted except I lost all the revision history from branch B and some people didn't like that | 03:32 |
| lifeless | cody-somerville: when you say 'a wasn't based on branch b' do you mean 'they were completely separate projects' ? | 03:33 |
| cody-somerville | No, it was Xubuntu docs and Ubuntu docs | 03:33 |
| cody-somerville | They're similar but the branches didn't have shared revision history because Matthew restarted all the branches from scratch for some reason | 03:33 |
| cody-somerville | I imagine for performance reasons | 03:33 |
| lifeless | ok, which means 'they were completely separate projects' | 03:34 |
| lifeless | no history -> separate projects | 03:34 |
| cody-somerville | Right | 03:34 |
| cody-somerville | B was based on C | 03:34 |
| lifeless | you should use 'bzr merge-into' to join them. | 03:34 |
| cody-somerville | and now I'm trying to merge C into B | 03:34 |
| cody-somerville | Oh I missed a part | 03:35 |
| cody-somerville | I removed everything in B and put in the contents from A to get the history back | 03:35 |
| cody-somerville | and then I merged A into B to get the metadata | 03:35 |
| cody-somerville | B *is* based off of C and now I'm trying to merge C into B | 03:36 |
| lifeless | well | 03:37 |
| lifeless | you might try merge --weave | 03:37 |
| cody-somerville | I moved a ton of stuff into a subdirectory | 03:37 |
| lifeless | it may do better | 03:37 |
| lifeless | did you move using 'bzr mv' ? | 03:37 |
| cody-somerville | so now I have a bunch of files in the old directory ending with .BASE and .OTHER | 03:37 |
| cody-somerville | lifeless, I did in A, yea | 03:37 |
| lifeless | or did you move by doing 'mv; bzr add' ? | 03:37 |
| cody-somerville | I did bzr move | 03:38 |
| cody-somerville | but in A | 03:38 |
| lifeless | is A merged into C or B or neither? | 03:38 |
| cody-somerville | into B | 03:38 |
| cody-somerville | so should I do: bzr remerge --merge-type weave --reprocess | 03:41 |
| * cody-somerville tries | 03:42 | |
| cody-somerville | lifeless, If this doesn't work, would branching C and doing the moves over again and then merging that into B work and make future merges of C work? | 03:43 |
| cody-somerville | hmm... only 1324 conflicts this time | 03:43 |
| cody-somerville | but didn't do the right thing. bzr diff desktop-guide (the directory I moved almost all the directories into) returns nothing. | 03:44 |
| lifeless | cody-somerville: what would you expect it to return? | 03:45 |
| cody-somerville | lifeless, The changes bzr merged in? | 03:45 |
| cody-somerville | lifeless, bzr isn't touching any of the files already in the branch | 03:47 |
| cody-somerville | lifeless, all the conflicts are on files its added | 03:47 |
| cody-somerville | I'm also getting this error now trying to branch inside the shared repository I created: http://pastebin.ubuntu.com/142494/ | 03:50 |
| lifeless | cody-somerville: you ran 'bzr init-repo' to make the shared repository, yes? | 03:52 |
| cody-somerville | yup | 03:52 |
| lifeless | cd to the root of the shared repo | 03:52 |
| cody-somerville | okay | 03:52 |
| lifeless | and run bzr upgrade --default-rich-root | 03:52 |
| cody-somerville | bzr: ERROR: no such option: --default-rich-root | 03:53 |
| lifeless | 'use bzr 1.14' :) | 03:53 |
| lifeless | hell you're canonical, you should be using the nightly ppa :) | 03:53 |
| cody-somerville | ;p | 03:55 |
| cody-somerville | also, I just got this when trying to do bzr remove */po/*.po: bzr: ERROR: [Errno 24] open: Too many open files: '.' | 03:55 |
| SamB | hmm, I wish that the GNOME vcs-imports branches weren't the default branches :-( | 04:40 |
| spiv | SamB: if there's a better branch to use, file a request at https://answers.launchpad.net/launchpad-bazaar asking for the default to be changed. | 05:20 |
| SamB | spiv: well, in #launchpad they've got me seeing if I was using a bleeding-edge enough bzr that they should have fixed the problem where it takes forever to push to a branch with little to no shared history with the branch it is to be stacked on ... | 05:21 |
| spiv | SamB: ah, yes. We keep fixing bugs :) | 05:22 |
| spiv | SamB: but even so, if there's a better branch, do let the relevant people know | 05:23 |
| SamB | and they said something about how GNOME is supposed to be switching to git | 05:23 |
| SamB | so that the bzr-playground branches might not be that great for too long | 05:24 |
| spiv | SSH handshake time is now well over a third of the overall time in random incremental pushes to my branches on LP. | 05:31 |
| SamB | oh, incremental pushes seem fine | 05:32 |
| spiv | SamB: I'm opening to changing the message if it can be less confusing | 05:49 |
| spiv | SamB: but I figured I should explain why it is saying that (and why it's not "lying"). | 05:49 |
| SamB | Well, "transferring" is a much more neutral word | 05:49 |
| SamB | if it can't be bothered to figure out which of the two activities it is engaged in is taking all the time ... | 05:49 |
| spiv | I'm not sure what you mean by that comment? | 05:50 |
| spiv | The activity is (accurately, by its choice of perspective) called "fetching". | 05:50 |
| SamB | well, it's not waiting on the fetches from the local repository ... it's waitng on the stores to the other one | 05:50 |
| spiv | Not really, those things aren't really decoupled. | 05:51 |
| SamB | well, okay, in that case the word is "transfer" | 05:51 |
| lifeless | so | 05:52 |
| lifeless | we're going to overhaul this | 05:52 |
| lifeless | and make it prettier | 05:52 |
| SamB | at least, in en_US that's the case | 05:52 |
| lifeless | transfer is indeed a synonym | 05:52 |
| lifeless | or nearly so | 05:52 |
| lifeless | at the right point in the code | 05:52 |
| SamB | maybe in en_AU or en_UK, fetch is more synonymous with transfer? | 05:52 |
| lifeless | but one of the basic problems is that the code doesn't *know* which end of the pipeline the human is sitting | 05:53 |
| lifeless | so really, a more directional adverb to describe what is going on isn't easy to correlate with the UI | 05:53 |
| SamB | well ... saying "transfer" is a nice and neutral thing to do in that case | 05:53 |
| SamB | or when, say, both repos are local | 05:53 |
| lifeless | sure, thats one way we can alter the message | 05:53 |
| lifeless | all I'm trying to say is: | 05:54 |
| lifeless | - it is broken at the moment | 05:54 |
| SamB | okay, yeah, I gathered ;-) | 05:54 |
| lifeless | - its not top of the pops for time until the rc | 05:54 |
| lifeless | - until then, I don't plan on thinking too hard about it | 05:54 |
| lifeless | (so please forgive me for simply acking that its an issue, until we're looking at the code, finding a combination that reads well and fits the code isn't necessarily easy | 05:55 |
| lifeless | the code itself *is* highly directional | 05:55 |
| SamB | you know, I guess I don't need to finish this push ;-) | 05:57 |
| lifeless | SamB: is it still slow? | 05:57 |
| SamB | it's just that I was just pushing the same thing to a new branch | 05:58 |
| SamB | so now that I've established that it was just a confusing progress message, I don't need to finish | 05:58 |
| lifeless | oh :) | 05:58 |
| lifeless | makes sense to me | 05:58 |
| vila | lifeless: did you see my patch about --parallel ? | 06:29 |
| lifeless | no | 06:31 |
| vila | lifeless: ~one liner to make it work but I think you're the one that can review it | 06:33 |
| lifeless | where is it | 06:49 |
| lifeless | vila: ^ | 06:57 |
| vila | http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2iqlozk7x.fsf%40free.fr%3E | 06:57 |
| lifeless | # A registry where get() returns a suite decorator. | 06:58 |
| lifeless | parallel_registry = registry.Registry() | 06:58 |
| lifeless | + | 06:58 |
| lifeless | + | 06:58 |
| lifeless | def fork_decorator(suite): | 06:58 |
| lifeless | those changes are bogus , PEP8 allows adjacent for things that are closely related | 06:59 |
| lifeless | specifically I want the FOO_decorator and register..FOO adjacent | 06:59 |
| lifeless | vila: reviewed | 07:05 |
| vila | lifeless: still ok to separate each couple ? | 07:15 |
| lifeless | sure | 07:18 |
| === serg_ is now known as serg | ||
| === serg is now known as anyone | ||
| === anyone is now known as serg | ||
| VSpike | If I do bzr revert on a file, does that count as a change? IOTW, if I commit it, will it commit the reverted file as a head revision? | 11:43 |
| luks | bzr revert is no different from manually changing the working tree | 11:45 |
| luks | plain 'bzr revert' will just revert to the head revision, so it wouldn't commit anything | 11:45 |
| VSpike | Ah OK - thanks. I used to use perforce, and that behaved quite differently IIRC. It would rememeber what revision number of each file you currently have in your working tree. | 11:46 |
| luks | hm? | 11:46 |
| VSpike | So pulling out an old version to look at was not a change. | 11:46 |
| luks | ah | 11:46 |
| luks | no, bzr revert operates purely on the working tree, you can do something like 'bzr cat -r file >file' and it will be more or less the equivalent | 11:47 |
| VSpike | Right - makes sense. Thanks! | 11:47 |
| awilkins | jelmer/vila: would authentication.conf have problems with passwords that contain @ characters? | 12:18 |
| awilkins | Specfically, if I put my password in the file, it fails, remove it and I get prompted more than once for each bzr-svn push | 12:19 |
| vila | awilkins: quote it | 12:21 |
| awilkins | Aha | 12:21 |
| awilkins | vila: Failed | 12:22 |
| vila | awilkins: :-/ quoted as in user@host => user%40host ? | 12:23 |
| awilkins | Ah, as in "c@r" | 12:23 |
| vila | awilkins: sorry, I meant url encode it | 12:23 |
| awilkins | Hmmph, still not working | 12:24 |
| awilkins | Although by now I may have locked out my account I suppose | 12:25 |
| awilkins | Nope, still works fine at the command line | 12:25 |
| vila | awilkins: what protocol are you using ? | 12:25 |
| awilkins | svn+http | 12:25 |
| vila | you mean bug #256612 ? | 12:26 |
| ubottu | Launchpad bug 256612 in bzr "should prompt for usernames during HTTP Basic/Digest auth" [High,In progress] https://launchpad.net/bugs/256612 | 12:26 |
| vila | or some related problem ? | 12:26 |
| awilkins | THe username is correctly being picked up from auth.conf with is set up for the host | 12:27 |
| awilkins | If I add the password it failes | 12:27 |
| vila | I thought connecting succesfully with *svn* was the current work-around | 12:27 |
| awilkins | Yes, I thought I'd done that | 12:27 |
| awilkins | Although it was with TSVN | 12:27 |
| awilkins | I'll try getting it cached in the CLI client also | 12:27 |
| awilkins | That works | 12:29 |
| vila | good, then you encountered the bug above or something very close | 12:30 |
| awilkins | It's obviously using the password when it's provided in the conf file, but it appears to be wrong | 12:33 |
| === ja1 is now known as jam | ||
| spiv | lifeless, jml: they've fixed the deepcopy(TestCase(...)) bug | 12:56 |
| spiv | lifeless, jml: but you might want to take a look at the new TestCase.addTypeEqualityFunc method | 12:58 |
| fbond | jelmer: I imported an svn repository with bzr-svn's svn-import. I see "svn revno: x" in log output, but I can't use -r svn:x. Why not? | 13:33 |
| === sabdfl1 is now known as sabdfl | ||
| === NEBAP is now known as NEBAP|work | ||
| === NEBAP|work is now known as NEBAP|away | ||
| === NEBAP|away is now known as NEBAP|work | ||
| jelmer | fbond: you need a newer version of bzr-svn to do that on imported branches | 14:17 |
| jelmer | igc: yeah, just taking a callback sounds good to me | 14:18 |
| fbond | jelmer: Okay, thanks. | 14:18 |
| fbond | jelmer: I'm using trac-bzr; it'd be really swell if I could get the old references to svn revisions work in the diff viewer. ;) | 14:19 |
| fbond | I mean [283] links and whatnot. | 14:19 |
| === ja1 is now known as jam | ||
| === abentley1 is now known as abentley | ||
| jelmer | vila: bleh, I'm not sure how I missed that appearance of 'password' | 15:04 |
| vila | jelmer: :-) | 15:04 |
| jelmer | vila: I did actually refactor that function but changed it back after I noticed it broke for LC_ALL=C | 15:05 |
| vila | jelmer: huh ? the one you copy from has been passing for ages or did I miss something ? | 15:07 |
| jelmer | vila: Yes, but I changed it after I copy pasted it | 15:07 |
| vila | haaa :) | 15:07 |
| jelmer | vila: and that broke the tests, so I fixed it and ended up with what the original did :-) | 15:08 |
| jelmer | vila: Your NotATerminal patch looks ok, with one minor concern | 15:08 |
| jelmer | vila: won't this caused backtraces when there's no terminal? | 15:08 |
| jelmer | getpass() will raise an exception that's not caught atm | 15:08 |
| vila | jelmer: which exception ? EOFError ? | 15:10 |
| jelmer | vila: termios.error | 15:10 |
| jelmer | in my case: | 15:11 |
| jelmer | termios.error: (25, 'Inappropriate ioctl for device') | 15:11 |
| jelmer | including backtrace | 15:11 |
| vila | and the backtrace leads to what ? 'sys.stdin.readline()' or some termios call ? | 15:12 |
| jelmer | vila: getpass.py line 32 | 15:13 |
| jelmer | that's indeed a termios call in getpass() | 15:14 |
| vila | jelmer: grr | 15:14 |
| vila | stream=None => stream = sys.stdout, damn, I explicitely avoid using a prompt and see what happens ! :) | 15:14 |
| vila | vila: oh no, it's indeed related to stdin | 15:15 |
| vila | hmm, so that's why NotATerminal was there :-/ | 15:17 |
| jelmer | vila: ah, right | 15:20 |
| jelmer | good I did some testing then :-) | 15:21 |
| jelmer | vila: So NotATerminal can't be removed, but your other refactoring is still valid right? | 15:21 |
| vila | jelmer: indeed ! | 15:21 |
| vila | jelmer: No | 15:22 |
| vila | hmm, or may be we just need to put raise NotATerminal in get_password... | 15:22 |
| vila | Urgh, how ugly, the user can enter its login but not its password | 15:22 |
| vila | no, I think the right fix is to either call readline() or getpass depending on stdin.isatty() or something like that | 15:25 |
| vila | turning echo off makes sense only on a tty and that's the reason we want to use getpass | 15:25 |
| jelmer | vila: sounds reasonable | 15:26 |
| === thunderstruck is now known as gnomefreak | ||
| === thunderstruck is now known as gnomefreak | ||
| exarkun | If I committed with a bad username, is there a way to fix those revisions to use a new value for that field? | 16:02 |
| LeoNerd | Only by uncommit/recommit | 16:05 |
| LeoNerd | Or variants thereof.. The internal revision ID uses a hash of the data, collectively. So changing the data would change the hash, and hence the revid | 16:05 |
| jelmer | vila: will you submit a new patch? | 16:06 |
| vila | I think so, but not in the coming minutes nor hours I'm affraid | 16:07 |
| jelmer | vila: thanks, no hurry :-) | 16:08 |
| jelmer | vila: and thanks for the work on this auth stuff, hopefully bzr/bzr-svn 1.14 will be the first bzr where this stuff works properly | 16:09 |
| vila | jelmer: np, I'd still like feedback from the other devs about utf8 encoding | 16:09 |
| exarkun | LeoNerd: Thanks | 16:09 |
| vila | jelmer: I noted that you didn't *call* get_username, are you planning to work on that ? | 16:09 |
| vila | jelmer: yeah hopefully, but as you see, evils is in the details :) | 16:10 |
| === serg_ is now known as serg | ||
| jelmer | vila: don't call it in what sense? | 16:10 |
| jelmer | vila: get_user() would use it | 16:11 |
| vila | oooh, yes, indeed, the other patch, ok | 16:11 |
| jelmer | vila: speaking of which.. | 16:11 |
| vila | then will you update that one to take into account the other calls to getpass.getuser() / | 16:12 |
| vila | s!/!?! | 16:12 |
| jelmer | vila: you mentioned that http uses get_user() atm and the others use getpass.getuser() | 16:12 |
| vila | yup, that point :) | 16:12 |
| jelmer | vila: Just to make sure; they should all call get_user() but get_user() should default to getpass.getuser() ? | 16:13 |
| jelmer | vila: You also mentioned something about only prompting if a prompt was specified | 16:13 |
| vila | jelmer: yes, except that defaulting should be the default but http can overrride it | 16:13 |
| vila | ha, I didn't think about using the prompt for that... | 16:14 |
| jelmer | vila: so defaulting is directly returning getpass.getuser() or rather printing "[DEFAULT]" and letting the user just hit <enter> to use that? | 16:14 |
| vila | ...I was thinking about a new, optional, parameter... | 16:15 |
| vila | no | 16:15 |
| vila | we don't want to require pressing enter where we didn't before | 16:15 |
| jelmer | ok | 16:15 |
| vila | when we default to getpass.getuser... we default period. You can ask for feedback but I doubt we want to change that | 16:16 |
| jelmer | vila: ok, so I won't touch anything but http at the moment | 16:16 |
| jelmer | vila: what would you like to change in case of http? | 16:16 |
| jelmer | is it ok to require pressing <enter> or entering a username there if there's no user specified in authentication.conf ? | 16:17 |
| vila | jelmer: I think you should change ftp/ssh/http, call ui.get_username() from config.get_user() but only if required via a parameter (i.e. http only) and get rid of the getpass.getuser() calls in ftp/ssh | 16:17 |
| vila | just do a grep getpass you'll understand easily I'm sure | 16:18 |
| jelmer | vila: ah, ok | 16:19 |
| jelmer | vila: so, just to make sure: | 16:19 |
| jelmer | vila: I'd add a new parameter to get_user() that specifies whether or not to ask the user | 16:19 |
| jelmer | vila: and only http for now sets that parameter to true | 16:20 |
| vila | exactly | 16:20 |
| exarkun | So once I do the uncommit/commit dance to get my username right in the revisions, if I want to fix what's on launchpad, should I do a push --overwrite? | 16:21 |
| vila | sounds like the cleanest way while still allowing get_username to get overwritten by GUIs with the usual mechanism | 16:21 |
| jelmer | exarkun: yes | 16:21 |
| exarkun | cool | 16:22 |
| === abentley1 is now known as abentley | ||
| === thunderstruck is now known as gnomefrak | ||
| === gnomefrak is now known as gnomefreak | ||
| === LenzGr is now known as LenzGr|dinner | ||
| nilg | hi, I've made bzr rm file, on the wrong file, is there anyway to get it back simply? | 18:42 |
| nilg | I haven't committed yet | 18:42 |
| luke-jr | is there a bzr-cvs plugin? | 18:46 |
| nilg | hi, I've made bzr rm file, on the wrong file, is there anyway to get it back simply? | 18:50 |
| luke-jr | bzr revert file? | 18:50 |
| nilg | luke-jr, it works thanks a lot (I got scared for a second) | 18:52 |
| ricardokirkner | hi jelmer, I am having some issues with bzr-svn, that I saw were supposedly fixed in bzr 1.6. I am using bzr 1.13 with bzr-svn from launchpad, and am still getting python: subversion/libsvn_subr/path.c:414: svn_path_is_empty: Assertion `is_canonical(path, strlen(path))' failed. | 19:43 |
| ricardokirkner | when trying to push to upstream | 19:43 |
| fbond | Any way to get a series of patches for a series of commits? | 19:53 |
| fbond | (In one command, or so.) | 19:53 |
| fbond | Hm, I guess I'll just shell script it. | 19:54 |
| jfroy | Any thoughts on https://bugs.launchpad.net/bzr/+bug/354036? | 19:56 |
| ubottu | Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,New] | 19:56 |
| jfroy | I suspect it may have to do with the recent Launchpad bzr 1.13 upgrade | 19:57 |
| jfroy | But that's speculation. | 19:57 |
| klbate | Hello! If I have pushed a commit but forgot to sign it, how can I push just the signature afterwards? | 19:57 |
| Peng_ | klbate: You can run "bzr sign-my-commits", but I dunno if pushing afterwards will push the new signatures. | 19:57 |
| klbate_ | Sorry, was disconnected... | 19:59 |
| klbate_ | In Git there is something like 'push --tags', is there a bzr equivalent? | 20:00 |
| Peng_ | klbate_: "bzr push" will silently push new tags, so it's a reasonable assumption that it will do the same with signatures. | 20:02 |
| Peng_ | It's worth a try, at least. | 20:03 |
| ricardokirkner | jelmer, really sorry to insist... but whenever you can I would really appreciate it, as it's a blocker for me right now | 20:04 |
| luks | can somebody in the ~bzr lp group please copy the qbzr 0.9.9 packages from https://launchpad.net/~qbzr-dev/+archive/ppa to https://launchpad.net/~bzr/+archive/ppa ? | 20:17 |
| Peng_ | Huh, bzr just started whining about an invalid config file somewhere. | 20:29 |
| Peng_ | lifeless: ping | 20:33 |
| abentley | lifeless: ping | 20:37 |
| abentley | emmajane: Oh, hi. | 20:38 |
| emmajane | ola abentley :) | 20:38 |
| abentley | Ça va? | 20:39 |
| ricardokirkner | what options should I use in order to find out why bzr-svn is crashing? | 20:39 |
| emmajane | presque. :) | 20:39 |
| emmajane | I'm inside and it's nice outside. :) | 20:39 |
| emmajane | abentley, how's the weather down south today? | 20:41 |
| emmajane | abentley, someone told me we're getting another dump of snow. which makes me cry inside. | 20:41 |
| abentley | emmajane: It's not bad. You can get away without a jacket for a bit. But the clouds have rolled in today. | 20:42 |
| Peng_ | abentley: What are you pinging him about:? :D | 20:43 |
| emmajane | abentley, boo to the clouds. | 20:43 |
| abentley | Peng_: WorkingTree4.iter_references | 20:43 |
| Peng_ | abentley: Oh. | 20:43 |
| abentley | emmajane: Did you know Mike Audet's up in Peterborough nowadays? | 20:45 |
| emmajane | abentley, the nerve! what's he doing up there? | 20:46 |
| emmajane | abentley, my cousin is at Trent. :) | 20:47 |
| abentley | emmajane: Teaching, doing some programming on the side. | 20:47 |
| emmajane | abentley, sweet! | 20:47 |
| kfogel | it's fairly standard in bzr to use "r800" as an abbreviation for "revno 800", right? | 20:57 |
| kfogel | (Users Guide seems to indicate so, but only by implication...) | 20:57 |
| mwhudson | kfogel: i certainly do that quite a lot | 20:58 |
| kfogel | mwhudson: thx | 20:58 |
| Peng_ | kfogel: I picked up the habit from svn and still use it with bzr. | 20:58 |
| kfogel | Peng_: more confirmation, good | 20:59 |
| james_w | does -r handle "r800"? | 20:59 |
| kfogel | james_w: in svn, yes :-) | 21:00 |
| james_w | I thought I remembered a bug about it not doing so | 21:00 |
| Peng_ | Oh crap. I just reverted bzr to r3234 instead of r4234. Now it doesn't even recognize the branch format. :D | 21:04 |
| Peng_ | Thank goodness I had another copy of bzr around. | 21:04 |
| lifeless | Peng_: pong | 21:07 |
| lifeless | abentley: pong | 21:07 |
| abentley | lifeless: DirStateWorkingTree.iter_references raises and AttributeError if you don't lock the tree before use. I found this surprising. | 21:07 |
| abentley | s/and/an | 21:08 |
| lifeless | abentley: thats certainly a bug; I would expect it to raise, but not AttributeError | 21:08 |
| Peng_ | lifeless: Oh hi. I filed bug 354075 about what I was pinging you about, but forgot to unping you. | 21:09 |
| ubottu | Launchpad bug 354075 in bzr "Branch.get_config_file smart verb breaks get_bzr_remote_path" [Undecided,New] https://launchpad.net/bugs/354075 | 21:09 |
| lifeless | abentley: btw, how long does it take you to run the bzr test suite ? | 21:09 |
| nsh22 | hi umm, how do i merge two different lp branches? | 21:09 |
| abentley | lifeless: This is because you initialize DirStateWorkingTree._repo_supports_tree_reference when the tree is locked. | 21:10 |
| lifeless | nsh22: cd branch1 && bzr merge branch2 && bzr commit && bzr push | 21:10 |
| abentley | lifeless: Rather than at __init__ time, as you do with the RevisionTree. | 21:10 |
| nsh22 | lifeless: thx | 21:11 |
| abentley | lifeless: What's the reason for delaying that? | 21:11 |
| lifeless | abentley: I guess I was thinking of cases where 'bzr switch' was used and the backing repo facilities changed | 21:12 |
| abentley | lifeless: I dunno how long the suite takes. Maybe 25 minutes? | 21:12 |
| lifeless | abentley: with the bzr-ec2test plugin & 2 warmed up instances, its takes ~90 seconds. You might like to play :) | 21:12 |
| abentley | lifeless: In the 'switch' case, the tree would remain write_locked during the switch, so the _repo_supports_tree_reference would get stale, wouldn't it? | 21:22 |
| lifeless | abentley: possibly yes; I guess you're trying to see whether to work around [e.g. getattr, init to None etc] or to move it to __init__ - I'm happy either way, or even a third | 21:22 |
| lifeless | I'd suggest avoiding a getattr(), I don't think one is justified | 21:23 |
| abentley | lifeless: I'm also wondering if the win of caching that data on WT is worth it. Thoughts? | 21:24 |
| lifeless | if its accessed during the iter_changes outer loop it may be measurable on 'bzr st' timings | 21:25 |
| lifeless | abentley: oh, possibly it wasn't caching at all; maybe WT2 can't be right root ? | 21:28 |
| lifeless | and so we have tree code that correctly needs to ask the tree not the repo. | 21:28 |
| abentley | lifeless: I suppose that's useful when you're detecting subtrees and then forcing them to directories because of the repo. | 21:30 |
| lifeless | abentley: well also for 'add-reference' to fail correctly when the tree can't represent the add | 21:31 |
| abentley | lifeless: In that case, I don't think the caching is essential. | 21:31 |
| abentley | WT2 can implement add_reference to always raise... | 21:32 |
| lifeless | Peng_: so, what is 'bytes' | 21:46 |
| Peng_ | lifeless: Eh? | 21:50 |
| jelmer | ricardokirkner: hi | 21:53 |
| jelmer | ricardokirkner: are you using the latest bzr, bzr-svn and subvertpy? | 21:53 |
| ricardokirkner | hi jelmer, thanks | 21:53 |
| ricardokirkner | bzr 1.13 | 21:53 |
| ricardokirkner | latest bzr-svn | 21:53 |
| ricardokirkner | and subvertpy | 21:53 |
| ricardokirkner | yes | 21:53 |
| ricardokirkner | I have been tracing bzr, until I got to line commit.py:600 | 21:53 |
| jelmer | ricardokirkner: please run inside of gdb and pastebin the bracktrace | 21:53 |
| ricardokirkner | I'll do that | 21:54 |
| ricardokirkner | but maybe I have found the reason. let me explain | 21:54 |
| jelmer | ricardokirkner: subvertpy 0.6.5? | 21:54 |
| ricardokirkner | yes | 21:54 |
| ricardokirkner | and python 2.6 (64 bits) | 21:54 |
| ricardokirkner | the line that causes an abort, is when doing | 21:55 |
| ricardokirkner | ret.append(ret[-1].add_directory(name, copyfrom_url, base_rev)) | 21:55 |
| ricardokirkner | now, I just saw that copyfrom_url ends with a '/' | 21:55 |
| ricardokirkner | I from what I read, that is causing the svn abort | 21:56 |
| ricardokirkner | does this make sense? | 21:56 |
| jelmer | ricardokirkner: copyfrom_url doesn't matter in this case | 21:56 |
| jelmer | ricardokirkner: does path end in / ? | 21:56 |
| ricardokirkner | what path? | 21:57 |
| ricardokirkner | name? | 21:57 |
| jelmer | ricardokirkner: anyway, that backtrace would really be useful here.. | 21:57 |
| ricardokirkner | ok | 21:57 |
| ricardokirkner | sec | 21:57 |
| ricardokirkner | jelmer, http://ricardokirkner.pastebin.com/d3ec659ab | 22:00 |
| lifeless | mwhudson: is loggerhead bust? | 22:04 |
| lifeless | mwhudson: it shows me no diff for http://bazaar.launchpad.net/~geoff.bache/bzr/trunk/revision/4158 | 22:04 |
| mwhudson | lifeless: 'expand all' | 22:04 |
| lifeless | mwhudson: does nothing | 22:05 |
| Peng_ | lifeless: It's all Ajaxy now. Do you have JS disabled, or a weird browser? | 22:05 |
| mwhudson | lifeless: hmm, maybe shift-reload | 22:05 |
| Peng_ | lifeless: It works for me. | 22:05 |
| Peng_ | Oh, good point. | 22:05 |
| mwhudson | i keep meaning to vary the static urls by version... | 22:05 |
| lifeless | Peng_: epiphany, | 22:06 |
| lifeless | mwhudson: thanks | 22:06 |
| lifeless | mwhudson: and please do that, kthanksworking | 22:06 |
| jelmer | ricardokirkner: please try again with latest rev on subvertpy | 22:08 |
| ricardokirkner | jelmer, I installed subvertpy using easy_install, should I try downloading from trunk? | 22:09 |
| jelmer | ricardokirkner: yeah | 22:09 |
| ricardokirkner | ok | 22:09 |
| jelmer | lifeless: any chance you can have a look at my BzrDir.push() patch ? | 22:09 |
| lifeless | jelmer: sure, url | 22:12 |
| jelmer | lifeless: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090401141753.GA16842%40vernstok.nl%3E | 22:13 |
| ricardokirkner | jelmer, same thing :-( | 22:14 |
| jelmer | ricardokirkner: are you sure you're running the latest subvertpy | 22:14 |
| jelmer | ricardokirkner: oh, whoops | 22:14 |
| jelmer | ricardokirkner: push failed, one sec | 22:14 |
| ricardokirkner | oh | 22:14 |
| jelmer | ricardokirkner: pushed properly now, r2051 | 22:15 |
| Peng_ | lifeless: Oh, sorry I didn't understand you. I updated the get_bzr_remote_path bug. | 22:16 |
| Peng_ | Wait a minute, it's *supposed* to be the contents of branch.conf, so why is ConfigObj balking? | 22:17 |
| ricardokirkner | jelmer, :-( | 22:19 |
| jelmer | ricardokirkner: ? | 22:20 |
| ricardokirkner | same thing still happening | 22:20 |
| ricardokirkner | I checked and doublechecked | 22:20 |
| jelmer | ricardokirkner: backtrace? | 22:20 |
| jelmer | ricardokirkner: at least the line numbers should be different.. | 22:20 |
| ricardokirkner | ok, one sec | 22:21 |
| === abentley1 is now known as abentley | ||
| ricardokirkner | jelmer, http://ricardokirkner.pastebin.com/d767040a9 | 22:23 |
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| ricardokirkner | jelmer, I have to go now,.. will try again later | 22:32 |
| ricardokirkner | thanks a lot for your help | 22:32 |
| jelmer | ricardokirkner: I'm working on a fix | 22:33 |
| jelmer | ricardokirkner: to subvertpy | 22:33 |
| jelmer | should be committed in a few minutes | 22:33 |
| Peng_ | lifeless: ping | 22:39 |
| lifeless | Peng_: pong | 22:45 |
| Peng_ | lifeless: Hi. | 22:46 |
| lifeless | hawwo, was just responding, again, to the 1.14 delay thread | 22:46 |
| lifeless | hopefully Ian wins troll of the year award | 22:46 |
| lifeless | for his april first post | 22:46 |
| Peng_ | ? | 22:46 |
| lifeless | new 1.14rc date, was posted april 1st | 22:47 |
| Peng_ | Oh. | 22:47 |
| lifeless | he really needs to jump out about now in the thread and say 'april fools' | 22:47 |
| lifeless | :) | 22:47 |
| lifeless | anyway | 22:47 |
| Peng_ | lifeless: I was just pinging you because I want hand-holding through the get_config_file bug. :D | 22:48 |
| lifeless | right | 22:48 |
| lifeless | just change it to bytes.splitlines('\n') is probably enoug | 22:48 |
| lifeless | rather than [bytes] | 22:48 |
| lifeless | also config objs constructor blows chunks | 22:49 |
| Peng_ | I just used "splitlines()". That's what I wanted to ask. | 22:49 |
| lifeless | oh | 22:49 |
| lifeless | yeah that shold be fine | 22:49 |
| lifeless | working >> anything else | 22:49 |
| Peng_ | Is that alright? Should I only split on \n? | 22:49 |
| lifeless | splitlines should be ok | 22:49 |
| lifeless | jelmer: does bzrdir.push work for you? | 22:50 |
| BasicOSX | lifeless: thanks for the response regarding 1.14 RC date | 22:52 |
| BasicOSX | I think mbp should never go on another holiday again, ever! :-P | 22:53 |
| lifeless | BasicOSX: :) | 22:54 |
| Peng_ | lifeless: Anyway, the other thing I wanted to ask you about was adding a test. | 23:01 |
| Peng_ | Um. | 23:01 |
| lifeless | Either expand one of the test_remote.py tests for _get_config | 23:01 |
| lifeless | or add another in the same class | 23:01 |
| lifeless | just set two keys and then get one back | 23:01 |
| lifeless | should trigger | 23:01 |
| Peng_ | Um. | 23:03 |
| Peng_ | Pardon my dumbness, but I'm completely lost in the test suite. | 23:06 |
| lifeless | una momento | 23:07 |
| Peng_ | Wait, hold on. | 23:07 |
| Peng_ | I think I can just copy test_get_branch_conf. | 23:07 |
| Peng_ | Or I could just modify it to use a 2-line file. | 23:08 |
| Peng_ | Oh, interesting. ConfigObj(['# line 1\n# line 2\n'], encoding='utf-8') works. | 23:10 |
| Peng_ | You need non-comment lines to trigger the failure. | 23:10 |
| Peng_ | lifeless: Where should I add the test? test_remote.TestBranchControlGetBranchConf? That seems to be the only place it's tested. | 23:15 |
| Peng_ | lifeless: (I mean, in that file..) | 23:15 |
| lifeless | Peng_: yes, thats the unit test for it | 23:20 |
| Peng_ | lifeless: Should I modify the current test or add a new one? I'd prefer to do the latter, just...cuz. | 23:21 |
| lifeless | either is fine, new test is clearer | 23:22 |
| Peng_ | Okay. | 23:24 |
| Peng_ | Then...send it to the mailing list? :D | 23:24 |
| Peng_ | lifeless: If that email *was* an April Fool's joke, he definitely wins this year. That sparked a huge discussion! | 23:26 |
| lifeless | Peng_: sadly it wasn't | 23:29 |
| lifeless | Peng_: yah, [MERGE] it up | 23:29 |
| Peng_ | lifeless: Oh, too bad. | 23:29 |
| lifeless | it will need to be cherry picked to 1.14 too now :) | 23:29 |
| Peng_ | lifeless: ok | 23:29 |
| lifeless | jelmer: ping | 23:33 |
| lifeless | jelmer: does the BzrDir.push patch meet your needs, and is it mainly moved code? | 23:33 |
| jelmer | lifeless: yes and yes | 23:34 |
| yacoob | Hello there :) | 23:34 |
| lifeless | jelmer: land it | 23:34 |
| jelmer | lifeless: is that a bb:approve ? :-) | 23:34 |
| yacoob | a (perhaps stupid) question: provided I want to keep a set of config files in a bazaar repository, is there a way of saying 'get me this revision of this file from repo'? | 23:35 |
| lifeless | jelmer: not quite | 23:35 |
| lifeless | yacoob: bzr cat -r X this_file | 23:35 |
| jelmer | lifeless: so what do you mean exactly? | 23:36 |
| lifeless | I've reviewed | 23:36 |
| lifeless | BasicOSX: I too am a little confused | 23:37 |
| lifeless | BasicOSX: did you mean 'land bbc now' too ? | 23:37 |
| BasicOSX | lifeless: yes | 23:38 |
| lifeless | ok cool. | 23:38 |
| lifeless | we'll land on trunk and merge to the rc branch then - you might like to clarify that on the list :) | 23:38 |
| jelmer | lifeless: ? land it where ? | 23:38 |
| jelmer | lifeless: oh never mind | 23:39 |
| jelmer | lifeless: I hadn't seen your email reply | 23:39 |
| Peng_ | What's being landed where? | 23:41 |
| Peng_ | lifeless: Anyway, I think I sent it. My IMAP server is slow today, but SMTP probably works. | 23:42 |
| lifeless | Peng_: if I understand BasicOSX correctly; brisbane-core will go to bzr.dev asap (meaning a once-through review) and be cherry picked to 1.14 | 23:42 |
| lifeless | BasicOSX: ^ is that what you mean to have happen? | 23:42 |
| Peng_ | Cherry-picking hundreds of revisions consisting of thousands of lines of code sounds like "fun". | 23:43 |
| jelmer | hmm | 23:44 |
| * jelmer thinks one of the hot topics at the bzr sprint this year should be "parallel imports" | 23:45 | |
| johnjosephbachir | 'ello. bzr newbie here. i just did a couple commits, then did "uncommit" twice, then commited that. all seems to have behaved as epected, and bzr status shows no changes. BUT, the actual source tree has not been changed! | 23:47 |
| lifeless | johnjosephbachir: it would't have | 23:48 |
| johnjosephbachir | ORLY | 23:48 |
| Peng_ | johnjosephbachir: "uncommit" and "commit" don't change the working tree. | 23:48 |
| lifeless | uncommit pops a commit off, it doesn't revert the changes in your tree | 23:48 |
| BasicOSX | I was under the impression BC was in 1 branch that could be merges in bzr.dev? | 23:48 |
| lifeless | BasicOSX: it is | 23:48 |
| BasicOSX | :%s/merges/merged/ | 23:48 |
| johnjosephbachir | lifeless Peng_ okay cool cool... sooooo what do i do? :) | 23:48 |
| lifeless | johnjosephbachir: well, what do you want to achieve? | 23:49 |
| BasicOSX | Sorry on the busy and very bumby, typing going to be hard | 23:49 |
| BasicOSX | busy=bus :-) | 23:49 |
| BasicOSX | type | 23:49 |
| lifeless | :) | 23:49 |
| johnjosephbachir | lifeless: i waaaant.... to make my source tree reflect... my commits? (maybe i have the wrong terminology) | 23:49 |
| lifeless | BasicOSX: so am I understanding correctly? [you can say yes/no] - we merge it to .dev, and to 1.14 | 23:50 |
| Peng_ | johnjosephbachir: After uncommitting, if you want to throw out all of your noncommitted changes, use "bzr revert". | 23:50 |
| * igc breakfast | 23:50 | |
| johnjosephbachir | Peng_: hmm... just tried it... no change to files | 23:50 |
| BasicOSX | yes .dev, yes 1.14 | 23:51 |
| lifeless | BasicOSX: thanks! will get right on it | 23:51 |
| Peng_ | johnjosephbachir: Because you went and committed all of the changes again. | 23:51 |
| johnjosephbachir | Peng_ lifeless oh maybe i didn't commit... the uncommits properly, because i didn't revert after doing the uncommits? | 23:51 |
| johnjosephbachir | haha, okay | 23:51 |
| Peng_ | johnjosephbachir: You don't commit an uncommit. When you run uncommit, it removes the revision from the branch's history. | 23:52 |
| BasicOSX | can yyuou clarify on the maikkling llist (eerrr!) so people aren't freaking out? <- lifeless | 23:52 |
| Peng_ | johnjosephbachir: After running "uncommit", it's done. There's nothing left to do. | 23:52 |
| johnjosephbachir | Peng_: OIC | 23:52 |
| johnjosephbachir | thanks | 23:52 |
| BasicOSX | i will follow up properly once I get home | 23:52 |
| Peng_ | johnjosephbachir: When you ran "commit" afterwards, all you did was commit all of the changes in your working tree, including the changes from the 2 revisions you uncommitted. | 23:52 |
| johnjosephbachir | oh noes! | 23:52 |
| johnjosephbachir | Peng_: okay, thanks, i'll try to apply all that knowledge and see where i get | 23:53 |
| johnjosephbachir | Peng_: yes, working perfectly now. hooray for bzr! | 23:53 |
| Peng_ | :D | 23:53 |
| lifeless | BasicOSX: sure thing | 23:54 |
| === abentley1 is now known as abentley | ||
| BasicOSX | almost out of battery back tonight | 23:55 |
| lifeless | ciao | 23:55 |
| === thewrath_ is now known as thewrath | ||
| thewrath | hey all | 23:58 |
| thewrath | i got bzr working | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!