| spiv | Ah, "bzr missing --theirs :bound" is slightly simpler. | 00:04 |
|---|---|---|
| fullermd | Oh look, another layer violation... | 00:13 |
| === arjenAU2 is now known as arjenAU | ||
| davidstrauss | fullermd: layer violation? | 00:20 |
| fullermd | Oh, it's another log on a long-standing gripe of mine. | 00:23 |
| nbjayme | hello folks. my repository has grown. is there a way to have bzr flush the rest of the revisions? from revision 1 to 68 and i want to flush revisions 1 to 30... that'll end my repository to have only from revisions 31 to 68. ? | 02:13 |
| ferringb | nbjayme: why do you want this? | 02:13 |
| ferringb | kind of defeats the purpose of a vcs if you're chucking out history | 02:13 |
| nbjayme | okay okay.... probably i worry too much of diskspace. :) he-he | 02:14 |
| ferringb | nbjayme: if you're talking thousands of revs, sure | 02:15 |
| ferringb | although personally that's still pretty small, at least for the repos I deal w/. either way, look into the pack command | 02:15 |
| lifeless | poolie - split inv fetching mysql down to under 1sec/rev | 02:16 |
| lifeless | nbjayme: how big is your tree? | 02:16 |
| jml | lifeless: can you please give me permission to set priorities on testresources bugs? | 02:18 |
| lifeless | nbjayme: I'd be bothering with that at the 100's of thousands of files & revisions | 02:18 |
| lifeless | jml: whats the metaproject called? | 02:19 |
| jml | lifeless: pyunit-friends | 02:19 |
| nbjayme | @ferringb... no not really that large.... i just want to make it minimal to lessen some bandwidth transfer. @lifeless, pretty small i would say.... | 02:19 |
| lifeless | nbjayme: deleting history like that is *possible* but it will not result in a significant bandwidth reduction because texts are delta compressed | 02:20 |
| nbjayme | lifeless... okay.... i'm still around 8mb though.. :) | 02:21 |
| lifeless | jml: I've put it in pyunit-friends, that may have done it? | 02:21 |
| lifeless | nbjayme: how are you measuring that? | 02:21 |
| nbjayme | i go to nautilus and righ-click on the .bzr directory.... | 02:21 |
| lifeless | nbjayme: that figure doesn't represent what is transferred | 02:21 |
| bob2 | nbjayme: are you often copying the whole repository, or just updates? | 02:22 |
| lifeless | nbjayme: there are transactional details that are not copied, and incremental pulls only copy new content anyway | 02:22 |
| jml | lifeless: thanks, let's see. | 02:22 |
| nbjayme | the project is small, i'm still going to upload it in launchpad... :-) just wanna be a good netizen... he-he. yes, transfers to repo are faster after the initial commit or push. :) | 02:24 |
| jml | lifeless: nope. There's no such thing as a driver or bugs supervisor for super-projects. | 02:24 |
| jml | lifeless: the thing to do is make a team with you and I in it and set it as the bugs supervisor (or appoint me project maintainer, whichever works) | 02:24 |
| lifeless | garh | 02:25 |
| lifeless | so complex | 02:25 |
| lifeless | jml: I think I'd like to stay as maintainer :P | 02:26 |
| jml | lifeless: de jure at least | 02:26 |
| lifeless | jml: of the day? | 02:26 |
| jml | lifeless: "by law". often contrasted with "de facto" | 02:27 |
| jml | :P | 02:28 |
| lifeless | oh right | 02:28 |
| lifeless | architecture astronauts R us | 02:28 |
| lifeless | just filed my LP bug for the day | 02:28 |
| jml | heh heh | 02:28 |
| lifeless | (bug supervisor field requires a precreated team) | 02:29 |
| lifeless | jml: https://edge.launchpad.net/~testresources | 02:30 |
| jml | lifeless: I've joined, moderate me please. | 02:31 |
| lifeless | done, you are now moderate | 02:33 |
| jml | lifeless: thanks. | 02:34 |
| * jml is born to be mild | 02:34 | |
| jml | lifeless: we're saying that a commit to trunk is a release, right? | 02:35 |
| lifeless | jml: yes | 02:35 |
| lifeless | jml: 'early and often' | 02:35 |
| lifeless | jml: can't get more early than every commit :P | 02:35 |
| * jml spams lifeless with bug mail. | 02:37 | |
| lifeless | too late | 02:37 |
| lifeless | you already did | 02:37 |
| ferringb | curious; fixing tracbzr, one thing I did was yoink out the revno in favor of revision_ids (will add revno at some point, but it complicates it); problem being, that's chunks of an email address most of the time. how are others handling the scraping potential there? | 02:37 |
| ferringb | ...aside from just using revnos instead | 02:37 |
| jml | lifeless: this is round #2 :) | 02:38 |
| lifeless | ferringb: not sure | 02:40 |
| lifeless | poolie_: I've put the usertest order back - because the numbers are a *lot* easier to read in the order I put together last week | 02:40 |
| poolie_ | ok | 02:42 |
| poolie_ | did you kill it too? | 02:42 |
| lifeless | poolie_: eys | 02:42 |
| lifeless | poolie_: fingers crossed .inv will be 'fast enough' now | 02:42 |
| lifeless | its about 0.8sec/rev for me now | 02:43 |
| poolie_ | did you kill it twice or more? | 02:43 |
| lifeless | on my laptop | 02:43 |
| lifeless | yes | 02:43 |
| poolie_ | it looked like it disappeared a while ago i was just trying to work out why :/ | 02:43 |
| lifeless | twice, once when I pushed my branch, and then again when I saw it skip .inv | 02:43 |
| lifeless | sorry for any panic :) | 02:44 |
| lifeless | bbiab | 02:56 |
| poolie_ | woo, python compiled the extensions on kerguelen | 03:17 |
| poolie_ | and selftest is running | 03:17 |
| lifeless | poolie_: its pulling much faster; 1.7G used so far :P | 04:17 |
| lifeless | poolie_: previously that took a day or so | 04:17 |
| poolie_ | great | 04:17 |
| jml | spiv: hi | 04:21 |
| jml | spiv: tell me where the smart server does error translation. | 04:21 |
| jml | I have a bug that needs a-filing. | 04:21 |
| * jml finds it manually | 04:22 | |
| spiv | jml: look at the bottom of bzrlib/remote.py | 04:23 |
| spiv | jml: that's where is mostly happens on the client side (although there's also some in bzrlib/transport/remote.py). | 04:24 |
| jml | spiv: I get this when I push to a non-existent product on Launchpad: bzr: ERROR: Generic bzr smart protocol error: Permission denied: "Project 'no-such-product-xxx-flibble-ai-po' does not exist." | 04:27 |
| jml | spiv: I have 99% confidence that we are raising an honest-to-goodness PermissionError from the bzr running on the server. | 04:28 |
| spiv | jml: which verb does -Dhpss reveal that to be in reply to? | 04:28 |
| spiv | Hmm, maybe BzrDir.open? There's a bug open about that one, I think. | 04:29 |
| jml | 5.217 hpss call: 'mkdir', '/~jml/no-such-product-xxx-flibble-ai-po/branch', '' | 04:30 |
| jml | 5.217 (to bzr+ssh://bazaar.staging.launchpad.net/%7Ejml/no-such-product-xxx-flibble-ai-po/branch/) | 04:30 |
| jml | 5.569 result: ('error', 'Permission denied: "Project \'no-such-product-xxx-flibble-ai-po\' does not exist."') | 04:30 |
| spiv | jml: (https://bugs.launchpad.net/bzr/+bug/278673 is the bug I was thinking of) | 04:31 |
| ubottu | Launchpad bug 278673 in bzr "Traceback when uploading to an invalid location" [High,Confirmed] | 04:31 |
| mwhudson_ | note that launchpad doesn't need to be involved | 04:31 |
| mwhudson_ | $ bzr push bzr+ssh://localhost/bob | 04:31 |
| mwhudson_ | bzr: ERROR: Generic bzr smart protocol error: Permission denied: "/bob": [Errno 13] Permission denied: '/bob' | 04:31 |
| spiv | jml: that's not a PermissionDenied error on the wire, that's a generic 'error'. | 04:32 |
| jml | spiv: interesting | 04:32 |
| spiv | jml: so the problem is server-side. | 04:32 |
| jml | mwhudson_: also interesting. | 04:32 |
| spiv | (and quite possibly still in bzrlib) | 04:32 |
| spiv | jml: bzrlib.smart.request.SmartServerRequest._call_converting_errors is probably the culprit | 04:33 |
| jml | spiv: looks plausible. | 04:34 |
| spiv | jml: in fact, it appears that currently the only place that encodes a PermissionDenied error is an explicit except in bzrlib.smart.vfs.GetRequest | 04:34 |
| jml | spiv: how many places does one need to list an error before it gets translated properly? | 04:35 |
| * jml finds https://bugs.edge.launchpad.net/bzr/+bug/246792 | 04:36 | |
| ubottu | Launchpad bug 246792 in bzr "permissiondenied not translated on creating branch over bzr+ssh" [Undecided,Confirmed] | 04:36 |
| spiv | jml: Ignoring tests, typically three. | 04:36 |
| jml | spiv: that seems like at least one place too many | 04:36 |
| spiv | jml: server side, client-side vfs, client-side non-vfs. | 04:36 |
| spiv | The latter two can probably be unified somewhat sanely now. | 04:37 |
| Linuturk | I've kinda followed the mini tutorial, but I've got a question. I created a branch on my laptop, and then pushed that to my personal sftp server | 05:32 |
| Linuturk | but, none of the files are showing up on the server | 05:32 |
| Linuturk | ideas? | 05:33 |
| Linuturk | there is a .bzr directory on the server though | 05:33 |
| Linuturk | just, no files in the project folder | 05:33 |
| mwhudson | Linuturk: pushes to a remote location don't push a working tree too | 05:36 |
| mwhudson | Linuturk: the push-and-update or 'upload' plugins might be what you want | 05:36 |
| mwhudson | (or maybe you shouldn't care, the .bzr directory contains enough to share the branch) | 05:36 |
| Linuturk | hmmm, so, if my laptop died, would the files be safe? | 05:37 |
| Linuturk | or, is my laptop considered the primary repo | 05:38 |
| Linuturk | and, the other links just point to it? | 05:38 |
| mwhudson | no | 05:38 |
| mwhudson | the .bzr folder contains the complete history of the branch | 05:38 |
| mwhudson | if you go to the server and run 'bzr co' | 05:39 |
| spiv | Linuturk: the files would be safe. The .bzr directory contains all the data. | 05:40 |
| * Linuturk quietly installs bzr on the server first | 05:41 | |
| Linuturk | lol | 05:41 |
| spiv | Linuturk: you can do "bzr log" or "bzr branch" or "bzr checkout" etc from that remote location. | 05:41 |
| Linuturk | ooo, what's the bzr co ? | 05:42 |
| Linuturk | checkout? | 05:42 |
| Linuturk | o sweet | 05:43 |
| Linuturk | and, that pulled from the local .bzr | 05:43 |
| Linuturk | not my laptop | 05:43 |
| Linuturk | I'm looking to use bzr to control system configs on my servers | 05:43 |
| Linuturk | and, it seems like this will work great | 05:44 |
| Linuturk | that sound good? | 05:45 |
| poolie_ | it does | 06:52 |
| vila | hi all ! | 07:07 |
| jml | hello. | 07:08 |
| spiv | Sometimes I think it'd be nice to be able to make a loom post hoc from a series of commits. So I could just start hacking on a non-loom branch, then go e.g. "loomify --base-from ancestor::submit", and get a loom with a thread per commit. | 07:29 |
| spiv | Well, by "sometimes" I mean "just now" :) | 07:29 |
| vila | A *thread* by commit ? Wow, care to give a bit more context ? | 07:30 |
| spiv | vila: the use case I have in mind is where I've just started hacking without being sure in advance what shape it'll take, or how far I'll want to go. | 07:30 |
| spiv | vila: so I do something interesting, commit it, do some more, commit, etc. | 07:31 |
| spiv | vila: and then I start thinking "this would make a nice series of changes to submit for merging, but I'd like to tweak some of the earlier steps" | 07:31 |
| spiv | If those steps were already in a loom, then I'd be set, but in this case I didn't have that foresight. | 07:32 |
| vila | So certainly you want somme commitS in the same thread no ? | 07:32 |
| spiv | But if I could trivially make a loom pre-populated with threads based on my commits, then I wouldn't need the foresight. | 07:32 |
| spiv | Sure, probably. But it's easy to collapse threads. | 07:33 |
| spiv | It's harder (not impossible, just not as easy) to split a thread. | 07:33 |
| vila | I learn recently and with a bit of pain that combine-thread is more detructive than I thought | 07:33 |
| spiv | That's true, but that's a separate problem :) | 07:33 |
| vila | So how do you collapse threads then ? | 07:34 |
| spiv | vila: "bzr combine-thread" | 07:36 |
| spiv | vila: e.g. if I have commits r1, r2 and r3, and corresponding threads t1, t2, t3, then from inside t2 "bzr combine-thread" will leave me with t1, t3. | 07:37 |
| vila | I'd like at least a warning there when I'm about to shoot in my foot :) | 07:37 |
| Mez | spiv, sorry, havent been able to get round to the whole bzrssh thing yet... it is on my todo list though | 07:38 |
| spiv | vila: sure, or at least an easy way to unshoot the foot | 07:41 |
| AfC | Mmmm. Self-inflicted wounds. | 07:42 |
| vila | I think my use case was: r1, r2, r3 in threads t1, t2, t3, then in t2, add r4, combine-threads, boom, r4 is gone | 07:42 |
| lifeless | vila: spiv: patches, appreciated, kthx | 07:46 |
| spiv | vila: right. I think it ought to require a --force when a combine-thread will lose a revision not merged in later threads. | 07:46 |
| vila | lifeless: things would more easier if the loom test suite was passing :-/ | 07:47 |
| lifeless | spiv: bzr create-thread; bzr pull . -r thread:<dead-head> | 07:47 |
| vila | be even | 07:47 |
| lifeless | vila: abentley has fixed that | 07:47 |
| spiv | lifeless: I know, just thinking out loud before I start hacking on a new idea. | 07:47 |
| vila | lifeless: huh ? bzr missing lp:~bzr-loom-devs/bzr-loom/trunk : Branches are up to date. | 07:50 |
| vila | damn lp:~abentley/bzr-loom/stuff | 07:51 |
| vila | why isn't that merged in trunk ? | 07:51 |
| poolie_ | hi vila | 08:12 |
| abentley | vila: wait, you're cursing me for fixing stuff? | 08:21 |
| vila | abentley: Surely not !!! I didn't think you were online ! THANKS A TON :_ | 08:21 |
| vila | :) | 08:22 |
| abentley | vila: of course, I *shouldn't* be online. | 08:22 |
| abentley | But you used my nick, so I'd have seen it in the morning. | 08:23 |
| vila | hehe, I didn't realized there was 'damn' and 'abentley' so close :) | 08:24 |
| vila | abentley: I was willing to review your user stuff but jam beat me to it :) (let's bring him into this too ;p) | 08:24 |
| abentley | lol | 08:25 |
| vila | spiv: just notice your --force remark, agreed | 08:26 |
| vila | abentley, lifeless, spiv: so what's the policy to bring remarkable abentley work merged into trunk ? | 08:26 |
| vila | :-) | 08:26 |
| abentley | spiv: I kinda want that thread-per-commit thing every now and then. But usually I just want to split a thread at a given revision. | 08:28 |
| abentley | spiv: So given r1, r2, r3 in a thread, I want to create a new thread with r3 and change the existing thread to have r2 as its head. | 08:29 |
| abentley | spiv: Which is doable, if a bit annoying. | 08:29 |
| spiv | abentley: yeah, that would be good. | 08:52 |
| poolie_ | hi spiv | 09:32 |
| a_c_m | i need a nudge in the right direction... i have checkouts via bzr:/localhost working, but want to only be accessible over ssh - any tips / links? | 11:23 |
| === Pilky_ is now known as Pilky | ||
| vila | abentley: ping | 13:17 |
| vila | I'm just pushing a trivial branch at lp:~vila/bzr/2843443-docfix | 13:18 |
| vila | sudden;y bzr says: Using default stacking branch /~bzr/bzr/trunk at bzr+ssh://vila@bazaar.launchpad.net/%7Evila/bzr/ | 13:18 |
| abentley | vila: pong | 13:18 |
| vila | Hurrah, did I think, automatic stacking ! | 13:18 |
| vila | But then the push seems to take as long as usual... | 13:18 |
| vila | Should I file a bug ? | 13:18 |
| vila | Or did I misunderstood something ? | 13:19 |
| abentley | vila: Are both the branch and repo in 1.6 format? | 13:19 |
| abentley | scratch that. Yes, it should be giving you auto stacking, and shouldn't take as long as before. | 13:20 |
| vila | bran/format: Bazaar Branch Format 6 (bzr 0.15) | 13:21 |
| vila | and the message is strange, what is '/~bzr/bzr/trunk' ? | 13:21 |
| vila | *I* suspect it's on launchpad, but yet | 13:21 |
| abentley | vila: it's a host-relative path. | 13:22 |
| vila | what host ? mine ? launchpad ? the target branch's ? | 13:23 |
| vila | ohhh, you mean an hpss one and it doesn't know its name ? | 13:23 |
| abentley | vila: We stack on /~bzr/bzr/trunk rather than bzr+ssh://vila@bazaar.launchpad.net/~bzr/bzr/trunk so that it works over all protocols. | 13:24 |
| abentley | It is relative to the target branch. | 13:24 |
| vila | Ha, some problem than yesterday, or related at least | 13:24 |
| vila | for clarity it would be nicer if the host was specified or even the url used internally no ? | 13:26 |
| abentley | vila: It's basically a question of precision vs accuracy. | 13:28 |
| abentley | The value we are writing to branch.conf is literally /~bzr/bzr/trunk | 13:29 |
| abentley | If we change it the way you're suggesting, then we can't tell from that message whether it will work over multiple protocols. | 13:29 |
| vila | I see | 13:29 |
| vila | How about "Using stacking branch /~bzr/bzr/trunk from branch.conf" or something ? | 13:30 |
| vila | and I stop there :) | 13:31 |
| abentley | vila: You mean "Writing stacking branch /~bzr/bzr/trunk to branch.conf"? | 13:31 |
| vila | wow, you mean this message is emitted when writing branch.conf ? | 13:32 |
| vila | if that the case, yes | 13:32 |
| vila | I will be happy with that, more even as it make it clear that lp is doing it | 13:32 |
| james_w | it's doing that on the host? If so, I think stating that might be good. | 13:33 |
| abentley | james_w: No, it's not. | 13:34 |
| james_w | oh, ok | 13:35 |
| abentley | vila: lp is not doing it. bzr is doing it. lp is just providing a file that suggests a location. | 13:35 |
| abentley | vila: the choice to follow lp's suggestion is made by bzr. | 13:35 |
| vila | what is the file name you're referring to ? | 13:36 |
| abentley | vila: bzr+ssh://abentley@bazaar.launchpad.net/%7Ebzr/bzr/.bzr/control.conf | 13:39 |
| abentley | or for the branch you're pushing, bzr+ssh://bazaar.launchpad.net/%7Evila/bzr/.bzr/control.conf | 13:41 |
| Odd_Bloke | Is there a way to set the parent of a branch from the UI, without having to do a ``bzr foo --remember``? | 13:43 |
| james_w | Odd_Bloke: if you count vim as a UI | 13:46 |
| Odd_Bloke | It seems like there should be a way to do it, but I'm not sure to what extent we want to avoid people editing the config files under .bzr... | 13:48 |
| vila | It would help if you tell us *why* you feel that need just now | 13:53 |
| vila | Because ISTM that you need to do that *before* issuing a bzr command which may be laking the --remember option :) | 13:54 |
| abentley | vila: You say about AuthenticationConfig._save: "Save the config file, only tests should use it for now." | 14:07 |
| abentley | vila: Is that because it's not atomic? | 14:08 |
| vila | Not more nor less than other config, but the true reason was because bzr never modifies it | 14:09 |
| vila | Are you working on that right now ? | 14:09 |
| Odd_Bloke | vila: The upstream location has moved, and the user wants to do this while they're doing the move, rather than next time they actually want to perform an operation. | 14:21 |
| Odd_Bloke | s/upstream/parent/ | 14:21 |
| vila | Odd_Bloke: I see | 14:23 |
| abentley | vila: Yes. | 14:25 |
| vila | abentley: ok, I'll work on something else then, I'm looking at your previous patch anyway | 14:26 |
| abentley | vila: As I mentioned to jam, we might want to support different authentications for sftp and bzr+ssh eventually. | 14:28 |
| vila | I didn't see that, can you explain why, it sounds strange | 14:30 |
| abentley | vila: Well, we support different authentications for other protocols. | 14:31 |
| vila | you can already differentiate on port or on path | 14:31 |
| abentley | vila: http and ftp can also be differentiated on port. | 14:32 |
| vila | sure, all schemes are handled the same | 14:33 |
| vila | but sftp and bzr+ssh really use ssh | 14:33 |
| vila | and the remote host will handle them with the same authentication | 14:33 |
| abentley | vila: But is that an implementation detail? Is "sftp" not a more obvious scheme for controlling sftp? | 14:33 |
| vila | hmmm | 14:34 |
| abentley | I know that for launchpad, it will be convenient to specify 'ssh'. | 14:35 |
| vila | I don't want users to define the same settings for sftp/bzr+shh or http/bzr+http | 14:35 |
| abentley | I'm not proposing replacing 'ssh'. | 14:37 |
| * vila hopes jam is not around and catch bzr+ssh typo... | 14:37 | |
| vila | What are you proposing ? | 14:37 |
| vila | that sftp and bzr+ssh are handled as ssh aliases ? | 14:37 |
| abentley | I'm saying that one day, we may want to support "sftp" and "bzr+ssh" as additional schemes in authentication.conf | 14:38 |
| vila | I don't understand what that means | 14:39 |
| vila | Currently we use auth.get_user('ssh', will that change ? | 14:39 |
| abentley | vila: Yes, it would change to if auth.get_user('sftp...) is None: auth.get_user('ssh'...) | 14:40 |
| vila | Do you have a need to specify, for the same host, different credentials or do you just want to be able to use sftp/ssh/bzr+ssh in the authentication.conf file interchangeably ? | 14:43 |
| abentley | vila: Neither. | 14:44 |
| vila | So what ? >-< | 14:44 |
| abentley | It would not make sense for bzr+ssh to affect sftp. It would not make sense for sftp to affect bzr+ssh. | 14:44 |
| vila | It makes sense to specify only once the credentials that can be used for both | 14:44 |
| abentley | And you would not *need* to specify different credentials for the same host. You could specify 'ssh' instead. | 14:45 |
| vila | And it may even be mandatory to store them in things like OS X keychain or gnome keyring, i.e. sticking to known schemes | 14:46 |
| vila | but if I use sftp and connect to bzr+ssh the credentials will not be found ? | 14:46 |
| vila | but if I define sftp credentials and connect to bzr+ssh the credentials will not be found ? | 14:46 |
| abentley | vila: Right. | 14:47 |
| vila | Eerk, what's the point then ? | 14:48 |
| vila | While writing the spec I *did* use sftp until I realized that it will be a trap for the user because all the remote host knows is users or keys for ssh, users for ftp, users for http, etc | 14:55 |
| pysquared | Hello. I am migrating from CVS. Is there a way to get Bazaar to either preserve mtime, or set the mtime of checked out files to the date of the last file change? | 14:55 |
| abentley | vila: There are certainly cases where users have multiple accounts on one machine, one for shell access, one for Bazaar. | 14:59 |
| abentley | vila: I haven't come up with a plausible reason for having two accounts, both used for Bazaar. | 14:59 |
| vila | You also need to come up with a way to handle that on the remote host | 15:00 |
| vila | but it may be possible with different ports | 15:00 |
| lifeless | abentley: on the way to bed... but you might like to know that the losa's run two accounts on launchpad's code hosting service from one unix account, on a pqm machine | 15:00 |
| abentley | vila: I don't see what the problem is. It's easy to have multiple ssh accounts. You just specify username. | 15:01 |
| lifeless | abentley: (both accounts are for separate unrelated private branches) | 15:01 |
| lifeless | anyhow, dunno if that matters; gnight everyone | 15:01 |
| beuno | night lifeless | 15:02 |
| nbjayme | vila: does that mean bzr+ssh is the most preferred way. i use bzr sftp. :( | 15:02 |
| nbjayme | ? | 15:02 |
| nbjayme | gnight lifeless. | 15:02 |
| vila | nbjayme: that's totally unrelated but bzr+ssh should gives you better performances :) | 15:02 |
| nbjayme | okay... thanks. :) | 15:03 |
| vila | nbjayme: we are discussing how to describe credentials in authentication.conf | 15:03 |
| vila | abentley: the only problem I have is that declaring sftp credentials leads to bzr+ssh credentials being not found except if use ssh, go explain that to the average user :-) | 15:05 |
| abentley | vila: Anyhow, as I said, I'm not interested it doing it now. | 15:06 |
| vila | ok | 15:06 |
| vila | abentley: what is the scope of you modification then ? Writing an authentication.conf file when launchpad-loging is used ? Or more ? | 15:07 |
| vila | LOSA: ping, pqm blocked | 15:09 |
| abentley | vila: Also, writing an authentication.conf entry when it discovers that there is a configured login, but no corresponding authentication.conf entry. | 15:12 |
| abentley | vila: But I think that's all. | 15:13 |
| vila | ok, great, I can work on other parts then | 15:13 |
| pysquared | Bazaar does not set mtime of checkout out files (which I would like), but when doing "bzr diff --using=...", the old/* files it creates have the mtime set (so it is possible). | 15:21 |
| pysquared | Should I submit a patch? | 15:21 |
| pysquared | Any bzr wizards around right now? | 15:22 |
| abentley | pysquared: Setting the mtime to the stored date messes up build systems. We do not want that. | 15:23 |
| pysquared | I did not realise until I started using bzr how much I used mtime as a visual clue. i want that. | 15:24 |
| pysquared | Perhaps a checkout --restore-mtime option? | 15:24 |
| pysquared | I hate coming back to work on a tree, doing a checkout and all the mtimes are the same. Anyone else find this? | 15:25 |
| abentley | pysquared: This has been discussed on the mailing list in the past. You should probably read up on it before trying to land such a patch. | 15:26 |
| pysquared | abentley: thanks, I did search a bit but found nothing, so I asked here, you guys are always helpful. I will look again. | 15:27 |
| abentley | pysquared: http://search.gmane.org/search.php?group=gmane.comp.version-control.bazaar-ng.general&query=mtime | 15:29 |
| abentley | pysquared: The ones about "revert" would also apply to checkout. | 15:30 |
| pysquared | abentley: fantastic | 15:30 |
| qebab | Hi. I have a bzr repository that I'm trying to make a svn repo from, for a couple of friends to use. I'm having problems getting things working here. Could anyone tell me how I should do this? I'm probably just doing it wrong, but I'm getting a lot of weird errors (Everything from segfaults to AttributeErrors). I'm using bzr-1.3.1ubuntu0 and bzr-svn 0.4.9-1. | 16:41 |
| jelmer | qebab, please try a more recent version of bzr-svn | 16:46 |
| qebab | jelmer: okay. As to how to do this, I svnadmin create a repo, svn co it somewhere, and then I bzr push to it? | 16:46 |
| qebab | or is there further magic I need to work | 16:47 |
| jelmer | qebab, there's no need to svn co it | 16:48 |
| jelmer | just "bzr svn-push <svn-repository-location>/trunk" | 16:48 |
| qebab | cool :) | 16:49 |
| === cprov is now known as cprov-lunch | ||
| nbjayme | i recently read in the launchpad news about stacked format. and, it's blazingly fast in uploading my large repo but under +junk. now I have a repo associated with a project... i tried --overwrite but it did not update the remote repo's format. must i really delete the project's branch and reupload / push? | 16:54 |
| nbjayme | i meant *delete the focus branch in launchpad* and push my local branch? | 16:55 |
| jelmer | nbjayme, yes, I think so | 16:57 |
| nbjayme | okay thanks!.... by the way, congrats to the devs for the great feature. :) | 16:58 |
| qebab | jelmer: when running make for bzr-svn, it gives me this: /bin/sh: rst2html: not found | 16:59 |
| qebab | jelmer: is that going to be a problem? | 16:59 |
| Odd_Bloke | qebab: That's presumably just for docs, but you could just install it? | 17:00 |
| qebab | Odd_Bloke: the apt package was apparently not recent enough :) | 17:01 |
| abentley | jelmer, qebab I don't think there's a requirement for the target branch to be in format 1.6. | 17:08 |
| jelmer | abentley: Sorry, I think I'm missing some context | 17:09 |
| abentley | jelmer: Sorry, I meant nbjayme | 17:10 |
| abentley | jelmer: I don't think there's a requirement to update the format of focus branches in Launchpad. | 17:11 |
| jelmer | abentley, ah, indeed | 17:11 |
| jelmer | abentley, related to that, it would still be nice to have a 'upgrade' button or "bzr upgrade" on a HPSS connection work a bit better ;-) | 17:12 |
| abentley | jelmer: Yes, it does, but upgrading is async, and would have to run on a non-web machine. Therefore a job handling framework is required. I have been working on one. | 17:13 |
| abentley | jelmer: I thought bzr upgrade on hpss was decent now, though. | 17:14 |
| jelmer | abentley, it works, but still does the actual conversion locally, thus it's very slow | 17:15 |
| sohmestra | Given a bazaar branch, and and a branch that is based on that branch, yet lacks any common history...is there any way to "graft" the 2nd branch back onto the first? | 17:20 |
| sohmestra | "lacks any common history" meaning: an export of the original branch was placed under revision control and development continued from there. | 17:21 |
| beuno | sohmestra, both versioned with bazaar, only that the second one wasn't branched from the first one? | 17:22 |
| abentley | sohmestra: You could perhaps regenerate the second one with the "rebase" plugin. jelmer would know more about that. | 17:23 |
| sohmestra | beuno: correct | 17:23 |
| beuno | sohmestra, what abentley said :) | 17:24 |
| sohmestra | abentley: I was fiddling with that...but it complained about having no common ancestery, so I figured that I didn't understand what it was supposed to be doing | 17:24 |
| sohmestra | anyway, I'll fiddle some more | 17:25 |
| jelmer | rebase doesn't handle the case where there is no common history yet (bug 231674) | 17:27 |
| ubottu | Launchpad bug 231674 in bzr-rebase "can't replay, need maptree support in rebase" [Wishlist,Triaged] https://launchpad.net/bugs/231674 | 17:27 |
| abentley | jelmer: what's maptree? Remapping file-ids? | 17:28 |
| jelmer | abentley, yes | 17:28 |
| abentley | jelmer: I think a PreviewTree would also work for that. | 17:29 |
| jelmer | abentley: MapTree does exist, it's just not hooked up in the bzr-rebase commands | 17:30 |
| jelmer | bzr-svn's upgrade command makes use of it though | 17:30 |
| abentley | jelmer: Yeah, I see it. | 17:30 |
| jelmer | abentley: I guess it wouldn't be a bad thing to get rid of it in favor of PreviewTree though | 17:31 |
| abentley | jelmer: All other things being equal, of course :-) | 17:31 |
| abentley | jelmer: maptree looks like it reimplements the Tree API. Can you use it as a merge source? | 17:34 |
| jelmer | abentley, yes, that's the idea | 17:35 |
| abentley | Wow, I'd have thought you needed a bigger implementation to support that. Good stuff. | 17:37 |
| jelmer | hmm, it doesn't appear we're doing that yet so it may not be complete anymore | 17:39 |
| === cprov-lunch is now known as cprov | ||
| mtaylor | hey all... if I made a stacked branch and want to replace it with a normal branch ... what's the best way? | 18:47 |
| beuno | mtaylor, maybe push --overwrite? I'm not sure if that will work | 18:49 |
| beuno | you can, alternitavely, delete it and push again, of course | 18:49 |
| mtaylor | beuno: but locally... if I branch from it, will I get another stacked branch, or one with everything? | 18:49 |
| beuno | if you branch from a stacked branch, I don't think it defaults to stacked, you would get the full branch, unless you specify otherwise | 18:50 |
| LarstiQ | beuno: hmm, that would surprise me | 19:20 |
| beuno | LarstiQ, me too, but, I've been suprised before :) | 19:25 |
| LarstiQ | :) | 19:26 |
| ktenney | Howdy, seeking help creating an alias from a script. Looks like bzrlib.builtins.cmd_alias.set_alias, but I've not had success using this | 19:29 |
| ktenney | I don't understand the cmd_xxxx stuff in general, is there doc? | 19:29 |
| LarstiQ | ktenney: the cmd_ stuff is not really meant to be invoked from other python code | 19:30 |
| ktenney | ah, what is recommended for defining an alias? | 19:30 |
| LarstiQ | ktenney: cmd_ should use other functions, those would be more fit for bzrlib consumers | 19:30 |
| * LarstiQ looks at alias | 19:30 | |
| LarstiQ | ktenney: config.GlobalConfig().set_alias(alias_name, alias_command) it looks like | 19:31 |
| LarstiQ | ktenney: where config is bzrlib.config | 19:31 |
| ktenney | LarstiQ: thx, I'll try that ... | 19:32 |
| ktenney | LarstiQ: works, thanks, bye. | 20:02 |
| LarstiQ | ok :) | 20:02 |
| mwhudson_ | jam: did you see that if your bzr branches are in a stackable format they should be stacked on lp:bzr now? | 20:03 |
| mwhudson_ | jam: might save your dsl line some stress :) | 20:03 |
| jam | mwhudson_: not entirely, I'd have to upgrade all my branches, which would cause LP to re-mirror everything | 20:04 |
| jam | so potentially in the future it will help | 20:04 |
| jam | but it wouldn't help for me to go do it right now | 20:04 |
| jam | :) | 20:04 |
| mwhudson_ | well, if the branch had been merged into lp:bzr it would be a pretty light mirror... | 20:05 |
| mwhudson_ | so i'm not sure i really see that | 20:05 |
| abentley | jam: Thanks for all the reviewage | 20:09 |
| jam | abentley: I'm happy to try and get our queue unstuck from time to time :) | 20:09 |
| jam | your's just happen to be at the bottom of my email and thus easiest to find | 20:09 |
| pickscrape | Anyone know off the top of their head what bundle buggy matches against when deciding if someone is a voter or not? | 20:22 |
| beuno | email address | 20:23 |
| beuno | or, you log in through the webui | 20:23 |
| pickscrape | Just the email address, and not the name part? | 20:23 |
| beuno | yeap, just the email address | 20:23 |
| beuno | of course, abentley would know 100% for sure | 20:23 |
| pickscrape | beuno: thanks. Just trying to debug why it's not working for me. That helps :) | 20:23 |
| beuno | but I'm 95% sure :) | 20:24 |
| abentley | pickscrape: The email address and the name part. | 20:24 |
| pickscrape | abentley: ah, so if you have two mail clients that have slightly different names set up (though using the same email address), you have to be registered independently for each name? | 20:25 |
| abentley | pickscrape: Well, each email-id needs to be associated with your account. | 20:25 |
| pickscrape | Ah, you mean in submitter.id? | 20:26 |
| beuno | phew, good thing I stuck with 95% | 20:26 |
| beuno | abentley, just curious, why do you check the name as well? | 20:26 |
| abentley | beuno: mostly because it was the fastest thing at the time. | 20:27 |
| beuno | abentley, heh, ok, makes sense :) | 20:28 |
| abentley | lifeless: ping | 21:09 |
| === thumper_laptop is now known as thumper | ||
| lifeless | abentley: hi | 22:19 |
| abentley | lifeless: nm. PQM was stuck. Isn't now. | 22:20 |
| === thumper_laptop is now known as thumper | ||
| lifeless | abentley: did a losa intervene, or did it just come good? | 22:20 |
| abentley | lifeless: herb intervened. | 22:20 |
| lifeless | k; do we know the cause? | 22:20 |
| === TheMuso_ is now known as TheMuso | ||
| pickscrape | What is the meaning/purpose of the "My Pending" and "Mine" tabs in BB? | 23:00 |
| jelmer | pickscrape, one is stuff you haven't reviewed (including stuff from others) | 23:05 |
| jelmer | pickscrape, the other are your own submissions | 23:05 |
| jam | pickscrape: things you have submitted which may be marked 'resubmit' | 23:05 |
| jam | versus things which you might have reviewed | 23:05 |
| jam | and may be responsible for merging | 23:05 |
| pickscrape | Right. I've submitted one thing myself (the only thing so far) and it not appearing under either. | 23:06 |
| pickscrape | It does appear under "My Todo" and "Pending" though. | 23:06 |
| a_c_m | i'm trying to get bzr working on my local host , using ssh+bzr but cant seem to get it to work | 23:26 |
| a_c_m | (testing it ready for a deployment on a server) | 23:27 |
| bob2 | is bzr in your PATH? | 23:27 |
| a_c_m | its in /usr/bin which is in my path yes | 23:30 |
| a_c_m | i get 2 errors when i try it | 23:31 |
| a_c_m | TERM environment variable not set. | 23:31 |
| a_c_m | bzr: ERROR: Generic bzr smart protocol error: bad response ('',) | 23:31 |
| a_c_m | i did quite a bit of google searching, i was quite supprised how little documentation there is on setting up a bzr server (plenty on using bzr though) | 23:33 |
| fullermd | That sounds like your shell rc files spitting output, confusing bzr. | 23:33 |
| a_c_m | ahhhh | 23:33 |
| a_c_m | that would be true! | 23:33 |
| a_c_m | let me try 2 ticks | 23:34 |
| a_c_m | well that gets me closer for sure! | 23:37 |
| a_c_m | Oh my... it worked | 23:38 |
| a_c_m | thank you VERY much fullermd ! | 23:38 |
| a_c_m | i never would have worked that out | 23:38 |
| fullermd | Oh. Well, it's surely a sign of my genius, and TOTALLY not the fruits of having screwed myself so indenumerable times in the past. | 23:41 |
| * fullermd nods at himself. | 23:41 | |
| a_c_m | lol | 23:44 |
| a_c_m | needs to go on a wiki page or somthing somewhere | 23:44 |
| a_c_m | as when i searched for those errors i got bugger all | 23:44 |
| fullermd | Well, there wouldn't really be any constant error. | 23:45 |
| a_c_m | no? | 23:46 |
| lifeless | a_c_m: probably sftp wasn't working for you either | 23:46 |
| lifeless | a_c_m: and there are hits for that :) | 23:46 |
| fullermd | "TERM environment variable not set." is the tipoff in this case, but that's nothing to do with bzr; that's output right from your shell. | 23:46 |
| lifeless | that said | 23:46 |
| lifeless | there is a test | 23:46 |
| fullermd | It would depend on exactly what output was being generated :) | 23:46 |
| a_c_m | ahh wasnt even trying sftp | 23:46 |
| lifeless | fullermd: we can write up a 'check your server config' checklist | 23:47 |
| lifeless | fullermd: with 'ssh -T host echo' as a test line | 23:48 |
| a_c_m | fullermd: mine was a combo of lifehackers handy bashrc + some simple customizations ;) | 23:48 |
| fullermd | Oh, I was thinking jump right to "ssh -T host bzr version" to check as much of the path as possible. | 23:50 |
| lifeless | fullermd: right - but when it fails, we can test that one step in isolation | 23:51 |
| lifeless | fullermd: which is clearer than we do today | 23:51 |
| lifeless | in other news | 23:53 |
| lifeless | Every 2.0s: du -s work_root_for-bzr.inv work_root_for-bzr.inv-branchAndFix Thu Oct 16 23:53:58 2008 | 23:54 |
| lifeless | 648036 work_root_for-bzr.inv | 23:54 |
| lifeless | 12446008 work_root_for-bzr.inv-branchAndFix | 23:54 |
| lifeless | thats right, split inventory is at 12G and climbing | 23:54 |
| lifeless | "epic" | 23:54 |
| fullermd | It's a feature. bzr comes with built-in I/O benchmarks. Email reading is expected for 2.0. | 23:55 |
| elmo | even gnu hello has email reading | 23:56 |
| lifeless | poolie: was debugging an lp issue @ 9. anything particularly interesting from the standup | 23:59 |
| lifeless | ? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!