[00:51] <jam> beuno: I leave the debs up to you. If you can't get to it, that's fine. I uploaded the tarballs to launchpad, and updated the download pages
[00:58] <beuno> jam, np, I'll upload them in a few hours
[01:03] <fullermd> Hmm...
[01:03] <fullermd>  Source of the stable release for any platform
[01:03] <fullermd> 	
[01:03] <fullermd> bzr-1.5.tar.gz
[01:03] <fullermd> But above it, "The current stable version is 1.4, released May 02, 2008."
[02:58] <bignose> How does the recipient of a 'bzr send' apply the bundle to their branch?
[03:03] <spiv> bignose: "bzr merge FILE"
[03:07] <bignose> spiv: thanks. (I think I knew that, but forgot it :-)
[04:11] <Peng> So, how awesome is protocol 3?
[04:17] <Peng> Ohnoes, bzr claims my bzr+http server is still using protocol 2.
[04:17] <Peng> So it reconnects 3 times.
[04:31] <spiv> 3 times sounds excessive.
[04:32] <spiv> (Although "reconnection" doesn't really apply to bzr+http either)
[04:33] <Peng> It was just a "bzr info" too.
[04:34] <Peng> Oh wow.
[04:34] <Peng> My HTTP smart server script is busted.
[04:34] <Peng> And has been for a while now.
[04:34] <Peng> I messed up sys.path so it uses the system bzr instead of bzr.dev.
[04:36] <Peng> Ok, now it works.
[04:37] <bignose> Using the 'bzr-svn' plugin to connect to Subversion repositories over SSH, Bazaar attempts to connect *three times* for operations like 'push'.
[04:37] <bignose> Whereas to a Bazaar repository over SSH, just once.
[04:37] <bignose> porquois?
[04:38] <bignose> and how can I bring it down to just one connection?
[04:38] <bignose> s/attempts to connect/starts a new connection/
[04:47] <spiv> bignose: sounds like a bug in the bzr-svn plugin
[04:48] <spiv> You could workaround it by configuring OpenSSH to do connection sharing (the ControlMaster option in your .ssh/config, IIRC).
[04:49] <spiv> (Or if it's just typing a password three times that's bugging you, switching to using publickey auth and using a key agent)
[04:52] <Peng> Aww, the bzr-hello plugin is out-of-date.
[05:10] <bignose> spiv: which only works if the server is accepting public-key auth
[05:11] <bignose> spiv: which, in the wake of DSA-1571, some servers are not yet doing.
[05:12] <lifeless> fbond: its in the todo that bzr should allow thread reorganisation
[05:12] <lifeless> fbond: a cherrypick like that is a good mannual representation of wat bzr would need to do internally; a traceback is definitely an error
[05:12] <lifeless> fbond: could you please file a bug?
[05:21] <fbond> lifeless: Okay, let me see if I can reprouce.
[05:26] <fbond> https://bugs.launchpad.net/bzr-loom/+bug/231283
[05:26] <fbond> lifeless: I'm using loom pretty heavily, so there probably aren't many bugs that are getting by me :)
[05:42] <lifeless> fbond: great
[05:43] <fbond> lifeless: I can sense your excitement ...
[05:51] <pickscrape> Is --rich-root-pack safe/sensible to use now?
[05:55] <bob2_> should be safe, sensible if you need it (ie bzr-svn)
[05:56] <pickscrape> Other than enabling things that bzr-svn needs, does it provide any other user-visible advantages? (performance etc)
[06:02] <lifeless> no
[06:02] <lifeless> for now, only use it if you need it
[06:03] <lifeless> old bzr's interoperate with glitches with it and normal repositories, and itws a one-way conversion
[06:07]  * beuno starts packaging 1.5 for ppa
[06:10] <beuno> lifeless, you might have a good answer for this. Considering I can copy packages on LP PPA now, I should loose the ~distro1 bit of the version, upload one, and copy for the rest, right?
[06:39] <pickscrape> lifeless: thanks for the clarification. i'll stick with the default for now then :)
[07:32] <beuno> ok, 1.5 is in PPA, 'm off to bed
[07:50] <lifeless> beuno: no idea
[07:51] <lifeless> spiv: hi
[11:36] <gour> do i understand correctly that 'checkouts' can be useful in the situation when 'gatekeeper' is reviewing merge-bundles received from other developers and then wants to commit to the main branch on public server?
[11:39] <lifeless> yes
[11:41] <gour> (ub)bind mechanism is quite cool...man, i like bzr
[11:42]  * gour puts his ad-hat labelled 'Go bzr'
[11:44] <lifeless> :)
[11:45] <gour> too bad many are just looking time in benchmark tests...
[11:46] <lifeless> indeed, it is frustrating
[11:46] <gour> as i wrote on ml, bzr is *powerful* with *simple* model and *safe*
[11:46] <gour> but, i'm sure, it will change...
[11:47] <lifeless> which 'it' ? ;)
[11:47] <gour> don't know why, but hg does not offer (much) more, but is seems too complicated...i was reading (~0.97-98) the 'book', but didn't grok it
[11:48] <gour> the 1st one ;)
[11:48] <gour> too late for the 2nd one :-)
[12:01] <gour> what's the status of support for nestedtrees?
[12:02] <lifeless> coming along
[12:02] <lifeless> I think it will happen for real shortly after the windows line nding filteriting support ian is hacking on at the moment
[12:03] <gour> ohh...here one gets one (pleasant) surprise after another
[12:03] <gour> line-ending will make it for 1.6?
[12:04]  * gour is reading sharedrepositorylayouts docs
[12:05] <gour> ..where it says: "...because Bazaar supports (and recommends) creating repositories with no working trees" i understand that in DVCS environment i want to have working tree in my shared repo containing all required branches, but i do not want to have trees on the 'public' server...or do i miss something?
[12:07]  * gour is coming from darcs background and no shared repos, so he requires some time to adjust to new capabilities and choose the right layout :-/
[12:08] <Peng> gour: You sound correct.
[12:09] <bob2> I tend to have --no-trees everywhere, and work in lightweight checkouts from the local repository
[12:10] <gour> Peng: good. it sounds logical to have full repo locally
[12:11] <gour> bob2: what is advantage of that?
[12:12] <bob2> I use "bzr switch" a lot to switch the one checkout between multiple branches in the repo
[12:13] <gour> bob2: ahh, 'bzr switch' is not (yet) in my propsed toolbox
[13:31] <Jc2k> jelmer: bzr-svn question: does svn-import involve python-subversion (more importantly, does it leak the same as if i branch
[13:31] <Jc2k> )
[13:34] <jelmer> Jc2k, yes
[13:34] <jelmer> Jc2k, are you using the memory leak patch for python-subversion ?
[13:40] <Jc2k> jelmer: debian etch, so i have one patch i think
[13:40] <Jc2k> but as soon as i get into the > 5000 revisions, i run out of memory
[13:43] <jelmer> Jc2k: you should be able to pull incrementally, e.g. 1000 revisions at a time
[13:44] <Jc2k> ah, i've been doing 2000 at a time
[13:44] <jelmer> The Debian etch python-subversion package indeed doesn't contain the leak fixes
[13:45] <fullermd> 2000 won't work, 'cuz it's a leap year...
[13:45] <Jc2k> etch-backports perhaps..
[13:46] <Jc2k> i'll have a look later
[13:47] <Jc2k> i'm sure 1000 at a time will be fine for now
[14:05] <nekohayo> abentley: making the file ids match? how the heck do I do that? :)
[15:14] <gour> what is missing in bzr's cherrypicking with bzr merge -r X foo ?
[15:16] <jelmer> gour: Missing in what sense?
[15:16] <gour> is it this "...Bazaar does not currently track cherrypicks.." ?
[15:16] <bob2> it will confuse merge later on
[15:16] <gour> jelmer: i heard there are ideas to improve it
[15:16] <gour> bob2: thanks. confirmed
[15:19] <gour> bzr merge --uncommitted is a nice one...
[15:26] <gour> is there a real need for 'rebase' command (provided by plugin) ?
[15:34] <lifeless> no
[15:37] <gour> so, it's only for 'refugees' from dumber VCSs
[15:37] <gour> until they become accustomed to powerful bzr ;)
[15:52] <gour> hey, bzr commit can work with roundup tracker as well...surprise, surprise
[16:06]  * gour finished reading user-guide...it's time for user-reference
[16:24] <gour> now i see reference for bob2's style in the user-reference
[18:19] <ricardokirkner> hi. I am struggling with this for a while now. I want bzr to authenticate users for checkout and commit (like I had on a svn installation), but I don't want to have to setup a shell user account for each one of them. Actually, I already have all the users on a ldap directory. Could it be somehow possible to grant access to users authenticated through ldap, but without having to give those users shell access?
[18:19] <ricardokirkner> (that is actually how I am doing today.. svn authenticates to ldap, but the users cannot access shell on the server)
[18:20] <sabdfl> ricardokirkner: i'm not sure you need to grant shell access, you can setup a restricted login which only lets them run ssh
[18:20] <jelmer> ricardokirkner: svn uses LDAP via apache's mod_auth_ldap ?
[18:21] <ricardokirkner> jelmer,  actually through mod_svn_dav
[18:21] <ricardokirkner> and maybe mod_auth_ldap too , I am not quite sure on that
[18:22] <ricardokirkner> I have apache standard acl but pointing to an ldap branch (which I didnt create but someone else, that's why I am not sure on the details)
[18:22] <sabdfl> ricardokirkner: https://lists.ubuntu.com/archives/bazaar/2008q1/037100.html
[18:29] <ricardokirkner> sabdfl, thanks, I was just recently looking at the bzr_access tool, but that would require each user to have their ssh-key to be uploaded to the server, and thus use passwordless authentication, which is not exactly what I  was looking for.  besides, I would need to create a unique user that would hold all the ssh keys, right? and then I have to specify all my users ssh-keys in that users authorized_key file, right?
[18:31] <ricardokirkner> I can currently make my system authenticate users to ldap (via pam) but don't allow them login access,. I don't get why I need login access in order to push my changes
[18:31] <ricardokirkner> I also tried the bzr smart server, thinking that maybe the default transport (sftp) was actually trying to execute the bzr client on the server side, and that was the reason for it to require login access, but I got the same results
[18:34] <Peng> sftp doesn't execute the bzr client on the server side. It uses SFTP.
[18:34] <Peng> bzr+ssh does execute the bzr client on the server side.
[18:36] <ricardokirkner> Peng, thanks for clarifying that
[18:38] <Peng> If you're using bzr+ssh, I would think you do need logins: it basically sshes in and runs "bzr serve --inet --directory=/".
[18:38] <Peng> I dunno how SFTP works.
[18:41] <lifeless> Peng: sftp and ssh are the same as far as auth goes
[18:41] <lifeless> Peng: 'login' means 'have a shell account' - you don't need that for sfpt or bzr+ssh
[18:41] <Peng> Oh.
[18:41] <Peng> Okies.
[18:42] <Peng> Is "okies" annoying?
[18:43] <radix> who you callin' a oakie
[18:43] <ricardokirkner> lifeless, if you don't need a shell account for sftp or bzr+ssh, how comes I cannot checkout/commit/... when I have my shell set up to /bin/false?
[18:44] <lifeless> ricardokirkner: you need a sufficient shell to spawn bzr
[18:44] <lifeless> ricardokirkner: because of how ssh hands off its commands; thats what the bzr_access program does AIUI
[18:46] <ricardokirkner> but then, I need one user that has a valid login shell, in that users .ssh/authenticated_keys file I setup one line per developer pointing to the bzr_access file, and I need to have bzr_access.conf in my repo giving the current access for each developer, right?
[18:46] <lifeless> vila: rfc 2616 section 4.2 - I've quoted the relevant bit for you in bugmail
[18:46] <lifeless> ricardokirkner: that sounds plausible yes
[18:47] <ricardokirkner> now, when I do bzr co sftp://user@host/path/to/bzr/branch, I have to specify the user that has a valid login, right?
[18:47] <ricardokirkner> that seems like a lot of work
[18:47] <lifeless> hmm
[18:47] <Peng> Does bzr_access work with sftp?
[18:48] <lifeless> Peng: I wouldn't expect it too; I could be wrong
[18:48] <vila> lifeless: "Field names
[18:48] <vila>    are case-insensitive." ?
[18:48] <ricardokirkner> it is quite a turn down for people trying to migrate form another authentication scheme... (I am trying to convince my boss to migrate  from svn to bzr, but with so many hindrances, I am quite unsuccessful)
[18:49] <lifeless> vila: yup
[18:49] <lifeless> vila: field name -- header name
[18:49] <vila> so www.gnone.org is buggy. I will commit a patch working around the problem anyway.
[18:49] <lifeless> indeed
[18:50] <vila> lifeless: ok, the patch is one line code and ~20 comment lines of explanations :)
[18:50] <lifeless> ricardokirkner: so what you had with svn was a one time setup against ldap, and that was that ?
[18:51] <lifeless> ricardokirkner: and are you aware you can run bzr's smart server via http ?
[18:51] <lifeless> so you should b e able to use the same apache setup to authenticate users for bzr
[18:52] <ricardokirkner> lifeless, I am aware of bzr+http, but I cannot get it to give me write access
[18:52] <ricardokirkner> that is what this is all about
[18:52] <ricardokirkner> authentication through bzr+http is working perfectlyu
[18:52] <ricardokirkner> but the problem is I cannot write to the repo
[18:53] <lifeless> does the apache user have write permission?
[18:53] <ricardokirkner> I am using a bzr user for the smart server, and the apache user belongs to the bzr group, and the repo has group write permissions. that should be enough, right?
[18:54] <gour> ricardokirkner: talk to your boss about bzr's advantages ;)
[18:54] <MachinShin> hey guys q. trying to check out a project and i get "unable to create symlink", i'm on windows, seems there's a plugin: https://launchpad.net/bzr-win32symlinks  that can resolve it, but how do i install it?
[18:54] <lifeless> ricardokirkner: well, if apache is setuiding sure
[18:55] <ricardokirkner> gour, I have already been, but when it comes to the real life, and you spend about a week trying to reproduce the old setup and you don't get it (which might be my fault, I dont say its bzr fault), you cannot expect much credibility
[18:55] <lifeless> MachinShin: bzr --version will tell you the plugin directory - put the plugin in that directory with a simple name like 'win32symlinks'
[18:55] <gour> ricardokirkner: maybe it's time to 'upgrade' the old setup
[18:55] <lifeless> ricardokirkner: I'm happy to debug this from first principles; I can tell you my first guesses are one of two things:either bzr is not finding the smart server and is using http, or the back end user doesn't have write permission in the repoisotry
[18:56] <lifeless> gour: ricardokirkner seems to have head screwed on straight
[18:56] <lifeless> gour: more sysadmin overhead would not be a win on its own.
[18:56] <MachinShin> lifeless: ok thanks, i'll try that
[18:57] <ricardokirkner> lifeless, sorry for my bad english, but what does 'have head screwed on straight' mean?
[18:57] <gour> ricardokirkner: we pray that you succeed in adopting bzr
[18:58] <ricardokirkner> gour, I hope so too, for I am unwilling to give up, although it certainly drains one's energy
[18:58] <ricardokirkner> (to be unsuccessful)
[18:58] <gour> changing paradigms is never easy, but it pays off in the long run
[18:59] <MachinShin> annoying that it hasn't been integrated into bzr yet, the plugin is nearly 2 years old :/ seems like base functionality
[18:59] <lifeless> ricardokirkner: it means you are doing things well, sensibly
[19:00] <ricardokirkner> lifeless, well, thank you for that :-)
[19:00]  * beuno grumbles. I lost access to my server and, with it, access to several pings during the night
[19:00] <lifeless> MachinShin: win32 has several different symlink answers though;
[19:00] <beuno> vila, emails answered  :)
[19:00] <MachinShin> lifeless: ok, pick one then :)
[19:00] <lifeless> MachinShin: remember the link and don't make on disk, cygwin symlnks, .lnk files etc
[19:01] <vila> beuno: thanks, dinner time here, gotta go
[19:01] <Pilky> anybody have a clue how long it usually takes between a new version of bazaar being released and the OS X installer packages appearing?
[19:01] <lifeless> a day or so I think
[19:02] <Pilky> good good
[19:03] <MachinShin> lifeless: the cygwin solution this plugin uses seemed to work for me :)
[19:03] <MachinShin> anyways thanks for the help :) i'm good to go now
[19:09] <lifeless> ricardokirkner: so; first test, with bzr+http -
[19:10] <ricardokirkner> I am right at it...
[19:10] <lifeless> ricardokirkner: do soemething like 'bzr info -Dhpss bzr+http://YOURURLHERE'
[19:10] <lifeless> ricardokirkner: and check in ~/.bzr.log
[19:10] <ricardokirkner> ok
[19:10] <lifeless> if a hpss server is present, you will see debug details, about the time each command takes to run
[19:11]  * gour thinks that #bzr community rocks
[19:12] <lifeless> thanks :)
[19:13] <gour> as well as bzr itself ;)
[19:15] <ricardokirkner> lifeless, ok, I think I am getting closer to the problem. apparently it is seeing the smart server, but cannot find the repository, because it is constantly asking for the same location (although being told to descend  in the hierarchy). I think I have seen this issue in the past few days being mentioned. I am using bzr 1.4... maybe this was fixed in 1.5?
[19:18] <lifeless> 1.4 should work fine - you have 1.4 on client and server?
[19:19] <lifeless> feel free to pastebin the log message, it might help me be clear on what you are seeing
[19:19] <ricardokirkner> yes, just upgraded 1.5 in client, and was about to do the same on server
[19:20] <ricardokirkner> I get: BzrDir.find_repositoryV2', '.', which returns 'ok', '..', 'yes', 'no', 'no', but the next line is again BzrDir.find_repositoryV2', '.'
[19:20] <ricardokirkner> always to the same url
[19:20] <ricardokirkner> in (to ... )
[19:25] <ricardokirkner> lifeless, ok, this is actually a reported bug: #230550
[19:33] <Pilky> just had a friend ask me if there's any hosted services for bazaar similar to gitnub, anyone know of any (this is for private projects so launchpad is out)
[19:34] <Peng> Lau...oh, private.
[19:34] <Pilky> heh
[19:36] <lifeless> statik: ^
[19:37] <lifeless> bug 230550
[19:39] <lifeless> ricardokirkner: garh;
[19:40] <lifeless> ricardokirkner: I suspect its something reusing a smart medium rather than recreating, and normalising from the original path; or some such
[19:40] <lifeless> spiv: ^ for when you get up on Monday :)
[19:42] <lifeless> ricardokirkner: its bedtime for me; but if its not been looked at tomorrow I'll have a peek
[19:42] <ricardokirkner> lifeless, thank you very much for your help
[19:42] <ricardokirkner> goodnight :-)
[19:45] <lifeless> night :)
[19:55] <Peng> Anyone interested in making bzr-hello compatible with bzr.dev? :D
[20:11] <weigon> jelmer: does bzr-svn 0.4.9 work with bzr 1.5 ?
[20:12] <weigon> the ubuntu package says no
[20:12] <Peng> weigon: 0.4.10 does.
[20:14] <weigon> k
[20:15] <weigon> which brings us to:
[20:15] <weigon> bzr-svn: Depends: python-central (>= 0.6.6) but 0.6.5ubuntu1 is to be installed
[20:15] <weigon> taking jelmers .debs. from samba.org
[20:21] <gour> there is no wonder that someone is lifeless here if there are 423 bugs related to him
[20:41] <beuno> anyone around?
[20:41] <beuno> all ssh keys seem to get rejected in LP
[20:42] <Peng> Hey, you're right.
[20:47]  * gour wants to upload ssh key
[20:48] <Peng> Launchpad is broked right now. See #launchpad
[20:49] <gour> right, it behaves strangely
[21:33] <j^> http://launchpadlibrarian.net/14566578/bzr-1.5.tar.gz times out here, where can i find a copy of bzr-1.5.tar.gz?
[21:34] <beuno> j^, launchpadlibrarian is down
[21:34] <j^> and that is the only place i can find 1.5?
[21:34] <beuno> they're working in it
[21:35] <j^> great, hope its not all that big of a problem, good luck
[21:46] <beuno> j^, librarian es back up
[21:50] <j^> beuno, thanks
[22:17] <Pilky> I'm getting a little confused between init-repo and init, am I correct in thinking that all the former does is set up stuff to aid in performance and the latter is what creates the actual .bzr file and allows me to start doing version control
[22:18] <Pilky> s/file/folder
[22:19] <Peng> Pilky: init-repo creates a shared repository and init creates a branch. Both involve .bzr directories.
[22:20] <Peng> Pilky: But you're basically correct.
[22:20] <Pilky> ok, just double checking
[22:20] <Pilky> thanks :)
[22:21] <Pilky> and I could commit directly into a shared repository if I wanted?
[22:22] <radix> no, you can only commit to branches
[22:22] <Pilky> ok
[22:22] <radix> the branch will store the revision data in the shared repository, if there is one
[22:25] <Pilky> if I've just started version control on a project by doing init, can I create a folder, do init-repo and then move the existing project into that?
[22:25] <radix> Pilky: you should use 'bzr branch' to migrate the branch into the new shared repository
[22:25] <Peng> Pilky: Well, yeah, but it won't use the shared repo. 'bzr reconfigure' may be able to help.
[22:25] <ricardokirkner> radix, and what happens it the repo's .bzr folder suddenly disappears? is then the branch corrupt, and all data lost? or is it possible to recover it?
[22:25] <Pilky> ok, fair enough, thanks
[22:26] <radix> ricardokirkner: if you lose the shared repository's .bzr folder, then yes, you're up a creek
[22:26] <radix> ricardokirkner: that's where all the revision data is stored
[22:26] <Pilky> ricardokirkner: at that point you start doing backups ;)
[22:27] <ricardokirkner> yeah.. it was a curiosity. what is stored in the branches .bzr folder, when you have a shared repo?
[22:27] <ricardokirkner> i guess branch-only data... but the question is actually
[22:28] <ricardokirkner> whenever you commit something , the branch first asks the repo if that information is already shared and stores it in the repo (and otherwise in the branch) or how is that made?
[22:28] <Peng> ricardokirkner: A branch is basically just a list of revisions, and some configuration data (like the parent branch, where you push, etc.). A repo is a big pile of revisions, and it's what takes up all the disk space. Shared repos let multiple branches use the same repo, so if they're related, they don't duplicate the data.
[22:29] <radix> to be specific, a branch is just a list of revision IDs
[22:29] <Peng> Yeah.
[22:29] <Peng> (In fact, in recent formats, .bzr/branch just stores the most recent revision ID, and the rest of the data is figured out from there. But anyway...)
[22:30] <ricardokirkner> Peng, so actually all the data is stored in the shared repo, and the branch only holds the revision ids
[22:30] <Peng> ricardokirkner: Yes.
[22:31] <ricardokirkner> so that in the worst case, if a branch .bzr folder, it could (theoretcally) be reconstructed
[22:31] <ricardokirkner> if a branch .bzr folder is "lost"
[22:31] <Peng> ricardokirkner: Yeah, it could.
[22:31] <ricardokirkner> ok, i understand, thanks
[22:35] <pickscrape> What would be the pros/cons of bzr+ssh vs bzr+http?
[22:35] <pickscrape> Security being a non-issue since this would be on an internal network.
[22:35] <jelmer> weigon, no, you need 0.4.10 for bzr >= 1.4
[22:36] <ricardokirkner> pickscrape, from what I was trying out at our company, using bzr+http you can use ldap authentication without having to have a shell account for each user
[22:36] <ricardokirkner> on the other hand, ssh is more secure, but you say that doesn't matter to you
[22:37] <pickscrape> And are you able to use standard apache configuration directive to, say restrict certain users to certain branches etc?
[22:37] <ricardokirkner> generally speaking, I think using bzr+http gives you more authentication options
[22:37] <weigon> jelmer: and the py-central dependency in your .deb packages ? is that a must ?
[22:37] <pickscrape> Any experience on the performance differences between the two?
[22:37] <weigon> you require 0.6.6, ubuntu hardy has 0.6.5
[22:37] <ricardokirkner> pickscrape, I think it might be possible, but you will have to try it out
[22:38] <pickscrape> Oh yes, I have a lot of experimentation to do :)
[22:38] <ricardokirkner> pickscrape, no
[22:38] <pickscrape> Always handy to be armed with as much knowledge as you can though before wading in...
[22:38] <ricardokirkner> :-)
[22:38] <ricardokirkner> I was having this issue the whole week with bzr+http
[22:39] <ricardokirkner> and I just found out that it wasn't working because some bug introduced in bzr 1.4
[22:39] <ricardokirkner> so you have to be careful
[22:39] <ricardokirkner> bzr+http is somewhat buggy
[22:39] <pickscrape> I'll keep that in mind.
[22:39] <jelmer> weigon, It's added by python-central itself
[22:39] <ricardokirkner> I mean, not so well tested as bzr+ssh
[22:40] <pickscrape> I'm mostly concerned with which one gives the best performance and authentication options
[22:40] <jelmer> weigon: it's not there in the source package
[22:40] <pickscrape> I can imagine that ssh might have more overhead (logging in, starting shell, encryption etc)
[22:40] <jelmer> weigon: you should be able to just rebuild the package to get rid of that dependency
[22:41] <weigon> jelmer: ok, I'll build the package from source there
[22:41] <weigon> yep
[22:42] <ricardokirkner> pickscrape, I imagine that too... but I wouldn't worry too much about that, since bzr is inherently slow
[22:42] <ricardokirkner> so I don't think that any option would provide significant improvements
[22:43] <Peng> If for some reason you're using knits and don't want to upgrade to packs, hpss makes a huge difference.
[22:43] <message144> Hi.. Just curious about something. I am considering switching my project to bzr. I read an article that said that bzr has not really experienced wide project adoption except for Ubuntu. I am curious if there are any opinions as to why this is the case?
[22:43] <j^> is there something like svn:externals in bzr by now?
[22:44] <Peng> j^: It's in progress.
[22:45] <Pilky> message144: I was reading something earlier about how there were quite a few largish projects that used it but moved away due to early performance problems
[22:45] <Peng> Yeah. Bazaar lost out on the big projects (OpenSolaris, Mozilla) due to performance.
[22:45] <Peng> It's getting better all the time, and is definitely good enough for non-huge projects though..
[22:45] <message144> hmm.. performance is the least of my concerns
[22:45] <Pilky> it's still not the fastest now, though I'd take an extra second or two to execute a command over having to try and wrap my head around git
[22:46] <Peng> In some specific areas, I think it is the fastest, or at least really close.
[22:46] <Peng> But generally not.
[22:46] <message144> My biggest concern more than anything else is community support, ease-of-use, then data integrity
[22:46] <Pilky> message144: I believe drupal uses bzr
[22:46] <message144> perfromance is lowest on my list of priorities
[22:47] <ricardokirkner> well, I must say, community support is superb
[22:47] <ricardokirkner> :-)
[22:47] <pickscrape> Yes, I've been very pleased with the community support.
[22:48] <pickscrape> I'm not scared of asking 'silly' questions like I was in the git community.
[22:48] <j^> is i have an svn branch is there any chance bzr-svn would pick that up so the two bzr repositories would have a common ancestor?
[22:48] <message144> yeah i felt pretty stupid asking some pretty basic stuff in #git
[22:48] <message144> heh
[22:49] <Pilky> message144: also, while it's not big in terms of code, the Sparkle update system for the Mac moved over to bzr a little while ago
[22:49] <jelmer> j^: can you rephrase perhaps? I don't really understand what you mean
[22:49] <weigon> jelmer: dpkg-buildpackage -uc -b ... works as expected, thx
[22:50] <Peng> j^: If two people use bzr-svn to branch from svn, the two bzr branches will be related.
[22:50] <j^> jelmer, i started a branch in svn, now i checkout trunk and the branch via bzr-svn the bzr repository of the branch only starts at the point of the last svn copy
[22:51] <j^> if bzr-svn would also checkout the things before the copy they should have a common root
[22:52] <jelmer> j^: it should follow copies of the branch root - is that what you mean?
[22:53] <j^> with bzr-svn 0.4.10 it stops here i.e. bzr branch https://svn.xiph.org/branches/theora-thusnelda has only  83 revisions
[22:55] <jelmer> j^: /trunk/theora is not considered a branch so it's not made part of the history
[22:55] <j^> those are all commits that happened in the branch. the branch was started with svn copy trunk/theora branch/theora-thusnelda
[22:55] <jelmer> if it was copied from /trunk or /branches/foo, it would've followed the copy
[22:56] <jelmer>  /trunk/theora not being considered as a branch is bug 130372
[22:57] <j^> ic
[22:58] <j^> otherwise the new version works great