[02:09] <lifeless>  http://www.linux-foundation.org/en/Net:Netem
[02:10] <lifeless> http://www.linux-foundation.org/en/Net:Netem
[02:11] <poolie_> lifeless, http://webkit.org/blog/108/yet-another-one-more-thing-a-new-web-inspector/
[02:15] <mlh> there was a python magling app/library I mentioned on the slug list sometime ago.  I forget the name
[02:18] <lifeless> magling?
[02:25] <mlh> my mangle got magled
[02:26] <TFKyle> mangling meaning obfuscation or something like symbol mangling?
[02:27] <mlh> er neither really, network simulation of a sort.  Searching hasn't found anything.  Maybe I'm misremembering
[02:27] <TFKyle> ah
[04:41] <ubotu> New bug: #181927 in bzr "bzr-gtk broken in repo" [Undecided,New] https://launchpad.net/bugs/181927
[05:32] <Peng> How does Bundle Buggy approval work?
[05:33] <Peng> Some merge requests need two "bb:approve"s and some don't.
[05:33] <Peng> Why?
[05:35] <lifeless> all requests need two voters
[05:35] <lifeless> some requests are from voters and thus have an implicit ingle initial approval
[05:36] <Peng> Ahhh.
[05:36] <Peng> That makes sense.
[05:36] <Peng> Okies. :)
[05:39] <Peng> Thanks.
[05:44] <lifeless> np
[05:45] <lifeless> its also in the developers guide IIRC
[07:25] <ubotu> New bug: #181945 in bzr "bzr pull lp:upstart fails" [Medium,Confirmed] https://launchpad.net/bugs/181945
[07:30] <ubotu> New bug: #181942 in launchpad-bazaar "bzr pull --remember fails with lp style url (dup-of: 181945)" [Medium,Confirmed] https://launchpad.net/bugs/181942
[10:18] <Zyroth> Is there a tool that uses bzr locally for versioning but can also commit to an svn repos?
[10:22] <Kinnison> You may be able to get somewhere with bzr-svn
[10:25] <Zyroth> thanks
[10:40] <IllX> Are there any good bzr videos out there? I just watched one from John Meinel and would enjoy to learn more
[10:42] <IllX> searching for "videos" on bazaar-vcs.org pulls up some sort of badcontent file; doesn't seem like what I'm looking for
[10:42]  * fullermd didn't know there were any videos...
[10:43] <IllX> It's informal but very nice to have
[10:43] <IllX> http://video.google.com/videoplay?docid=-7349765443983887725
[10:43] <IllX> wish I could find more
[10:44] <fullermd> They promised me the videos were all erased, and anyway the statute of limitations had expired.
[10:44] <IllX> the rails guys have spoiled me I guess
[10:44] <fullermd> Er.  I MEAN....
[10:45] <Odd_Bloke> Rails is enough to spoil anything. ;)
[10:46] <fullermd> Every time I look at ruby, I feel spoilt all right...
[10:47] <Odd_Bloke> 'Tis the season to be trolly, trollollollolloll troll oll oll oll.
[10:48] <fullermd> Gah.  Who's making a ruckus up on my bridge?!
 Get off my bridge!
