[00:07] <awmcclain> Done.
[00:12] <jelmer> awmcclain: thanks :-)
[00:15] <ubotu> New bug: #216542 in bzr "unable to do merge on windows" [Undecided,New] https://launchpad.net/bugs/216542
[00:16] <ubotu> New bug: #216541 in bzr "bzr mv dies when using a checkout over http://" [Undecided,New] https://launchpad.net/bugs/216541
[00:29] <Linnk> Hey guys, I'm using Bazaar on Ubuntu 7.10. I'm trying to use the gui (Olive) to view a diff of a file, but the diff window simply shows up blank
[00:29] <jelmer> Linnk: how are you using it exactly?
[00:30] <Linnk> I click the file I want to see a diff for and click the Diff button in the toolbar
[00:31] <Linnk> I figured that I would then be asked which versions to diff, but apparently not
[00:36] <jelmer> Linnk: I think that just checks what changes there are in the working tree
[00:36] <jelmer> so on a fresh checkout it's correct the window is empty
[00:37] <Linnk> ah yeah, that explains why it suddenly works now that I've changed some files
[00:38] <Linnk> so I'll have to use the terminal for diff's between revisions?
[00:47] <jelmer> Linnk: You can use "bzr viz" to find a revision to show the diff for
[00:48] <Linnk> jelmer: Ok, thanks a lot :)
[01:28] <antoranz> Guys! How do I change the "remembered location" of a branch so I don't have to specify it on every "bzr merge" call?
[01:30] <jelmer> awmcclain: use --remember
[01:30] <jelmer> s/awmcclain/antoranz/
[01:31] <jelmer> antoranz: or edit .bzr/branch/branch.conf
[01:31] <antoranz> what does bzr bind do?
[01:32] <antoranz> jelmer: what you said worked. Thanks
[01:33] <bob2> binds a local branch to a remote one
[01:33] <bob2> making it a checkout (ie commits go to both immediately)
[01:36] <antoranz> ok
[02:06] <ubotu> New bug: #216586 in bzr "annotate removed-revision feature" [Undecided,New] https://launchpad.net/bugs/216586
[02:10] <awmcclain> I'm really at a loss here... I cannot get the bzr-email plugin to work for the life of me. No log entries, nothing. I'm flummoxed.
[02:19] <jelmer> awmcclain: What did you do to set it up?
[02:27] <awmcclain> jelmer: I've installed the plugin into my site packages. I've verified that it shows up until the bzr commands
[02:27] <awmcclain> ...
[02:27] <awmcclain> and
[02:28] <awmcclain> I've set the post_commit_to config variable in the branch.conf, and in ~/.bazaar/.bazaar.conf
[02:30] <jelmer> awmcclain: it shows up in "bzr plugins" you mean?
[02:30] <awmcclain> correct
[02:31] <awmcclain> i can also do bzr help email
[02:31] <jelmer> what os are you on?
[02:31] <awmcclain> ubuntu gutsy
[02:31] <awmcclain> it iddn't work in 1.2, and still doesn't work on 1.4r1
[02:32] <awmcclain> what should my config file look like, do you know?
[02:32] <awmcclain> i have
[02:32] <awmcclain> [DEFAULT]
[02:32] <awmcclain> post_commit_to          = admin@fluther.com
[02:34] <jelmer> yeah, that should be sufficient I think
[02:34] <jelmer> running bzr commit doesn't trigger it?
[02:46] <ubotu> New bug: #181534 in bzr-svn "Discards credentials specified in URL" [Medium,Fix committed] https://launchpad.net/bugs/181534
[03:54] <schmichael> if i have bzr 1.3 installed what repo format should i use?
[03:54] <schmichael> it seems to default to pack
[03:54] <bob2> the default, unless you have some special requirement (e.g. working with branches from svn)
[03:54] <schmichael> bob2: thanks!
[03:55] <ubotu> New bug: #216614 in bzr "should not immediately abort of .bzr/format can't be opened" [Undecided,New] https://launchpad.net/bugs/216614
[03:59] <AfC> there is an annotation cache, right?
[03:59] <AfC> does it get corrupted? if so, how do you force it to be regenerated?
[04:00] <spiv> AfC: not (yet) for pack formats.
[05:51] <matid> jelmer: Hi there. Any news on the issue with svn+https and bzr?
[06:30] <awmcclain> jelmer: No, running bzr commit doesn't trigger it. At all.
[06:30] <awmcclain> Are there any hidden log files I should check?
[06:32] <spiv> awmcclain: ~/.bzr.log, maybe try "bzr -Dhooks commit ..." too.
[06:35] <awmcclain> hrm
[06:35] <awmcclain> the -D switch is complaining
[06:36] <awmcclain> oh oh,never mind
[06:38] <awmcclain> A ha! Ok. It seems like the email only works if I commit ON the machine, not through SSH
[06:43] <awmcclain> Why would it not work over bzr+ssh://? Is there a different way to configure the post_commit_to?
[10:24] <pygi> morning
[12:45] <wildfire> is their a bzr equivalent of 'git add -i' (it allows you to select particular hunks of a file to add)
[12:47] <oleavr> wildfire: check out the interactive plugin at http://bazaar-vcs.org/BzrPlugins
[12:47] <asabil> wildfire: git add is different from bzr add
[12:47] <asabil> the interactive plugin adds a -i to commit
[12:48] <asabil> thanks for the advertisement oleavr :D
[12:49] <oleavr> asabil: "uncle software, coming to a store near you" ;D
[12:49] <asabil> lol
[12:51] <bob2> shelve kinda does the opposite
[12:53]  * asabil needs to implement bzr revert -i when he gets free time and motivation
[12:54] <wildfire> oleavr, and I just copy the *.py into ~/.bazaar/plugins/ and it'll work?
[12:55] <oleavr> wildfire: copy the directory in there, yes
[12:55] <asabil> wildfire: cd ~/.bazaar/plugins
[12:56] <asabil> bzr branch lp:bzr-interactive interactive
[12:56] <asabil> wildfire: you will need to have a subfolder inside plugins
[12:58] <wildfire> asabil, thanks - that branch command seemed to do the trick
[13:00] <asabil> great
[13:02] <asabil> let me know if there is any problem with it
[13:11] <wildfire> asabil, *** Bazaar has encountered an internal error.
[13:12] <wildfire> wildfire@muspell:/etc/bind$ sudo bzr record-patch
[13:12] <wildfire> bzr: ERROR: bzrlib.patches.MalformedHunkHeader: Malformed hunk header.  Does not match format.
[13:12] <wildfire> 'Binary files postfix/virtual.db\t2008-04-04 01:58:00 +0000 and postfix/virtual.db\t2008-04-10 09:06:09 +0000 differ\n'
[13:12] <asabil> can you paste the traceback somewhere please
[13:14] <wildfire> asabil, http://pastebin.com/m15c6399a
[13:14] <wildfire> hmm, when recording the changes I have to give it a patch-name
[13:15] <asabil> never tried with bzr 1.0.0 actually
[13:15] <asabil> and record-patch is a different thing than commit -i
[13:16] <asabil> both bzr commit -i and record-patch are working here
[13:16] <asabil> using bzr 1.3.1
[13:17] <asabil> they also worked with 1.1 and 1.2 iirc
[13:17] <matthewlmcclure> does bazaar support  perforce foreign branches?
[13:17] <bob2> as in actual perforce branches, or something like them?
[13:18] <asabil> matthewlmcclure: you can try bzr-fastimport, but never tested it myself
[13:18] <matthewlmcclure> an actual perforce branch
[13:18] <asabil> wildfire: ?? can you upgrade bzr ?
[13:19] <matthewlmcclure> asabil: i saw that, but i'm unclear how to provide input to bzr-fastimport
[13:20] <asabil> matthewlmcclure: http://bazaar-vcs.org/BzrFastImport/FrontEnds
[13:20] <matthewlmcclure> one of the wiki pages recommends git-p4, but it looks like that tool is hardcoded to git
[13:21] <dato> if git-p4 outputs in git-fast-import format, bzr-fastimport should do (or attempt to) do something useful with it
[13:21] <asabil> right
[13:21] <dato> but I think that'll be for importing only, not to work with them as foreign branches (like bzr-svn does with subversion's)
[13:21] <asabil> dato: seems like git-p4 runs git commands
[13:21] <dato> aha
[13:21] <asabil> proc = subprocess.Popen(["git", "rev-parse", branch], ...
[13:22] <asabil> matthewlmcclure: git-p4 can be a good starting point for hacking a bzr-p4
[13:22] <matthewlmcclure> asabil: that's what i thought; thanks for confirming
[13:23] <asabil> matthewlmcclure: but as dato said, fastimport is only about importing
[13:23] <asabil> I don't know if that's enough for you
[13:23] <matthewlmcclure> right, i'd really prefer two-way foreign branch support
[13:23] <asabil> someone needs to step up and implement it then
[13:24] <matthewlmcclure> i'm looking for an interesting project to hack on, so i may give it a shot
[13:24] <asabil> great :)
[13:24] <wildfire> asabil, I'm not sure what version of ubuntu this machine is running
[13:25] <wildfire> asabil, and this is a server
[13:25] <asabil> :/
[13:25] <wildfire> asabil, so an upgrade needs to be co-ordinated amongst a larger set of people than just me
[13:25] <asabil> I understand
[13:26] <asabil> but isn't it for your own usage ?
[13:26] <asabil> I mean, why would you need to install bzr on the server ?
[13:28] <asabil> wildfire: you don't really need bzr on the server
[13:29] <wildfire> we do if we manage /etc with it
[13:30] <asabil> wait wait
[13:30] <asabil> you seem to have called record patch on a binary file
[13:31] <asabil> that's a bug in bzr-interactive I guess
[13:31] <asabil> let me try to fix
[13:37] <matid> Hi there.
[13:37] <matid> A quick question - what does bzr up do on an unbound branch?
[13:40] <asabil> updates the working tree
[13:41] <asabil> this is useful when you push to a server
[13:41] <asabil> you can run update on the server to update the working tree
[13:41] <matid> So it's only useful if someone pushes code to my branch, right?
[13:42] <asabil> yep
[13:42] <asabil> for unbound branches of course
[13:42] <matid> Yeah, I know.
[13:43] <matid> And would bzr pull on an unbound branch be any different from bzr up on a checkout or a bound branch?
[13:43] <matid> (svn convert here, still failing to grasp all the differences ;))
[13:46] <asabil> it may be different if you pull from a different url
[13:46] <asabil> and a pull may not work if the branches have diverged
[13:47] <asabil> (in which case you need to merge)
[13:47] <matid> You may need to merge with bzr up too, right?
[13:48] <asabil> didn't use bzr up extensively, but I think it will merge automatically
[13:48] <asabil> it would work as in svn
[13:48] <asabil> if you see what I mean
[13:48] <matid> OK, thanks.
[13:48] <matid> I kinda get it now ;)
[13:48] <asabil> whereas bzr pull fails even when there are no conflicts
[13:49] <asabil> it fails simply because the code has diverged and requires a merge
[13:49] <matid> Ahh... So up would be like pull + merge in case pull fails.
[13:49] <asabil> something like that
[13:49] <asabil> *I think*
[13:50] <matid> asabil: Thanks a lot.
[13:50] <asabil> you're welcome
[15:21] <dwt> Guys, can somebody help me with this? I'm trying to update a repository to a specific tag, but I don't get how to do this. What seems obvious to me (bzr up -r tagname) doesn't seem to be the way to do this
[15:23] <dwt> And I'm lost finding this in the docs - though it has to be something easy. :/
[15:27] <asabil> dwt: can you give more details ?
[15:28] <asabil> is it a checkout or a branch ?
[15:28] <dwt> I'm a bit new, I think its a branch, i.e. it has full history
[15:28] <dwt> If thats what you meant.
[15:28] <asabil> and what do you mean to update to a specific tag ?
[15:28] <asabil> yes that's what I meant :)
[15:29] <dwt> :-)
[15:29] <asabil> so you branched from somewhere
[15:29] <dwt> Jes.
[15:29] <asabil> and you want to rollback to a specific tag ?
[15:29] <dwt> Well, I am playing around with bzr-svn and have a checkout of the 0.4 branch
[15:29] <dwt> yes!
[15:30] <asabil> bzr help revert
[15:30] <asabil> :)
[15:30] <dwt> ahhhh
[15:30] <asabil> or you can crate a new branch from that one
[15:30] <asabil> (that's generally better)
[15:30] <dwt> So the best way would be to move this directory aside
[15:30] <asabil> bzr branch -r tag:mytag . ../branch-mytag
[15:31] <dwt> branch from it, and only get revision up to the tag from the revision
[15:31] <asabil> yep
[15:31] <dwt> Why exactly is that better? I mean, I don't want to start developing on this checkout just yet
[15:31] <dwt> (and probably never)
[15:32] <asabil> so that you don't need to checkout again too many revisions
[15:32] <asabil> if you want to go ahead
[15:32] <asabil> if you see what I mean
[15:32] <dwt> So revert really removes the revisions from the repository?
[15:32] <dwt> uh, thats nastsy.
[15:32] <asabil> from your local branch
[15:32] <dwt> Is there not a simpler way to just go back in the history to a specific time?
[15:33] <dwt> While still retaining all the revisions in the repository?
[15:35] <asabil> actually I am not sure if revisions are removed from the branch
[15:35]  * dwt is currently reading the revert docs
[15:36] <dwt> I'l look this up a bit and come back to tell what I found.
[15:36] <asabil> oki
[15:36] <dwt> Thansk anyway for the help so far. :)
[16:30] <dwt> asabil: Well, the documentation in in bzr help revert is not completely clear on this, but <http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#undoing-mistakes> says that it only throws away local commits.
[16:31] <dwt> I'm not sure what I should make of this
[16:31] <dwt> anyway for my usecase revert seems like the right thing for me
[16:31] <asabil> k
[16:35] <radix> revert only modifies your working tree
[16:35] <radix> so it won't delete revisions
[16:35] <dwt> so also local commits are not deleted?
[16:36] <dwt> thanks for the clarification radix!
[16:36] <radix> sure thing
[17:37] <dwt> ok, thanks and cu!
[18:25] <rocky> anyone know if there is an equivalent to tag_svn_revision for bzr in setup.cfg (ala python setuptools) ?
[19:22] <cr3> if I have a remote machine from which I need code updated from a bzr repository, but the machine only has incoming traffic and no outgoing traffic, can I update the remote machine from my local machine using push or somesuch?
[19:22] <cr3> when I actually did try push, I get the error that the remote machine does not have a .bzr directory, which kinda makes sense because it's not a repository
[19:25] <cr3> I wonder if I need the bzr-push-and-update plugin, but I think there's a way to make this work somehow
[20:27] <matid> jelmer: Hi there!
[20:27] <matid> jelmer: I've got a question regarding bzr-svn, got a minute?
[20:28] <jelmer> matid: sure
[20:28] <jelmer> matid: I posted a patch to the subversion development list that fixes the https issue, btw
[20:29] <matid> jelmer: Oh, cool.
[20:29] <matid> jelmer: Thanks a lot.
[20:29] <matid> jelmer: The question is - what is a preferred way of dealing with diverged branches in svn?
[20:30] <jelmer> matid: There is no preferred way; it's up to you, what do you like best?
[20:30] <jelmer> matid: You can merge and push, but that may potentially change your existing revision history in svn
[20:30] <jelmer> matid: Some people prefer rebasing before pushing
[20:30] <matid> jelmer: Let's say, I branch some code, work with it, but in the meantime someone updates svn. I did bzr pull but I asked me to merge. And so did I, but after a push a strange commit appeared in svn.
[20:31] <matid> jelmer: It was a duplicate of the commit that was done in between my branch and the push.
[20:32] <matid> jelmer: And to be honest with you I don't even know how subversion will cope with it. If it's diff based then it should simply ignore it.
[20:32] <matid> jelmer: So I was supposed to rebase, right?
[20:34] <matid> jelmer: Oh, in fact it reverted the changes, it's not the same.
[20:40] <matid> jelmer: Eh, it's the same after all. I don't get it...
[20:54] <jelmer> matid: "bzr push" will push the current mainline in your bzr branch
[20:55] <matid> jelmer: Let's say with got a situation like this:
[20:55] <ubotu> New bug: #216924 in bzr "Push failed using (bzr push lp:). On windows machine" [Undecided,New] https://launchpad.net/bugs/216924
[20:55] <jelmer> matid: That may involve changing the current mainline in Subversion
[20:56] <matid> jelmer: I branch the svn code at revision 154. Now another person submits revision 155 and 156 to svn, whereas I make one commit in my bzr branch.
[20:57] <matid> jelmer: Now what I did was a bzr merge followed by bzr commit and bzr push.
[20:57] <matid> jelmer: Which resulted in a new svn revision containing duplicated 155, 156 and my bzr changes.
[20:57] <matid> jelmer: Is this expected behaviour?
[20:59] <jelmer> matid: Yes, because that's what's in your local bzr mainline
[20:59] <jelmer> matid: If you want to push something on top of what's in svn, use rebase
[21:00] <matid> jelmer: Is there a change what I just did (bzr merge and push) broke something?
[21:01] <matid> jelmer: Or is it just an innocent duplication?
[21:01] <jelmer> matid: It still contains the same data as is in your local bzr branch
[21:02] <matid> jelmer: But well, if I did a merge before I pushed it should also contain all the changes that were made in svn in the meantime, right?
[21:02] <jelmer> matid: yes
[21:02] <matid> jelmer: Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right?
[21:03] <matid> jelmer: I'm not really used to this kind of behaviour :)
[21:03] <jelmer> you'll notice the same revisions are in the svn branch as are output by "bzr log --line"
[21:04] <jelmer> matid: Not sure I understand what you mean by "Which means that bzr pushed a some diffs which applied to svn trunk simply didn't do a thing, am I right?"
[21:05] <matid> Hmm...
[21:05] <matid> jelmer: It seems like bzr log --line shows some differences between svn and bzr.
[21:05] <jelmer> can you be more specific?
[21:06] <matid> jelmer: I mean, there's one extra commit in svn between the moment I branched the code and the moment I pushed it.
[21:06] <matid> jelmer: This is a commit that I merged in bzr by using `bzr merge`
[21:06] <jelmer> matid: and it's still there if you use "svn log" on the full branch url?
[21:07] <matid> jelmer: Eee... It disappeared... How come?
[21:07] <jelmer> matid: it's not part of the mainline
[21:08] <matid> jelmer: You can't delete changesets in plain svn, or can you?
[21:08] <jelmer> matid: it's part of the right hand side history. You'll see if you run "bzr log" on the remote svn branch it'll show up indented
[21:08] <jelmer> matid: Nope, it's still part of the repository, just not part of the mainline history of that branch
[21:10] <matid> jelmer: Guess I've never stumbled upon this kind of thing in svn...
[21:11] <matid> jelmer: Which means that both solutions (rebase and merge&push) are going to result in the same code state in svn.
[21:11] <matid> jelmer: Yet push will rearrange the revision history.
[21:12] <jelmer> matid: After rebase, you still have to push
[21:12] <matid> jelmer: Yeah, it's not going to change anything in svn though. Just append new changesets, right?
[21:12] <jelmer> matid: yep
[21:12] <matid> jelmer: I guess I'll use rebase then.
[21:13] <matid> jelmer: I mean for me it makes no difference, but other people are not going to frown upon some strange things going on in svn :)
[21:15] <jelmer> matid: :-)
[21:15] <matid> jelmer: It's kinda strange since it looks like I committed changes someone else made earlier.
[21:16] <jelmer> matid: It matches the behaviour of merge, commit and push for native bzr branches
[21:16] <jelmer> and that's what bzr-svn tries to do
[21:17] <matid> jelmer: To me it looks like I'm trying to make others' changesets look like mine :D
[21:18] <jelmer> matid: the same thing will happen if you use svn merge with a subversion branch
[21:18] <matid> jelmer: Hm... It's just that in svn I used to do it the other way round.
[21:19] <matid> jelmer: Work on a branch, then merge changes into trunk and commit there.
[21:19] <matid> jelmer: I think this would also be possible if I simply kept one clean checkout of svn trunk and merge other bzr branches into it, right?
[21:23] <lifeless> abentley: ping
[21:23] <lifeless> morning y'all
[21:23] <abentley> lifeless: pong
[21:24] <lifeless> I'm trying to get BB up and running again on squid-cache.org
[21:24] <lifeless> I'm a little confused by your response to the bug I filed
[21:24] <jelmer> matid: yes - but if you do that, each merged bzr branch will only show up as a single commit in svn
[21:24] <jelmer> matid: (since a bzr merge puts only one revision on mainline)
[21:24] <abentley> I understood you were running TG 1.02 and SQLAlchemy 0.4.4.  Is that right?
[21:25] <lifeless> did you mean that if I downgrade sqlalchemy somehow, it will fix the error, or that 1.0.4.3 is a hard dependency now
[21:25] <matid> jelmer: That's what I'd do in svn, but it seems like using rebase is a better solution.
[21:25] <jelmer> matid: yeah, rebase makes snese in this case
[21:26] <lifeless> abentley: yes, thats what freebsd ships
[21:26] <matid> jelmer: Cool. Is there any case in which bzr-like merge and push will prove superior to rebase?
[21:27] <abentley> lifeless: for revno 249 and later, 1.0.4.x is a hard dependency.
[21:27] <jelmer> matid: It will probably give better results combining two branches
[21:27] <jelmer> matid: Rebase simply does diff + patch for each of the revisions you have that aren't in upstream
[21:27] <lifeless> abentley: you wouldn't happen to know if loggerhead is compatible with 1.0.4.x  ?
[21:28] <abentley> At least, in my experience, TG 1.0.2 did not work properly with SQLAlchemy 0.4
[21:28] <matid> jelmer: OK. Which means that in case of not-so-complicated merges it should work the same.
[21:28] <abentley> lifeless: Sorry, I don't know that.
[21:29] <lifeless> thats ok, wishful thinking :P
[21:29] <lifeless> I find myself thinking unpleasant thoughts towards the turbogears maintainers
[21:30] <lifeless> the dependency tree seems unpleasant
[21:30] <abentley> I'm quite disheartened about the whole thing.
[21:30] <abentley> Especially that SQLAlchemy managed to ship two releases which had blatent bugs that my measly test suite caught.
[21:30] <lifeless> tests FTW
[21:31] <lifeless> mwhudson: ping
[21:31] <mwhudson> lifeless: hi
[21:31] <abentley> This was stupid stuff where they failed to import a symbol they used.
[21:32] <lifeless> !!!
[21:32] <lifeless> thats apalling
[21:32] <abentley> you've got that right.
[21:36] <lifeless> I do want to talk about the tension that bubbled out on thursday; however sunday morning I woke up with a head cold
[21:36] <jelmer> matid: yeah
[21:37] <lifeless> I'd rather be at my best when debugging important things
[21:43] <lifeless> abentley: welcome back
[21:43] <abentley> thanks.  Last thing I saw was "﻿I'd rather be at my best when debugging important things"
[21:43] <lifeless> abentley: that was the last thing I wrote
[21:44] <abentley> Cool.
[21:59] <lifeless> aarrgghh
[22:00] <lifeless> abentley: you'll love this. I'm trying to update the turbogears package for freebsd
[22:00] <lifeless> 1.0.4.3 wants turbojson 1.1.2
[22:00] <lifeless> there is no egg for 1.1.2
[22:01] <abentley> That's nutsy
[22:01] <lifeless> http://files.turbogears.org/eggs/ is where the package is looking
[22:02] <abentley> 1.1.2 is available on PyPI, though.  It doesn't fall pack to that?
[22:02] <abentley> s/pack/back
[22:02] <lifeless> no
[22:03] <abentley> Strange.  I thought it did.
[22:03] <lifeless> easyinstall may
[22:04] <abentley> Oh.
[22:04] <abentley> Yes, that's what I was talking about.
[22:05] <lifeless> I'm really not sure what to do at this point
[22:06] <threeve> I'm trying to get bzr-svn going on Windows using Python 2.5(.2).  I have svn 1.4.6 installed, an have installed bzr 1.3 and bzr-svn 0.4.9 using the binary installers, and installed the updated svn 1.4.6 python bindings.  `bzr version` now crashes for me.  Have I missed something I need to install?
[22:08] <wildfire> lifeless, i think going back to linux is the answer ;-)
[22:09] <lifeless> wildfire: this machine has never been linux :(
[22:09] <lifeless> squid-cache.org
[22:09] <jelmer> threeve: How did you install svn 1.4.6 ?
[22:09] <threeve> jelmer: windows binary installer from Tigris, iirc.
[22:10] <cr3> interesting coincidence, I'm installing squid as we speak
[22:10] <wildfire> lifeless, ahh, right. well that's nothing a chroot couldn't solve if you get really stumped
[22:10] <lifeless> wildfire: but even if I did that, this points out a generic problem for folk that are not on development editions of linux
[22:10] <jelmer> threeve: You can't use a stock subversion 1.4. You need either the one with the patches linked from the bzr-svn wiki page or Subversion 1.5.
[22:11] <wildfire> lifeless, i don't think developers will ever be 'generic folk' personally. Most people never miss the 'new'
[22:12] <lifeless> wildfire: EPARSE ?
[22:13] <threeve> jelmer: Okay, I thought that might be the case but I thought maybe only the patched bindings were necessary.  Building a new Subversion now.  Thanks
[22:13] <lifeless> cr3: :P
[22:16] <wildfire> lifeless, most people are not neophiliac's like you and I and most other developers. People who are not on development editions will never, generally, run into the issue since "shiny" isn't what they care about - they are 'generic folk'.
[22:16] <wildfire>  Therefore the problems of generic folk and development folk are not normally intertwingled.
[22:17] <jelmer> wildfire: I think more people care about "shiny" than just a couple of developers :-)
[22:17] <lifeless> wildfire: for this discussion, I'm wearing the hat of generic folk
[22:17] <lifeless> wildfire: I don't want a shiny bb, I want a working bb.
[22:18] <lifeless> wildfire: dependency issues between components used by bb have forced bb to require versions that are not available on freebsd; either by being too old, or once fixed, by being too new.
[22:21] <wildfire> lifeless, with my (slight-tipsy) sysadmin hat on, I'd suggest the best thing would be a specific python chroot devoted to have the right dependancies for tg, sqlalchemy and bb all installed at the specific versions
[22:21] <wildfire> s/to have/to having/
[22:21] <wildfire> once they OS has the appropriate ones you can always migrate it back out of the chroot
[22:22] <lifeless> wildfire: I don't want to sysadmin this service :P. So I'm simply punting the problem to the -noc team there
[22:25] <Pretto> hi all
[23:08] <mwhudson> this is strange, right:
[23:08] <mwhudson> mwh@grond:debian-packaging$ cat .bzr/branch/last-revision
[23:08] <mwhudson> 2 ted@canonical.com-20080401051631-3zsnbir02j3c0ihp
[23:08] <mwhudson> mwh@grond:debian-packaging$ bzr revision-history | wc -l
[23:08] <mwhudson> 30
[23:08] <mwhudson> ?
[23:08] <jelmer> mwhudson: yeah, that's very weird
[23:13] <lifeless> the cached revcount would appear to be wrong
[23:14] <mwhudson> sure looks like it
[23:15] <mwhudson> i can try and grab ted and ask what he did i guess
[23:15] <mwhudson> (it's this branch)
[23:15] <mwhudson> https://code.edge.launchpad.net/~ted-gould/gnome-power/debian-packaging
[23:15] <lifeless> abentley: so the api I proposed in my new stream doco doesn't work
[23:16] <abentley> I guess we're all a bunch of boobs, then.
[23:16] <lifeless> abentley: I think it will work better if rather than returning the bytes, I return a factory object that can return as_knit, as_fulltext, etc.
[23:16] <lifeless> I mean, it works ok in the common case
[23:17] <lifeless> but isn't able to handle the iter_rev_trees thing. I tink that the small change above will.
[23:17] <lifeless> so I'm doing a hallway test :P
[23:18] <lifeless> breakfast
[23:20] <abentley> I don't get it.  Isn't this just for fetch?
[23:22] <lifeless> its for fetch including the case of plain -> rich roots
[23:23] <lifeless> I have a call in ~8 minutes with thumper and an errand to run first, back to chat after that
[23:53] <igc> morning
[23:54] <jelmer> Hi Ian!
[23:55] <igc> hi jelmer - I'm back from holidays
[23:55] <igc> fiji was awesome
[23:55] <jelmer> :-)