[02:49] <kumi> If I move (w/ filesystem tools, not w/ bzr) paths around, how do I tell bzr about the new arrangement of folders and files?
[02:49] <kumi> I had to migrate some code to a new server, which has a different directory structure... "/www/htdocs/" has become "/www/a.com/pages/" and "/www/htdocs/common/" has become "/www/c.com/pages"
[02:50] <Verterok> kumi: bzr mv --after
[02:50] <kumi> Verterok: thanks :D
[02:50] <Verterok> np :)
[03:29]  * Verterok heading to bed
[09:43] <awmcclain> Hey all.. is there any way to prevent bzr logfiles from littering my directories after each checkin?
[10:02] <jelmer> moin
[10:05] <james_w> hi jelmer
[10:05] <james_w> awmcclain: to which logfiles do you refer?
[10:06] <awmcclain> bzr_log.OxncjQ~ bzr_log.RNweuu~
[10:06] <awmcclain> Commit logs
[10:06] <jelmer> I think those are only left when bzr aborts a commit
[10:08] <james_w> awmcclain: if that is not the case then I think a bug report is appropriate
[10:08] <awmcclain> Hrm
[10:08] <awmcclain> Bug report!
[10:08] <james_w> awmcclain: what's your OS?
[10:09] <jelmer> I think this is Windows-related
[10:09] <awmcclain> 10.5, running bzr 1.2.0, using vim to edit commits.
[10:09] <awmcclain> (commit mesages)
[10:09] <james_w> they are not editor backup files are they?
[10:09] <jelmer> since it's by default impossible to delete a file unless nobody has it open
[10:09] <jelmer> actually, I think they are
[10:09] <awmcclain> So. Silly
[10:09] <james_w> that's not what vim's look like on linux, but I don't know Mac.
[10:10] <awmcclain> Yeah, you'd think the ~ would have tipped me off.
[10:10] <awmcclain> Hrm
[10:10] <awmcclain> weird though
[10:10] <jelmer> james_w: if you 'set backup' in vim, it'll write ~ files
[10:10] <awmcclain> Is there a setting to have the commit files written to /tmp?
[10:10] <james_w> ah, backup as opposed to .swp, I see.
[10:11] <james_w> perhaps we should be using $TMPDIR anyway.
[10:15] <jelmer> james_w: The current setup has the nice side-effect that if bzr crashes during commit, the log file is still there
[10:30] <lifeless> moin
[11:15] <ubotu> New bug: #197597 in bzr "branches command slow" [High,Confirmed] https://launchpad.net/bugs/197597
[12:46] <ubotu> New bug: #197618 in bzr "Document BZR_REMOTE_PATH in man page" [Undecided,New] https://launchpad.net/bugs/197618
[14:30] <abentley> Hi all.  I'm at the hotel.
[14:39] <lifeless> hi
[14:40] <lifeless> I'm at the office
[14:42] <lifeless> abentley: which hotel are you in?
[14:52] <lifeless> abentley: hi
[14:53] <abentley> Hey there.  How's things?
[14:53] <lifeless> good
[14:53] <lifeless> at the office at the moment
[14:53] <lifeless> have you eaten lunch?
[14:53] <abentley> No.
[14:53] <lifeless> Henrik Nordstrom and I are considering food
[14:53] <lifeless> which hotel are you in?
[14:53] <abentley> I'm in favour of food.
[14:53] <abentley> I'm at the Rochester.
[14:54] <lifeless> cool
[14:54] <abentley> I think all the Canonical people are at the Rochester.
[14:54] <lifeless> many are, but not al I believe
[14:55] <lifeless> I'd happily swap to the plaza - they serve prridge for breakfast :>
[14:55] <lifeless> abentley: we'll come to the hotel
[14:55] <lifeless> abentley: be about 15 minutes
[14:56] <abentley> Cool.  I'll be in the lobby.
[15:22] <seba__> hi
[15:22] <seba__> i am importing from hg to bzr using fastimport
[15:23] <seba__> i used to have a crash till last rls
[15:23] <seba__> and now i have some warning msg like that instead:
[15:23] <seba__> WARNING: ignoring delete of content/xul/document/public/nsIXULContentSink.h as not in inventory (:65)
[15:23] <seba__> what does it mean exactly ?
[15:24] <james_w> seba__: I'm guessing that fastimport is being told to delete that file, but it doesn't think that it exists to delete it.
[15:24] <seba__> that's rather strange
[15:25] <james_w> seba__: indeed.
[15:25] <seba__> i guess a delete from hg was actually made on an existing file
[15:27] <luks> it might have been done in a different order and hg-fast-export might not handle it correctly
[15:34] <seba__> bah it failed again now later...
[15:34] <seba__> I wonder if those fastimport plugin are tested on projects bigger than 5 commits and 1 branch...
[15:38] <james_w> seba__: I believe it is being developed as the developer is working on importing OO.org
[15:42] <seba__> oo chose bzr ?
[16:19] <jelmer> hey
[16:19] <jelmer> any sprint people awake?
[16:28] <james_w> jelmer: i am, but I'm not there. Are you after someone there, or just someone who is going?
[16:29] <thumper> james_w, jelmer: hi
[16:30] <james_w> hi thumper
[16:30] <thumper> anyone staying in the rochester?
[16:30] <james_w> I am, but I don't arrive until Wednesday.
[16:31] <james_w> I think lifeless and abentley are. They were here a little earlier.
[16:31] <jelmer> james_w: Just wondering who is here
[16:32] <jelmer> james_w: I just met up with the two eclipsebzr guys
[16:32] <jelmer> we're going to get some food in a few minutes
[16:32] <jelmer> thumper: All the canonical folks are in the rochester
[16:32] <jelmer> All the non-canonical folks are in the park plaza
[16:34] <thumper> jelmer: ah, is that the way it is
[16:44] <jelmer> hmm, LarstiQ either forgot to turn his phone on or is still on the plane..
[16:44] <nexus10> hi -- can anyone tell me what's the advantage of 'bzr ignore foo-pattern' over 'echo foo-pattern >> .bzrignore'?
[16:52] <Odd_Bloke> jelmer: Where did you meet the EclipseBzr guys?
[16:58] <jdong> nexus10: the former's more intuitive to find for the newcomer and the latter makes Git users happy? :D
[16:58] <jdong> nexus10: (ignore me, I'm in a grumpy flame-git mood today)
[16:58] <nexus10> jdong :-D
[16:58] <nexus10> jdong: that's what
[16:59] <nexus10> jdong: ... I was hoping you'd say -- cos I have some probs with bzr ignore
[17:00] <jdong> nexus10: Yeah, from a user interface perspective, the first place I'd look for my VCS's "ignore" function would be in the commands list
[17:00] <nexus10> jdong (and anyone else): is there a "why bzr kicks git's posterior' doc you can suggest?
[17:00] <jdong> nexus10: indeed there is one on the wiki
[17:01] <jdong> http://bazaar-vcs.org/BzrVsGit
[17:01] <nexus10> jdong: ta, I'll go hunt -- dunno how git has got such buzz in the Rails world, but I need some ammo against all that buzz
[17:01] <nexus10> jdong: fantastic, ta
[17:02] <jdong> nexus10: I think the reasons are quite compelling, and although that article prefaces itself to be bzr-biased, for the most part I think it's a quite unbiased view of reality
[17:02] <jdong> nexus10: the one thing I do give Git massive credit for is performance. Git's still noticeably faster than bzr on some tasks (bzr log on 5000 revisions), etc
[17:02] <nexus10> jdong: I don't need persuading -- but I have a git diehard to win over
[17:03] <jdong> nexus10: though frankly for the average size project I don't care if I wait another 1 second for log to show
[17:03] <jdong> the time it took me to figure out how to tell git to stop committing things without my permission, bzr could'll logged itslef a billion times
[17:03] <jdong> lol
[17:04] <jdong> nexus10: if this Diehard Git user is a part of a bigger project, cross-platformness will instantly knock him down a few pegs. Force him to live the life of a Windows user for a day, and I bet he'll reconsider his choice :)
[17:04] <nexus10> jdong: Rails projects are usually small - 2000 files or so
[17:05] <jdong> nexus10: yep, as I've noticed. I worked on a rails project last summer that was entirely versioned via bzr and all went great
[17:05] <TFKyle> jdong: bzr log doesn't seem that slow on 3184 revisions here, time bzr log > /dev/null == real 0m4.640s (hot cache though)
[17:06] <nexus10> jdong: this user was on Windows -- now on gentoo and much happier
[17:06] <jdong> TFKyle: time git log > /dev/null on the entire mirror of Subversion's repository took less than a second
[17:06] <jdong> TFKyle: git log is unbelievably fast, but faster than most people would need it to be
[17:06] <nexus10> speed is addictive
[17:06] <jdong> nexus10: yes, but in reality most projects would have to address Windows contributors, and Git's frankly unusable under Windows
[17:07] <jdong> nexus10: its speed and functionality are closely knit with the POSIX model of doing things
[17:07] <TFKyle> jdong: hmm, indeed
[17:07] <jdong> nexus10: and something else that might be a concern.... Git has little support for "dumb protocols"
[17:07] <nexus10> jdong: don't understand why the git buzz is so incessant for Rails
[17:08] <jdong> nexus10: in particular, to push a git repo somewhere, you almost HAVE to have a git server on the remote end. Which isn't something one can always negotiate
[17:08] <nexus10> can git even do symlinks properly?
[17:08] <jdong> nexus10: not sure. I'm not sure if we do that correctly too. At least we can *version empty directories*
[17:08] <jdong> (which might be something useful in dir-structure-sensitive things like Rails)
[17:09] <nexus10> indeed
[17:09] <nexus10> eg -- a Rails plugin has foo.rb and foo/*
[17:09] <nexus10> rename it and you need to rename both
[17:09] <TFKyle> jdong: having a bit of a hard time measuring git log's performance btw as it seems to run PAGER. there a quick way to disable that?
[17:10] <jdong> TFKyle: AFAIK if it's redirected somewhere it would not use a pager
[17:10] <TFKyle> doesn't here (git 1.5.4.3)
[17:10] <jdong>        -p|--paginate
[17:10] <jdong>            Pipe all output into less (or if set, $PAGER).
[17:10] <jdong> I guess you can set PAGER to (1) nothing (2) cat
[17:11] <TFKyle> still, I assume setting it to cat hurts it a bit, but meh
[17:12] <jdong> lol if setting a pager to cat hurts performance, change operating systems :)
[17:12]  * jdong looks on his HDD for any git repos he has lying around
[17:13] <TFKyle> (doing that on the wine source tree from maybe a month ago takes ~1.5secs btw
[17:13] <jdong> how many revisions are in the wine tree?
[17:13] <jdong> ok I've got a git mirror of Rockbox and a bzr-svn mirror of it
[17:14] <jdong> the git mirror is 1k revs behind, lemme bring that up and we can compare
[17:14] <TFKyle> (though, gitk and qgit4 do seem quite slow compared to bzr visualize, dunno why)
[17:14] <jdong> I wish gitk was a gtk based frontend
[17:14] <jdong> there's apparently something called gitview somewhere out there
[17:15] <lifeless> jdong: gitview is based on bzr viz :)
[17:15] <dudemeister> hi, i have a beginner question here. how do i actually start a project using a centralized style - the user guide seems to cover only the developer's site, but are there tutorials on how to setup the server?
[17:16]  * TFKyle wishes hg view was gtk-based as well
[17:16] <jdong> git log > /dev/null  0.60s user 0.00s system 98% cpu 0.615 total
[17:16]  * jdong waits for bzr
[17:16] <jdong> bzr log > /dev/null  10.86s user 0.33s system 98% cpu 11.305 total
[17:16] <jdong> order of magnitude
[17:17] <jdong> of course, logging 16378 revs is not exactly a "real world usecase"
[17:17]  * TFKyle still isn't sure how to tell the amount of revs in a git tree, hardly ever uses it :)
[17:18] <jdong> git rev-list --all | wc -l
[17:18] <jdong> lol that might be a hack
[17:18] <jdong> but everything in git seems that way.
[17:18] <TFKyle> and that's why I love bzr :)
[17:18] <jdong> and it's ALSO kinda annoying that git's on-disk size explodes when you commit to it
[17:19] <jdong> kinda forcing you to pack at least once every busy coding day if you don't want the thing taking up 5x the space it should.
[17:19] <TFKyle> 43449
[17:19] <nexus10> jdong, TFKyle: thanks, this was v useful
[17:19] <TFKyle> nexus10: oh, sorry - didn't mean to go off topic
[17:19] <jdong> TFKyle: yeah, git's fast at operations like this :)
[17:19] <jdong> but the UI is so.... urg....
[17:19] <nexus10> TFKyle: no worries, not OT for me
[17:20] <jdong> I tried to explain Git to someone who uses svn the other day, and he thought I was mocking him
[17:20] <nexus10> jdong: so the consensus is -- git wins on speed, bzr on evetrything else?
[17:20] <jdong> i.e. I invented a parody of svn that was hard to use
[17:20] <jdong> nexus10: roughly put, yeah
[17:21] <jdong> nexus10: rather, git has a lot of gotchas that should make one think twice before adopting it across some project where not everyone is familiar with the tool
[17:22] <jdong> nexus10: on my coding project last summer, one guy had no experience with version control, and in an afternoon he was comfortable branching, pushing, pulling, merging..... bzr's that intuitive.
[17:22] <jdong> I can't say the same about git
[17:24] <james_w> There was a bunch of patches to the git list the other day to make it halfway windows compatible.
[17:24] <james_w> so, the git on windows effort seems to be progressing ok.
[18:06]  * jdong bzr branches his todo list ponders the real-life meaning of what he just did.
[19:01] <abentley> jelmer: no
[19:01] <abentley> :-)
[19:29] <weigon> lifeless: the link needs a /Sprint .. instead of //Sprint
[19:50] <h4writer_> Hi
[19:50] <h4writer_> hope I can ask a question related to launchpad and bzr here?
[19:50] <h4writer_> I have locked my own branch :-(. How can I unlock it
[19:52] <elmo> bzr lazy imports are self-created and not a standard python thing, right?
[19:52] <elmo> h4writer_: bzr break-lock, I think?
[19:52] <lifeless> elmo: impoty bzrlib.lazy_import
[19:52] <h4writer_> doesn't do the job, but I had this before and had to use sft
[19:52] <h4writer_> *sftp
[19:53] <lifeless> h4writer_: bzr break-lock URL
[19:53] <elmo> lifeless: ok - not sure I wanna make dak depend on bzrlib :)  thanks
[19:53] <h4writer_> Still having the issue
[19:53] <h4writer_> :-(
[19:54] <h4writer_>  bzr break-lock bzr+ssh://h4writer@bazaar.launchpad.net/~h4writer/+junk/awn-customize-icons
[19:54] <h4writer_> doesn't do anything
[19:55] <lifeless> elmo: go on
[19:59] <awmcclain> Is there a way to set a configuration value across all users and branches?
[20:00] <awmcclain> h4writer_: Total shot in the dark, but have you tried bzr break-lock sftp://h4writer@bazaar.launchpad.net/~h4writer/+junk/awn-customize-icons ?
[20:01] <h4writer_> awmcclain, Indeed I thought it was that, but it isn't helping either :-(
[20:01] <awmcclain> :(
[20:01] <h4writer_> awmcclain, still locked, already for 30 min. :-(
[20:02] <awmcclain> ...or is the only way to specify a branch.conf in each one of my branches?
[20:02] <poolfool> h4writer_: you tried both 'sftp://' and 'bzr+ssh://' ?
[20:03] <h4writer_> poolfool, indeed
[20:03] <h4writer_> but I see there are some processes busy with bzr if I do "ps -ax | grep bzr"
[20:04] <poolfool> h4writer_: What is with the '+' plus sign in your path? ... what exactly is displayed on your screen about the lock OR when you try and break the lock?
[20:04] <h4writer_> poolfool, when I try to break it, nothing happens (so I get nothing returned)
[20:04] <poolfool> h4writer_: Wait ... 'ps -ef' on your local machine or on the lauchpad server?
[20:05] <h4writer_> poolfool, local
[20:06] <h4writer_> poolfool, can't kill those :-S, how come that
[20:07] <poolfool> h4writer_: do you own the process ? '#ps -ef |grep bzr' and check the User ID (uid).
[20:08] <h4writer_> poolfool, don't know, but I now killed them with system monitor :-D
[20:08] <h4writer_> poolfool, still locked :-(
[20:09] <h4writer_> poolfool, ?
[20:09] <h4writer_> poolfool, I did the committing with sftp
[20:09] <h4writer_> poolfool, and now it works
[20:10] <poolfool> h4writer_: Yea ... kind of new to bazaar my self. but you did fix the 'lock' problem? But you can commit with sftp?
[20:11] <h4writer_> poolfool, I didn't fix the lock problem. I still have it when I try with bzr bzr+ssh:// LOL
[20:11] <Polarity> If I want to track /etc with bzr, what is the proper way to ignore all the rcX.d directories?  rc.d/rc*.d/ in .bzrignore doesn't seem to work
[20:11] <h4writer_> poolfool, only a workaround :-(
[20:11] <h4writer_> poolfool, lifeless, awmcclain and elmo thank you for helping. I can do again further :-D
[20:16] <poolfool> Polarity: I saw something on the channel the other day, someone is doing the same thing but with Ubunto(sp) ... maybe a google search might help.
[20:16] <poolfool> Polarity: But sounds like something I have wanted to try for a while. Good luck.
[20:30] <TFKyle> lifeless: playing around with loom a bit, this has probably been suggested before or is total crack but would something like a goto-thread command to go to a specific thread instead of manually up/downing multiple times be a good idea?
[20:31] <lifeless> TFKyle: 'bzr switch threadname'
[20:31] <ubotu> New bug: #197748 in bzr "getattr on WorkingTree should not raise ObjectNotLocked" [Undecided,New] https://launchpad.net/bugs/197748
[20:31] <lifeless> going out to dinner now, back tomorrow UK morning time
[20:32] <TFKyle> ah, cool
[20:34] <CarlFK> I was tole to:  bzr co http://maya.asidev.com/srv/localhost/htdocs/tc/ninput/trunk
[20:34] <CarlFK> but that errors.
[20:35] <CarlFK> while I wait, is there any poking around that might help?
[20:36] <dato> CarlFK: "co" with "http" doesn't make much sense. but what error do you get?
[20:36] <CarlFK> http://maya.asidev.com/srv/localhost/htdocs/tc/ninput/trunk/ is permanently redirected to https://asidev.com/srv/localhost/htdocs/tc/ninput/trunk/
[20:36] <CarlFK> bzr: ERROR: Not a branch: "https://asidev.com/srv/localhost/htdocs/tc/ninput/trunk/".
[20:38] <dato> CarlFK: they gave you a wrong URL
[20:39] <CarlFK> yep
[20:40] <CarlFK> "Never mind, I've attached the full checkout tarball."
[20:41] <stefanv> a colleague of mine requested similar functionality to "hg cleanup" -- which removes all unknown files in the current working tree.  i wrote a small script to do just that... would it be of any interest?  how hard would it be to convert it to a plugin, or to add it as a command?
[20:41] <dato> stefanv: hm. "clean-tree" from the bzrtools package can do that
[20:41] <stefanv> great, thanks for the pointer
[20:43] <radix> I often just use rm `bzr unknowns`. (adding -r when necessary)
[20:43] <stefanv> that's probably fine for posix
[20:43] <stefanv> i'm not sure what he is running
[20:44] <stefanv> unknowns must be fairly recent
[20:46] <awmcclain> Anyone know... can I use pyqt4 with qbzr?
[20:50] <Peng> Soo.
[20:50] <Peng> Remind me not to get swapped to death (presumably by svn-import) in the future.
[21:19] <awmcclain> Ug. What a nightmare it is to compile PyQt on a mac.
[21:36] <poolfool> awmcclain: don't tell me that ... I am still looking for something nice to run on Mac OS X (leopard) with an OK gui.
[21:36] <poolfool> awmcclain: Do you have a good link for a Mac OS X tool chain? Have you tried fink?
[21:37] <awmcclain> poolfool: Ug. I'm not a huge fan of fink. Plus i think they only have pyqt3, not pyqt4. One of htese weekends when things die down I'm going to start a cocoa app for bzr.
[21:38] <awmcclain> poolfool: Wildcat works pretty well, except for the fact that it doesn't work. ;)
[21:38] <luks> ... and qbzr is no an 'app' :)
[21:38] <luks> *not
[21:39] <awmcclain> luks: Well, an "app" that has extensive, non-trivial dependencies. :)
[21:40] <luks> no, I mean it's more like tortoise* except that instead of using a graphical shell you use the command line
[21:40] <luks> there is no actual application that would run on it's own
[21:41] <awmcclain> I'm confused... did you mean bzr or qbzr is not an 'app'?
[21:41] <luks> qbzr
[21:42]  * awmcclain scratches his head.
[21:44] <luks> the dev version has a partially-working standalone application, but I guess I'll never finish that
[21:44] <poolfool> luks: did you write qbzr ?
[21:44] <luks> mostly because I know that I won't use it, so I'm not very motivated :)
[21:44] <luks> yes
[21:45] <awmcclain> :)
[21:46] <awmcclain> Oh, I see.. you mean you have to invoke qbzr from the command line
[21:46] <luks> more that you invoke qdiff, qci, etc. from the command line
[21:48] <awmcclain> ahhh...
[21:48] <awmcclain> luks: Can qbzr give me a graphical display of bzr status?
[21:48] <luks> yes and no :)
[21:48] <awmcclain> meaning it shows me the console output in a window?
[21:48] <luks> qcommit shows you the equivalent of bzr status
[21:49] <luks> but there is no standalone command for that
[21:49] <awmcclain> No, that's fine
[21:49] <awmcclain> Can you step through each file and get a graphical diff?
[21:49] <luks> sure
[21:49] <awmcclain> And finally....can you resolve conflicts through it?
[21:49] <luks> and add files, revers, etc.
[21:49] <luks> *revert
[21:50] <luks> no
[21:50] <awmcclain> ok.
[21:50] <luks> but this one is on my todo list pretty high
[21:50] <awmcclain> mmm
[21:50] <awmcclain> any sense of timeline?
[21:51] <luks> depends on when will I have to deal with first conflicting merge :)
[21:51] <awmcclain> Bascially I'm just looking for a way to 1. see the specific changes going out and 2. be able to resolve conflicts using a side-by-side diff.
[21:52] <luks> I definitelly don't plan writing a merge tool
[21:52] <luks> so resolving conflicts would involve just involving an existing tool
[21:54] <awmcclain> Ah yes, sorry, I wasn't more clear... can you pipe those diffs to diffmerge or something? I'm just looking for the workflow, really.
[21:54] <luks> at the moment, no
[21:54] <awmcclain> ah.
[21:54] <luks> it just uses internal side-by-side diff viewer
[21:55] <awmcclain> Basically I'm just looking for the eclipse-style team synchronization view. (But we've abandoned eclipse, thankfully)
[21:56] <luks> hm, I've never used eclipse with a VCS
[21:57] <luks> http://publib.boulder.ibm.com/infocenter/wsphelp/topic/org.eclipse.platform.doc.user/images/Image245_sync_view.jpg ?
[21:59] <awmcclain> Pretty much, yeah. You see files incoming, files outgoing, ignored and conflicts.
[21:59] <awmcclain> I suppose I could just run extmerge with a file merger for file conflicts.
[22:02] <luks> I'm afraid qbzr isn't going to help you much in it's current state
[22:02] <awmcclain> S'ok. :)
[22:02] <luks> I seem to need a GUI for quite different actions
[22:02] <awmcclain> branching and such?
[22:03] <luks> no, mostly history browsing
[22:03] <awmcclain> ahhh
[22:03] <awmcclain> we have bzr-trac for that. :)
[22:03] <awmcclain> (which also doesn't really work. ;) )
[22:03] <luks> :)
[22:06] <awmcclain> Is there any way to see, when you update, what the exact merges will be?
[22:07] <stefanv> something a bit more detailed than bzr missing?
[22:09] <awmcclain> now that I know about bzr missing, i think, no. :)
[22:10] <luks> ditch the checkout, use a real branch, merge --preview? :)
[23:02] <mc__> I've accidentically remove am file with rm. Can I restore it with bzr? (It was version controlled of course)
[23:03] <ferringb> mc__: bzr revert file # should do it.
[23:03] <mc__> thanks
[23:04] <ferringb> any security issues w/ bzr server for ro access?
[23:05] <ubotu> New bug: #183565 in trac-bzr "KeyError: 'root_directory'" [Low,Incomplete] https://launchpad.net/bugs/183565
[23:07] <james_w> ferringb: none known, but I don't think it's been audited
[23:07] <ferringb> mmm
[23:10] <ubotu> New bug: #57447 in trac-bzr "Viewing changeset diffs is slow" [Low,Triaged] https://launchpad.net/bugs/57447
[23:10] <ubotu> New bug: #126835 in trac-bzr "COPYING file not being included in tarball" [Low,Fix committed] https://launchpad.net/bugs/126835
[23:11] <ferringb> james_w: do you know what sort of perms it requires?  specifically, I'm thinking about locking on the repo
[23:11] <ferringb> I'd rather run the server as a user that has no write access on disk personally
[23:12] <james_w> ferringb: that should help.
[23:12] <james_w> ferringb: there are read and write locks taken out by bazaar, and working tree, branch and repo locks.
[23:12] <ferringb> yeah, that's specifically what I was concerned about
[23:13] <james_w> some of the read locks are just nops, but I can't remember if all are.
[23:13] <ferringb> mmm
[23:13] <ferringb> well, I'll experiment
[23:13] <ferringb> server is fast enough I'm going to bring it up- 3.2k revs, http pull has been pretty painful for our users
[23:13] <james_w> read only on everything except .bzr/whatever/lock/ should be ok I guess.
[23:13] <james_w> Obviously not ideal, but better than nothing.
[23:13]  * ferringb nods
[23:14] <james_w> ferringb: does bzr+http:// not suit you?
[23:14] <ferringb> james_w: wasn't even aware of it- specifics?
[23:15] <james_w> ferringb: well you can serve over http://
[23:15] <james_w> however for better performance you can use the "smart server", which requires bzr to be installed on the server.
[23:16] <ferringb> yeah, bzr server; thought that was 'bzr branch bzr://...' ?
[23:16] <james_w> That means you can use bzr+ssh:// for people you trust and need to grant write acess to.
[23:16] <ferringb> ah, right
[23:16] <james_w> And you also get bzr+http:// which is fast readonly (though I've never used it, so don't believe everything I say)
[23:16] <ferringb> mmm
[23:17] <ferringb> how do you setup bzr+http:// ?  only familiar with bzr+ssh
[23:17] <james_w> and bzr:// which is a native tcp protocol, which by default is read only, but you can grant write access with.
[23:17] <james_w> and allows read access to every file beneath the directory you serve.
[23:19] <james_w> ferringb: http_smart_server in the docs. Do you have the source of bzr? Otherwise what OS are you on?
[23:19] <ferringb> linux, likely have docs, but didn't see it in the --help
[23:19] <james_w> It's not a help topic, but a doc
[23:20] <ferringb> this up on the site at all?  I went looking for perf. stats on bzr --server (and a quick intro to it), but didn't find anything
[23:20] <james_w> /usr/share/doc/bzr/txt/en/user-guide/http_smart_server.txt.gz
[23:20] <james_w> for me on Debian/Ubuntu
[23:22] <james_w> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
[23:23] <james_w> it's got a big fat warning on that section, so maybe it is not trustworthy.
[23:23] <james_w> Serving over plain http should be pretty secure for read only access.
[23:23] <james_w> It is slower though, so if you have a large project it would be far from ideal.
[23:24] <ferringb> well hell
[23:25] <ferringb> been forcing people to use http://; speed up is a speed up, even if I just use bzr+http:// ;)
[23:30] <ferringb> james_w: does bzr+http play nice with shared repositories?
[23:30] <ferringb> it's giving me a 404 error indicating it doesn't ;)
[23:31] <james_w> ferringb: you trying to branch a shared repository, or a branch in a shared repo?
[23:31] <ferringb> branch a shared repo
[23:32] <ferringb> bzr.pkgcore.org/ferringb/pkgcore-dev; trying to pull that down, /bzr/ferringb/pkgcore-dev, shared repository at /bzr/
[23:34] <ferringb> mmm.  screw it, bzr:// it is (it's fast enough I'll shove through the permissions issues)
[23:34] <ferringb> james_w: thanks for the info
[23:35] <james_w> ferringb: no problem. Feel free to ask again if you need any more info.
[23:35] <fullermd> bzr, bzr+ssh, and bzr+http use mostly the same code, so they should be equally speedy and secure (or slow and insecure)
[23:35] <ferringb> heh
[23:36] <ferringb> hell, I'm just happy to see smart server is around- been waiting for it a while, *very* happy to see a 71s checkout for users rather then the usual ~15m affair
[23:59] <LaserJock> jelmer: friendly ping on getting newer bzr-svn in PPA for gutsy :-)