[00:04] <spiv> Ah, "bzr missing --theirs :bound" is slightly simpler.
[00:13] <fullermd> Oh look, another layer violation...
[00:20] <davidstrauss> fullermd: layer violation?
[00:23] <fullermd> Oh, it's another log on a long-standing gripe of mine.
[02:13] <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:14] <nbjayme> okay okay....  probably i worry too much of diskspace.  :) he-he
[02:15] <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:16] <lifeless> poolie - split inv fetching mysql down to under 1sec/rev
[02:16] <lifeless> nbjayme: how big is your tree?
[02:18] <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:19] <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:20] <lifeless> nbjayme: deleting history like that is *possible* but it will not result in a significant bandwidth reduction because texts are delta compressed
[02:21] <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:22] <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:24] <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:25] <lifeless> garh
[02:25] <lifeless> so complex
[02:26] <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:27] <jml> lifeless: "by law". often contrasted with "de facto"
[02:28] <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:29] <lifeless> (bug supervisor field requires a precreated team)
[02:30] <lifeless> jml: https://edge.launchpad.net/~testresources
[02:31] <jml> lifeless: I've joined, moderate me please.
[02:33] <lifeless> done, you are now moderate
[02:34] <jml> lifeless: thanks.
[02:34]  * jml is born to be mild
[02:35] <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:37]  * 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:38] <jml> lifeless: this is round #2 :)
[02:40] <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:42] <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:43] <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:44] <lifeless> sorry for any panic :)
[02:56] <lifeless> bbiab
[03:17] <poolie_> woo, python compiled the extensions on kerguelen
[03:17] <poolie_> and selftest is running
[04: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:21] <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:22]  * jml finds it manually
[04:23] <spiv> jml: look at the bottom of bzrlib/remote.py
[04:24] <spiv> jml: that's where is mostly happens on the client side (although there's also some in bzrlib/transport/remote.py).
[04:27] <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:28] <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:29] <spiv> Hmm, maybe BzrDir.open?  There's a bug open about that one, I think.
[04:30] <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:31] <spiv> jml: (https://bugs.launchpad.net/bzr/+bug/278673 is the bug I was thinking of)
[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:32] <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:33] <spiv> jml: bzrlib.smart.request.SmartServerRequest._call_converting_errors is probably the culprit
[04:34] <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:35] <jml> spiv: how many places does one need to list an error before it gets translated properly?
[04:36]  * jml finds https://bugs.edge.launchpad.net/bzr/+bug/246792
[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:37] <spiv> The latter two can probably be unified somewhat sanely now.
[05:32] <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:33] <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:36] <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:37] <Linuturk> hmmm, so, if my laptop died, would the files be safe?
[05:38] <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:39] <mwhudson> if you go to the server and run 'bzr co'
[05:40] <spiv> Linuturk: the files would be safe.  The .bzr directory contains all the data.
[05:41]  * 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:42] <Linuturk> ooo, what's the bzr co ?
[05:42] <Linuturk> checkout?
[05:43] <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:44] <Linuturk> and, it seems like this will work great
[05:45] <Linuturk> that sound good?
[06:52] <poolie_> it does
[07:07] <vila> hi all !
[07:08] <jml> hello.
[07:29] <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:30] <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:31] <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:32] <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:33] <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:34] <vila> So how do you collapse threads then ?
[07:36] <spiv> vila: "bzr combine-thread"
[07:37] <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:38] <Mez> spiv, sorry, havent been able to get round to the whole bzrssh thing yet... it is on my todo list though
[07:41] <spiv> vila: sure, or at least an easy way to unshoot the foot
[07:42] <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:46] <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:47] <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:50] <vila> lifeless: huh ? bzr missing lp:~bzr-loom-devs/bzr-loom/trunk : Branches are up to date.
[07:51] <vila> damn lp:~abentley/bzr-loom/stuff
[07:51] <vila> why isn't that merged in trunk ?
[08:12] <poolie_> hi vila
[08:21] <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:22] <vila> :)
[08:22] <abentley> vila: of course, I *shouldn't* be online.
[08:23] <abentley> But you used my nick, so I'd have seen it in the morning.
[08:24] <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:25] <abentley> lol
[08:26] <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:28] <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:29] <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:52] <spiv> abentley: yeah, that would be good.
[09:32] <poolie_> hi spiv
[11:23] <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?
[13:17] <vila> abentley: ping
[13:18] <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:19] <vila> Or did I misunderstood something ?
[13:19] <abentley> vila: Are both the branch and repo in 1.6 format?
[13:20] <abentley> scratch that.  Yes, it should be giving you auto stacking, and shouldn't take as long as before.
[13:21] <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:22] <abentley> vila: it's a host-relative path.
[13:23] <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:24] <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:26] <vila> for clarity it would be nicer if the host was specified or even the url used internally no ?
[13:28] <abentley> vila: It's basically a question of precision vs accuracy.
[13:29] <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:30] <vila> How about "Using stacking branch /~bzr/bzr/trunk from branch.conf" or something ?
[13:31] <vila> and I stop there :)
[13:31] <abentley> vila: You mean "Writing stacking branch /~bzr/bzr/trunk to branch.conf"?
[13:32] <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:33] <james_w> it's doing that on the host? If so, I think stating that might be good.
[13:34] <abentley> james_w: No, it's not.
[13:35] <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:36] <vila> what is the file name you're referring to ?
[13:39] <abentley> vila: bzr+ssh://abentley@bazaar.launchpad.net/%7Ebzr/bzr/.bzr/control.conf
[13:41] <abentley> or for the branch you're pushing,  bzr+ssh://bazaar.launchpad.net/%7Evila/bzr/.bzr/control.conf
[13:43] <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:46] <james_w> Odd_Bloke: if you count vim as a UI
[13:48] <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:53] <vila> It would help if you tell us *why* you feel that need just now
[13:54] <vila> Because ISTM that you need to do that *before* issuing a bzr command which may be laking the --remember option :)
[14:07] <abentley> vila: You say about AuthenticationConfig._save: "Save the config file, only tests should use it for now."
[14:08] <abentley> vila: Is that because it's not atomic?
[14:09] <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:21] <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:23] <vila> Odd_Bloke: I see
[14:25] <abentley> vila: Yes.
[14:26] <vila> abentley: ok, I'll work on something else then, I'm looking at your previous patch anyway
[14:28] <abentley> vila: As I mentioned to jam, we might want to support different authentications for sftp and bzr+ssh eventually.
[14:30] <vila> I didn't see that, can you explain why, it sounds strange
[14:31] <abentley> vila: Well, we support different authentications for other protocols.
[14:31] <vila> you can already differentiate on port or on path
[14:32] <abentley> vila: http and ftp can also be differentiated on port.
[14:33] <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:34] <vila> hmmm
[14:35] <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:37] <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:38] <abentley> I'm saying that one day, we may want to support "sftp" and "bzr+ssh" as additional schemes in authentication.conf
[14:39] <vila> I don't understand what that means
[14:39] <vila> Currently we use auth.get_user('ssh',  will that change ?
[14:40] <abentley> vila: Yes, it would change to if auth.get_user('sftp...) is None: auth.get_user('ssh'...)
[14:43] <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:44] <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:45] <abentley> And you would not *need* to specify different credentials for the same host.  You could specify 'ssh' instead.
[14:46] <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:47] <abentley> vila: Right.
[14:48] <vila> Eerk, what's the point then ?
[14:55] <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:59] <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.
[15:00] <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:01] <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:02] <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:03] <nbjayme> okay... thanks. :)
[15:03] <vila> nbjayme: we are discussing how to describe credentials in authentication.conf
[15:05] <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:06] <abentley> vila: Anyhow, as I said, I'm not interested it doing it now.
[15:06] <vila> ok
[15:07] <vila> abentley: what is the scope of you modification then ? Writing an authentication.conf file when launchpad-loging is used ? Or more ?
[15:09] <vila> LOSA: ping, pqm blocked
[15:12] <abentley> vila: Also, writing an authentication.conf entry when it discovers that there is a configured login, but no corresponding authentication.conf entry.
[15:13] <abentley> vila: But I think that's all.
[15:13] <vila> ok, great, I can work on other parts then
[15:21] <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:22] <pysquared> Any bzr wizards around right now?
[15:23] <abentley> pysquared: Setting the mtime to the stored date messes up build systems.  We do not want that.
[15:24] <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:25] <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:26] <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:27] <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:29] <abentley> pysquared: http://search.gmane.org/search.php?group=gmane.comp.version-control.bazaar-ng.general&query=mtime
[15:30] <abentley> pysquared: The ones about "revert" would also apply to checkout.
[15:30] <pysquared> abentley: fantastic
[16:41] <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:46] <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:47] <qebab> or is there further magic I need to work
[16:48] <jelmer> qebab, there's no need to svn co it
[16:48] <jelmer> just "bzr svn-push <svn-repository-location>/trunk"
[16:49] <qebab> cool :)
[16:54] <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:55] <nbjayme> i meant *delete the focus branch in launchpad* and push my local branch?
[16:57] <jelmer> nbjayme, yes, I think so
[16:58] <nbjayme> okay thanks!.... by the way, congrats to the devs for the great feature. :)
[16:59] <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?
[17:00] <Odd_Bloke> qebab: That's presumably just for docs, but you could just install it?
[17:01] <qebab> Odd_Bloke: the apt package was apparently not recent enough :)
[17:08] <abentley> jelmer, qebab I don't think there's a requirement for the target branch to be in format 1.6.
[17:09] <jelmer> abentley: Sorry, I think I'm missing some context
[17:10] <abentley> jelmer: Sorry, I meant nbjayme
[17:11] <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:12] <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:13] <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:14] <abentley> jelmer: I thought bzr upgrade on hpss was decent now, though.
[17:15] <jelmer> abentley, it works, but still does the actual conversion locally, thus it's very slow
[17:20] <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:21] <sohmestra> "lacks any common history" meaning: an export of the original branch was placed under revision control and development continued from there.
[17:22] <beuno> sohmestra, both versioned with bazaar, only that the second one wasn't branched from the first one?
[17:23] <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:24] <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:25] <sohmestra> anyway, I'll fiddle some more
[17:27] <jelmer> rebase doesn't handle the case where there is no common history yet (bug 231674)
[17:28] <abentley> jelmer: what's maptree?  Remapping file-ids?
[17:28] <jelmer> abentley, yes
[17:29] <abentley> jelmer: I think a PreviewTree would also work for that.
[17:30] <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:31] <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:34] <abentley> jelmer: maptree looks like it reimplements the Tree API.  Can you use it as a merge source?
[17:35] <jelmer> abentley, yes, that's the idea
[17:37] <abentley> Wow, I'd have thought you needed a bigger implementation to support that.  Good stuff.
[17:39] <jelmer> hmm, it doesn't appear we're doing that yet so it may not be complete anymore
[18:47] <mtaylor> hey all... if I made a stacked branch and want to replace it with a normal branch ... what's the best way?
[18:49] <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:50] <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
[19:20] <LarstiQ> beuno: hmm, that would surprise me
[19:25] <beuno> LarstiQ, me too, but, I've been suprised before  :)
[19:26] <LarstiQ> :)
[19:29] <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:30] <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:31] <LarstiQ> ktenney: config.GlobalConfig().set_alias(alias_name, alias_command) it looks like
[19:31] <LarstiQ> ktenney: where config is bzrlib.config
[19:32] <ktenney> LarstiQ: thx, I'll try that ...
[20:02] <ktenney> LarstiQ: works, thanks, bye.
[20:02] <LarstiQ> ok :)
[20:03] <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:04] <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:05] <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:09] <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:22] <pickscrape> Anyone know off the top of their head what bundle buggy matches against when deciding if someone is a voter or not?
[20:23] <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:24] <beuno> but I'm 95% sure  :)
[20:24] <abentley> pickscrape: The email address and the name part.
[20:25] <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:26] <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:27] <abentley> beuno: mostly because it was the fastest thing at the time.
[20:28] <beuno> abentley, heh, ok, makes sense   :)
[21:09] <abentley> lifeless: ping
[22:19] <lifeless> abentley: hi
[22:20] <abentley> lifeless: nm.  PQM was stuck.  Isn't now.
[22:20] <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?
[23:00] <pickscrape> What is the meaning/purpose of the "My Pending" and "Mine" tabs in BB?
[23:05] <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:06] <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:26] <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:27] <a_c_m> (testing it ready for a deployment on a server)
[23:27] <bob2> is bzr in your PATH?
[23:30] <a_c_m> its in /usr/bin which is in my path yes
[23:31] <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:33] <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:34] <a_c_m> let me try 2 ticks
[23:37] <a_c_m> well that gets me closer for sure!
[23:38] <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:41] <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:44] <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:45] <fullermd> Well, there wouldn't really be any constant error.
[23:46] <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:47] <lifeless> fullermd: we can write up a 'check your server config' checklist
[23:48] <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:50] <fullermd> Oh, I was thinking jump right to "ssh -T host bzr version" to check as much of the path as possible.
[23:51] <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:53] <lifeless> in other news
[23:54] <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:55] <fullermd> It's a feature.  bzr comes with built-in I/O benchmarks.  Email reading is expected for 2.0.
[23:56] <elmo> even gnu hello has email reading
[23:59] <lifeless> poolie: was debugging an lp issue @ 9. anything particularly interesting from the standup
[23:59] <lifeless> ?