[00:08] <igc> emmajane: ping
[00:35] <KhaZ_> Hello!  I apologize if this is the wrong place to ask this, but does anyone here use the bzr-p4 plugin?  I'm trying to understand just what it does but the documentation on it appears to be rather minimal.
[00:36] <lifeless> you can try bzr help p4 (if thats what the directory for the plugin is called)
[00:36] <lifeless> I don't know how complete it is
[00:36] <KhaZ_> Ah, OK.  I supopse I'll isntall it.  Just trying to  read more of it before I install it - not sure if it will solve my problems or not.
[00:37] <lifeless> but most foreign VCS plugins allow 'bzr pull' 'bzr branch' etc to Just Work with urls/locations in those systems
[00:37] <KhaZ_> Ah, neat.  Maybe that is something similar to what I want.  Is bzr push normally facilitated as well, or is it usually up to the client to use the other VCS' tool for that?
[00:37] <lifeless> depends on how complete the plugin is :)
[00:38] <KhaZ_> Ah, but it's not out of the qeustion then at least.
[00:38] <lifeless> but yes, certainly for bzr-svn and bzr-git the whole gamut of push/pull/branch/merge commands work
[00:38] <KhaZ_> Swank.  I will have to dabble with this.  Perforce is getting on my nerves.
[01:16] <KhaZ_> ALright, dumb question.  How can I see what plugin directory bzr is scanning for?  I'm running cygwin on vista, and I've tried $APPDATA/bazaar/2.0/plugins and ~/.bazaar/plugins, and yet bzr plugins doesn't return me any of my nifty plugins.  Is there an easy way to get it to spit out the path it's looking up?
[01:18] <fullermd> Not directly, I don't think.  But it should be a 'plugins/' subdir under the 'Bazaar configuration' dir that `bzr version` spits out, I think.
[01:19] <KhaZ_> Genius, that works.  Thanks fullermd.
[01:20] <KhaZ_> Ah, right.  I had reset my BZR_HOME in order to try and keep my linux/windows configurations the same.  D'oh, should've checked the env. variables. :/
[01:20] <fullermd> Maybe there should be an arg to 'plugins' to list the search path.
[01:20] <KhaZ_> I was hoping --verbose would show it
[01:20] <KhaZ_> fullermd: Might be a nice add.
[01:20] <fullermd> Nah, that just shows where the existing plugins are from.
[01:20] <jdub> i'm getting the following error after attempting to bzr co with http basic auth against loggerhead:
[01:20] <jdub> bzr: ERROR: exceptions.KeyError: 'user'
[01:21] <jdub> (interactive or provided in the url)
[01:21] <KhaZ_> fullermd: Right.  I guess my assumption was it woudl say, "Found the following plugins from scanning these paths [searchpath1,searchpath2,searchpath3]: plugin1 [plugin1path], etc."
[01:21] <KhaZ_> Not that it matters, but that was where my intuition took me.
[01:24] <fullermd> It's a reasonable intuition.  You should file a bug on it.
[01:26] <spiv> jdub: hmm, sounds crummy.  pastebin a full traceback?
[01:27] <jdub> spiv: http://www.gnome.org/~jdub/2009/bzr-20091021002215-9259.crash
[01:31] <KhaZ_> fullermd: Good idea.  Done: https://bugs.launchpad.net/bzr/+bug/456834
[01:47] <lifeless> jdub: is loggerhead doing the auth, or some front-end web server?
[01:48] <jdub> lifeless: front end
[01:48] <lifeless> how are you passing the user details to the backend then ? :)
[01:49] <jdub> lifeless: not sure i am; if anything, i don't want to
[01:49] <mwhudson> jdub: i'm suspicious of the bzr-svn in that traceback
[01:50] <jdub> mwhudson: you think bzr-svn on the client might be screwing with it?
[01:50] <mwhudson> it's possible
[01:51] <jdub> ah, you know, yes
[01:51] <jdub> it might be trying to use bzr svn on the http url?
[01:51] <jdub> jdub@sliver:/tmp$ bzr co bzr+http://whitlam.crikey.com.au/code/live/bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://whitlam.crikey.com.au/code/live/.bzr/smart: Unknown response code 403
[01:51] <lifeless> I think you should:
[01:51] <lifeless> file a bug
[01:51] <lifeless> remove bzr-svn if you don't need it
[01:51] <lifeless> see if that helps
[01:51] <lifeless> there is a bug, thats for sure.
[01:51] <mwhudson> jdub: that seems like a more plausible problem in some ways
[01:52] <lifeless> jdub: note that bzr+http shouldn't be needed - http:// will probe for .smart anyway.
[01:52] <jdub> yeah
[01:52] <jdub> jdub@sliver:/tmp$ bzr co http://whitlam.crikey.com.au/code/live/
[01:52] <jdub> bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://whitlam.crikey.com.au/code/live/.bzr/branch-format
[01:52] <jdub> ^ without bzr-svn installed
[01:53] <jdub> ooh, what a lovely little mess :-)
[01:53] <lifeless> jdub: 403 sounds like you aren't passing POST to the backend, to me.
[01:53] <jdub> that interactive password request dudie did seem a little svn-riffic
[02:01] <jdub> lifeless: naw, looks like i'm not serving static files at all :_)
[02:03] <lifeless> jdub: yes but that doesn't matter
[02:03] <lifeless> jdub: there should be a 'smart' POST attempt in the log
[02:03] <lifeless> if that is passed through to loggerhead properly, bzr will talk to that, not to static files.
[02:05] <jdub> right
[02:05] <jdub> the smart post hits the frontend with a 403
[02:06] <RenatoSilva> how to  bzr pull --preview merge-directive.patch?
[02:06] <RenatoSilva> or bzr mssing it
[02:18] <jdub> lifeless: does the smart check attempt to auth before posting?
[02:19] <lifeless> jdub: auth is on-demand, when the server gives 401
[02:19] <lifeless> RenatoSilva: I'm not sure missing works with merge diectives
[02:20] <lifeless> RenatoSilva: pull --preview should just work
[02:22] <jdub> lifeless: aaaaaaaahhhhhhhhh
[02:22] <jdub> lifeless: *lightbulb*
[02:22] <jdub> lifeless: i should not bar access to .bzr on this host :)
[02:23] <lifeless> you want .bzr/smart to work
[02:23] <lifeless> not the rest
[02:23] <lifeless> [or at least, you *shouldn't need* the rest]
[02:23] <jdub> right
[02:23] <lifeless> and you want it auth protected.
[02:25] <jdub> yeah
[02:25] <james_w> does loggerhead work as a smart server with no extra configuration?
[02:25] <jdub> lifeless: oh man... new issue
[02:25] <jdub> bzr: ERROR: Server sent an unexpected error: ('error', 'No repository present: "chroot-46030224:///"')
[02:25] <jdub> james_w: recent versions, yeah
[02:25] <lifeless> jdub: ah, shared repo ?
[02:26] <jdub> lifeless: yeah :|
[02:26] <lifeless> jdub: there is a bug, Peng will know more
[02:26] <james_w> that's neat
[02:26] <lifeless> basically it needs to make the chroot in the backend higher up.
[02:26] <lifeless> so I know what needs to be done, I haven't gone and looked at it
[02:26] <lifeless> jdub: look for Chroot in the loggerhead code, you can probably figure it out
[02:27] <lifeless> jdub: rather than branch.base, it will be branch.repository.bzrdir.root_transport, for the chroot root path
[02:28] <jdub> lifeless: looks like that might be a bzrlib thing
[02:28] <lifeless> jdub: nope
[02:28] <lifeless> smart server handles this fine ;)
[02:28] <jdub> there's no Chroot in loggerhead
[02:28] <lifeless> ugh
[02:28] <lifeless> look for smart then
[02:29] <jdub> can i /msg for a moment?
[02:30] <lifeless> of course
[02:30] <spiv>             wsgi_app = wsgi.SmartWSGIApp(self.transport)
[02:31] <spiv> that's in loggerhead/apps/transport.py, line 85
[02:31] <lifeless> so self.transport needs to be adjusted
[02:31] <lifeless> you'll need to find the actual root you want
[02:31] <lifeless> and probably need to pass in some adjuster - spiv knwos this much better than I :)
[02:32] <spiv> which in turn gets transport from make_app_for_config_and_path, which gets it from the config
[02:33] <spiv> Which apparently defaults to '.', unless you pass a command line arg?
[02:34] <spiv> I don't really know my way around the loggerhead codebase very well.
[02:34] <jdub> yeah
[02:34] <lifeless> spiv: yes, but you know the wsgi helpers in bzrlib
[02:34] <lifeless> spiv: you see the problem, right?
[02:36] <RenatoSilva> lifeless: pull --preview didn't work
[02:36] <spiv> lifeless: not really, it's calling the right wsgi helper, I would expect that so long as it feeds the right path to it is all good.
[02:38] <RenatoSilva> lifeless: iirc someone here noted that pull doesn't have --preview as expected
[02:38] <spiv> lifeless: but I don't know enough about how self.transport is created to know where loggerhead is going wrong
[02:39] <spiv> or where jdub's configuration of loggerhead is going wrong, perhaps?
[02:39] <jdub> spiv: i'm just passing it a path (to the repo)
[02:39] <jdub> spiv: then attempting to co the branch under it
[02:40] <jdub> loggerhead autoserves branches under a repo
[02:41] <lifeless> spiv: its the transport of the branch, not the repo
[02:41] <spiv> lifeless: oh, right, yes, I got that bit :)
[02:42] <lifeless> spiv: it needs to be shifted up to the repo; but requests at that path need to be shifted down to the branches relative path
[02:42] <spiv> lifeless: I don't know why; the code I've read suggests it shouldn't be
[02:42] <spiv> lifeless: i.e. the code I've seen so far looks like it is doing things correctly
[02:43] <lifeless> spiv: if you're not bogged down with critical stuff, I think this is actually well worth treating as high and digging into
[02:43] <jdub> spiv: 0.17 or beyond?
[02:43] <spiv> Hmm, the UserBranchesFromTransportRoot looks a bit suspicious
[02:43] <spiv> jdub: I'm reading the code in trunk
[02:43] <spiv> Not sure how that relates to version numbers ;)
[02:44] <spiv> lifeless: I'm certainly happy to dig for a while
[02:44] <spiv> lifeless: I just posted a patch for that "second push failed to complete" bug
[02:44] <jdub> thanks dudes :-)
[02:44] <lifeless> spiv: awesome; I saw it, but got distracted just as I hit the diff
[02:44] <lifeless> Lynne has the lurgy now too
[02:45] <spiv> Urgh, lucky Lynne :(
[02:46] <spiv> mary and I think we've been fighting off something this week, so far not so bad but not quite feeling 100% either.
[03:02] <spiv> Ah, found it I think.
[03:02] <lifeless> spiv: vitamin C!
[03:08] <thumper> can anyone with windows experience comment on https://bugs.launchpad.net/bugs/455636 to say where to put the ssh key that bzr will use?
[03:11] <lifeless> thumper: there isn't a place AIUI
[03:12] <lifeless> thumper: you run a gui - pageant - and tell it to add the key
[03:12] <thumper> lifeless: hmm, that's about as much as I know too
[03:12] <SamB_XP> that really ought to be in the help file :-(
[03:34]  * igc lunch
[03:39] <SpamapS> Hi.. in perforce if I see a change #, I can say 'p4 describe ######' and it shows me al the changes associated with that.. does bzr have something similar? Right now I have to find the previous revision and use bzr diff..
[03:39] <spiv> jdub, lifeless: so I have a fix for your bug, but now I'm hitting https://bugs.edge.launchpad.net/bzr/+bug/348308
[03:39] <jdub> spiv: boh!
[03:40] <spiv> jdub, lifeless: will keep poking after lunch, that bug was going to bubble to the top of my list sooner or later
[03:41] <fullermd> SpamapS: You don't have to find the previous revision, you can use '-c'.
[03:41] <SpamapS> fullermd: ahh thats what I get for only paying attention to the examples and not reading the whole manual. ;)
[03:42] <fullermd> SpamapS: (and technically you don't need it with -r either, -c is just less typing  ;)
[03:43] <fullermd> SpamapS: "bzr diff -c$REV" == "bzr diff -rbefore:$REV..$REV"
[03:51] <lifeless> spiv: sweet
[03:51] <lifeless> spiv: that is the bug isn't it :)
[04:04] <mwhudson> oh _that_ bug!
[04:05] <SpamapS> fullermd: thank you.. :)
[04:20] <fullets> I've been using a workflow like: bzr init-repo repo; bzr branch svn-trunk bzr-trunk; bzr branch bzr-trunk bzr-feature; hack on bzr feature; cd bzr-trunk; bzr merge ../bzr-feature; bzr push
[04:20] <fullets> Trying to bzr diff -c a merge commit from a branch outside that repository causes bzr to crash. Are there any workarounds for this?
[04:21] <dash> huh. what version of bzr?
[04:21] <fullets> 2.0.1 from the jaunty ppa
[04:21] <dash> huh, dang.
[04:22] <dash> I've never seen that happen
[04:22] <lifeless> what crash
[04:22] <fullets> bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository(path) has no revision
[04:24] <lifeless> interesting
[04:24] <lifeless> can you try -r before:X..X PATH/TO/BRANCH
[04:24] <lifeless> as in 'bzr diff -r before .....
[04:25] <fullets> Sorry, what should the X's be? The revision number of the merge commit?
[04:25] <fullets> If so, the same crash happens
[04:26] <lifeless> fullets: yes, exactly.
[04:26] <fullets> Also -r m..n that cross the merge commit give the same crash
[04:26] <lifeless> fullets: if you cd to that branhc
[04:26] <lifeless> and then run the command, does it work?
[04:27] <fullets> It crashes whether the branch, repo, or the repo's parent dir are my cwd
[04:29] <lifeless> does 'bzr log' work when the branch is your cwd
[04:31] <fullets> Yes, both displaying the whole log and the log for the merge commit work. Trying to show the merged revisions with --include-merges shows none of the merges
[04:33] <lifeless> log -n0 will do that
[04:33] <lifeless> I think you should file a bug
[04:33] <lifeless> if log works but diff -c doesn't, there is something very strange going on.
[04:35] <fullets> I shall file a bug once I finish putting steps to reproduce together :)
[04:42] <lifeless> fullets: please file the bug earlier
[04:42] <lifeless> fullets: as you may need our help to diagnose it, and bugs provide a place to track the conversation
[04:42] <fullets> Very good
[04:53] <thumper> how do I create a branch with the LCA of two other branches?
[04:54] <lifeless> thumper: cd two; bzr revision-info -r ancestor:one
[04:54] <lifeless> then bzr branch -r revid:.... one
[04:55] <fullets> lifeless: https://bugs.launchpad.net/bzr/+bug/456908
[04:55] <lifeless> thanks
[04:55] <lifeless> bug 456908
[04:55] <thumper> lifeless: ta
[06:17] <spiv> jdub: http://bzr.pastebin.com/m5e6d6205
[06:18] <spiv> jdub: there's a couple of minor debug droppings in that (the print statement and the commented out pdb line), but that makes serve-branches work for me with a shared repo
[06:18] <spiv> jdub: I'm working on a proper fix for the bzr bug that works around
[06:20] <jdub> spiv: rocking -- thanks! :-)
[06:20] <lifeless> spiv: nice
[06:21] <jdub> spiv: beautiful :-)
[06:22] <jdub> spiv: what are the chances that will work with --allow-write? :-)
[06:24] <spiv> jdub: I don't see why it wouldn't :)
[06:28] <spiv> thumper: btw, https://answers.edge.launchpad.net/bzr/+questions?field.search_text=ssh+windows&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status=ANSWERED&field.status=SOLVED&field.status-empty-marker=1 has some info about ssh and windows if you're prepared to dig a bit
[06:33] <jdub> spiv: it does, btw :-)
[06:37] <Peng_> spiv: You rock! Thanks for working on this! :)
[06:40] <lifeless> james_w: is there a PPA with bzr builder in it?
[07:16] <Peng_> mwhudson: ping
[07:37] <bialix> hello all
[07:37] <Peng_> Hi. :)
[07:47] <spiv> Ah good, I have what seems to be a working fix for the bzr+http bug and a draft of a reasonable test.
[07:48]  * spiv heads to yoga class feeling satisfied
[07:48] <Peng_> spiv: I love you. :)
[08:46] <Kamping_Kaiser> sigh. dependancy hell for the win.
[09:39]  * igc dinner
[09:49] <alex_morelli> hello all
[09:50] <alex_morelli> long time ago, I found a plugin for bzr that implemented a "make-log" command a la tla
[09:51] <alex_morelli> Now I can't find it anymore... anyone ever heard of it?
[09:57] <bob2> what did make-log do?
[10:00] <alex_morelli> It created a log file, to which you appended what you were doing until commit
[10:00] <alex_morelli> and you couldn't commit without that log file
[10:01] <bob2> what does it do different to 'touch x ; edit x ; bzr ci -F x'
[10:02] <alex_morelli> not much, but you can commit anyway this way
[10:07] <alex_morelli> and make-log sort of forced you to behave
[10:14] <Kamping_Kaiser> Is `bzr svn-import` supposed to work from a client checkout of an svn repo?
[10:15] <Peng_> Kamping_Kaiser: Not sure. It's not hard to get the URL, though.
[10:15] <Kamping_Kaiser> I gen an error "bzr: ERROR: No Repository found at gns/builder-clean. For individual branches, use 'bzr branch'." when trying to run it against an svn checkout (I don't hae access to the svn repo)
[10:15] <Kamping_Kaiser> Peng_: ah, i'm supposed to run it on the url?
[10:16]  * Kamping_Kaiser tries
[10:18] <Kamping_Kaiser> aaah. *yay*
[10:18] <Kamping_Kaiser> Peng_: thanks :)
[10:19] <Peng_> Kamping_Kaiser: :)
[10:19] <Peng_> Kamping_Kaiser: FYI, if you *did* have a copy of the repo locally, you could run it against the directory path too.
[10:19] <Peng_> Probably.
[10:22] <Kamping_Kaiser> good to know, thanks.
[10:28] <james_w> lifeless: https://edge.launchpad.net/~dailydebs-team/+archive/bzr-builder
[10:32] <Kamping_Kaiser> perhaps a strange question: having vampired out of the svn repo, i have a 34mb .bzr directory, and the builder/ directory is empty. is there a non-obvious step involved in making the repository useful?
[10:33] <Peng_> Kamping_Kaiser: svn-import doesn't create working trees by default. cd to a branch and run "bzr checkout".
[10:33] <Kamping_Kaiser> ah.
[10:34] <Kamping_Kaiser> Peng_: would it be worth noting that somehow on the help (bzr help svn-import)? (sorry if it is, in newer versions)
[10:34] <Peng_> Kamping_Kaiser: I'm running the bzr-svn trunk, and it does mention it.
[10:34] <Kamping_Kaiser> Peng_: no worries then. thanks for checking!
[10:42] <Kamping_Kaiser> caw. its there
[10:42] <Kamping_Kaiser> thanks so much\o/
[10:43] <Peng_> jam: StaticTuple.as_tuple() doesn't recursively convert other StaticTuples inside the StaticTuple to tuples. Do you think it should?
[10:43] <Peng_> jam: In other words, is that a bug or a feature? :)
[11:38] <Peng_> beuno: ping
[12:10] <bialix> шпсЖ зштп
[12:10] <bialix> igc: ping
[12:10] <igc> hi bialix
[12:11] <bialix> I want to convert cvs repo of FTE to bzr
[12:11] <bialix> I've managed to rsync entire repo from sf.net
[12:11] <bialix> can you point me where to start?
[12:11] <bialix> should I use instructions from here: http://cvs2svn.tigris.org/cvs2bzr.html
[12:12] <igc> bialix: start with http://doc.bazaar-vcs.org/migration/en/data-migration/index.html
[12:12] <bialix> or your plugin has inside something else?
[12:13] <igc> bialix: if the instructions aren't clear, we need to improve them
[12:13] <bialix> ok, I'll read
[12:13] <bialix> will ask questions tomorrow
[12:13] <igc> bialix: fast-export-from-cvs calls cvs2bzr to do the export
[12:13] <bialix> aha
[12:14] <bialix> cvs2bzr page mentions some options.file
[12:15] <igc> bialix: hopefully you don't need a custom options file. If you do, I think fast-export-from-cvs allows you to provide one
[12:16] <bialix> igc: I have installed TortoiseCVS
[12:17] <bialix> I hope it will be enough to use cvs2svn
[12:17] <bialix> as I know it can work with RCS co utility or cvs executable
[12:17] <bialix> do you control this aspect somehow?
[12:18] <bialix> igc: ok, help for fast-export-from-cvs is clear, I'll start experimenting and will report all issues I'll encounter
[12:19] <igc> bialix: thanks. we need to get the process *clearly* documented
[12:19] <spiv> Peng_: test added, patch up for review
[12:20] <spiv> Peng_: feel free to sneak it into your deployment right now and get rid of your monkey patch ;)
[12:20] <bialix> igc: my mileage as typical windows/tortoisecvs user will vary
[12:21] <spiv> Peng_: Btw I discovered that doing that fix was exactly as painful and confusing as I thought it would be, so I feel less bad about not doing it sooner now :P
[12:21] <bialix> igc: and btw, I found gnuwin32.sf.net project is better than unxutils.sf.net
[12:22] <spiv> Peng_: (even though the eventual patch is actually quite clear I think, but fully analysing this stuff is always makes me go a bit cross-eyed)
[12:24] <bialix> igc: unxutils.sf.net is no more maintained and I'm unable to download sort there
[12:27] <Peng_> spiv: Heh, that makes me feel better about not trying to figure it out myself.
[12:33] <Peng_> spiv: I just confirmed that your fix works. I love you! :)
[12:46] <spiv> Peng_: great, thanks for testing :)
[12:51] <spiv> Peng_: yeah, it's not so much that it's hard exactly.  Just that there are just enough confusingly similar variables involved that it's hard to keep track of what's going on.
[12:52] <Peng_> spiv: Not to rush you, but you're working on a fix for Loggerhead too, right? What's the status of that?
[12:52] <spiv> All the various path the user sees/path the http request is delivered to/path in the hpss request/path adjusted relative to server backing transport/path relative to request handler etc
[12:53] <spiv> Oh yeah, good point.
[12:53] <spiv> I've even tested that it works (with my fix for bzrlib)
[12:53] <spiv> So I'll file that merge directive now
[13:00] <spiv> Peng_: https://code.edge.launchpad.net/~spiv/loggerhead/shared-repo-fix/+merge/13701
[13:02] <Peng_> spiv: Great. :)
[13:03] <Peng_> This is missing the point, but testing with "bzr revno" is clever. I always use "bzr log -r -1 -n 1", which takes a while
[13:04] <spiv> Peng_: :)
[13:04] <spiv> Peng_: a while to type if nothing else!
[13:04] <Peng_> Yeah, that too.
[13:10] <igc> night all
[13:11] <spiv> g'night
[13:19] <beuno> Peng_, hi
[13:24] <Peng_> beuno: I just wanted to say that lp:~beuno/loggerhead/yui3-0-0 is redundant. I pushed a similar branch to lp:~mnordhoff/loggerhead/yui-3.0.0 and lp:~loggerhead-team/loggerhead/yui-3.0.0, which also handles a couple of renamed files better.
[13:26] <beuno> Peng_, did you get it working?
[13:31] <Peng_> beuno: No. I didn't do anything more than update the copy of YUI.
[13:33] <beuno> Peng_, gotcha. I will see if I can spend an afternoon fixing it. I have some idea of what needs to be tweaked
[13:34] <Peng_> Oh, good. :)
[13:35] <beuno> Peng_, did you get the LP tshirt?
[13:36] <Peng_> beuno: Not yet.
[13:37] <beuno> mrevell-lunch, do you know anything  ^
[13:37]  * beuno has delegated the problem to a smarter person
[13:40] <nil1> Hi!
[13:41] <nil1> Is bzr able to handle concurrent commits on a "dumb" server (like FTP)?
[13:41] <beuno> nil1, yes
[13:41] <nil1> thanks!
[13:42] <Peng_> There are very brief windows where the repo will be write-locked, though, no?
[13:42] <nil1> Does it require a reliable locking mechanism?
[13:43] <nil1> (locking in the sense of a .lock file being written)
[13:43] <Peng_> nil1: Yes. Bazaar implements said reliable locking mechanism itself. It works fine over FTP.
[13:43] <beuno> yes, it locks the repo for brief moments
[13:43] <beuno> I guess that would limit how concurrent it can be
[13:44] <nil1> I use the FTP interface of the Tahoe storage grid, where the latency is probably higher than on a normal FTP server
[13:47] <nil1> I'll ask them if writes are reasonably atomic
[13:47] <nil1> (them = Tahoe devs)
[13:47] <beuno> nil1, let is know  :)
[13:47] <nil1> will do!
[13:52] <Peng_> Using StaticTuple in Loggerhead is fun. There are currently fewer tuples than lists in memory. :D
[13:55] <beuno> Peng_, did it have an impact in memory usage?
[13:57] <Peng_> beuno: It's way too dynamic to be sure.
[13:59] <mrevell> Peng_ Your t-shirt'll be in the post today.
[14:00] <Peng_> mrevell: Yay!
[14:02] <beuno> thanks mrevell
[14:08] <mrevell> Peng_ I've just been told that it has now been sent.
[14:10] <beuno> Peng_, spiv's branch looks good to land now, want to merge it yourself or want me to?
[14:12] <Peng_> beuno: You can if you want to.
[14:12] <Peng_> mrevell: Thanks! :)
[14:12] <Peng_> beuno: But I don't mind doing it.
[14:12] <spiv> Peng_: woo
[14:12]  * spiv -> zzz
[14:13] <beuno> spiv, thanks
[14:13] <beuno> Peng_, go for it
[14:13] <Peng_> beuno: 'kay
[14:17] <Peng_> Pushing now
[14:19] <beuno> woo!
[14:22] <Peng_> (Pushed again, cuz I forgot to mention bug #348308 in NEWS.)
[14:22] <Peng_> I can never merge something in just one revision. :P
[14:24] <beuno> heh
[14:33] <Peng_> jam: ping
[14:36] <pickscrape> Could someone explain to me what the --incremental option of bzr svn-import does?
[14:39] <Peng_> pickscrape: "bzr svn-import --incremental" is to "bzr svn-import" as "bzr pull" is to "bzr branch".
[14:40] <pickscrape> Peng_: Ah, so if I have an import that I have to kill due to it using 13G of ram, using that option will allow it to carry on from where it left off?
[14:41] <Peng_> pickscrape: ...Probably.
[14:41] <pickscrape> Peng_: thanks, I'll try that the next time I have to kill it
[14:42] <Peng_> pickscrape: I'm not sure how much of the import will have been saved if you kill it, but it probably will include most of the repo.
[15:00] <jam> morning all
[15:00] <jam> spiv: thanks for the reviews, sleep well
[15:00] <jam> Peng_: wave
[15:01] <jam> jelmer: it looks like we need an updated bzr-rewrite as wel
[15:04] <Peng_> jam: First of all, I'm sorry about pestering you to keep adding features to StaticTuple. Thanks to all of your work, I finally got the Loggerhead branch working. :)
[15:05] <jam> Peng_: good to hear. Did you see my recent patch to support more object types?
[15:05] <jam> That should land in bzr.dev today
[15:05] <Peng_> jam: Yeah, I'm using it.
[15:05] <jam> it will change slightly, but not dramatically
[15:05] <Peng_> jam: Anyway, on to the continued pestering: The only other things I could want are these, but they're not necessary: Pickle support, and the ability to pass a generator to from_sequence.
[15:06] <Peng_> jam: What do you think? Like I said, they're not necessary, but they would be nice.
[15:07] <jam> Peng_: from_sequence(tuple(generator)) should work fine :)
[15:07] <jam> and essentially give the same results
[15:07] <jam> I have to iterate the generator because ST is a fixed-width object
[15:07] <Peng_> jam: OK.
[15:07] <jam> given that, from_sequence(list(generator)) might be better
[15:07] <jam> I'm not clear on the tuple internals wrt a generator
[15:08] <Peng_> from_sequence(list(generator)) might be better than from_sequence(tuple(generator))? Why?
[15:08] <jam> Peng_: because tuple() is also fixed width, so it has to somehow stage the whole generator result somewhere
[15:08] <jam> and then create a tuple
[15:08] <jam> *list* can grow
[15:09] <jam> so it can stage the contents into itself
[15:09] <Peng_> jam: Ahh, interesting. ...It probably doesn't matter much, though.
[15:09] <jam> Peng_: looking at the internals of PySequence_Tuple() it re-allocates the internal tuple
[15:10] <jam> holding a size of 10, and then reallocating over and over as it grows
[15:10] <jam> so I guess ~ the same as List does
[15:10] <jam> Pickle support... I really don't know what it takes to tell pickle about a custom type
[15:11] <Peng_> I think these tuples are only like 1 or 2 items long, so it shouldn't matter much.
[15:12] <jam> http://docs.python.org/library/pickle.html#pickling-and-unpickling-extension-types
[15:12] <Peng_> Oh, I hadn't scrolled down that far in the docs.
[15:13] <Peng_> jam: BTW, your merge proposal got the LP equivalent of bb:tweak, more or less. Have you seen it yet?
[15:13] <jam> Peng_: yeah, I'm cleaning it up now
[15:13] <Peng_> jam: ok :)
[15:19] <jam> Peng_: so if pickling is important to you, I'm happy to look over a patch, give suggestions, etc. I'm probably not going to worry about it myself, though.
[15:19] <jam> In general, I think it wouldn't be too hard
[15:19] <jam> you just have to implement __reduce__() and __setstate__()
[15:20] <jam> except __setstate__() sounds like it happens *after* the class has been instantiated
[15:20] <Peng_> Step 1: Learn C. :P
[15:20] <jam> Peng_: if you wrote it sufficiently in Python, translating it to C wouldn't be hard (for someone)
[15:21] <jam> you could try doing it on the pure python StaticTuple type to start with
[15:21] <jam> or if it 'just gets' it from 'tuple', check what to do there
[15:22] <jam> they also mention that you can do this 'after-the-fact' by registering with the 'copy_reg' module
[15:23] <jam> http://docs.python.org/library/copy_reg.html#module-copy_reg
[15:23] <jam> that may work better, as it can
[15:23] <jam> 1) probably be done in pure python
[15:24] <jam> 2) you can be more sure that you don't have to construct an object and then call __setstate__ on it
[15:24] <jam> hmm.. maybe no nee
[15:24] <jam> need
[15:24] <jam> given the callable you pass takes a tuple of arguments for the callable
[15:25] <Peng_> I just tested a copy_reg one-liner. It whined about __builtin__.StaticTuple not existing.
[15:26] <jam> Peng_: did you have _static_tuple_c imported before you did the unpickle?
[15:28] <Peng_> jam: I had "from bzrlib.static_tuple import StaticTuple".
[15:29] <jam> so potentially that is the pure python class, though not if everything is working correctly
[15:29] <Peng_> jam: It's the C version.
[15:29] <Peng_> I note that the C StaticTuple has no __module__ attribute.
[15:32] <jam> interesting, given that 'tuple' itself does
[15:35] <jam> Peng_: actually *instances* of tuple do not have the __module__ attribute, but t.__class__.__module__ does
[15:35] <jam> and
[15:35] <jam> >>> _static_tuple_c.StaticTuple.__module__
[15:35] <jam> '__builtin__'
[15:35] <jam> I don't specifically know how to change that
[15:35] <jam> as I don't see where it is set
[15:40] <jam> it seems to be in 'typeobject.c' a function called type_module()
[15:40] <jam> and it looks like if you set "tp_name" to "bzrlib._static_tuple_c.StaticTuple" then it will get a module
[15:41] <jam> otherwise it defaults to __builtins__
[15:42] <jam> Peng_: give this a shot: http://paste.ubuntu.com/298325/
[15:44] <Peng_> Are you supposed to hardcode the module like that? Obviously, it isn't necessary when writing Python code.
[15:45] <jam> Peng_: that seems to be why Type.__module__ expects
[15:46] <jam> we aren't creating a heap type, so we can't just set "Type.__module__" directly
[15:46] <jam> and if it isn't a heap type, it checks 		s = strrchr(type->tp_name, '.');
[15:46] <jam> and if not found returns __builtin__
[15:46] <jam> so I think so
[15:50] <Peng_> jam: This fixes it, but you'll have to adjust __repr__, as it now includes the module too.
[15:51] <Peng_> jam: Or, don't adjust repr, but adjust any tests where it's still hardcoded (if there are any).
[15:52] <jam> well, seeing the full format in print '%r' also isn't very nice
[15:52] <jam> and I think we have the flag set so you can't subclass StaticTuple
[15:52] <jam> so it is safe to just hard-code it there
[15:53] <Peng_> jam: With that patch, pickling works with this one-liner: copy_reg.pickle(StaticTuple, lambda st: (StaticTuple, st.as_tuple()))
[15:53] <Peng_> jam: Although it will probably die horribly if you enable or disable the C extensions in between pickling and unpickling.
[15:54] <jam> Peng_: it won't work because the module is hard-coded in the pickle stream
[15:55] <jam> now if we wanted to be 'evil'
[15:55] <jam> we would make the module name "bzrlib.static_tuple"
[15:55] <jam> and then set
[15:55] <jam> bzrlib._static_tuple_py.StaticTuple.__module__ == 'bzrlib.static_tuple'
[15:55] <jam> at that point
[15:55] <jam> I think you could switch between them
[15:55] <jam> i'm not positive
[15:56] <Peng_> Probably.
[15:56] <jam> but I think the unpickler just tries to grab a class at the given path
[15:56] <jam> and passes it the args
[15:57] <Peng_> IMO doing that is nice, but unacceptably evil.
[16:00] <Peng_> Boy. I'm running bzr.dev with 2 unmerged branches + a patch. Fun!
[16:28] <Peng_> jam: So... what do you want to do? About tp_name, and about __reduce__? I could probably do it all, but it would take me a while, since I've written about 4 lines of C, none of them involving Python's C API.
[16:34] <jam> Peng_: I can probably put it on my "get to it eventually" list, as the actual amount of work is pretty small
[16:34] <jam> did you try the 'nice but evil' hack and see if it worked?
[16:39] <Peng_> jam: What, to make switching between C and Python work? No.
[16:41] <Peng_> jam: Are you going to land the tp_name patch? I'm going to work on pickling -- though I might give up -- so I can make it a part of that. But I don't know what, if anything, to do about repr.
[16:42] <jam> Peng_: just change the part that formats to hard-coding it
[16:42] <jam> I would land them all together
[16:42] <Peng_> jam: Alright.
[16:46] <jam> static tuple type support is in pqm now
[16:47] <jam> Peng_: what other unmerged branch are you running?
[16:49] <Peng_> jam: lp:~spiv/bzr/bzr-http-jailbreak-bug-348308
[16:50] <Peng_> Uh-oh. Applying the tp_name patch to another branch, it doesn't work. :\
[16:52] <Peng_> And no, I'm not making some mistake like importing the wrong file.
[17:08] <awilkins> Thought of the day : a fast-import frontend you can use for benchmarking
[17:08] <awilkins> ie - it replays revisions by making changes to the filesystem and driving the porcelain of your chosen VCS
[17:09] <awilkins> So you could take a git-fast-export of say.. the kernel tree... and pipe it through this thing to see how various things performed on real-world data
[17:21] <jfroy> verterok: ping
[17:21] <verterok> jfroy: pong
[17:21] <verterok> jfroy: hi
[17:22] <verterok> jfroy: I wasn't able to get a spare minute and reboot into OS X, so no push yet :(
[17:24] <jfroy> alright, just ping me when you do
[17:35] <verterok> jfroy: sure, let me try to get the changes from the HFS+ disk ;)
[17:44] <verterok> jfroy: pushed revno 13 to lp:~verterok/+junk/OSX-package
[17:44] <verterok> jfroy: I remove the -desktop pmdoc, as it was quite outdated
[17:44] <verterok> *removed
[18:08] <jfroy> verterok: so what's the process for the desktop installer?
[18:09] <verterok> jfroy: there isn't a desktop installer :)
[18:09] <verterok> jfroy: I just builded a PyQt.pkg and included it in the DMG
[18:09] <verterok> jfroy: as I'm still using my old script to build the 10.5 installer
[18:10] <verterok> jfroy: basically, I think we need a new pmdoc (-desktop) for 10.6
[18:11] <jfroy|work> I see
[18:12] <jfroy|work> well that should be easy enough
[18:12] <jfroy|work> I don't see a switch to have fetch-external grab PyQt and Sip, am I missing something?
[18:13] <Tak> yay, subvertpy crash fixed!
[18:14] <verterok> jfroy: it should fetch all the deps
[18:15] <jfroy|work> Ah, so it did
[18:17] <jfroy|work> hum
[18:18] <jfroy|work> why did you modify the config for sip and pyqt that much?
[18:23] <jfroy|work> ah I see, the default paths are bogus
[18:24] <verterok> jfroy: yeap
[18:27] <jfroy|work> anyways, it needs to be done that way too because there's no prefix or root option
[18:27] <jfroy|work> was the -q option necessary for pyqt?
[18:28] <jfroy|work> it should find the default just fine I would think
[18:29] <jfroy|work> oh, did you include Qt in your dmg?
[18:34] <verterok> jfroy: no, QT  needs to be installed
[18:34] <verterok> jfroy|work: ^
[18:35] <verterok> jfroy|work: I'm still trying to build a standalone bundle with qt and pyqt
[18:39] <Peng_> jam: I just sent a merge request for pickling. Peng_ wrote C, ha! (Well, Peng_ copy-and-pasted C.)
[18:41] <jam> Peng_: \o/ for you
[18:43] <jam> Peng_: https://code.launchpad.net/~mnordhoff/bzr/statictuple-pickling/+merge/13720 doesn't have anything with pickling
[18:43] <jam> it only has the repr and tp_name changes
[18:44] <Peng_> jam: I know. Launchpad's mirror is out-of-date; see my message.
[18:44] <Peng_> I didn't want to wait another 4 hours to submit the proposal, or figure out how to trigger a mirror again.
[18:44] <Peng_> Sorry for making it confusing.
[18:46] <abli> Hi! If I do a bzr merge of certain revisions (i.e. with from_rev..to_rev) why doesn't it get noted that I have pending merges when I do a "bzr st"? And why dont the merged versions's comments get added when I check in the merge? Any ideas?
[18:47] <abli> (using bzr 1.16.1)
[18:47] <dash> abli: that's a cherry-pick and bzr doesn't treat it like a 'normal' merge
[18:47] <dash> it just applies the changes and doesn't track history
[18:48] <jam> Peng_: you could have always hosted the branch... :)
[18:48] <abli> and is there some way  to make bzr treat it like a normal merge? To get the merged comments in the checkin comment?
[18:48] <jam> Peng_: reviewed. I think you need one more Py_INCREF but otherwise it looks good.
[18:48] <jam> abli: use "bzr merge -r to_rev"
[18:49] <jam> and if you really need to
[18:49] <abli> For example, bzr will know that those revisions were merged, right? I.e. won't show them when I run "bzr missing" later?
[18:49] <jam> bzr merge --force -r from_rev..ancestor:../other
[18:49] <jam> abli: it will show them as missing
[18:49] <jam> as said earlier, we don't track the history of cherrypicks
[18:49] <Peng_> jam: How's that fun? If I had originally pushed to LP, it would have been very quick, instead of 8 minutes of streaming data to the out-of-date repo on my server. :D
[18:50] <dash> abli: what's your situation?
[18:50] <abli> Btw why isn't cherry-picking treated like a normal merge? (I.e. why is the workaround you guys mentioned needed?)
[18:51] <jam> Peng_: well at least your server is up to date now :)
[18:52] <abli> trying to merge "half" of a branch to trunk. I.e. I have a branch with commits that implement  two features, and I want to merge those belonging to one of the features to trunk
[18:56] <abli> jam: how should I read that from_rev..ancestor:../other part? I assume I am to run "bzr merge" from the branch I am merging to, right? So running "bzr merge -r from_rev..to_rev other_branch" is a normal cherry-picking, right? so how do I run this non-cherry-pick-but-only-some-revisions merge? Or is it even possible?
[18:57] <Peng_> jam: Thanks for the review. :)
[18:58] <Peng_> Writing (a little bit of) C is kind of fun. Python is so easy that it's boring. :P
[19:02] <jam> abli: we don't have a way to internally represent "i'm merging some of the ancestry but not all of it"
[19:02] <jam> so there are some options
[19:02] <jam> but they all 'break' for some use cases
[19:03] <jam> abli: for example you can do
[19:03] <jam> bzr merge ../other -r from_rev
[19:03] <jam> bzr revert .
[19:04] <jam> bzr commit -m "Explicitly remove the initial changes"
[19:04] <jam> bzr merge ../other -r ../to_rev
[19:04] <jam> however, in that case the initial changes 'won't' land
[19:04] <jam> though you can then do the reverse sync
[19:04] <jam> with cd ../other
[19:04] <jam> bzr merge ../trunk
[19:04] <jam> bzr revert .
[19:04] <jam> bzr commit -m "Revert the removal from trunk"
[19:04] <jam> or something along those lines
[19:05] <jam> caveat that merging trunk probably does more than just bring in the feature you just did
[19:06] <jam> abli: alternatively, you can look at something like: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
[19:06] <jam> for how to take a branch that has multiple features developed on it
[19:06] <abli> and then merge to to_rev, and commit, right? But that will show the revisions up to from_rev as merged, won't it? I will want to merge those at some later point
[19:06] <jam> and split it into independent branches
[19:19] <abli> Ok, thanks, I'll try out that refactoring thing.
[20:57] <emmajane> igc, pong (belated)
[20:58] <igc> hi emmajane, how are you?
[20:58] <beuno> mwhudson, Peng_, I think I have LH working with 3.0.0
[20:58] <emmajane> igc, hey :)
[20:59] <beuno> just need to iron out a few errors with the search js
[21:00] <mwhudson> beuno: cool
[21:10] <thumper> beuno: 3.0.0 what?
[21:13] <lifeless> moin
[21:13] <lifeless> YUI I imagine
[21:16] <igc> hi lifeless, thumper
[21:23] <beuno> thumper, lifeless, yes
[21:23] <beuno> I'm pretending this is research for the lazr-js sprint in dallas
[21:26] <lifeless> beuno: 'it is'
[21:29] <jml> I've recently been motivated to care about this bug: https://bugs.launchpad.net/bzr/+bug/152008
[21:35] <jml> lifeless, you now have commit rights to testtools.
[21:36] <lifeless> cool
[21:36] <lifeless> [what prompted this?]
[21:36] <jml> I'm yak shaving :)
[21:37] <jml> I want to release txsshserver
[21:37] <jml> to do this, I need to make sure the tests pass
[21:37] <jml> right now, running the tests in trial makes them all skip
[21:37] <jml> I have NFI why that's the case, but suspect a bug in testtools (or maybe in trial)
[21:37] <lifeless> awesome
[21:38] <jml> you've been keeping up to date with python test development much more than I, so I feel that you are in a much better position to get stuff landed.
[21:38] <jml> and I feel I'll be less of a blocker if I don't have sole commit rights.
[21:39] <lifeless> what was your previous 'policy' about reviews of committer's code
[21:39] <lifeless> and how do you want me to behave
[21:40] <lifeless> e.g. 2 +1s, then land, or 'if you think it is right just land', or 2 +1s with a timeout?
[21:41] <lifeless> jml: ^
[21:43] <jml> lifeless, my policy has been patches get reviewed, and I land patches without review. but I was the sole controller.
[21:43] <jml> lifeless, I just got on a call w/ thumper, will actually think about policy when I'm off :)
[21:44] <lifeless> jml: indeed, but you can see why I ask :)
[21:44] <jml> yes :)
[21:44] <lifeless> jml: if you're to be less of a blocker we need committing to be quorate without needing you
[21:45] <jml> lifeless, that's right.
[21:45] <lifeless> enjoy the call
[21:45] <jml> :)
[21:46] <jam> jelmer: ping (still need a newer bzr-rewrite for 2.1.0b1 release...)
[21:46] <jam> morning lifeless
[21:47] <lifeless> hi jam
[21:47] <igc> hi jam, jml
[21:48] <jml> igc, hi
[21:49] <igc> emmajane: my email from last week? Did I miss your reply or is it still coming?
[21:49] <emmajane> igc, email from last week?
[21:49] <emmajane> igc, on-list?
[21:49] <igc> emmajane: no, just to you
[21:49]  * emmajane checks the backlog of lsit email.
[21:49] <emmajane> oh. hrm.
[21:49] <jam> morning igc
[21:49] <emmajane> igc, can you resend?
[21:50] <igc> emmajane: it was the one about templating, etc - shall do
[21:50] <GaryvdM> Hi jam - Thanks for the bzr-beta-ppa approval.
[21:50] <emmajane> igc, thanks. I don't remember getting one to me about templating. :/
[21:51] <igc> emmajane: just re-forwarded it now - date was 12/Oct; title was "Next steps ..."
[21:51] <jam> GaryvdM: no problem
[21:51] <jam> easier than having you request a copy every month :)
[21:51] <GaryvdM> :-)
[21:52] <emmajane> igc, got it this time. I'm not sure where the other one went. :/
[21:52]  * emmajane reads
[21:52] <igc> jam, lifeless: OOo fast-imports now with latest trunk and cache of inventories cut down to 5 (was 100)
[21:53] <igc> jam, lifeless: I'm just trying qt now with a few different cache sizes to see memory and speed impact
[21:53] <emmajane> igc, Good list. I'll send a response back tonight with a plan.
[21:53] <igc> emmajane: thanks
[21:54] <emmajane> no problem! thanks for pinging me about it.
[21:54] <jam> igc: you're saying that it succeeds at importing w/ a cache of only 5?
[21:54] <jam> (and cache of what?)
[21:54]  * ToyKeeper ponders how to rebase a series of merges on top of a new upstream tarball...  bzr-rebase seems to think the source branch (with new tarball) is a descendent of the target branch (with merges), and pulls instead of rebasing.
[21:54] <jam> btw, it *might* be reasonable to handle a hunk stream by copying everything into the chk store, and then extracting it from there.
[21:55] <jam> though 'pack' won't gc those extra objects.
[21:55] <ToyKeeper> Hmm, I bet a null commit before the merges would un-confuse it.
[21:56] <himanshu__> Hi, I am getting following error :bzr: ERROR: Unknown repository format: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n'
[21:56] <himanshu__> Not sure why?
[21:57] <ToyKeeper> himanshu__: It sounds like your version of bzr is too old to read the repository.
[21:57] <himanshu__> bzr server is running on remote repository  with version 2.0.1
[21:58] <himanshu__> my client machine is ubuntu with bzr version 1.6.1
[21:58] <ToyKeeper> It's because your client is old, then.
[21:58] <himanshu__> so new bzr version is not backward compatible with any bzr version?
[21:59] <ToyKeeper> It is if you're using a backward-compatible format.  Format 2a is compatible back to bzr 1.16...
[22:00] <fullermd> (though you really would rather not use it with <2.0.0)
[22:00] <fullermd> _bzr_ is compatible; that _repo_ isn't.
[22:00] <ToyKeeper> Ah, okay.
[22:01] <ToyKeeper> himanshu__: Upgrading your client would probably be the best option, but you could also rebuilt the repo with an old format, like 1.6.1-rich-root.
[22:01] <ToyKeeper> s/rebuilt/rebuild/
[22:02] <himanshu__> so what do you suggest..Shoudl I rebuilt repo with old format  or upgrade client
[22:02] <fullermd> Upgrade the client, definitely.
[22:02] <fullermd> 2a is a better format in a lot of ways, and unrelated to that 2.0.1 will be a lot faster etc. than 1.6.1 as well.
[22:03] <himanshu__> what is the quickest way to upgrade client on ubuntu?
[22:03] <himanshu__> I have installed using apt-get install bzr
[22:03] <fullermd> Older format mirrors are for when (for whatever reason) clients _can't_ be upgraded.
[22:04] <fullermd> That probably involves PPA's, but I don't know any details about it.
[22:04] <himanshu__> ohk so I need to build it from source ?
[22:04] <ToyKeeper> Ubuntu backports may have it.
[22:04] <himanshu__> what is backports?
[22:04] <ToyKeeper> https://help.ubuntu.com/community/UbuntuBackports
[22:04] <igc> jam: fastimport caches inventories
[22:04] <himanshu__> ok cool let me check
[22:05] <himanshu__> Also, 1 more question
[22:06] <GaryvdM> himanshu__: New versions can also be found in the ppa: https://launchpad.net/~bzr/+archive/ppa/
[22:06] <himanshu__> ok cool let me check
[22:07] <lifeless> jam: inventory cache
[22:07] <lifeless> jam: fast import has a huge one
[22:08] <ToyKeeper> BTW, know of any tools to modify fast-import files?  It would be nice sometimes to remove files, revisions, and other stuff from history.
[22:09] <himanshu__> I have 1 question related to supporting bzr repositor
[22:09] <ToyKeeper> It can be done by hand, but it's a lot of work.
[22:10] <himanshu__> say if I have 10 users acess to bzr repository but I want to ensure that no user can have read/write access in other user's project
[22:10] <himanshu__> how can that be possible?
[22:10] <jam> ToyKeeper: you may want to look at 'bzr replay' versus 'bzr rebase'
[22:10] <fullermd> himanshu__: Why do you need it in one repository?  Or do you?
[22:10] <ToyKeeper> jam: Ooh, sounds promising.  Thanks.  :)
[22:11] <himanshu__> so it possible to start bzr server with each user repository?
[22:11] <jam> igc: so you might be extra interested in the patch I'm about to propose again (chk_map changes). Providing you are caching chk inventories.
[22:11] <rockstar> ToyKeeper, I'm actually rather surprised you hadn't heard about bzr replay.
[22:12] <fullermd> himanshu__: The server and 'repositories' are almost completely decoupled.  You serve a directory tree, which may have one, two, or six hundred repositories under it.
[22:12] <fullermd> himanshu__: Now, the bzr server doesn't itself do any AAA.  You'd have to do that in a high level, via the web server for bzr+http, or the ssh daemon for bzr+ssh.
[22:13] <himanshu__> what is AAA?
[22:13] <fullermd> himanshu__: I've never messed with bzr+http; I use bzr+ssh everywhere.
[22:13] <fullermd> himanshu__: Authentication, Authorization, Accounting.
[22:14] <himanshu__> ok here is what i am doing rite now: I have created 1 bzr repository  and executed following command
[22:14] <himanshu__> nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log &
[22:14] <himanshu__> nohup serve-branches /home/bzradmin/repository >> /home/bzradmin/logs/bzr_loggerhead.log &
[22:14] <himanshu__> but this way I am giving everyone read-write access
[22:14] <igc> jam: cool
[22:14] <fullermd> Right.
[22:14]  * igc breakfast - bbl
[22:15] <himanshu__> but I just want to limit it to each user group
[22:15] <himanshu__> I mean each user group should not have any read-write access of other usergroup
[22:15] <himanshu__> not even on http
[22:15] <fullermd> I'd do it all via bzr+ssh (the writing, anyway).
[22:16] <fullermd> And use FS permissions.
[22:16] <ToyKeeper> rockstar: It was a hidden command...  :(
[22:16] <rockstar> ToyKeeper, those are the ones you find first usually.
[22:16] <rockstar> :)
[22:16] <fullermd> Really, there's no way to provide meaningful security differentiation within a repository; if you can write into it, you can change anything.  So you'd need one repo per slice of the auth domain.
[22:17] <himanshu__> how do you use bzr+ssh?
[22:17] <fullermd> Oh, I just use regular system accounts.
[22:18] <fullermd> You COULD do it with a ssh daemon that uses PAM or some other auth, and refers to an external database rather than using regular system accounts.
[22:18] <fullermd> But that would be rather more complicated.
[22:19] <himanshu__> so this way each usergroup will be having their own repository?
[22:19] <ToyKeeper> I haven't checked in a while, but if bzr-access ever got developed to a usable point, it might help.
[22:19] <fullermd> bzr-access can't provide control at a sub-repository level.
[22:19] <ToyKeeper> No, it can't.
[22:20] <fullermd> Nothing can, without bzr moving a ways.
[22:20] <lifeless> if you need privacy or integrity, use separate repos
[22:20] <lifeless> thats a design statement, not a feature statement
[22:21] <fullermd> himanshu__: You may be assigning more meaning to 'repository' than bzr does.  It's not like cvs/svn, where the 'repository' is an important semantic unit.
[22:21] <lifeless> we can and will remove the VFS eventually, or at least make pushing with it disabled work [modulo plugins this is the case already]
[22:21] <lifeless> and with the VFS removed many middling hostile attacks are prevented
[22:22] <fullermd> Yah, VFS is a hole you can drive a 11-dimensional multiverse through.
[22:22] <fullermd> I didn't know we have all the core actions moved off it.  That's pretty neat.
[22:23] <himanshu__> I am getting little confure here: say I need to support 10 usergroup over same bzr server completly isolated from one another
[22:23] <lifeless> fullermd: 2.0.0. baby
[22:23] <fullermd> (well, aside from having to longcut to it to find out the !@&$ format of a remote branch...)
[22:23] <lifeless> himanshu__: then you have 10 repositories
[22:23] <lifeless> himanshu__: or more if you like :)
[22:23] <himanshu__> then I should create 10 different respository setting read-write access according to group
[22:24] <fullermd> himanshu__: Remember, your users will [practically] never be interacting with repositories; they'll be dealing with branches.  So think in terms of a directory hierarchy of branches, slicing that up how access control needs to be.
[22:24] <fullermd> Then you can see where it's worth creating repositories within that.
[22:25] <himanshu__> then each user group can access their resporitory over the bzr+ssh
[22:27] <himanshu__> I agree that users will always interact with branches but I need a way to make sure that set of branches are accesible to only 1 particular user group
[22:28] <fullermd> Yah, having those branches have all their data be 775/664 works well for that.
[22:28] <himanshu__> ok  cool
[22:29] <himanshu__> so it seems 1 repository, within that I create sub directory fo reach user group
[22:30] <fullermd> No, that's a step backward, since they all have to write into the repository.
[22:30] <fullermd> Step back and forget about [explicit] repositories; just arrange a bunch of individual standalone branches.
[22:30] <himanshu__> ok
[22:31] <fullermd> So you end up with $ROOT/team1/ and $ROOT/team2/ and $ROOT/team3/ etc. dirs, each full of branches.
[22:31] <himanshu__> ok
[22:31] <fullermd> With everything under teamX set with that group having write access, and everybody else just read (or no access, if that's what you want)
[22:31] <fullermd> So, you can run with just that, and not create any repositories.
[22:32] <fullermd> That has its shortcomings, but it's functionally equivalent.
[22:32] <himanshu__> what is the shortcoming here?
[22:32] <fullermd> Every branch has a full copy of the history, so (assuming that some/many/most/all of the branches are of the same project), you'll have a giant pile of copies of the same data.
[22:32] <fullermd> Which eats up disk space, and also means the users can end up having to push up more data to get their work done.
[22:33] <fullermd> But, ignoring space and time, everything acts just like it would with repos.
[22:33] <fullermd> Now, if we assume that most/all of these branches are of the same project, just creating a repo in each teamX/ branch means we have 10 copies of the history (one for each team), but that's not so bad probably.
[22:34] <himanshu__> i want branches of same project in teamX directory only
[22:34] <fullermd> You could have a repo for teamX/ even if all the branches in it were of different projects of course, but it wouldn't gain anything in that case (since there's no common history to store only 1 copy of)
[22:35] <fullermd> So, it sounds like you want a tree sorta like that, with a repo per teams and its perms set as appropriate.
[22:35] <himanshu__> so requirement is that if there is some projectX, then that projectX is just limited to TeamX, cannot be read/write by any other Team
[22:39] <himanshu__> thanks a lot fullermd, i got your suggestions
[22:40] <himanshu__> From my requirement, it makes sense to maintain 1 respoitory for each Team as they have nothing in common, I mean no project, no read-write access
[22:40] <fullermd> Sounds like a perfect fit then   :)
[22:41] <himanshu__> so when I start bzr server, this would be wrong choice"	
[22:41] <himanshu__> nohup bzr serve --allow-writes --directory=/home/bzradmin/repository >> /home/bzradmin/logs/bzr_serve.log &
[22:41] <himanshu__> "
[22:41] <himanshu__> so how should I start server?
[22:42] <himanshu__> assume I have multiple respository
[22:43] <himanshu__> should I give path of top level common directory maintaningg all user repos as underlying sub directory
[22:44] <fullermd> You don't 'start' the server.  The users use bzr+ssh, which ssh's in and spawns bzr itself behind the scenes.
[22:45] <fullermd> So you just have bzr installed and in $PATH, and them able to login.
[22:45] <himanshu__> ok cool
[22:45] <fullermd> Then they give whatever path they want.  Even a path to one of the other teams if they want, but since the filesystem permissions won't let them write...
[22:45] <jml> lifeless, how's this: all patches need reviews from a committer who is not the author. If the author is a committer, there is a 24hr timeout on this rule.
[22:45] <himanshu__> ok cool
[22:45] <fullermd> So they'd do something like "bzr branch bzr+ssh://me@server/bzr/team5/mainbranch mylocalbranch"
[22:46] <himanshu__> ok cool~
[22:46] <lifeless> jml: sounds fine to me
[22:46] <himanshu__> Also, is it possible if I can expose this kind of view over http using loggerhead?
[22:46] <jml> lifeless, cool.
[22:46] <jml> lifeless, let's do that then.
[22:48] <fullermd> himanshu__: Well, since you've moved the devs to bzr+ssh, you don't need writes over the web (or over a 'bzr serve' bzr:// server, if you still want to run one), so that just needs read access.
[22:48] <fullermd> If you wanted write over bzr+http, you'd have to do access control via Apache (well, or whatever other httpd you have).
[22:48] <himanshu__> ok cool
[23:22] <lamalex> is there a way to only get part of a branch?
[23:32] <beuno> mwhudson, https://code.edge.launchpad.net/~beuno/loggerhead/yui3-0-0/+merge/13744
[23:32] <beuno> in case you have a little while
[23:32] <beuno> notifying oopsed
[23:32] <beuno> so I'm doing it manually  :)
[23:32] <beuno> Peng_, ^
[23:32] <lamalex> im trying to set up bzrbuilder, but our debian package branch is in a subdir of the branch
[23:33] <lamalex> is there a way to just get the debian dir of the branch or should i just use run to do an mv
[23:33] <beuno> lamalex, there's no way to get a specific dir with bzr at the moment
[23:34] <lamalex> so i guess run mv is the way for now
[23:34] <lamalex> thanks
[23:35] <lifeless> jml: is the new team subscribed for reviews to trunk ?
[23:37] <jml> lifeless, is now.
[23:37] <lifeless> :)
[23:37] <jml> g'night.
[23:37] <lifeless> night