[06:09] <fullermd> Sheesh, it's quiet today.  Did I miss a memo about a picnic?
[06:26] <quik_> hey folks
[06:27] <quik_> if `bzr break-lock` isn't breaking the lock set yesterday.. what does one do?
[06:27] <Peng> quik_: Are you running it on the URL of the locked branch?
[06:28] <quik_> eh?
[06:28] <Peng> quik_: Are you trying to break the lock on your local branch or the server you push to or what?
[06:28] <quik_> the server I want to push to
[06:28] <Peng> quik_: Does "bzr break-lock" prompt you about the lock or do nothing?
[06:29] <quik_> seemingly, nothing
[06:29] <Peng> quik_: You need to pass it the URL of the branch. "bzr break-lock sftp://..." or whatever.
[06:30] <quik_> ah right
[06:31] <Peng> :)
[06:31] <quik_> thanks Peng
[06:32] <Peng> You're welcome. :)
[07:50] <jmhodges> hey, i can't bzr rspush to, for instance, deploy@foobar:~/thing. it tells me its not a branch or empty directory.  however, i have previously bzr pushed to that same directory.  is this a problem with the macports install of bzr and bzrtools or am i missing something?
[07:52] <fullermd> Yes   :)
[07:52] <fullermd> I have no real knowledge of the domain.  But I have a hard time picturing a way the install could be horked up, and it would work well enough to run, but be broken enough to look in the wrong place.
[07:53] <fullermd> You sure you're not accidentally push'ing instead of rspush'ing?
[08:19] <lifeless> jmhodges: what does ls -l of that directory show ?
[08:20] <jmhodges> lifeless: not the place for unix quesions. this is #bzr
[08:20] <jmhodges> lifeless: the #linux or #bsd or whatever you're on :)
[08:20] <jmhodges> s/the/try/
[08:20] <lifeless> jmhodges: also rspush is very old; you may prefer push + jam's post-push rsync plugin
[08:20] <lifeless> jmhodges: I'm helping you debug it, but whatever.
[08:21] <jmhodges> lifeless: jesus i'm sorry i misread
[08:21] <lifeless> jmhodges: I'm one of the core authors of bzr.
[08:21] <lifeless> jmhodges: still, I meant 'ls -al'
[08:21] <jmhodges> lifeless: i thought you asked me what ls -l always does
[08:21] <jmhodges> lifeless: like a newbie asking a question about ls
[08:21] <lifeless> heh
[08:21] <jmhodges> lifeless: i was like "wtf? havnt i seen this guy here before?"
[08:21] <jmhodges> sorry
[08:21] <jmhodges> one sec
[08:22] <jmhodges> lifeless: its just .bzr
[08:22] <lifeless> ok
[08:22] <jmhodges> lifeless: from the pushes i did before
[08:22] <lifeless> cat .bzr/branch-format, and .bzr/repository/format
[08:22] <jmhodges> lifeless: locally or in the remote?
[08:22] <lifeless> in the remote
[08:23] <jmhodges> branch-format: Bazaar-NG meta directory, format 1   and format: Bazaar pack repository format 1 (needs bzr 0.92)
[08:23] <jmhodges> that looks.. wrong somehow
[08:23] <jmhodges> bzr --version says "Bazaar (bzr) 1.0.0"
[08:24] <lifeless> ok, thats all good
[08:24] <jmhodges> yay
[08:24] <lifeless> the most likely thing then is that the path you are giving is not resolving correctly; could you try an absolute path ?
[08:24] <lifeless> deploy@foobar:/path/to/thing
[08:24]  * jmhodges nods
[08:25] <jmhodges> one sec, need to ci some changes
[08:26] <jmhodges> bzr rspush deploy@biggecko:/home/deploy/bzr/atelier-main # => bzr: ERROR: Remote location is not a bzr branch (or empty directory)
[08:26] <jmhodges> lifeless: ^
[08:37] <jmhodges> lifeless: again, sorry for being a jerk earlier.  i blame the couple of hours of sleep i've been getting for the past week and my own inattention.
[08:37] <lifeless> interesting
[08:37] <fullermd> Does rspush stuff anything in .bzr.log?
[08:37] <lifeless> forget about it
[08:38] <lifeless> jmhodges: I really recommend you try jam's plugin instead of rspush
[08:38] <lifeless> jmhodges: it ssh's in and runs bzr update
[08:38] <jmhodges> lifeless: jams plugin?
[08:38] <jmhodges> i've been out of bzr for too long
[08:38]  * jmhodges googles
[08:38] <fullermd> push-and-update, I think.
[08:38] <fullermd> Something like that.
[08:39] <jmhodges> fullermd: that's it
[08:40] <jmhodges> cool.  i'm assuming then that speed gains of rspush aren't worth other problems that i dont know about (other than "it not working")?
[08:40] <lifeless> oh, rspush is likely slower
[08:40] <fullermd> Actually, with packs, the speed gains of rspush can become very negative.
[08:40] <jmhodges> ohhh
[08:40] <jmhodges> thanks!
[08:41] <jmhodges> i'll just grab it out of trunk then.  thanks again
[08:47] <jmhodges> hm.. it pushes fine, and the command shows up in `help commands` but bzr push doesn't "do what i expected" or does it really require running `bzr push-and-update` ?
[08:48] <jmhodges> weird
[08:48] <fullermd> Probably, if that shows up in the command list.
[08:49] <lifeless> try bzr help push-and-update :)
[08:54] <jmhodges> natch.  for some reason, i thought it "overwrote" push
[09:23] <Laurens_S> Hello, is there someone here who has experience using bzr 1.0, with bzr+ssh on windows? I can't seem to get it to work. sftp works fine, but I'd like the speedimprovement of bzr+ssh which I've seen in linux
[09:30] <spiv> Laurens_S: what problem are you having?
[09:31] <Laurens_S> this is the error I get:
[09:32] <Laurens_S> (reproducing error.....)
[09:34] <Laurens_S> Z:\src>bzr log bzr+ssh://username@server/full/path
[09:34] <Laurens_S> Connected (version 2.0, client OpenSSH_3.8.1p1)
[09:34] <Laurens_S> SSH username@server password:
[09:34] <Laurens_S> Authentication (password) successful!
[09:34] <Laurens_S> Secsh channel 1 opened.
[09:34] <Laurens_S> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[09:34] <Laurens_S> Z:\src\>
[09:34] <Laurens_S> I tried -Dhpss, didn't show anything more
[09:34] <spiv> Laurens_S: -Dhpss puts more information in the .bzr.log file
[09:35] <Laurens_S> ah :)
[09:35] <Laurens_S> I'll try again
[09:35] <spiv> ("bzr version" should report the location of that file)
[09:36] <spiv> So, put the contents of the log file on pastebin.com
[09:37] <Laurens_S> ah, I finally figured it out:
[09:37] <spiv> I'm guessing it's something wrong on the server side, perhaps "bzr" is not on the PATH?
[09:37] <Laurens_S> yes, that was indeed the case
[09:37] <spiv> Heh, lucky guess :)
[09:37] <Laurens_S> I set BZR_REMOTE_PATH to the correct location now
[09:38] <Laurens_S> I thought I did that, but SET revealed that I messed up :
[09:38] <spiv> Ah, right.
[09:38] <Laurens_S> zbr_remote_path=/home/ls/local/bin/bzr is not really the same as BZR_REMOTE_PATH :)
[09:38] <spiv> heh.
[09:38] <Laurens_S> well, thanks for helping out :)
[09:38] <spiv> You're welcome :)
[09:39] <Laurens_S> now it turns out I forgot to do a bzr bind, bzr commit before leaving the house :)
[09:39] <Laurens_S> anyway, thanks again, and have a good day y'all :) Loving bzr!
[09:57] <Kinnison> lifeless: Has anyone come up with the answer for you for the traffic shaping?
[09:57] <Kinnison> lifeless: If not, my recommendation is to use 'tc' but it's arcane and confusing, even for people who already know how to use it
[10:02] <gus> I broke my branch :(
[10:02] <gus> anyone know what this means:
[10:02] <AfC> Try using gun tape. That'll fix anything
[10:02] <gus> % bzr commit
[10:02] <gus> bzr: ERROR: Cannot commit to branch BzrBranch6('file:///home/gus/debian/libapache-sessionx-perl/debian/'). It is bound to BzrBranch6('sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/'), which is bound to sftp://mongrel/home/gus/archives/libapache-sessionx-perl/debian/.
[10:02] <gus>  
[10:03] <gus> its not real informative
[10:03] <AfC> gus: Sounds like you don't have write permissions on the target branch, but I assume this used to work for you?
[10:03] <gus> yes
[10:04] <AfC> gus: anyone else committing to this branch?
[10:04] <gus> it was a lightweight checkout, but I removed that and did a heavyweight checkout
[10:04] <gus> nope, its all me
[10:04] <fullermd> Er.  It's recursive.
[10:04] <AfC> gus:  (ie, beware debian style group-per-user nonsense which can result in various users trampling permissions in a repo)
[10:04] <gus> afc: its my laptop and home desktop - i don't think there are other users here
[10:05] <fullermd> You've got a branch bound to itself.  That kinda doesn't work...
[10:05] <AfC> gus: and as another aside, any particular reason you're using a bound branch ("checkout") instead of a full power branch?
[10:05] <gus> I don't know, I'm not really a power bzr user
[10:05] <Kinnison> gus: log onto mongrel, cd into /home/gus/archives/libapache-sessionx-perl/debian/
[10:05] <Kinnison> gus: type bzr unbind
[10:05] <Kinnison> gus then try again
[10:06] <Kinnison> gus: As fullermd says, your remote branch is bound to itself, which is the complaint
[10:06] <gus> works fine
[10:06] <gus> interesting
[10:06] <gus> before the unbind, it said this:
[10:06] <gus> % bzr info
[10:06] <gus> Repository bound branch (format: dirstate-tags)
[10:06] <gus> Location:
[10:06] <gus>   shared repository: /home/gus/archives/libapache-sessionx-perl
[10:06] <gus>   repository branch: .
[10:06] <gus>  
[10:06] <gus> Related branches:
[10:06] <gus>     push branch:
[10:06] <gus>   parent branch: /home/gus/archives/libapache-sessionx-perl/upstream
[10:06] <gus>  
[10:07] <gus> where's the bit that tells me where its bound to?
[10:07] <Kinnison> gus: oddness, it doesn't specifically say it was
[10:08] <Kinnison> it should say checkout of branch: .....
[10:08] <Kinnison> but then again, it was bound to itself, so who know how odd it could have gotten
[10:08] <fullermd> My checkouts say "Repository checkout (format: dirstate-tags)"
[10:08] <Kinnison> gus: fyi, in future, please use a pastebin like pastebin.ca or rafb.net/paste/ for anything more than a line or two
[10:08] <gus> meh. I haven't touched these for ages, perhaps I typed something dumb once ages ago
[10:09] <gus> kinnison: yep, sorry I'm being lazy.  me--
[10:09] <fullermd> What version of bzr are you running?
[10:09] <Kinnison> fullermd: oh true, repos will say that
[10:09] <Kinnison> gus: and it does say "Repository bound branch" at the top
[10:09] <gus> I now have bzr 1.0 at both ends, but these repositories were created / last-modified by a much older bzr version (I couldn't tell you how old)
[10:10] <gus> anyway, thanks.  I can pretend I'm still an active debian developer now.  ;)
[10:12] <Kinnison> If you have 1.0, consider using pack format for faster operation (make backups first obv.)
[10:12] <Kinnison> I've found pack to be much faster when working with remotely bound branches
[10:12] <Kinnison> But then again, I am odd :-)
[10:13] <gus> heh.
[10:13] <gus> as an aside: I had lots of trouble finding a way to convert a lightweight checkout into a heavyweight.  Is there some way of doing that 'in place'?
[10:14] <fullermd> I think reconfig can do that.
[10:14] <fullermd> At least in recent versions.
[10:14] <gus> didn't seem to (at least in 1.0)
[10:16] <fullermd> It's got --checkout in 1.0...
[10:17] <gus> right, but both heavyweight and lightweight checkouts are checkouts, right?
[10:17] <gus> or have I confused some terminology somewhere
[10:17] <gus> I guess I want a bound branch or something
[10:17] <fullermd> Unqualified 'checkout' implies heavyweight.
[10:18] <gus> ah ok.  I'll give that a go next time.
[10:54] <i386> lifeless: ping
[12:21] <dgl_> hi, where can I find something really useful about bzr? I guess documentation at http://bazaar-vcs.org are not very clear.
[12:21] <dato> dgl_: try http://doc.bazaar-vcs.org/
[12:24] <dgl_> dato: I've already been there, sorry about that but I really don't think bzr has a complete documentation that can explain it at all .
[12:24] <dato> explain it all in what sense?
[12:25] <dato> what all? using should be well covered by http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[12:25] <dato> usage
[12:27] <dgl_> dato: I've been svn user since a couple of years ago and it has a clear workflow description. I know bzr has a lot of possible workflows, but none of them are really explained.
[12:28] <dato> not really explained *where*? I haven't read the user guide myself, but the table of contents *hints* like as if they are explained there
[12:35] <dgl_> dato: I've read it, it just superficially describes some workflows.
[12:36] <luks> anything in particular that you think is missing there?
[12:39] <dgl_> dato: I guess, as svn user, learn decentralized workflows is a little hard.
[12:40] <dato> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#team-collaboration-distributed-style has the very basics, but honestly, there's not *much* more
[12:41] <dgl_> dato: and there are some concepts that works little different, like branches, where in svn is just a copy
[12:41] <luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#branch
[12:41] <dato> dgl_: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#concepts
[12:42] <dato> oh, what luks says is better
[12:42] <dato> but using DAG in that section, eek
[12:43]  * fullermd finds copies a buttload harder to understand.
[12:45] <dgl_> gutsy uses bzr 0.9 and my local doc are a little bit smaller
[12:46] <fullermd> 0.9?!
[12:46] <dato> 0.90
[12:46] <dato> dgl_: the docs got *really* polished for 1.0
[12:46] <fullermd> Jeez.  Don't DO that to my poor brain...
[12:47] <dgl_> sorry 0.90
[12:47] <dato> dgl_: if you could read or download the online versions, I think it'd be very helpful
[12:47] <dato> dgl_: most of it if not all will apply
[12:48] <dgl_> dato: I'll read online version
[12:48] <dato> great
[12:50] <dgl_> dato: maybe I'll do some pinning to get 1.0
[12:51] <dato> there ought to be backports for gutsy in bazaar-vcs.org/releases/debs
[13:11] <zurgutt> Hi folks.  Is there gui for bzr, or some ide/editor with integration?
[13:13] <dgl_> olive
[13:14] <dgl_> zurgutt: olive is a gui for bzr
[13:16] <zurgutt> thanks dgl
[14:41] <smagoun> We have a bzr repository on a server. I'm interested in running
[14:42] <smagoun> a script whenever someone pushes to that repo. Is there an easy way to do that?
[14:42] <smagoun> (I want to run the script on the server side, and ideally don't want to install a plugin on every developer workstation)
[14:43] <mwh_> well
[14:44] <mwh_> if you're pushing over a dumb transport that sounds kinda hard
[14:44] <smagoun> mwh_: I was afraid someone would say that. Polling the repo is the obvious solution then?
[14:45] <mwh_> if it's bzr+ssh only then something might be possible
[14:45] <mwh_> but, hm, probably not easy
[15:31] <ndim> Meh. Google for "git to bzr conversion" and the first hit is titled "How To Convert Bazaar Repo to Git".
[15:31] <LeoNerd> Use Tailor
[15:32] <ndim> LeoNerd: Is http://bazaar-vcs.org/BzrForeignBranches/Git known to be broken?
[15:33] <ndim> I'm looking for a one-off conversion. I have a few git branches based on old CVS versions of Mailman, and Mailman has since switched to bzr.
[15:33] <LeoNerd> Dunno.. never seen it before. Try it :)
[15:33] <ndim> Good :)
[15:33] <LeoNerd> If it's just a oneoff conversion, do you care about history?
[15:33] <LeoNerd> If not, it might be easier just to do an export/import snapshot, and forget history
[15:33] <ndim> I care about the stuff I did.
[15:33] <ndim> History-wise.
[15:34] <ndim> It will probably be easier to merge 50 line patches than one 2000 line patch.
[15:34] <ndim> divide et impera and stuff. :)
[15:36] <luks> ndim: the converted branch probably won't help you much if you want to merge it to the current mailman bzr branch
[15:37] <luks> revisions will have different IDs, files will have different IDs
[15:45] <ndim> $ bzr branch mailman-2.1.7.cg mm-git2bzr-test
[15:45] <ndim> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_output_one_line'
[15:45] <ndim> luks: Uhm.
[15:46] <luks> what does ~/.bzr.log say about the error?
[15:46] <ndim> Sounds like I'm better off converting current mailman from bzr to git, rebase my git stuff on that converted thing, and then convert the merged thing back to bzr...
[15:47] <luks> ndim: converting from git won't get you branch mergeable with trunk either
[15:47] <ndim> luks: traceback in stgit.
[15:47] <luks> oh
[15:47] <luks> mailman-2.1.7.cg is a git branch?
[15:48] <ndim> yupp.
[15:48] <ndim> cogito, to be exact.
[15:48] <ndim> bzr-git/stgit incompatibility.
[15:49] <ndim> The conversion from git to bzr I could do as generating a few dozen patches and commiting them with bzr.
[15:49] <ndim> That result would then be mergeable.
[15:49] <ndim> As I'd start on the bzr side with real upstream's bzr repo.
[15:49] <luks> ah
[16:07] <dato> jelmer: any chance to look at #180128?
[16:07] <dato> bug #180128
[16:07] <ubotu> Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128
[16:07] <jelmer> will have a look in the next few days
[16:07] <dato> ok, no hurries, just thought I'd ask.
[16:07] <jelmer> there's a couple of other bzr-svn issues I have to look at as well, and I prefer doing them in batches
[16:07] <dato> very well
[16:07]  * jelmer is in Samba-mode atm :-)
[16:30] <ubotu> New bug: #181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New] https://launchpad.net/bugs/181811
[16:36] <jelmer> ddaa: btw, I made a couple of small fixes to your bzr-git branch
[16:36] <ddaa> great
[16:36] <jelmer> https://code.edge.launchpad.net/~jelmer/bzr-git/jelmer
[16:36] <jelmer> fixes support for python2.4
[16:37] <ddaa> jelmer: I do not plan to put any more work on bzr-git in the near future.
[16:37] <jelmer> ok
[16:37] <ddaa> feel free to own it
[16:37] <jelmer> I'm not sure I want to :-)
[16:37] <ddaa> well, it actually has the beginning of a useful test suite :)
[16:37] <jelmer> I may end up owning it though, if I start using it for Samba
[16:48] <muffinresearch> Quick question. Does anyone think it would be useful to have a shell script installer for mac that installs bazaar including all of the dependencies
[16:48] <muffinresearch> Does anything like that exist already?
[16:49] <jelmer> muffinresearch, I know there were some people working on it
[16:49] <jelmer> muffinresearch, not sure what the status is though
[16:49] <jelmer> phanatic: ping
[16:49] <muffinresearch> I see this: http://www.nabble.com/Bazaar-OS-X-Installer-status-td14254776.html
[16:49] <phanatic> jelmer: pong
[16:50] <jelmer> phanatic: ^^
[16:50] <phanatic> muffinresearch: there is already an installer available for leopard (bazaar 1.0)
[16:51] <phanatic> muffinresearch: http://bazaar-vcs.org/Download
[16:52] <muffinresearch> I don't have leopard
[16:53] <muffinresearch> Presumably macports is kept fairly up to date.
[16:53] <phanatic> indeed
[16:53] <phanatic> that works fine as well
[16:54] <phanatic> jelmer: i could even get bzr-gtk working with macports, it's pretty cool :)
[16:54] <muffinresearch> The main reason is just providing a quick way for colleagues to get up and running with the latest version. I normally install from source myself
[16:57] <muffinresearch> macports is probably the best option. I'll get someone to try that
[17:37] <nebuchadnezzar> hello
[17:38] <jelmer> hi
[17:55] <nebuchadnezzar> I'm following the bzr upgrade in my debian SID and I see some new format, rich-root and rich-root-pack, I don't find documentation/specification about them.
[18:48] <brianpeiris> hello
[18:49] <brianpeiris> quick question, am I correct in assuming that bzr diff does not support UTF-16 ?
[18:50] <jelmer> brianpeiris: AFAIK, yes
[18:50] <jelmer> brianpeiris: you can however use it with external diff tools
[18:50] <luks> but it will print utf-16
[18:51] <brianpeiris> ok, explains the "binary files ... differ" message I was getting while trying to diff a UTF-16 sql script.
[18:51] <luks> actually, it won't print anything
[18:51] <luks> yeah
[18:51] <luks> bzr checks if the file has nul bytes, and if yes it assumes it's binary
[18:54] <brianpeiris> alrighty, thanks for the help.
[18:55] <ubotu> New bug: #181842 in bzr "BZR_SSH environment variable is not explained in docs" [Undecided,New] https://launchpad.net/bugs/181842
[18:55] <dgl> hi
[18:56] <dgl> Can anyone explain me what are the differences between init and init-repos?
[18:57] <jelmer> init creates a branch
[18:57] <jelmer> init-repo creates a (shared) repository
[18:58] <dgl> jelmer: ok, i've already read that, but what does it mean?
[19:01] <dgl> basically you create a branch just few times and then start to 'branch' it, isn't it?
[19:01] <jelmer> dgl: see http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#core-concepts for an explanation of branch and repository
[19:04] <brianpeiris> @dgl, see also: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#repositories
[19:05] <dgl> thanks, I will
[19:29] <UbuntuStats> Hi - From now on #bzr will have statistics on ubuntuircstats.org (gouki)
[19:32] <dgl> where is a nice place to create a shared repos at an ubuntu server?
[19:32] <gouki> Here it is: http://ubuntuircstats.org/bzr.html
[19:32] <gouki> Enjoy guys!
[20:01] <ubotu> New bug: #181855 in bzr "cygwin bzr branch crashes with IOError: [Errno 0] Error" [Undecided,New] https://launchpad.net/bugs/181855
[20:16] <dgl> where is a nice place to create a my mainline shared repos at an ubuntu server?
[20:17] <beuno> dgl, Launchpad es where you create branches, but it doesn't support shared branches as far as I know
[20:17] <beuno> I suppose, at the moment, it's meant for local use, to save space
[20:17] <LarstiQ> depends on what you mean with shared
[20:17]  * beuno waves at LarstiQ 
[20:18] <LarstiQ> multiple people can push to branches on launchpad, provided they are part of the team owning the branch
[20:18] <LarstiQ> beuno: heya :)
[20:18] <dgl> beuno: I've got a server with ssh, I just want to use it as a shared repos
[20:18] <LarstiQ> dgl: you're asking what a good location is to place public repositories?
[20:18] <beuno> dgl, you want multiple people to be able to work on a branch, or you want multiple branches to use the same repo?
[20:18] <LarstiQ> in a FHS kinda way
[20:19]  * LarstiQ user /srv/bzr/<repository-name-here>
[20:19] <dgl> LarstiQ: sorry, but I think I was not clear
[20:19] <dgl> I was talking about filesystem
[20:20] <beuno> dgl, that just confuses me more  :D
[20:21] <dgl> beuno: LarstiQ's understood me
[20:21] <beuno> ah, yes, he's very good at that
[20:21] <dgl> beuno: I was asking about a nice place to create a shared repos at my server file system
[20:22] <beuno> dgl, happy you got your answer  :D
[20:23] <LarstiQ> dgl: it depends on the rest of your filesystem layout of course, /var/www/bzr/ is also not unthinkable :)
[20:23] <dgl> LarstiQ: and /var/bzr?
[20:23] <LarstiQ> dgl: not where I'd place it myself
[20:23]  * LarstiQ thinks it fits best under /srv
[20:24] <LarstiQ> dgl: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
[20:24] <lifeless> /srv/bzr/www
[20:24] <lifeless> hmm, maybe /bzr/www/srv/var/
[20:24] <LarstiQ> lifeless: argh :P
[20:25] <lifeless> no like?
[20:25] <LarstiQ> you'd have to have a rather complex setup for that to make sense I think
[20:25] <lifeless> ok, ok.
[20:25] <LarstiQ> something like launchpad perhaps
[20:25] <lifeless> /var/bzr/srv/www/
[20:25] <LarstiQ> lifeless: are you pulling my leg again? :)
[20:25] <lifeless> moi?!
[20:25] <dgl> I just want to use sftp
[20:26] <LarstiQ> lifeless: true true, I've never caught you doing it before.
[20:26] <lifeless> maybe not on IRC; in person you have:)
[20:26] <LarstiQ> hah! Now I did ;)
[20:26] <lifeless> dgl: anything is fine; key things to think of is 'will it be backed up by your backup programme'
[20:28] <dgl> lifeless: thanks
[21:12]  * lamont looks around for a bzr god
[21:12] <lamont> lifeless: you awake?  and are you a god? :-)
[21:14] <lamont> if a user has read access to .bzr/* (and down), but lacks read access on bar/foo.c, how can I tell bzr to just ignore that little issue and keep right on going with its life?
[21:15] <dato> heh
[21:15] <lifeless> lamont: (True, True)
[21:17] <lamont> lifeless: I see that you remember ghostbusters.
[21:17] <lamont> now about bzr and bar/foo.c ....  any hope for me?
[21:20] <lamont> lifeless: ^^
[21:23] <lifeless> lamont: you can't
[21:24] <jearl> \q
[21:24] <lifeless> lamont: (in general). Bu perhaps you can give me more info ;)
[21:37] <Peng> Nice, some random doofus clicked on one of my bundles because it's the only Google result for "JGR1my space". :\
[21:38] <Peng> Googlebot also found a link to /yaygyosr.html in one of them.
[21:43] <lifeless> rotfl
[22:31] <Peng> Ooh, the "JGR1my space" search was from Mexico!
[22:39] <lifeless> yay hung test :(
[22:39] <LeoNerd> Hung-like-horse, or hung-like-Sadam ?
[22:39] <Peng> Ouch.
[22:39] <lifeless> I'll find out soon
[22:40] <lifeless> hung like reading bytes that never came
[22:40] <Peng> I got a "Connection reset by peer" after 3 minutes pushing 1 KB of changes over bzr+ssh. :D
[22:55] <abentley> lifeless: Your patch to remove the need for ParentProvider.get_parents looks very strange.  The goal is fine, but please don't merge in current form.
[22:56] <lifeless> abentley: good timing; I had just hit enter to push and submit
[22:56] <lifeless> whats wrong with it ?
[22:56] <abentley> It means that Graph.parents_provider is sometimes None.
[22:56] <abentley> Sorry
[22:56] <abentley> Graph.get_parents is sometimes None
[22:56] <abentley> That's a public API
[22:56] <dato> abentley: (when you have a couple minutes and if you don't mind, did you see my question about having send, when -r is specified, always bundle those revisions, even if they're in the submit branch?)
[22:57] <abentley> It should always be a callable.
[22:57] <lifeless> abentley: oh, that wasn't clear to me because its not defined explicitly
[22:58] <abentley> You can deprecate it, or remove it entirely, but no one expects a method to sometimes be None.
[22:58] <lifeless> so if I add
[22:58] <lifeless> 'if self.get_parents is None: del self.get_parents' you're happy ?
[22:59] <abentley> You mean Graph.get_parents would sometimes be defined, and sometimes not defined?
[22:59] <lifeless> or I can write a regular get_parents method
[22:59] <lifeless> well currently I can supply a ParentsProvider with get_parents = None
[22:59] <abentley> I prefer either deprecate it, or remove it in all cases.
[22:59] <lifeless> because the Graph class does not define any of what you are referring to
[23:00] <lifeless> and we don't provide any thunking in either direction
[23:00] <abentley> lifeless: You can, but that's an API violation.
[23:00] <lifeless> abentley: how about I write Graph.get_parents and graph.get_parent_map, both in terms of each other
[23:01] <lifeless> abentley: then the constructor can replace just one from the ParentsProvider
[23:01] <abentley> Why would you write Graph.get_parents_map?
[23:01] <abentley> Let's just standardize on ParentsProviders having that.
[23:01] <lifeless> so that providers with get_parents still work - that is the point of deprecating that isn't it ?
[23:02] <abentley> There are no providers with only get_parents.
[23:02] <lifeless> let me rephrase; we appear to have a deprecation which is not really a deprecation - its not compatible. I'm happy to either turn it into a full break; or a real deprecation where the old code works. Your choice.
[23:02] <lifeless> abentley: third party repositories will almost certainly be providers with only get_parents
[23:02] <lifeless> which is public in that Graph.__init__ takes a public parameter.
[23:04] <abentley> I have a slight preference for real deprecation, but I'd be fine with either.
[23:04] <lifeless> ok I'll whip it up
[23:05] <abentley> dato: That has already proven to result in horrible messes, and that's why there's a submit branch.
[23:05] <abentley> However, if you want an override, that's fine.
[23:05] <dato> override == option?
[23:06] <abentley> Yes.  People have asked for that in the past, but they've never suggested how the commandline would work.
[23:06] <dato> ok, I'll make a note, and possibly talk to you about it in the (near) future. now it'd be bed time for me.
[23:06] <abentley> One way would be a second revision spec.
[23:06] <abentley> Another would be an option that says --use-revision-spec-instead-of-submit-branch
[23:08] <dato> (I guess I didn't realize the time it was when I brought up the subject, sorry. chao)
[23:09] <abentley> But remember that a merge directive, is meant to convey the changes you want made.  That's what the -r controls.
[23:10] <abentley> The revisions supplied are the ones necessary for other people to apply the those changes.
[23:10] <abentley> For a cherry-pick, that is typically *more* revisions than the -r range includes.
[23:11] <abentley> The submit branch should indicate which revisions everyone already has.