[12:22] <LeMec> hi! is anyone here using bzr-svn latest version?
[12:22] <LeMec> by reading the announcement I got the impression that it no longer needs the python svn bindings patch
[12:23] <Odd_Bloke> jelmer is the man to ask. :)
[12:23] <LeMec> however, when I'm trying to run it (Mac OSX Tiger, Python 2.5.1, Bzr 1.1RC1, bzr-svn 0.4.6) I am getting this error: Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details.
[12:23] <LeMec> do you know his timezone?
[12:23] <LeMec> at least I know when to ask him :)
[12:24] <fullermd> UTC+1 or 2, I think.
[12:24] <LeMec> (based on the name he should be EU, but not sure)
[12:24] <Odd_Bloke> I don't, I'm afraid.
[12:24] <fullermd> But don't quote me on that.
[12:25] <LeMec> #jelmer: can you please comment on my issue with bzr-svn? thanks
[12:32] <AfC> Jelmer is his own IRC channel? Neat!
[12:33] <dato> heh
[12:33] <Odd_Bloke> jelmer implements RFC 1459.
[12:33] <LeMec> :)
[12:33] <Odd_Bloke> s/jelmer/Chuck Norris/
[12:34] <fullermd> Oh, he's working on bzr-irc now?
[12:35] <LeMec> I've rechecked the documentation... and I have bad news for me
[12:35] <AfC> LeMec: did you have an opportunity to try the Subversion access case you are fighting on a different platform, say Linux? (if so, did it work there, making this a porting to Mac issue, or did it not work there either, making this a use of bzr-svn bug)
[12:35] <LeMec> "At the moment, the svn plugin only works with
[12:35] <LeMec> Subversion 1.5 (trunk)."
[12:36] <LeMec> I currently have access only to a Win and a Mac machine
[12:37] <LeMec> I have some VMWare Linux images somewhere but not close enough
[12:38] <LeMec> maybe I am the laziest guy, but it looks kind of weird to require an unreleased svn version
[12:39] <Odd_Bloke> It's going to be released fairly soon, I believe.
[12:39] <LeMec> I mean... you usually don't like to stay on the cutting edge versions when working with your sourcebasse
[12:39] <fullermd> Yeah, the release is right around the corner.  Just like it was last year this time.  And the year before...
[12:39] <dato> LeMec: sometimes what you want to do is not possible at all with released versions...
[12:41] <LeMec> maybe you are right
[12:41] <LeMec> unfortunately I must confess that getting up to speed with Bazaar hasn't worked for me so far
[12:41] <LeMec> :(
[12:41] <fullermd> Well, in this case, he is; the python bindings in 1.4.x are totally b0rked.
[12:42] <LeMec> I see
[12:42] <fullermd> And the 1.5 release has been a month or two out for something like 18 months now   :|
[12:43] <fullermd> It would be enough to drive me batty, if I used svn   ;)
[12:43] <LeMec> unfortunately, for me this only means that one of the strongest Bazaar selling points is just out
[12:45] <LeMec> I tried to resist so far... but it looks like I should try the remaining alternative (git)
[12:48] <AfC> LeMec: You're writing off Bazaar because some other VCS is borked?
[12:49] <LeMec> Afc: no, just because I cannot use it for my needs
[12:49] <LeMec> I may be sounding harsh here (which is definitely not my intention) but
[12:49] <LeMec> - Mercurial: has the easiest distro (for multi platforms), but is lacking the svn support
[12:50] <LeMec> - Bazaar: has the svn support, but requires the user to pass through some weird hops
[12:50] <LeMec> - Git: has the svn support, but it's support for different platforms is not quite good
[12:51] <LeMec> and I definitely wanted to write its instead of "it's" :)
[12:51] <AfC> "weird hoops"? Bazaar forces far less  behaviour than any of the other 3rd generation DVCS systems.
[12:51] <Kinnison> may be weird for bzr-svn
[12:52] <LeMec> Afc: that is your opinion and I am not gonna comment it
[12:52] <fullermd> "Weird" is certainly my impression of the process.  Either (a) your packaging system ships patched bindings, or (b) you're in for a world of manual pain.
[12:52] <dato> LeMec: it was just a misunderstanding, I think
[12:52] <LeMec> unfortunately, I am not gonna install XCode 1Gb, compile things by my own and hope it works
[12:53] <LeMec> moreover move to install on my system another "beta" product (svn)
[12:54] <LeMec> (well, it looks like I'm pretty tired and my writing reflects it)
[12:55] <LeMec> I just hoped I could grab something, install it and start working... that is what I was looking for
[12:59] <AfC> LeMec: you're in the Bazaar project's channel saying bzr doesn't work. You could reasonably expect that people here might be interested in finding out what about Bazaar isn't performing correctly with an interest in either helping you use it better or fixing a problem with bzr if one is present.
[12:59] <LeMec> I think I've provided all available data
[12:59] <LeMec> if I missed anything I would be glad to provide more
[12:59] <fullermd> No, he's in the Bazaar project channel saying that getting bzr-svn working requires a lot of hoop-jumping...
[13:00] <LeMec> fullermd: in the past month I've discussed other aspects of bzr too
[13:00] <AfC> Well, that's Subversion's fault for not having cut a release in forever, I should think. Not really something you can blame bzr for.
[13:01] <LeMec> the bzr-svn is just the today theme... and I thought that bzr-svn even if a plugin is an important part of bzr
[13:01] <LeMec> I apologize if this isn't the right place to discuss about it
[13:01] <fullermd> It doesn't have to be something bzr can be blamed for, to make it a showstopper   :p
[13:01] <AfC> point
[13:02] <LeMec> Afc: I theoretically agree with you
[13:02] <LeMec> but svn allown works for me, and it is the bzr to svn which is not
[13:02] <dato> LeMec: it is the right place. I understand your frustation, but there's little more we could do.
[13:02] <fullermd> If interfacing with svn is important, and doing so with bzr is a PITA, it doesn't matter whether it's bzr's or svn's fault.  It's still a "Well, let's try something else" moment.
[13:02] <LeMec> moreover, I am not here to blame, but rather to get help and provide feedback
[13:02] <dato> LeMec: short of having somebody with mac knowledge provide packages somewhere
[13:02] <AfC> dato: I don't suppose we should suggest tailor
[13:03] <fullermd> Which has been discussed a time or two recently.
[13:03] <AfC> dato: (which is an abomination, but usually works for one time transformations)
[13:03] <fullermd> Urg.  For a conversion, tailor would work OK.  For interaction, not so much.
[13:03] <dato> AfC: I don't think he wants a one-time transformation
[13:03] <LeMec> AfC: I have used tailor in the past
[13:03] <jelmer> LeMec: hi
[13:03] <LeMec> but bzr-svn selling point is the continuous integration
[13:03] <LeMec> and not the 1-time improt
[13:03] <LeMec> jelmer: hi
[13:07] <LeMec> dato: that would be optimal; in a discussion with Martin Pool I have suggested this (I think my email finally got to the bzr mailing list)
[13:11] <jelmer> LeMec: I'm afraid bzr-svn (and python-subversion) being hard to install on Mac OS X is a known issue,
[13:11] <jelmer> there were some folks working on an installer
[13:11] <jelmer> but I'm not sure what the status of that is
[13:11] <duckx> Hy all
[13:12] <LeMec> are you referring to Sylveszter? (sorry if I've misspelled the name)
[13:12] <duckx> are nested tree ok ? I mean a bazaar tree in a bazaar tree ?
[13:12] <jelmer> LeMec: yes
[13:12] <duckx> Is there any doc on this
[13:12] <LeMec> jelmer: I haven't heard back from him in a month :(
[13:12]  * duckx : bzr stays my favorite vcs ;) 
[13:13] <duckx> By the way, I use it to revision control all my conf on my servers ..
[13:13] <jelmer> duckx: nested trees are an experimental feature, you'll need the dirstate-with-subtree format
[13:14] <LeMec> jelmer: but can you please detail why is it difficult to get it working under Mac?
[13:14] <duckx> Ha ok
[13:14] <duckx> Thx jelmer
[13:14] <LeMec> I mean afaik git has solved it somehow, and considering bazaar is python I would expect things to be a bit easier
[13:14] <fullermd> duckx: Now, you can put one branch inside another and just treat them as two separate branches without any special support.
[13:14] <fullermd> LeMec: git doesn't use the python bindings   :)
[13:15] <jelmer> LeMec: git doesn't use python
[13:15] <jelmer> LeMec: afaik it just invokes the svn binary
[13:15] <duckx> Ok, I got my /etc bzrified and my /etc/apt/ bzrified too
[13:15] <LeMec> jelmer: than why bzr-svn is not doing the same?
[13:15] <duckx> in /etc bzr add /etc/apt is ok ?
[13:16] <jelmer> LeMec: Because that's more complicated and slower
[13:16] <LeMec> jelmer: if you know the bindings are the problem... then avoiding them would be the option
[13:16] <jelmer> LeMec: the bindings are mainly a problem on the Mac
[13:16] <jelmer> LeMec: Most Linux distributions ship with the patches included
[13:16] <LeMec> jelmer: complicated and slower than not working?
[13:16] <jelmer> LeMec: I don't have a Mac so I'm not entirely sure what the problem is with providing patched bindings for the Mac
[13:17] <LeMec> I see... then the only thing missing is a prepared distro for the Mac
[13:24]  * AfC waves to jelmer (who he rarely sees), dato, and fullermd
[13:24] <AfC> night gents
[13:24] <jelmer> g'night AfC
[13:26] <Lo-lan-do> Hi all
[13:27] <jelmer> hi Lo-lan-do
[13:27] <Lo-lan-do> jelmer: If I may bother you... would it be possible to store the mappings between svn revs and bzr revs somewhere else than in properties?
[13:28] <mwh> i guess i could try again to build on the mac
[13:28] <mwh> won't be for a couple of weeks yet though :/
[13:28] <Lo-lan-do> Commit messages are getting more and more unreadable as time passes and I commit to gforge's SVN through bzr : http://lists.gforge.org/pipermail/gforge-commits/2008-January/000798.html
[13:28] <jelmer> Lo-lan-do, they could be stored in revision properties
[13:29] <jelmer> Lo-lan-do, but that requires a subversion 1.5 server
[13:29] <jelmer> Lo-lan-do, I've started some work on that in a separate branch earlier this year
[13:29] <Lo-lan-do> Hmm.  Maybe it would simply be better to enhance the svnmailer then, so it only shows what has changed in the properties, rather than the old+new versions.
[13:30] <jelmer> yeah, that's what we did for Samba
[13:31] <Lo-lan-do> Do you know where I could find a patch?  Or if it was trivial enough that I could redo it?
[13:37] <jelmer> we use a custom script, not svnmailer
[13:38] <jelmer> svn://svn.samba.org/samba/hooks/commit-email.pl
[13:40] <Lo-lan-do> Blah, current svnmailer already does the right thing.
[13:41] <Lo-lan-do> "current" as in "currently released", not "currently installed on gforge.org" :-(
[14:12] <Kinnison> Can bzr serve cope with multiple repos?
[14:12] <Kinnison> I.E. can I do bzr serve --directory=/path/to/store
[14:12] <Kinnison> where there is /path/to/store/repo1/branch1 /path/to/store/repo1/branch2 /path/to/store/repo2/branch1 etc.
[14:12] <Kinnison> ?
[14:12] <fullermd> AFAIK, 'server' doesn't serve repos, it serves a FS tree.
[14:13] <fullermd> So anything underneath --directory is fair game.
[14:13] <Kinnison> interesting, ta
[14:21] <Lo-lan-do> jelmer: Another quick question: is it possible to easily get the svn revision number when I'm in a bzr-svn branch?
[14:22] <jelmer> Lo-lan-do: not really
[14:23] <spiv> Kinnison: fullermd is right.  Each smart request includes a relpath.  In your example "bzr branch bzr://localhost/repo1/branch1" would work fine.
[14:23] <Lo-lan-do> Okay, I'll live without.
[14:23] <jelmer> Lo-lan-do: There is an open bug about showing the svn revno in "bzr log", but that requires bzr changes
[14:24] <jelmer> Lo-lan-do: you can always parse the revid :-)
[14:25] <Lo-lan-do> True.  I'll write a wrapper around that.
[14:25] <Lo-lan-do> Thanks for the idea.
[14:27] <Lo-lan-do> bzr log --short --show-ids -r -1 | grep revision-id: | head -1 | awk -F: '{print $5'}
[14:27] <Lo-lan-do> There :-)
[14:27] <jelmer> :-)
[14:28] <Kinnison> spiv: can the smart server pay attention to the hostname used to access it, or is that not part of the protocol?
[14:29] <fullermd> I wish --show-ids were more granular...
[14:29] <Kinnison> spiv: also, how trivial is it to access control it? I'm guessing bzr+http[s] is easier to access control, but I'm not sure about read vs write
[14:30] <dato> Kinnison: there is something in contrib/ about access control
[14:30] <dato> contrib/bzr_access,
[14:31]  * Kinnison looks
[14:32] <spiv> Kinnison: the hostname isn't part of the protocol
[14:32] <Kinnison> dato: which contrib/ ?
[14:32] <dato> bzr.dev's at least
[14:32] <dato> oh
[14:32] <spiv> Kinnison: contrib in bzr.dev, and probably 1.1rc1
[14:32] <dato> I wonder why that isn't installed in the debian package
[14:32]  * Kinnison bzr pulls
[14:34] <rjek> Hi.  So I'm thinking about migrating from svn to bzr.  What's the best option for migrating my data (including history) to bzr, while at the same time rearranging the data?
[14:38] <LeoNerd> Tailor ?
[14:39] <jelmer> rjek: what do you mean by rearranging the data?
[14:39] <rjek> I had considered it, I just wanted to make sure it was a sensible choice.
[14:39] <rjek> jelmer: Well, the way projects and such are organised in the current svn repository is not ideal.
[14:41] <Kinnison> spiv: would it be reasonable to assume that the smart protocol over http uses GET for read-only and POST for writing?
[14:41] <fullermd> I don't think so.  I'm pretty sure it POST's everything.
[14:41] <Kinnison> :-(
[14:42] <fullermd> I think the lowest overhead suggestion I've seen was to use different configs for http and https, and allow writing and require auth on the latter.
[14:43] <Kinnison> mmm
[14:43] <Kinnison> rjek: would that be acceptable?
[14:44] <rjek> It sounds like a hack.
[14:44] <fullermd> Yeah, that's a side effect of it being a hack   :)
[14:44]  * rjek grins.
[14:44] <rjek> It'd be nice if it used GET: that'd give you the advantage that you could take advantage of web caches.
[14:45] <rjek> (If-Modified-Since etc)
[14:45] <fullermd> Doesn't work too well with the sort of things smart requests do.
[14:46] <rjek> Does it not ask for the whole contents of a file occationally?  Of course, the output of CGIs could be cachable, so the parameters of the smart request could still be done in a GET and still be usefully cached.
[14:47] <fullermd> A lot of them would be really hard to get that information for.  And then there's the limits on GET request size...
[14:48] <rjek> There's a limit on the size of a request URI?
[14:48] <fullermd> Oh, yes.
[14:49] <fullermd> You probably don't see it much in practice, since IE's limit on URL length is lower than the RFC's or Apache's, but it's there.
[14:49] <fullermd> (not that I'm bitter about that, or that it's ever cost me a half days work or anything, mind you)
[14:49] <rjek> I thought it was something astronomically large (comparitively) like 16kB or something.
[14:50] <fullermd> I think it's more like 2k.
[14:50] <rjek> Right.
[14:50] <fullermd> And sending around lists of revision id's can eat that up fairly quick.
[14:50] <rjek> You need to encode it more efficently than using ASCII digits. :)
[14:51] <fullermd> It's a URL; you encode LESS efficiently than ASCII digits after you escape all the necessary characters   :p
[14:52] <rjek> I was assuming a revision id was a decimal number, and thus encoding it as a decimal number in ASCII wouldn't be as efficent as, say, encoding it in base 36 or something.
[14:53] <fullermd> No, they're opaque text strings.
[14:53] <rjek> Right.
[14:55] <Kinnison> rjek: those are revno rather than revid
[14:55] <dato> rjek: about your rearranging, it *sounds* as if you have several different projects in your svn repository, and want to rearrange *them*?
[14:55] <rjek> dato: Both.
[14:56] <dato> rjek: normally you'll create a different bzr branch for each project
[14:56] <dato> rjek: and since they are normal directories, you can later arrange them (at the filesystem level) as you please
[14:56] <dato> does that answer your question, or I misudnerstood you?
[14:57] <rjek> I'm not entirely sure yet. :)
[14:57] <rjek> I think it answers my question.
[14:59]  * Kinnison struggles with the wsgi stuff
[15:01] <dato> rjek: as for the conversion, if you can install bzr-svn easily (which it mostly is if you're on linux afaik), then I think that'd be the easiest way, converting one project at a time. if not, tailor... do you have branches of your projects?
[15:01] <rjek> Very very few.
[15:01] <rjek> (perhaps one or two.)
[15:03] <dato> ok, afaik it works well as well, with bzr-svn.
[15:05] <cory> I've been having trouble.  My commits typically never make it paste "Saving data locally - Stage 2/5", which is taking an incredible amount of time.
[15:05] <rjek> OK, I'll look into that too.
[15:11] <cory> Ok, things have magically resolved themselves.  Maybe I'm just impatient.  Never mind, then. :P
[15:19] <Kinnison> Gah, this is hard
[15:19] <Kinnison> I have a bunch of repos in /path/to/trees
[15:19] <Kinnison> I set that as the base of the smart fcgi
[15:20] <Kinnison> and then set /trees/ as the prefix
[15:20] <Kinnison> but then a request tries to read /path/to/trees/trees/repo/branch/.bzr/branch-format
[15:20] <Kinnison> which is just confusing as hell
[15:21] <Kinnison> Anyone here dones the whole bzr as an fcgi thing?
[15:22] <LeoNerd> Sounds like the sort of thing I'd do.. but I haven't
[15:23] <spiv> Kinnison: there are some patches from me in http://bundlebuggy.aaronbentley.com/
[15:23] <LeoNerd> Largely on account of not being able to find a webserver that will do FastCGI that doesn't suck piggie
[15:23] <spiv> Kinnison: that fix bugs in the patch handling in this area
[15:23] <Kinnison> patch handling?
[15:23] <spiv> path handling.
[15:23] <spiv> My fingers are too ready to type "patch" it seems :)
[15:24] <Kinnison> which should I be looking for?
[15:24] <spiv> http://bundlebuggy.aaronbentley.com/request/%3C20071214015112.GC14963@steerpike.home.puzzling.org%3E
[15:24] <spiv> http://bundlebuggy.aaronbentley.com/request/%3C20071214011937.GA26039@steerpike.home.puzzling.org%3E
[15:24] <spiv> Unfortunately, I really need to sleep now
[15:24] <spiv> I hope that's of some help
[15:24] <Lo-lan-do> Sleep usually helps
[15:25] <spiv> Lo-lan-do: :)
[15:26] <Odd_Bloke> When in doubt, sleep.
[15:26] <Kinnison> spiv: so is this a client or a server issue?
[15:43] <orospakr> What is Bundle Buddy?
[15:43] <Kinnison> Okay, so I got it talking a bit
[15:44] <Kinnison> only it can't think about branches in shared repos
[15:44]  * Kinnison sighs
[15:44] <Kinnison> I appreciate that bzr+http is a hack, but this is pitiful :-(
[15:44] <dato> orospakr: an application to track pending merges in a project
[15:45] <orospakr> er, s/buddy/buggy/
[15:45] <orospakr> neat.
[15:54] <Peng> How is bzr+http a hack?
[16:01] <Kinnison> Peng: it's a vaguely stateful protocol (bzr smart protocol) being run over a stateless protocol (http)
[16:01] <Kinnison> afaict
[16:01] <Kinnison> anyway, time to drive to mother-in-law's
[16:01] <Kinnison> byw
[16:16] <RainCT> Hi
[16:18] <RainCT> There is no "bzr cp" feature (like "bzr mv" but instead of moving the file, duplicating it, so having two different files with the same history), or?
[16:20] <ubotu> New bug: #182040 in bzr "reconfigure form lightweight checkout to checkout don't pull tags from master branch" [Undecided,New] https://launchpad.net/bugs/182040
[16:21] <hendrixski> Hey, I just saw on Mark Shuttleworth's blog that there's a bzr-eclipse plugin on the way.   Has anybody tried it, does it work well yet?
[16:23] <Peng> RainCT: That is correct. No copying.
[16:23] <Peng> RainCT: Because of how bzr's really great renaming is done, copying is not supported.
[16:24] <Peng> RainCT: There's at least thought about doing it differently so copying can be supported.
[16:27] <RainCT> Peng: Thanks for the information :).
[17:28] <soul9> hi
[17:29] <soul9> !help
[17:29] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
[17:29] <soul9> !info server
[17:29] <ubotu> Package server does not exist in gutsy
[17:29] <soul9> :-)
[17:29] <soul9> heh
[17:29] <soul9> i would like to set up a bzr server
[17:30] <soul9> i know it's distributed, but it'd still be nice
[17:30] <soul9> i haven't been able to find anything about the setup
[17:33] <luks> if you have a sftp server and a http server, you already also have a bzr server
[17:38] <soul9> ok
[17:38] <soul9> so there is no guide about this?
[17:38] <soul9> i do think i have sftp (i do have ssh)
[17:38] <soul9> but then what?
[17:38] <dato> then
[17:38] <Lo-lan-do> mkdir
[17:38] <luks> then you just use it
[17:39] <dato> you `bzr push` to a location in the server where the http server will serve it
[17:39] <soul9> so if i do have sftp enabled
[17:39] <soul9> i should be able to use an ftp client
[17:39] <dato> eg. bzr push --create-prefix sftp://host/var/www/bzr/project/trunk
[17:39] <soul9> to connecT?
[17:39] <dato> or. bzr push --create-prefix sftp://host/~/public_html/project/trunk
[17:41] <soul9> so with this way, i should use a shared useraccount if I want to work in team?
[17:41] <soul9> or?
[17:42] <dato> soul9: or make /var/www/bzr/project group-writeable, and create a group
[17:43] <soul9> yeah
[17:43] <soul9> 0o
[17:45] <soul9> ok, so sftp works
[17:45] <soul9> that way though, i need to create users
[17:45] <soul9> with shell accounts..
[17:47] <LarstiQ> soul9: or use an sftp server that doesn't require system users
[17:47] <soul9> o
[17:47] <soul9> that would definitely be nice
[17:47] <Peng> bzr+ssh is speedier than sftp.
[17:48] <Peng> That requires SSH logins for everyone though.
[17:48] <Peng> And it requires bzr be installed on the server.
[17:48] <soul9> yeah
[17:48] <soul9> i think i'll just do sftp+http
[17:48] <soul9> if i can find an sftp server that doesn't need system logins
[17:49] <dato> with bzr+ssh, you can set the login shell of those people to a wrapper that just calls bzr serve with the appropriate arguments, I think
[17:50] <soul9> yeah, like hg
[17:50] <soul9> i don't like that though
[17:50] <soul9> i can't find such an sftp server though
[17:50] <dato> maybe LarstiQ knows of one
[17:52] <soul9> LarstiQ: would you be so kind, if you know an sftp of the likes, to hint me with at least the name of it? :-P
[17:53] <soul9> :-(
[17:54] <LarstiQ> soul9: iirc spiv wrote one, let me look
[17:54] <soul9> thx
[17:58] <LarstiQ> soul9: can't seem to find it atm. Another option is chrooting your sftp server.
[17:58] <soul9> ok
[18:00]  * LarstiQ goes to bed
[18:00] <soul9> night
[18:02] <dato> LarstiQ: are you in EU?
[18:02] <LarstiQ> dato: yes
[18:02] <dato> ok, enjoy your sleep :)
[18:03] <LarstiQ> dato: fever :/
[18:03] <dato> aw. i wish you a prompt recovery!
[18:04] <LarstiQ> dato: thank you, and now I really detach :)
[18:06] <CardinalFang> Hi.  I have a repo that seems to have been "repo-init"'d with "--no-trees".  How can I change that default?
[18:07] <dato> rm foo/.bzr/repository/no-working-trees, I guess
[18:07] <dato> I can't recall that we have an UI to change it
[18:07] <CardinalFang> Ah.  I figured there was a cooler way.  Thanks.
[19:35] <Solarion> how do I make a branch have a new parent?
[19:35] <Lo-lan-do> bzr pull --remember?
[19:36] <Solarion> aaah, danke.
[19:45] <jdahlin> Is pushing from a bzr-svn repository known to be slow?
[19:45] <jelmer> jdahlin: What do you mean exactly? Pushing from Bazaar into Svn?
[19:45] <jdahlin> jelmer, Oh. Yes, exactly that
[19:46] <jelmer> Is this the first you're accessing the Subversion repository?
[19:46] <jdahlin> I have a subversion repository with 6000 revisions which I branched off, but it seems to take a while to push the changes
[19:46] <jelmer> jdahlin: What version of bzr-svn?
[19:46] <jdahlin> jelmer, it's the first time I'm committing yes
[19:46] <jdahlin> 0.4.2
[19:46] <jdahlin> no, sorry. 0.4.5
[19:47] <jelmer> Newer versions (0.4.6 in particular) do more efficient caching
[19:47] <jelmer> in any case it will be a lot faster the next time you push
[19:47] <jdahlin> Okay, sounds good.
[19:47] <jdahlin> Is bzr push the normal way of merging back to the svn repository?
[19:48] <jelmer> yes
[19:49] <jdahlin> and bzr diff -r ancestor:svn://.. to get a diff?
[19:49] <Lo-lan-do> (Phew -- I've been doing that for the last six months :-)
[19:50] <jelmer> jdahlin: I usually use "bzr diff -rbranch:.." but I think ancestor should work as well
[20:01] <jdahlin> I really hope it will be faster the next time, it's already been running for 20 minutes.
[20:02] <jelmer> you may want to upgrade to 0.4.6
[20:03] <jdahlin> oh, it just finished
[20:03] <jdahlin> and it worked as it should!
[20:03] <jdahlin> let me try to commit a second time
[20:04] <jdahlin> Indeed, it seems to take quite a bit
[20:05] <jdahlin> *of time
[20:08] <jelmer> on the samba svn repository (>25k commits) it usually takes less than 10 seconds
[20:09] <jdahlin> real	5m7.607s
[20:11] <jdahlin> Let me retry with 0.4.6.
[20:12] <jdahlin> jelmer, it's doesn't seem to be caching svn connections very well, it's connecting to the remote host every second or so
[20:13] <jdahlin> Yes, my connection to the svn server is quite restrained
[20:19] <jdahlin> real    5m46.833s
[20:19] <jdahlin> jelmer, so, no speed improvements using 0.4.6
[20:31] <jdahlin> second time with 0.4.6 brought it down to 2m19, getting much better
[21:11] <LeMec> jdaklin: was it a large commit?
[21:12] <LeMec> 5m sounds like a lot of time; or was is due to a weak connection?
[21:13] <jdahlin> LeMec, no, it was a tiny commit
[21:13] <jdahlin> LeMec, due to a weak connection yes
[21:21] <jelmer> re
[21:21] <jelmer> jdahlin: can you try running again with -Dtranport and see what sort of operations its doing?
[21:21] <jelmer> it should be writing to ~/.bzr.log
[21:22] <jelmer> jdahlin: 5 minutes is way more than it should be
[21:22] <jelmer> after the initial cache, push to a svn repository is often faster than push to a native bzr repository for me
[21:25] <jdahlin> jelmer, sure, but I'm down to 2:19
[21:29] <jelmer> jdahlin: that's still much more than it should be, unless your connection is really really slow
[21:31] <jdahlin> jelmer, here is the output of the relevant .bzr.log parts; http://rafb.net/p/V28F8H24.html
[21:31] <jelmer> jdahlin: thanks!
[21:32] <jdahlin> if I install python-curl I will get a certificate error
[21:33] <jelmer> you can use svn+https:// rather than https:// to work around that
[21:33] <jelmer> hmm, .bzr.log looks ok
[21:33] <jdahlin> oh, let me try that
[21:33] <jdahlin> it went pretty quickly the last time
[21:34] <jdahlin> but I forgot to time it
[21:34] <jelmer> it's not the amount of network traffic that will be problematic
[21:34] <jdahlin> I think it's the number of roundtrips.
[21:35] <jelmer> that's less than 50 I think, looking at this log file
[21:36] <jdahlin> jelmer, check this out, a snippet from strace: http://rafb.net/p/8wwViQ44.html
[21:36] <jdahlin> there's lots of socket/connect calls which shouldn't be there.
[21:37] <jdahlin> real	2m13.438s
[21:38] <jelmer> does using svn+https:// rather than https:// help?
[21:38] <jdahlin> not significantly
[21:41] <jelmer> the log says there should only be 4 TCP connections opened
[21:41] <jelmer> all the other stuff is done by the svn library
[21:42] <jdahlin> okay, so how can the svn library be told not open up so many connections?
[21:45] <hsn_> !apt
[21:45] <ubotu> APT is the Advanced Package Tool, which together with dpkg forms the basic Ubuntu package management toolkit. Short apt-get manual: https://help.ubuntu.com/community/AptGetHowto - Also see !Synaptic (Gnome) or !Adept (KDE)
[21:45] <jelmer> jdahlin: I don't think there is a way to do that atm :-/
[21:46] <jelmer> jdahlin: How many connect()'s are there in total in those 2 minutes?
[21:46] <jdahlin> jelmer, let me check.
[21:50] <jdahlin> jelmer, 78 calls
[21:50] <jdahlin> and that's just for changing one file
[21:51] <jdahlin> actually, some are dns lookups. It's only 73 to the remote host
[21:55] <Lo-lan-do> How can I "bzr diff" a current branch to a previous version of another one?
[21:55] <jelmer> jdahlin: 73 is still excessive. I wonder what's causing them; I'll see if I can reproduce it here.
[21:58] <Lo-lan-do> Ah: Sorry, diffing arbitrary revisions across branches is not implemented yet.
[21:59]  * Lo-lan-do makes a new copy of the remote branch
[21:59] <jdahlin> jelmer, Yes. I am trying to figure out myself which call might be causing it
[22:17] <Peng> Hey, one of my bzr bundles tops another popular Google search term:  'legal land description" Indiana  winamac
[22:25] <ubotu> New bug: #182140 in bzr "bzr-svn interferes with bzr operation" [Undecided,New] https://launchpad.net/bugs/182140
[22:32]  * Peng wanders off.