[02:49] <Kamping_Kaiser> gah. i just broke bzr-svn again
[02:52]  * Kamping_Kaiser slaps his wrist
[02:52] <jelmer> Kamping_Kaiser, hello
[02:53] <Kamping_Kaiser> jelmer: hi. seems 'OperationalError: database is locked' isn't caught. (i filed a bug, fwiw).
[02:53] <Kamping_Kaiser> and i admit the user deserves a screen full of backtrace if htey are silly enough to try and branch twice :p
[02:54] <jelmer> Kamping_Kaiser: to work around that, you can install python-tdb. the default cache is based on sqlite, which doesn't allow concurrent writers
[02:56] <Kamping_Kaiser> jelmer: ok, thanks :)
[07:16] <boybzr> hi guys
[07:16] <boybzr> i am wondering, i have a shared repository with multiple branches below
[07:17] <boybzr> i am making a new directory in it in which i just want to merge ALL the branches into (suppose we have no conflicts)
[07:17] <boybzr> in git, i do an octomerge
[07:18] <boybzr> in bzr, must i do this for every branch ? isn't that a LOT of extra commit msges ?
[07:22] <lifeless> boybzr: bzr merge --force will let you do octomerges
[07:22] <boybzr> lifeless: an example?
[07:23] <lifeless> bzr merge b1
[07:23] <lifeless> bzr merge --force b2
[07:24] <lifeless> bzr commit -m 'commit a merge of b1 and b2'
[07:24] <boybzr> i can also do this:
[07:24] <boybzr> bzr merge b3
[07:24] <boybzr> eek
[07:24] <boybzr> bzr merge --force b3
[07:24] <lifeless> yes
[07:24] <boybzr> bzr merge --force b4
[07:24] <boybzr> THEN commit yes?
[07:24] <lifeless> yes
[07:24] <boybzr> ok
[07:25] <boybzr> is there any way to do all of this together
[07:25] <boybzr> in one line
[07:25] <lifeless> you could write a wrapper, or a plugin
[07:25] <lifeless> there isn't a builtin way
[07:26] <boybzr> ok
[07:26] <boybzr> another question now
[07:26] <boybzr> say i play with my branches in my shared repository
[07:26] <boybzr> and i want to push to launchpad
[07:27] <boybzr> will pushing from branches residing in a shared repository pose a problem?
[07:29] <boybzr> aka, how launchpad gets correct history?
[07:41] <lifeless> no problem
[07:43] <boybzr> reading on stacked branches now
[07:52] <lifeless> that should be transparent to you; just make sure your trunk is marked as such on the series page in launchpad
[07:53] <boybzr> yeah noticing
[07:54] <boybzr> the gui tools look awesome as well
[09:22] <boybzr> alright, another question guys, if you can
[09:23] <boybzr> suppose i have to unrelated in ancestry repositories that at some point have to be merged into a new project, and i want to keep the history of both without starting from zero
[09:23] <boybzr> will such a merge happen cleanly and if not, will it bust future merges that are similar?
[09:25] <lifeless> generally works ok
[09:26] <boybzr> ok, how so
[09:26] <mgz> I'm about to go out for the day, but quick request lifeless
[09:26] <mgz> could you look at uploading testtools 0.9.5 for debian?
[09:26] <mgz> it fixes a few things I'd messed up in 0.9.4
[09:35] <lifeless> mgz: sure; was going to wait for the next release
[09:35] <lifeless> boybzr: what do you mean?
[09:56] <parthm> Hello. I am trying to branch into a certain directory on RHEL and its generating a TransportError EPERM. I am not sure what to make of it. I have permission and copy etc. works. http://pastebin.com/5tYFwhX7
[09:57] <parthm> The /data/dev in the paste is a mount.
[12:19] <maxb> jel
[12:19] <maxb> oops
[13:03] <ddaa> hey jelmer
[13:04] <ddaa> I just noticed "bzr init --subversion"
[13:04] <ddaa> I see that creates a local subversion repo
[13:04] <ddaa> What's the use case for that?
[13:04] <jelmer> ddaa: hi
[13:04] <jelmer> ddaa: Nothing in particular, it's just something that we get automatically if we hook in a new format
[13:05] <jelmer> and I guess it gives you the ability to avoid the svn command-line altogether
[13:06] <ddaa> I don't see a lot of point in creating a local repo and not hooking it into an actual subversion server.
[13:09] <jelmer> ddaa: I use a local svn repo quite often for testing, but you can also e.g. create a repo for the svn apache module
[13:10] <jelmer> What I mean to say is, just creating a svn repo somewhere can mean it's picked up by the svn apache module
[13:13] <ddaa> I see. Still, if could configure apache in this way, one needed enough knowledge of svn to know "svnadmin create"...
[13:13] <ddaa> Anyway, I understand it is not a designed feature. And I think it is possibly confusing.
[13:15] <ddaa> To try putting it out more clearly.
[13:16] <ddaa> "bzr init" is user operation, but "svnadmin create" is an administrative operation
[13:17] <ddaa> Most of the time, a svn repo is provided by a hosting service, or a sysadmin.
[13:18] <ddaa> Unless people start using local svn repos over network shares, but I shudder at the thought of it.
[13:18] <fullermd> Well, dunno about svn, but a fair number of my CVS repos were primarily accessed locally.  And the rest were all over ssh anyway, so...
[13:20] <ddaa> fullermd: thinking about it, local or ssh is just better than pserver
[13:20] <ddaa> but it's only becaus pserver is such a POS
[13:20] <fullermd> Yeah.  But had I gone down the svn garden path, I can't think why I'd have done anything differently.  So, no real server-admin type stuff necessarily involved in creating repos.
[13:21] <ddaa> I see.
[13:21] <ddaa> I remain unconvinced that "bzr init --subversion" is a good tradeoff between convenience and possible confusion.
[13:23] <ddaa> It looks to me like a feature that would be documented as "You don't really need to use that ever, but its presence is a side effect of the bzrlib architecture."
[13:24] <jelmer> While I can see the points both ways, I haven't come across any users who have actually used this option and confused by what it did.
[13:25] <jelmer> s/points/arguments/
[13:25]  * fullermd waits for `bzr init --rcs`...
[13:26] <ddaa> fullermd: is bzr turning into emacs? :-)
[13:26] <fullermd> I think it has to grow "bzr checkout INBOX" capability before that.
[13:29] <ddaa> jelmer: I'd bet the format options to init are almost unused in the real word. That does reduces the likelihood of this option causing confusion.
[13:29] <ddaa> fullermd: checkout, I don't know, but "bzr merge INBOX" would make some sense: as a complement to "bzr send".
[13:30]  * ddaa considers the question settled
[13:30] <ddaa> thank you jelmer
[13:31] <jelmer> ddaa: Thanks for your thoughts. I won't take action on this now, but I'll keep it in mind while we make more changes to the control directory infrastructure in Bazaar.
[16:06]  * maxb ponders syncing ~bzr/proposed into ~bzr-beta-ppa/ppa
[23:46] <anthony__> I was looking to get some help with a little ubuntu problem Im having