[00:01] <jelmer> enigma42, sorry, back now
[00:01] <jelmer> enigma42, see privmsg
[00:04] <jelmer> enigma42, sorry you seem to be hitting the jackpot of bzr-svn bugs :_(
[00:05] <enigma42> jelmer: :-) No problem.
[00:05] <enigma42> jelmer: I'm happy to report them so they won't be bugs anymore. :-D
[00:06] <jfroy|work> might have seen this issue before myself
[00:06] <jfroy|work> somewhat curious about it
[00:06] <jfroy|work> I'm still using my alternate prefix hack to work around possibly invalid bzr-svn properties :/
[00:07] <jelmer> jfroy|work, is there a bug open about that?
[00:07] <jfroy|work> jelmer: never investigated in depth the problems. It's more of a speculative hack, in the sense that I used early versions of 0.5 at some point which may have written now-invalid properties.
[00:08] <hughesw> it's really odd, old old versions of bzr-svn can pull down from this repo without issue (0.4.9 in hardy for instance) but 0.4.16 crashes when making local branches and it looks like enigma42's got 0.5 crashing on the actual svn branch
[00:08] <jfroy|work> Until and if I can dump and reload the repository, there's no much else to be done.
[00:11] <jelmer> jfroy|work, can you send me that hack? Should give me some idea as to what's going wrong?
[00:12] <jfroy|work> jelmer: it's nothing like that. I merely changed the prefix from bzr to bz2, such that all previous bzr-svn attributes, including the potentially invalid alpha 0.5 ones, are effectively ignored.
[00:12] <jfroy|work> Been using the last build of 0.4 for months with that modification without any issues.
[00:14] <enigma42> jfroy|work: That hack is clever...I was wondering what I might be able to do for bad 0.4.x metadata.
[00:19] <jfroy|work> enigma42: yeah, it worked remarkably well.
[00:19] <jfroy|work> Forces people interfacing with that repository to use a custom branch of bzr-svn.
[00:19] <jfroy|work> A better solution would be to add a property that bzr-svn could check first, say bzr:bzr-svn-prefix
[00:20] <jelmer> jfroy|work, any chance you can try again with a vanilla bzr-svn 0.5 ? It would be nice to get this sort of thing fixed before 0.5.0
[00:20] <jfroy|work> which it would read from the most recent revision. That way, the prefix for all clients could be changed by the repository itself, versus a code change.
[00:20] <jfroy|work> jelmer: I'll give it a try.
[00:21] <jfroy|work> What's your release schedule? I should get enough time to do a useful test next week.
[00:21] <jelmer> Before the end of january basically
[00:24] <jfroy|work> That's pretty tight, might not be able to generate good enough data. But we'll see.
[00:24] <jfroy|work> I'll try to live a few days on mainline 0.5, and hopefully any issues will pop up.
[00:25] <jfroy|work> Note that this isn't a case of just migrating from 0.4 to 0.5. The svn repository involved has pre-release 0.5 properties as well.
[00:25] <jelmer> jfroy|work, Just doing a clone with bzr-svn should demonstrate that problem if you've hit it in the past
[00:26] <enigma42> jfroy|work: I've been living on mainline 0.5 since mid-december. It's been good!
[00:26] <enigma42> jfroy|work: revprops are the best!
[00:27] <enigma42> jfroy|work: I was just able to fixup a metadata error this morning because I'm using revprops now.
[00:35] <jfroy|work> enigma42: sadly the svn server we're using is still 1.4
[00:35] <jfroy|work> no revprop for me :|
[00:38] <enigma42> jfroy|work: We have a 1.4 server, but revprops are enabled.
[00:38] <jfroy|work> oh?
[00:38] <jfroy|work> I could have sworn that was a 1.5 feature
[00:38] <enigma42> Yeah.
[00:38] <enigma42> Well, we're hosted on collabnet.
[00:39] <jfroy|work> Secret sauce huh
[00:39] <enigma42> I guess.
[00:39] <jfroy|work> bzr-svn is using properties on the root directory of branches, at least as far as I can tell.
[00:40] <jelmer> jfroy|work, yes
[00:40] <jfroy|work> on my repository, I mean
[00:40] <jfroy|work> so they're not revprops. AFAIK Trac doesn't display revprops anywhere in its SCM browser module.
[00:42] <jelmer> jfroy|work, I'm not sure what causes a server to support revision properties during commit
[00:42] <jelmer> jfroy|work, bzr-svn just looks at what capabilities the server has
[00:42] <jfroy|work> jelmer: neither am I
[00:43] <jelmer> maybe a later 1.4 point release?
[00:47] <enigma42> Since it's on collabnet, it could be some special svn code.
[00:53] <LaserJock> anybody know if there's a branch format/bzr version chart or table?
[00:55] <enigma42> I just read "bzr help upgrade"
[00:56] <nDuff> "bzr help formats", "bzr help current-formats" and "bzr help other-formats" should be helpful; I don't know about a table.
[00:58] <nDuff> ...both current-formats and other-formats include information on when the given formats were introduced
[00:58] <LaserJock> nDuff: I don't have either of those
[00:59] <LaserJock> just bzr help formats
[00:59] <LaserJock> a table would be nice though, to decide whether to upgrade or not
[00:59] <nDuff> in current versions, "bzr help formats" has textual guidance on whether to upgrade
[01:00] <nDuff> ...it's also in a mailing list post somewhere, and I should be able to do a quick pastebin...
[01:00] <nDuff> http://pastebin.ca/1316514
[01:02] <LaserJock> hmm
[01:02] <LaserJock> that's sort of helpful
[01:02] <LaserJock> but it kind of assumes you standarize around a bzr version
[01:03] <LaserJock> rockstar: around?
[01:04] <rockstar> LaserJock, yes, but my wife is hungry, so not for long.
[01:04] <rockstar> What's up?
[01:04] <LaserJock> rockstar: do you know of any plan to have downloadable tarballs of bzr revisions?
[01:05] <LaserJock> rockstar: seems like that would really speed up "branching" in some cases
[01:05] <rockstar> LaserJock, what do you mean?
[01:05] <rockstar> Do you want just a tarball of the current up to date bzr branch's working tree?
[01:05] <LaserJock> rockstar: meaning, like github, you could select a revision and LP would give you a tarball to download
[01:06] <LaserJock> no, not the working tree, the .bzr
[01:06] <rockstar> Someone asked a question about that recently, but we hadn't talked about it at all.
[01:06] <LaserJock> k
[01:06] <rockstar> LaserJock, I don't see where the speed up really is there.
[01:06] <LaserJock> just struck me as I sit here for an hour trying to branch something ;-)
[01:06] <rockstar> Either way, you're downloading it.
[01:06] <rockstar> LaserJock, what are you trying to branch?
[01:07] <LaserJock> yeah, but bzr is a lot slower than just rsync/wget a tarball of .bzr
[01:07] <LaserJock> rockstar: lp:gnome-app-install
[01:07] <rockstar> LaserJock, it's taking you an hour to branch 637 revisions?
[01:08] <LaserJock> something like that
[01:08] <LaserJock> I'm not timing well
[01:08] <LaserJock> I need to alias bzr to time bzr :-)
[01:09] <rockstar> LaserJock, hm, I suspect there's something amiss here.  Without a shared repo, I can branch 1000 revisions relatively quickly.
[01:09] <LaserJock> it's because it's in an ancient format I believe
[01:09] <rockstar> LaserJock, ah, that might be.
[01:09] <LaserJock> I seem to always hit on those
[01:09] <LaserJock> I don't understand how I end up so cursed with bzr
[01:10] <LaserJock> just my lot in VCS-life I guess :-)
[01:10] <LaserJock> rockstar: can I do one of these new stacked branch thingies with it?
[01:10] <LaserJock> or does the repo have to be in a certain format for that
[01:10] <rockstar> Not if it's in an ancient format.  You need 1.6 or better.
[01:11] <jelmer> jfroy|work, YOu had installed subvertpy manually as well right?
[01:11] <LaserJock> man, I can't tell if it's frozen or something
[01:11] <LaserJock> the "wheel" isn't spinning or anything
[01:13] <rockstar> Yea, bzr does have issues with demonstrating it's actually doing something.
[01:22] <enigma42> jelmer: Does "bzr svn-upgrade" move everything to revprops if possible?
[01:23] <jelmer> enigma42, nope. There is a svn-set-revprops command that intends to do that, but it's hidden, experimental and doesn't have a testsuite yet.
[01:23] <enigma42> OK.
[01:24] <enigma42> Yeah, it will be nice to retrofit my svn repos to only use revprops.
[01:24] <jelmer> enigma42,  bzr-svn will at least only use revprops for new revisions
[01:24] <enigma42> Ignore some of that crufty data stuck in file properties.
[01:25] <enigma42> jelmer: New error
[01:25] <enigma42> jelmer: bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0xa41c8ac> has delta references to items not in its repository:
[01:25] <jelmer> :-( Please pastebin
[01:25] <enigma42> OK
[01:26] <enigma42> jelmer: Oh...the branching worked great, BTW.
[01:26] <enigma42> This was after branching from SVN was over.
[01:26] <jelmer> ah, this is running "bzr check" ?
[01:26] <enigma42> I did a local branch.
[01:26] <enigma42> bzr branch svn-branch local-branch
[01:26] <enigma42> specifically: bzr branch des-dw-harmony foobar
[01:28] <enigma42> http://pastebin.ubuntu.com/108822/
[01:29] <enigma42> My coworker tells me he's been seeing this error since he upgraded to bzr-svn 0.4.17 on Monday.
[01:29] <enigma42> Actually...correction.
[01:29] <enigma42> (03:24:58 PM) hughesw: monday. after updating to bzr 1.10 and bzr-svn 0.4.16 from the package on the bazaar site.
[01:29] <enigma42> bzr-svn 0.4.16
[01:30] <hughesw> yeah...
[01:30] <hughesw> there's some revisions from a local branch that don't seem to have been pushed up to the repository
[01:34] <hughesw> I can see the hughesw@hughesws2k8-20090121211631-kx8io79zatxfxjhc commit ID in my local trunk on my work machine, but it's not in the repository.
[01:34] <jelmer> enigma42, what happens if you run "bzr check" in the original branch?
[01:34] <hughesw> jelmer: when I did that with 0.4.16 it crashed on me.
[01:34] <jelmer> hughesw, with what error?
[01:35] <hughesw> let me check again
[01:35] <jelmer> similar to the one pasted above?
[01:35] <hughesw> sorry, the error's on a different machine, reproducing it here real fast.
[01:36] <enigma42> jelmer: ...still running bzr check...
[01:37] <enigma42> jelmer: see privmsg
[01:38] <enigma42> This concerns me:
[01:38] <enigma42>     20 ghost revisions
[01:38] <enigma42>     20 revisions missing parents in ancestry
[01:38] <enigma42>     12 inconsistent parents
[01:38] <jelmer> ghost revisions are not necessarily bad, they are just revisions to which there are references but that are not present in the repository
[01:38] <hughesw> check crashed on me again
[01:39] <hughesw> I privmsg'd you jelmer
[01:39] <jelmer> hughesw, thanks
[01:39] <hughesw> it also crashes on 0.4.17 with the same message
[01:39] <enigma42> jelmer: Oh...fwiw: I'm on bzr 1.11 with bleeding edge 0.5
[01:39] <hughesw> since I updated to that with my home machine after it died the first time
[01:45] <jelmer> lifeless, ping
[02:20] <hayalci> Hi, I think it would be great if bazaar web page stated bazaar hosting options, like launchpad and savannah.
[02:21] <hayalci> That info is presented nicely on git web site and it probably makes an impact
[02:21] <Peng_> jelmer: FWIW, the repo from my old bzr-svn import said there was one ghost. The new one says there are no ghosts, but 158 inconsistent parents. :)
[02:21] <Peng_> Inconsistent parents should not be created anymore, should they?
[04:32] <lifeless> jelmer: jo
[04:32] <jelmer> lifeless, in this error: http://pastebin.ubuntu.com/108822/
[04:33] <jelmer> what are the "delta references" ? The delta parents ?
[04:33] <jelmer> hi, btw :-)
[04:33] <lifeless> they are basis texts for delta compression
[04:34] <jelmer> so how can that error occur if that branch was created by just calling VF.add_lines() ?
[04:34] <lifeless> should be impossible
[04:34] <lifeless> unless its stacked; there was a bug in stacking at one point
[04:36] <lifeless> could be a bug in the checking code I guess if it is checkin graph not delta fields
[04:36] <jelmer> yeah, that's what I'm wondering
[04:36] <jelmer> since the text revisions there are from a ghost revision
[04:36] <jelmer> but the texts are actually there
[06:29] <jfroy> how does one setup a remote branch so people that bzr send to it will get an email automagically?
[06:29] <jfroy> I thought it would be enough to have an email setting in a properly configured localtions.conf section, but apparently not.
[07:51] <jfroy> Ok, the setting in questionis child_submit_to
[07:52] <jfroy> Doesn't seem to be a way to bulk set it on a group (or directory) of branches :|
[11:18] <mikey_p> got a question about the internal workings of bzr+ssh, how does the directory to serve get passed to the remote machine?
[11:19] <mikey_p> i.e. if I do bzr branch bzr+ssh://hostname/path/to/file all that gets passed to remote server as an ssh command is "bzr serve --inet --directory=/ --allow-writes"
[11:20] <mikey_p> how does path/to/file get passed to the remote machine?
[11:37] <fullermd> Over stdin after the server starts up.
[12:12] <mikey_p> fullermd: then why the empty directory arg at startup?
[12:25] <fullermd> Because serv takes an arg describing how high in the tree it's allowed to go.
[12:27] <dereine> is there a tutorial how to use bazaar for web development automatic update of the checkout on a test server, which has only ftp acess
[12:56] <AfC> dereine: not sure you need a tutorial for that. Just try doing it. Should work. You _might_ find the bzr-upload plugin of value.
[13:17] <fullermd> Oh, there's training involved.  It takes some practice to get just the right angle for yanking out the fingernails of whoever setup a server with only FTP access.
[14:19] <etenil> Hi there
[14:20] <etenil> I'm used to subversion and just switched to bazaar
[14:21] <etenil> I usually stored the stable releases of my projects as tags in the subversion directory, but I don't find the equivalent in bzr
[14:21] <Peng_> "bzr tag"?
[14:21] <etenil> really?
[14:22] <etenil> I didn't see that in the doc
[14:22] <Peng_> Bazaar supports tags, but they aren't implemented as directory copies as in Subversion.
[14:22] <etenil> Oooooohhhh
[14:22] <etenil> I've got the one paragraph
[14:22] <etenil> seems I overlooked it ^^
[14:23] <etenil> thanks a lot Peng_
[14:23] <Peng_> :)
[14:23] <etenil> er, that's a big documentation, for once I can't complain ;)
[14:25] <jelmer> jfroy, child_submit_to is what you're looking for
[14:25] <etenil> is it possible to fix a bug in a tag too
[14:25] <Peng_> etenil: What? You can tag any revision you want to?
[14:26] <etenil> I mean, if I make a stable release and then work on the next one. If I make a security fix on the stable one (tagged), how should I proceed then?
[14:27] <etenil> if I commit the fixed old one, it's gonna interfere with the development of the new version.
[14:29] <Peng_> "bzr branch -r tag:foo-1.2.3 foo.dev fix-vuln; cd fix-vuln; hackhack; bzr commit; bzr tag foo-1.2.3.1; cd ../foo.dev; bzr merge ../fix-vuln", maybe?
[14:31] <etenil> thx peng_
[14:31] <etenil> i'll have a further look.
[15:22] <kfogel> I'm having a conversation with a GNU/Savannah admin over at https://savannah.gnu.org/support/index.php?106612, about converting the Emacs project over from CVS to bzr (which Emacs has decided to do, but hasn't actually done yet).  The admin says: "Given that bzr works on top of sftp, what's the point in having bzr even installed at Savannah?"
[15:23] <Peng_> kfogel: To make it faster?
[15:23] <LarstiQ> kfogel: administration and speed
[15:23] <kfogel> I'm kind of new to bzr, so I'm not sure I understand that.  Does he mean that bzr clients can upload bundles (or something?) via sftp, and there need be NO bzr running on the server end?
[15:23] <kfogel> Peng_, LarstiQ: thank you.  So one *can* do it the way he says, but it's inefficient?
[15:24] <Peng_> kfogel: Sure, using plain old SFTP as the server works perfectly; it's just not as fast.
[15:24] <kfogel> what kind of speed difference are we talking about?
[15:25] <Peng_> I don't know. A lot of operations still don't take advantage of the smart server, making them almost as slow as SFTP.
[15:25] <LarstiQ> kfogel: it varies with what exactly you are trying to do. But 'dumb' transports like sftp are used with only vfs operations like open(), stat(), read() and write(), on a .bzr level
[15:26] <LarstiQ> kfogel: whereas with bzr on the server (bzr+ssh or as a daemon) you can do things like 'Branch.last_revision_info'
[15:26] <kfogel> So there's a feature difference too?
[15:26] <Peng_> kfogel: No.
[15:26] <LarstiQ> well
[15:26] <LarstiQ> there is, but not on this level
[15:27] <LarstiQ> kfogel: I personally use sftp a lot.
[15:27] <kfogel> Uh.
[15:27] <kfogel> Would you ever recommend the sftp method for people who are *not* (and are not going to be) bzr experts?
[15:27] <kfogel> :-)
[15:27] <LarstiQ> kfogel: the main feature difference is that you can not run server side hooks with sftp, but you can when bzr is on the server
[15:27] <Peng_> kfogel: It's faster to have the server read the files and send back the data you want than for the client to read the files over the Internet, even if the same information can be obtained either way.
[15:27] <kfogel> I'm not referring to myself, but to the Savannah admins.
[15:28] <kfogel> Peng_: makes perfect sense -- thanks.
[15:28] <kfogel> LarstiQ: okay, good to know.  We do, in fact, need to run server-side hooks.
[15:28] <kfogel> So sftp-only is a non-starter.
[15:29] <LarstiQ> kfogel: my advice to the Savannah admin would indeed be to offer more than sftp-only, even though I get the 'no work for me' appeal as a sysadmin ;)
[15:29] <kfogel> heh, sure :-)
[15:29] <LarstiQ> kfogel: git afaik, but hg certainly, can also use dumb transports. But the users will lynch you if you are not running the daemon, since it is utterly slow otherwise.
[15:30] <LarstiQ> kfogel: if he needs help btw, I'm willing to offer it
[15:30] <kfogel> I seriously wonder why the tools even offer these options.  It's not worth the confusion to non-expert users.
[15:30] <kfogel> LarstiQ: wow, thank you
[15:31] <Peng_> LarstiQ: AFAIK, hg only supports dumb HTTP, not SFTP.
[15:31] <Peng_> And the HTTP is probably read-only.
[15:31] <LarstiQ> kfogel: you'd be surprised at the amount of users that only have an FTP server available to them :/
[15:31] <kfogel> LarstiQ: if you are really interested (and this may mean a serious commitment), privmsg me your email addr and I'll make sure the Savannah admins have it.
[15:31] <LarstiQ> kfogel: how serious a commitment?
[15:32]  * LarstiQ does already have a fulltime job
[15:32] <kfogel> LarstiQ: I don't know, really.  Maybe I'm being overly dramatic -- possibly Savannah just needs someone they can consult.
[15:32] <Peng_> LarstiQ: The goons with black ski masks are already on their way to kidnap you. ;)
[15:32] <LarstiQ> Peng_: hah! :P
[15:32] <kfogel> LarstiQ: anyway, as a volunteer, you don't need to do more than you have time for, obviously.  So it's up to you!
[15:34] <LarstiQ> kfogel: any irc channel I could hang out in?
[15:37] <kfogel> LarstiQ: most of the activity is on the emacs-devel@gnu.org mailing list and on that bug ticket I referred to earlier.  The ticket has mail links.
[15:37] <LarstiQ> ok
[15:39] <LarstiQ> kfogel: I see the admin would also like a loggerhead init script
[15:40] <Peng_> There is a Loggerhead init script.
[15:40] <LarstiQ> Peng_: afaik that does not use server-branches?
[15:40] <kfogel> LarstiQ: I'm about to let him know that you're offering some help.
[15:40] <LarstiQ> kfogel: and I'm happy to see it's Debian based, I'll feel right at home ;)
[15:43] <Peng_> It uses serve-branches.
[16:05]  * LarstiQ tries the last attempt at fixing the router
[16:05] <jelmer> Peng_, It doesn't abide by the Debian/Ubuntu policy though, so I ship a different one in the Debian package
[16:07] <Peng_> jelmer: Oh? What's wrong with it?
[16:10]  * jelmer looks for the list of problems he sent earlier
[16:10] <jelmer> Peng_, Doesn't use start-stop-daemon but sudo, doesn't use the pidfile but greps through the process list (potentially killing user-started loggerhead processes), doesn't use /etc/default/loggerheadd but requires configuration in /etc/init.d/loggerheadd, init script blocks, assumes that if something is running on the configured loggerhead port it is loggerhead, ...
[16:11] <Peng_> Heh.
[16:12] <Peng_> Oh, your script uses start-loggerhead though.
[16:22] <Lo-lan-do> I may have missed some context, but there's a branch with a mostly correct (if crude) initsript at http://bzr.debian.org/loggerhead/users/lolando/loggerhead/daemonise
[16:26] <Peng_> Ergh, *another* one?
[16:28] <Peng_> Someone needs to throw all of the Loggerhead init scripts in a blender and make a perfect one. :D
[16:32] <jelmer> Peng_, Well, basically the equivalent of the Debian one that uses serve-branches instead of start-loggerhead
[16:33] <jelmer> Lo-lan-do, I hope to merge yours once start-loggerhead is removed upstream and serve-branches has its own configuration file
[16:33] <Peng_> Oh, ok.
[16:35] <LarstiQ> so now we need someone to act as upstream.
[16:36] <jelmer> beuno, IIUC this is what upstream intends to do
[16:36]  * jelmer wonders if beuno is around
[16:40] <beuno> jelmer, I'm really *not* here
[16:40] <beuno> but
[16:40] <beuno> serve-branches will have a config file soon
[16:40] <beuno> and we will kill start-lh for evar
[16:40] <jelmer> \o/
[16:40] <beuno> and merge whatever you guys thing is the best deamonizer
[16:40]  * Lo-lan-do cheers
[16:41] <beuno> now, back to not being here...
[16:41] <Lo-lan-do> This is not the beuno you are looking for.
[16:41] <beuno> :)
[16:41] <fullermd> We're all right there not with you on that!
[19:24] <dereine> how can i pull and overwrite to the current state at a remote branch?
[19:29] <jelmer> dereine, bzr pull --overwrite
[19:31] <dereine> thx
[20:08] <LarstiQ> jelmer: could pkg-bazaar-maint receive less spam maybe?
[20:08] <jelmer> LarstiQ, how?
[20:08] <jelmer> I'm all for it :-)
[20:08] <LarstiQ> jelmer: disallowing non-subscribed posters?
[20:08] <LarstiQ> or does that raise the bar unacceptably for drive by contributions
[20:09] <LarstiQ> or maybe the spammers are already subscribing?
[20:41] <jelmer> LarstiQ, yeah, that may be a good idea
[22:30] <Goosey> hello. I am looking to use a DVCS as a local tool in an SVN environment, for ramping local changes/branches prior to SVN committing them. I am on windowsXP. Bazaar's good svn support and windows packages led me to give it a try, but I am having some issues.
[22:31] <Goosey> If I do any local commits and then pull commits from the SVN repo, when I try to push I cannot and am advised to rebase
[22:31] <Goosey> I installed the rebase plugin, but using it says there are no changes to rebase.
[22:32] <Goosey> So I am a bit confused to what I am doing wronge or where to go next. :)
[22:32] <Lo-lan-do> When you do local commits, you shouldn't normally be able to pull from SVN.  Did you mean you merged from SVN instead?
[22:33] <Goosey> No, I mean 'bzr pull'
[22:34] <Lo-lan-do> Maybe I'm missing something, but I think you can't pull when there have been commits both locally and remotely since the last common ancestor.
[22:37] <Goosey> i am sorry, you are right. 'bzr pull' warns the branches have diverged, so i use 'bzr merge' to pull the changes in
[22:37] <Goosey> and then a 'bzr commit' to commit the merge results
[22:38] <Goosey> and finally 'bzr push' to the svn repo, which is where I get the 'please rebase' error
[22:39] <Lo-lan-do> I see.  I don't know exactly how to fix that, but you may consider using another workflow that seems to work for me.
[22:39] <Goosey> ok, which workflow do you use?
[22:39] <Lo-lan-do> I have a bzr branch bound to svn, and other "floating" bzr branches based on it.
[22:40] <Lo-lan-do> When I need to push stuff from a local branch to SVN, I merge that branch into the svn-bound branch and commit.
[22:41] <Lo-lan-do> I do bzr update from time to time in the svn-bound branch to bring it up-to-date with what's in svn, and push or merge into the others according to the situation.
[22:47] <Goosey> hmm i gave this setup a try but ran into the same issue, Lo-lan-do
[22:48] <Lo-lan-do> Then I'm afraid I'm not enough of a bzr guru to be of significant help :-/
[22:48] <Goosey> I did a SVNRepo bound branch 'A' and branched from that 'B'. Then I made some local commits into B, made some SVN repo commits from elsewhere, pulled those into A, merged those into B, and commited B, and on pushing B the error :/
[22:48] <Goosey> am I missing a subtlety of how your workflow works?
[22:49] <Lo-lan-do> Try merging B into A (or pulling) instead of pushing maybe.
[22:51] <Goosey> ok that worked
[22:52] <Goosey> iiiinteresting
[22:54] <Lo-lan-do> I'll leave you with the wizards for the explanation, but in the meantime at least you can commit :-)
[22:55]  * Lo-lan-do → sleep
[22:55] <Goosey> enjoy sleep :_)
[23:36] <cody-somerville> Hey
[23:36] <cody-somerville> I can't install bzrtools from the bzr ppa
[23:36] <cody-somerville> bzrtools: Depends: bzr (< 1.11~) but 1.11-1~bazaar1~hardy1 is to be installed