[00:00] <james_w> and Fix Released when I tell it I release a milestone
[00:00] <james_w> or something
[00:00] <james_w> I'll leave the details to you guys :-)
[00:00] <beuno> I don't quite understand
[00:00] <beuno> fix committed automatically when what?
[00:00] <Odd_Bloke> beuno: When a branch is merged to the development focus.
[00:01] <beuno> ah
[00:01] <beuno> what has that to do with bugs?
[00:01] <Odd_Bloke> s/branch/branch that fixes a given bug/
[00:01] <james_w> I'm talking about the bugs statuses
[00:01]  * beuno blinks
[00:01] <Odd_Bloke> Then the bug gets automagically marked as Fix Committed.
[00:02] <beuno> that's a bit tricky
[00:02] <james_w> you have "Fix Available" on the branch when I push a --fixes. If that gets merged to the development focus then it sets the bug "Fix Committed".
[00:02] <emmajane> beuno, *grin* and you thought I was bad. ;)
[00:02] <beuno> james_w, gotcha
[00:02] <beuno> should be viable
[00:02] <Odd_Bloke> emmajane's paying us to make her look better. :p
[00:02] <beuno> file a bug, I'll try and make it happen
[00:02] <emmajane> james_w, how come I have to report bugs and you just get IRC requests. ;)
[00:02] <emmajane> WOO!
[00:02] <emmajane> :)
[00:02] <beuno> emmajane, ;)
[00:04] <emmajane> beuno, hopefully the screenshots were helpful as well?
[00:04] <beuno> emmajane, they're better than a patch
[00:04] <beuno> deeply appreciated
[00:04] <emmajane> kay
[00:05] <emmajane> I'll continue to include them as I find more things.
[00:05] <beuno> if all users where like you, software would beperfect
[00:05] <emmajane> hehe
[00:05] <emmajane> beuno, You can come and work with Drupal when you're done with LP. ;)
[00:05] <beuno> (my typing, on the other hand...)
[00:05] <beuno> done with LP? ha!  like that will ever happen
[00:06]  * emmajane grins
[00:06] <beuno> LP is *big*
[00:06] <beuno> huge
[00:06] <emmajane> so is Drupal ;)
[00:06] <emmajane> it will be ready for you when you're done ;)
[00:06] <Flare183> When I try to push my bzr branch to launchpad it give me this error: Transport operation not possible: http does not support mkdir()
[00:07] <beuno> heh, I'm sure it will
[00:07] <Flare183> What can I do to fix this?
[00:07] <beuno> Flare183, you need to specify your launchpad login
[00:07] <Odd_Bloke> Flare183: 'bzr launchpad-login -h'
[00:07] <beuno> bzr launchpad-login <username>
[00:07] <Flare183> oh ok
[00:07] <beuno> -h?
[00:07] <Odd_Bloke> Help. :D
[00:08] <beuno> right, fish/teach to fish
[00:08] <beuno> I hate fishing, so I just give people food
[00:10] <Odd_Bloke> NOM NOM NOM
[00:13] <Flare183> ok Now I get this error: Target directory already exists. Please select another target.
[00:13] <Flare183> I know it exists thats why I'm pushing it there. Duh bzr!
[00:13] <Flare183> How can I fix this on?
[00:13] <Flare183> one*
[00:13] <Odd_Bloke> Flare183: What command are you using?
[00:13] <Flare183> bzr push
[00:14] <Odd_Bloke> Or, rather, what's the full command-line?
[00:14] <Flare183> Actually I'm using Olive
[00:14] <Flare183> But I can use the command line
[00:14] <Flare183> hold on
[00:14] <Odd_Bloke> Heh, serendipitous.
[00:14] <Odd_Bloke> What's the location you're trying to push to?
[00:14] <beuno> Flare183, add --use-existing
[00:14] <Flare183> oh ok
[00:15] <beuno> the error should be telling you to add the flag  ;)
[00:15] <Flare183> jesse@jesse-desktop:~/Python Projects/bot$ lp:~richardson183/ubuntu-bots/flarebot --use-existing
[00:15] <Flare183> bash: lp:~richardson183/ubuntu-bots/flarebot: No such file or directory
[00:15] <Flare183> jesse@jesse-desktop:~/Python Projects/bot$
[00:15] <Flare183> ...
[00:15] <Odd_Bloke> 'bzr push ...'? :)
[00:15] <Flare183> hold on
[00:15] <Flare183> sorry i screwedup
[00:15] <Flare183> screwed up*
[00:25] <Peng_> lifeless: FWIW, Launchpad hasn't been able to mirror https://code.launchpad.net/~lifeless/bzr/repository for a month.
[00:25] <lifeless> fail
[00:25] <lifeless> :P
[00:49] <loxs> folks, is there any permissions implemented in bzr itself?
[00:49] <loxs> because we are having a problem... one of my devs has read access to the main branch, but cannot co the trunk
[00:49] <loxs> http://dpaste.com/88990/
[00:50] <Odd_Bloke> loxs: Have you checked FS permissions?
[00:50] <bob2> won't read-access via ssh (try to) take a lock?
[00:50] <lifeless> no
[00:50] <loxs> Odd_Bloke, they have read access
[00:51] <loxs> bob2, what do you mean by "take a lock"?
[00:51] <Odd_Bloke> Well, checkout implies commit access.  Does 'branch' work?
[00:51] <bob2> loxs: don't mind me
[00:51] <loxs> hmm, I didn't know that, we'll try with branch
[00:52] <Odd_Bloke> loxs: Also, do they have execute permissions on .bzr?
[00:52] <Odd_Bloke> Because if not then they won't be able to access anything under it.
[00:53] <Odd_Bloke> "chmod -R a+rX .bzr" or some equivalent is probably what you want.
[00:53] <loxs> yes, they have +x
[00:53] <james_w> beuno: thanks
[00:54] <Odd_Bloke> james_w: Whereabouts are you based these days?
[00:54] <james_w> Odd_Bloke: Bristol
[00:54] <Odd_Bloke> loxs: And can they actually read that file via other means?
[00:55] <Odd_Bloke> james_w: Cool, I remembered that your old job was there, but didn't know if you were still there.
[00:55] <james_w> Odd_Bloke: yeah, no reason to leave yet
[00:55] <james_w> Odd_Bloke: how's work treating you?
[00:55] <Odd_Bloke> james_w: Eh, so-so.
[00:55] <james_w> oh no, that will be over now won't it?
[00:56] <james_w> oh, it's a year isn't it?
[00:56] <Odd_Bloke> 9 months.
[00:57] <Odd_Bloke> I'm finding getting up in the mornings quite difficult.
[00:57] <Odd_Bloke> And there's rather more OpenOffice in my life than I'm entirely comfortable with.
[00:57] <Odd_Bloke> I don't really know whether I have issues with this job, or with 9-5 jobs in general, though, this being my first of more than 2 weeks.
[00:57] <james_w> OpenOffice should come with a health warning
[00:58] <james_w> yeah, I found 9-5 tough
[00:58] <loxs> yes, Odd_Bloke they can read the file when they do it via cat etc... and it raises the same exception when using branch
[00:58] <Odd_Bloke> We're doing so much crazy stuff with OO.o.
[00:58] <james_w> though I ended up working like 7-3 quite often so that I actually had an evening
[00:59] <Odd_Bloke> Ranging from writing an automated presentation player to backporting OO.o 3 to Sarge. >.<
[00:59] <james_w> ouch
[00:59] <james_w> my sympathies
[00:59] <Odd_Bloke> Thankfully I've mostly avoided the backporting.
[01:00] <Odd_Bloke> It's also a little frustrating that I don't feel I'm working _on_ free software so much as I'm working _with_ it.
[01:00] <Odd_Bloke> Which is nice, but this presentation player we're writing is going to be non-free.
[01:01] <Odd_Bloke> Making it, IMO, a complete waste of my time.
[01:03] <Odd_Bloke> Certainly it's a far cry from stage diving. :p
[01:04] <james_w> :-)
[01:07] <lifeless> spiv: ping me when you're online please
[01:07] <Odd_Bloke> james_w: Anyway, the reason I asked where you were is that I have a friend at Bristol, and it'd be good to meet up for a drink if I ever get around to visiting him.
[01:08] <james_w> Odd_Bloke: sure, I'd like that
[01:10] <Odd_Bloke> Cool.
[01:15] <lifeless> loxs: hi
[01:16] <lifeless> loxs: /home/bazaar/bloxs/trunk/.bzr/branch-format is the path reported in your error
[01:16] <lifeless> loxs: can you have one of the users try 'scp HOST:/home/bazaar/bloxs/trunk/.bzr/branch-format .'
[01:28] <loxs> lifeless, thanks but we resolved it... typical administrator error... :)
[01:28] <loxs> they had permissions to read the repositories... but they didn't have permissions to read the top /home/bazaar/ directory :)
[01:28] <lifeless> heh
[01:43] <spiv> lifeless: pong
[01:43] <spiv> lifeless: was online, just not looking at IRC very much!
[01:44] <lifeless> spiv: I wanted to know if my comments made sense etc
[01:44] <lifeless> spiv: the void was a tad disturbing
[01:45] <spiv> lifeless: don't stare into the abyss ;)
[01:46]  * spiv quickly rereads
[01:49] <spiv> lifeless: so, I see a loop you added to fetch, although I don't grasp how it's deltaing a chain of inventories
[01:50] <spiv> lifeless: the high-level description you gave makes sense, I just don't see the code.
[01:53] <lifeless> spiv: ah yes
[01:53] <lifeless> spiv: I lied apparently
[01:53] <spiv> Heh.
[01:54] <lifeless> spiv: the loop would be something like:
[01:54] <lifeless> grab the the inventory meta node for all the inventories
[01:54] <lifeless> plus one for any arbitrary inventory outside the set that the target has
[01:54] <spiv> lifeless: _install_revision looks like it has added code related to this, maybe?
[01:55] <lifeless> then do a set based difference on the node's pointers
[01:55] <lifeless> and repeat
[01:59] <lifeless> spiv: not really
[02:00] <lifeless> spiv: _install_revision has a inventory cache to get deltas, because it can insert deltas more cheaply than full inventories
[02:05] <spiv> lifeless: thanks
[02:05]  * spiv -> lunch
[02:34] <lifeless> spiv: the packer has no cache set
[02:34] <lifeless> spiv: you should chat more :>
[04:24] <lifeless> spiv: ugh, I hate lp's handling of attachments
[04:24] <lifeless> send me the damn diff, biatch
[04:36] <spiv> lifeless: http://rafb.net/p/9LQyFJ98.html
[04:36] <spiv> lifeless: or do you mean email?
[04:36] <lifeless> spiv: lol I was ranting at lp
[04:36] <lifeless> at what it does
[04:36] <lifeless> not at you
[04:36] <spiv> Oh, right :)
[04:36] <spiv> Yeah.
[04:36] <lifeless> I clicked to see the attachment
[04:37] <lifeless> and I commented too
[04:44] <emmajane> lifeless, careful or beuno will tell you to post a bug about LP. ;)
[04:47] <lifeless> emmajane: oh theres plenty of those already
[04:47] <lifeless> emmajane: :)
[04:47] <emmajane> heheh
[04:48] <emmajane> he likes it when you *attach* pictures. ;)
[06:35] <gour> morning
[06:36] <gour> am i right that 'shelve' is moving into core?
[06:37] <luks> already moved, as far as I know
[06:39] <spiv> Yep.
[06:39] <gour> yeah, i saw r3823...very nice
[06:43] <gour> fix for #293054 will go into 1.9 ?
[06:43] <lifeless> gour: its a new shelf, not the old one moved
[06:43] <lifeless> bug 293054
[06:44] <lifeless> gour: I don't know, it might, 1.10 for sure
[06:44] <gour> lifeless: but the new shelf provides the same functionality?
[06:44] <lifeless> different
[06:44] <lifeless> much in common
[06:44] <lifeless> it can shelve more things
[06:44] <lifeless> but some aspects are not as mature
[06:45] <gour> aha...still it's nice that plugin's functionality goes into core...
[06:46]  * fullermd really looks forward to being able to shelve more things.
[06:46] <fullermd> A notable percentage of the times I've wanted to shelve, there have been renames or binary files involved.
[07:27] <vila> hi all
[07:28] <vila> gour: I doubt bug #293054 will make it into 1.9 but I'll try
[07:32] <gour> vila: thanks
[07:33] <vila> gour: you're welcome, your testing of python-2.6 support is very much appreciated :)
[07:35] <gour> vila: heh, python-2.6 is default in archlinux, so i didn't do any extra work :-)
[07:35] <gour> ...except using bzr
[07:38] <vila> gour: which is exactly the point of having testers :) I had to rebuild a python-2.6 from sources to reproduce the problem, and a pycurl too (for different but related reasons) since my setup wasn't as clean as I thought, so indeed, it was harder for me to notice the problem
[07:40] <gour> i'm glad if i was somewhat useful in improving my beloved tool
[07:51] <fullermd> Man, I hate the half-assed VCS capability of wikis sometimes...
[07:59] <eydaimon> Is there a plugin or some such that allows emails to be sent out from the server when commits are made?
[08:01] <lifeless> the bzr-email plugin; I *think* its been updated to work with commits as long as you're using bzr+ssh
[08:01] <lifeless> spiv: ^ do you recall?
[08:01] <lifeless> eydaimon: you can definitely just install it on each machine
[08:02] <lifeless> eydaimon: there is also a cron based plugin that can mail when a branch changes
[08:02] <eydaimon> ok, thanks
[08:45]  * fullermd figures he's spammed enough people for one night.
[08:47] <spiv> lifeless: don't know, sorry
[08:59]  * gour just re-read http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism post and wonder whether there is scope for rebase in bzr
[09:01] <gour> what's happening with loom plugin? it looks like not much since 1.3...
[09:03] <spiv> gour: there's a rebase plugin for bzr.
[09:04] <spiv> gour: I just happen to think it's usually not the best option :)
[09:07] <gour> spiv: yeah, i did not go into looms yet, but example of selective merge is simple & good enough that i wodner why i'd need rebase
[09:08] <dissonans> I just merged a bunch of revisions from another branch using bzr 1.9rc1 and bzr-svn 0.4.14, but apparently the merge wasn't recorded
[09:08] <dissonans> first off, bzr st showed only straight modifications and no merge, then the "missing" command still shows the merged revisions as missing
[09:08] <spiv> gour: the attraction of rebase is that it's a fairly simple mental model to work with
[09:09] <gour> spiv: heh, it seems my mind is at different wavelength then :-D
[09:09] <spiv> gour: so if you are the sort of person that thinks in terms of "this branch would be better if revision #N was done differently" then rebase seems natural
[09:11] <gour> what is the price for it?
[09:12] <spiv> Well, you lose the original history.
[09:12] <gour> and new merge will produce (more) conflicts?
[09:13] <dissonans> when you've merged, it's supposed to be indicated by "status" no?
[09:13] <spiv> Which impacts operations that use history, most obviously merge -- if someone else has branched off your original branch, then you rebase, now you have two branches that independently make similar changes.  Which means you've almost certainly created conflicts that you didn't have before.
[09:13] <spiv> dissonans: right
[09:13] <dissonans> well, it isn't :/
[09:13] <dissonans> I just confirmed
[09:13] <spiv> dissonans: but we don't record merge history for cherrypicks yet
[09:13] <gour> spiv: yes, similar with doing unrecord in darcs after the patch went into wilderness?
[09:13] <spiv> dissonans: how did you do the merge?  "bzr merge -r A..B"?
[09:13] <dissonans> spiv: ah hm
[09:14] <dissonans> yep, specific revisions
[09:14] <dissonans> that's a problem
[09:14] <spiv> gour: I'm not familiar enough with darcs, but that sounds likely.
[09:14] <dissonans> I know merge has worked as I expected, but maybe I wasn't cherrypicking
[09:15] <spiv> dissonans: probably.  Or maybe the base of your cherrypick was already in the branch you were merging into.
[09:15] <dissonans> spiv: nah
[09:15] <gour> spiv: is it possible to record merge history when cherrypicking in bzr?
[09:15] <gour> (by bzr's design)
[09:16] <spiv> gour: there was talk about how to support them at the March 2008 sprint
[09:16] <spiv> I forget the details, but they're probably on the list somewhere.
[09:17] <gour> cool. cherrypicking-ala-darcs would be great
[09:17] <spiv> It would.  It's a pretty common request, unsurprisingly.
[09:18] <dissonans> should I follow any other pattern to integrate changes from the trunk in my release branch then?
[09:18] <crisb> hi everyone.  has anyone got any tips about converting from an RCS like system (PVCS) to bzr?
[09:18] <dissonans> can't see how to avoid it, and I kind of relied on having the merge history
[09:19] <gour> btw, what is with the bug #109143 ?
[09:19] <spiv> gour: not enough people have complained about it recently ;)
[09:20] <gour> ok, let me add myself to the list
[09:20] <fullermd> I knew I shoulda set up that cron job...
[09:20] <spiv> gour: actually, you're the second person to mention it to me in the last week or so.  It's probably due to be bumped up to the top of my list of things to do...
[09:21] <crisb> we want to convert to bzr and i'm thinking of moving just the head over then manually recreating any branches we had (PVCS has no concept of a whole project branch, just a file by file one) does that sound stupid?
[09:23] <crisb> i mean can i somehow change timestamps of commits?
[09:23] <fullermd> crisb: I would suspect converting PVCS to CVS or SVN, and then going from there to bzr, would be the simplest thing to try...
[09:23] <fullermd> (since there are existing tools for both those paths out of PVCS, and both of those paths into bzr)
[09:24] <crisb> fullermd: yes sorry thats my plan, its just they dont give me anything very sane at the end of it if I leave it all up to the conversion tool
[09:26] <fullermd> Mmm.  Yeah, if you started doing the sort of weird per-file stuff PVCS/RCS/CVS let you do, I can see that...
[09:28] <crisb> fullermd: so as we really dont want to end up with people having to know 2 (very different) tools we want to make a complete break from the past :) but do i have the ability to go in and fiddle about with the bzr repository when i'm making these manual branches from the historical stuff?
[09:32] <fullermd> You can't change existing commits, no.  But you can certainly [through bzrlib; not through the CLI] set whatever attributes (including timestamps) you want on freshly created revisions.
[09:33] <gour> where can one find more info in regard to "Predefined formats for dumping version information in specific languages are currently in development." ?
[09:34] <fullermd> gour: "bzr help version-info"?
[09:36] <gour> fullermd: i mean if there is some work for other concrete language-formats like it's for 'python'
[09:39]  * gour thinks (un)shelve is great stuff
[09:40] <vila> so one can go from zzz to afk and hist IRC client noticed...
[09:40] <vila> so one can go from zzz to afk and his IRC client noticed...
[09:42] <gour> hmm, cdiff prints in grey on white bg...how to fix it?
[10:46] <NET||abuse> uhoh,, i just ran bzr merge in my local svn working copy of a project i'm working on... i'm tired and think i just didn't think,, will this do anything bad?
[10:47] <NET||abuse> it says it's generating file id map at the moment.
[10:52] <lifeless> NET||abuse: just hit ctrl-C if you didn't want to do that
[10:53] <NET||abuse> .. well, doing a svn up on the working copy doesn't give out
[10:53] <NET||abuse> svn status shows up no new weird entries
[10:53] <NET||abuse> seems ok
[10:54] <NET||abuse> back in my bzr copy now
[10:55] <fullermd> As I see it, the problem is that that project isn't in bzr   ;)
[10:55] <NET||abuse> did bzr merge to get changes from other people down, bzr log only shows rev 487, we're on 520
[10:56] <beuno> james_w, hey hey, happy birthday!
[11:02] <lifeless> NET||abuse: thats normal
[11:02] <lifeless> NET||abuse: revnos are per-branch
[11:03] <lifeless> NET||abuse: (by analogy, consider multiple svn repos being synced with svk; revno's are per repository there)
[11:03] <lifeless> gnight
[11:08] <NET||abuse> lifeless: cheers. :)
[11:08] <NET||abuse> lifeless: seeya
[11:36] <james_w> thanks beuno
[11:56] <Rolly> I have a live website that is a standalone tree. I want to allow someone remote read+write access to the repository (htdocs/.bzr/), but I don't want to give them any access to the working tree files (htdocs/) or in fact any path on my server's filesystem. What would be the quickest way to accomplish this?
[11:57] <Rolly> Oh and SSH / SFTP are out of the question
[11:59] <awilkins> Holy monkey, why does this "bzr log -v" require 500MB of ram.....
[11:59] <awilkins> It's a rather large tree, but even so
[12:03] <Rolly> I also forgot to mention I need some sort of authentication, even if it's rudimentary. I think that rules out "bzr serve"
[12:03] <quicksilver> I'm not aware of any other form of write access
[12:04] <quicksilver> since you've ruled out ssh, sftp and the smart server
[12:04] <quicksilver> well, except bridging the filesystem to them somehow.
[12:04] <Rolly> Hm, but I've read that the smart server can be used with http
[12:04] <quicksilver> you can't write over http.
[12:04] <Odd_Bloke> You can, with the webdav plugin.
[12:05] <Odd_Bloke> vila will know more.
[12:05] <soren> How can I tell a signed commit from an unsigned ditto?
[12:05] <Rolly> argh
[12:05] <Rolly> I didn't see that mentioned in the docs, thanks
[12:06] <vila> bzr+ssh, bzr+http[s], webdav all provide various kind of authntication
[12:07] <Rolly> right I was just looking at authentication.conf
[12:07] <vila> wrong path
[12:07] <vila> authentication.conf is how you describe *your* credentials when accessing remote servers not how you want your local server to handle authentication
[12:08] <Rolly> Right, I think I understand that. It's SSH/webserver/webdev/etc that provide the server-side auth
[12:08] <vila> and if you install a smart server in your http server you *have* write access and you can use http[s] to handle authentication
[12:09] <vila> Rolly: yes
[12:09] <Rolly> Ah, you mean like with bzr-smart.fcgi or fcgi.py I can get write support?
[12:09] <vila> yes
[12:09] <Rolly> fabulous
[12:09] <Rolly> It's a little confusing at first
[12:10] <vila> If you feel you can make that clearer in the doc at any place, patches are welcome :)
[12:11] <Rolly> just to be clear, using the smart server in the http server will just allow my remote user to just access the repository, yes? No filesystem access?
[12:11] <Rolly> (ignore that redundant "just")
[12:12] <vila> Rolly: that's the idea yes
[12:13] <Rolly> Cool
[12:14] <Rolly> the user reference definetely needs some clearing up, maybe I'll take a stab if I wrap my head around this
[12:14] <vila> Err, wait, re-reading your description: access to htdocs/.bzr but no access to htdocs itself is a bit contradictory since the later is the working tree for the former
[12:15] <vila> if you really want to separate the two just give your user write access to a different branch at a different place and merge/update locally what you want
[12:15] <Rolly> I didn't mean literal filesystem access to htdocs/.bzr/, I actually meant "access to the repository"
[12:16] <Rolly> like with svnserve, you can serve a repository through svn:// and the users don't have filesystem access
[12:16] <vila> In that sense then yes if .bzr is a repository and not a branch my warning doesn't even apply
[12:17] <Rolly> Well, when I "cd htdocs && bzr info", I get "Standalone tree,  branch root: ."
[12:20] <Rolly> In SVN terminology, htdocs/ is my repository _and_ my checkout. I need to give remote access to the repository but not the checkout
[12:20] <vila> You realize that if you give write access to your repo, even if the smart server doesn't update your working tree when your remote user commit, you will take his commits into account the next time you do bzr update ?
[12:20] <Rolly> yeah, that's what I want
[12:20] <Rolly> I just need a firewall (me) to check missing revisions before I update
[12:21] <vila> Then you'd better give him access to another branch from where you can pull or merge (IMHO)
[12:22] <vila> That will give you more control of your htdocs content
[12:22] <vila> While taking his modifications will still be easy (even easier the day you disagree with some modification)
[12:24] <Rolly> I see your point
[12:26] <vila> That's a usual setup where your user pull from your repository, push to a staging one and *you* pull or merge from the staging one acting as the gatekeeper (or firewall as you said)
[12:27] <Rolly> Hm, in what cases is that more convenient for the gatekeeper?
[12:29] <Odd_Bloke> Rolly: In the case where you don't want some changes.
[12:30] <Odd_Bloke> Because then you just don't pull, rather than having to perform acrobatics with the history of the branch.
[12:30] <Rolly> But in a production<->staging scenario, a bad commit can just be deleted (there isn't going to be a lot of activity on this repository, and no parallel coding going on
[12:30] <Odd_Bloke> A bad commit can be deleted, but should you be deciding the best way to do that, or should the developer?
[12:31] <Rolly> in this case, me
[12:31] <Odd_Bloke> In that case, there's not a massive amount to be gained from pushing to a separate branch, except that it is: a) good practice, and b) more future-proof.
[12:31] <Rolly> gotcha
[12:33] <Rolly> by the way, in the user reference, there is one mention of using an "http:// URL when a smart server is available via HTTP"
[12:33] <Rolly> everywhere else, it talks about "bzr+http://". What is the difference?
[12:34] <Odd_Bloke> Rolly: Where is that reference?
[12:34] <Rolly> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks
[12:35] <Rolly> and then if you look here, it also mentions both protocols: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
[12:35] <Rolly> "Now you can use bzr+http:// URLs..."
[12:35] <Rolly> "Plain HTTP access should continue to work..."
[12:36] <Odd_Bloke> Hmm, I'm afraid I don't know.
[12:36] <Odd_Bloke> I've never set up smart HTTP access.
[12:36] <Rolly> I'll just dive in and see what happens
[12:39] <vila> Rolly: the smart client probes any http server and revert to plain http when no smart server answers
[12:40] <Rolly> aha
[12:41] <Odd_Bloke> vila: You can disable that behaviour using http+nosmart://..., right?
[12:41] <vila> right
[12:41] <Odd_Bloke> And does the HTTP smart server give me any benefit on read-only branches?
[12:42] <Rolly> a benefit would be speed, right?
[12:42] <vila> Odd_Bloke: more and more :)
[12:43] <Odd_Bloke> Right, I wasn't sure if 'smart' meant 'I can write to this', or meant 'generally better in every way'.
[12:43] <vila> and if you find a place where it is slower than raw http, file a bug
[12:43] <vila> the later
[12:44] <Odd_Bloke> Cool.
[12:44] <Odd_Bloke> I'll look into setting it up at some point.
[12:49] <jml> lifeless: *nudge* https://code.edge.launchpad.net/testresources/+activereviews
[13:35] <loxs> hello, is there a way to version control ODT documents with bzr?
[13:36] <gour> loxs: odt is compressed xml or not?
[13:36] <loxs> gour, I have no idea
[13:37] <beuno> loxs, I don't thing there is a good way to do so ATM, no
[13:38] <beuno> it will version it as binaries
[13:38] <gour> loxs: it looks it's zipped xml content, so not the best candidate
[13:38] <beuno> which isn't very good
[13:38] <luks> a good way to do what exactly?
[13:38] <beuno> OO has versioning built in
[13:38] <beuno> and you can plug VCSs into it
[13:38] <beuno> but I don't know too much abput it
[13:39] <loxs> hmm, OO has versioning? interesting
[13:39] <gour> loxs: i decided to use reST markup for all my writings...it can be nicely versioned with bzr, and there is nice rst2odt converter
[13:39] <loxs> but I suppose there is no good way for collaboration built in OO
[13:40] <gour> loxs: ...if reST markup satisfy your writing needs.
[13:40] <luks> loxs: what do you expect when you say 'to version control ODT documents'?
[13:40] <loxs> gour, the thing is that most of my contributors won't manage to do it
[13:40] <loxs> luks, version control and collaboration :)
[13:40] <luks> what does that mean?
[13:40] <gour> loxs: hmm, reST is so simple and one can write it in Notepad
[13:40] <luks> bzr can do it just fine, if you use my definition
[13:41] <gour> loxs: and using some bzr-gui it's easy for your contributors to commit and/or send you 'bundles' for merging
[13:41]  * gour --> lunch.bbs
[13:43] <loxs> I'm afraid that I need rich formatting in a WSIWYG editor... so rest is not the best option, gour
[13:44] <loxs> it's not technical documentation, but medical one...
[13:44] <Odd_Bloke> Well, versioning ODTs in bzr won't be pretty.
[13:44] <loxs> and we need to collaborate on things like presentations etc
[13:44] <Odd_Bloke> Or, for that matter, much better than saving copies of the ODT, AFAIK.
[13:44] <luks> versioning binary files won't be pretty in any vcs
[13:45] <luks> but as this question is in #bzr, I don't think that's the problem
[13:45] <Odd_Bloke> But if you could get it in an intermediate format, then things might be better.
[13:45] <loxs> yeah, after all I can give up and use google docs :(
[13:46] <loxs> the thing is that I want the docs "in-house" :)
[13:46] <luks> it's not like google docs can merge documents better than bzr
[13:47] <jonnydee> hi, when I try to push my branch to a shared repository via ftp protocol I get:
[13:47] <jonnydee> zr: ERROR: Transport error: FTP temporary error during APPEND /bzr-repo/.bzr/repository/upload/bh3t4m7b8vud2womzv46.fetch.Aborting. 451 /bzr-repo/.bzr/repository/upload/bh3t4m7b8vud2womzv46.fetch: Append/Restart not permitted, try again
[13:47] <jonnydee> Does anyone know what this means?
[13:47] <luks> jonnydee: your FTP server doesn't support APPEND
[13:47] <luks> jonnydee: which probably means you can't use it with bzr
[13:48] <guilhembi> weird... after a "bzr pull" of the latest bzrtools, all bzrtools command are gone (absent from "bzr help commands")...
[13:48] <jonnydee> well, that's not good news :(
[13:48] <Odd_Bloke> guilhembi: What do you see in ~/.bzr.log?
[13:48] <guilhembi> Odd_Bloke: I see
[13:48] <guilhembi> 'dict' object has no attribute 'register_lazy'
[13:48] <guilhembi> Unable to load plugin 'bzrtools' from '/home/guilhem/.bazaar/plugins'
[13:49] <luks> you are using old bzr, upgrade to 1.9
[13:49] <guilhembi> on the screen, that's interesting... now updating to latest bzr.dev
[13:49] <luks> or downgrade bzrtools
[13:49] <guilhembi> luks: thanks, it's the solution
[13:51] <jonnydee> I just asked our IT to create an ftp account for hosting bazaar branches and now the APPEND functionality should be the problem? ok, I see I will not be able to use Bazaar in our company... :(
[13:52] <Odd_Bloke> jonnydee: :(
[13:52] <Odd_Bloke> Do you really only have FTP to access your servers?
[13:52] <jonnydee> thanks Odd_Block
[13:52] <Odd_Bloke> You might want to start slapping your IT department around if that's the case. :p
[13:53] <jonnydee> well there is also a windows network share...but this one is not reachable from our development-intranet network. the only server which is reachable from everywhere is our ftp server....
[13:54] <jonnydee> ok, anyway, thanks
[13:55] <Odd_Bloke> It seems likely that a workaroubnd could exist (i.e. fetch remote file, append locally, push new file back).
[13:55] <Odd_Bloke> But I don't know where append is used, so that might be prohibitive in terms of performance.
[13:55] <luks> I wonder what do packs need append for
[13:57] <Odd_Bloke> jonnydee: Could you paste the .bzr.log section for the command run in question?
[13:57] <Odd_Bloke> Or, better, file a bug containing it.
[13:58] <jonnydee> ok, I will file a bug. Thanks for your attention.
[13:59] <Odd_Bloke> jonnydee: No worries.  Sorry this didn't work. :(
[14:01] <jonnydee> Maybe one day I will be able to use Bazaar in our development team. At the momen I can at least use it locally...
[14:27] <gour> loxs: have you considered something like lyx (latex-front end)? it's wysiwym
[14:28] <gour> loxs: it can be nicely versioned, it has some collaboration tool integrated...
[14:31] <loxs> hm, a good idea gour, thanks
[14:32] <loxs> but that will solve only the "doc" needs, we still have to find a way for the presentations
[14:32] <gour> loxs: use latex beamer class for presentation and create presentation in pdf without worrying whether it can be presented or not ;)
[14:33] <loxs> the thing is that the documents will be written by people who have never heard of latex
[14:34] <gour> loxs: check http://wiki.lyx.org/Examples/Beamer....well lyx hides almost all of latex stuff, it's like wysiwyg editor
[14:36] <gour> loxs: i was once burnt with binary format when working on one book and was not able to open it next day - program was crashing immediately...after that, i never wrote and save in binary format...only text formats (LaTeX, ConTeXt, reST....)
[14:36] <loxs> yet, I think it will be impossible to convert them to lyx.... I had gread difficulties to make them use OO, and I think it's impossible to change them any more :)
[14:37] <Odd_Bloke> The LyX beamer stuff probably isn't good enough...
[14:38] <gour> Odd_Bloke: good enough for what? you mean OO has better features?
[14:39] <Odd_Bloke> Sorry, good enough for people who don't want to know about LaTeX.
[14:39] <Odd_Bloke> I vastly prefer Beamer to any other presentation software, but always use vim for it.
[14:39] <Odd_Bloke> I do use LyX for other documents.
[14:39] <gour> ahh, ok then ;)
[14:39]  * gour is moving to ConTeXt instead of lyx/latex
[14:40] <Odd_Bloke> That sounds suspiciously Mac-like.
[14:40] <loxs> never heard of context
[14:41] <jonnydee> Odd_Bloke: I've just filed a bug regarding my previously reported issue: https://bugs.launchpad.net/bzr/+bug/294709
[14:41] <Odd_Bloke> jonnydee: Thanks. :)
[14:42] <gour> Odd_Bloke, loxs: check http://wiki.contextgarden.net/Main_Page
[14:42] <gour> it's kind a 'what-latex3-is-supposed-to-be-one-day'
[14:45] <jonnydee> Odd_Bloke: You're welcome :)
[14:58] <fynn> Hi. How do I serve a bzr repo off a dumb HTTP server?
[15:03] <Odd_Bloke> fynn: Put it somewhere HTTP accessible.
[15:05] <fynn> Odd_Bloke: can I just put an empty directory with the .bzr dir inside it?
[15:22] <Odd_Bloke> fynn: Just 'bzr branch <BRANCH> <PUBLICALLY ACCESSIBLE LOCATION>'.
[15:25] <luks> um, `bzr push <PUBLICLY_ACCESSIBLE_LOCATION>` instead?
[15:35] <fynn> OK, that would publish a working copy with its .bzr directory, right?
[15:35] <NfNitLoop> not if the destination is remote.
[15:36] <NfNitLoop> bzr doesn't try to build a working copy when it pushes to remote locations.
[15:36] <NfNitLoop> for performance reasons (I think?)
[15:37] <fynn> sounds like "a bare repository" in git...
[15:41] <Keybuk> Why isn't the bzr-svn in the PPA installable?
[15:54] <Odd_Bloke> luks: I don't know, I fail. :p
[15:54] <Odd_Bloke> Keybuk: I think mostly because PPAs don't keep old versions of packages around.
[15:56] <Keybuk> Odd_Bloke: the version of bzr-svn in the PPA explicitly depends on the version of bzr *not* in the PPA though
[15:56] <Keybuk> that's kinda odd
[15:56] <Odd_Bloke> Keybuk: A newer version or an older version?
[15:57] <Keybuk> it depends:
[15:57] <james_w> a new bzr-svn hasn't been uploaded yet
[15:57] <Keybuk> bzr >= 1.6~, bzr << 1.8~
[16:01] <fynn> one more question: is there a way to publish a bzr repo on a dump HTTP server as a single file?
[16:01] <Odd_Bloke> fynn: You could just tar it up.
[16:02] <fynn> Odd_Bloke: would people be able to pull directly from the tarred form?
[16:03] <luks> fynn: no
[16:03] <fynn> OK, it's like git in that sense then.
[16:03] <fynn> you need to publish the full .bzr tree if you want people to pull from it.
[16:04] <luks> right
[16:04] <sven> hi! when i run 'bzr visualize', it says "bzr: ERROR: No module named dbus  You may need to install this Python library separately.". but i have dbus installed.
[16:04] <sven> i'm using the current development branch of bzr, and the latest dbus that comes with ubuntu
[16:06] <Odd_Bloke> sven: Check the appropriate part of ~/.bzr.log.
[16:07] <sven> Odd_Bloke, ok, here: http://pastebin.com/m38ce1a03
[16:11] <fynn> OK, not sure I got it:
[16:11] <fynn> how do I clone to a bare repository in Bazaar?
[16:11] <fynn> ("bare" == a repository without a working copy, essentially only the .bzr directory)
[16:12] <luks> first you need to fix your terminology
[16:12] <luks> you can't clone a repository, you can get a copy of a branch
[16:12] <luks> `bzr branch PUBLIC_LOCATION`
[16:12] <fynn> OK, and how do I make a copy of a branch that contains only the .bzr, and no working files?
[16:13] <luks> I don't think you can do it directly, either setup a treesless local repository and run `bzr branch` or run `bzr branch` followed by `bzr remove-tree`
[16:14] <luks> or better, what are you doing?
[16:14] <fynn> publishing a bzr repo over a dumb HTTP server.
[16:14] <luks> maybe it's something git-specific for which has bzr a different solution?
[16:15] <luks> what's the use case for a not having the working tree?
[16:15] <luks> locally, of course, it won't be on the server
[16:16] <fynn> the server is not to house a working tree, because nobody is editing files on the server.
[16:16] <fynn> it's just a server to pull/push from/to.
[16:16] <luks> right, so it's a misunderstanding
[16:16] <sven> Odd_Bloke, did .bzr.log tell you anything?
[16:16] <luks> let's say you have ~/project (where you work) and ~/public_html/bzr/project (where you want to publish the repo)
[16:17] <luks> now, in ~/project you run `bzr push ~/public_html/bzr/project`
[16:17] <luks> and on another computer you run `bzr branch http://example.com/~user/bzr/project`
[16:17] <luks> that's all
[16:18] <luks> you can replace ~/public_html/bzr/project with any bzr-supported procotol, e.g. sftp://example.som/home/user/public_html/bzr/project
[16:19] <luks> fynn: did that help or did I confuse you even more? :)
[16:20] <fynn> luks: "now, in ~/project you run `bzr push ~/public_html/bzr/project`" -> but wouldn't that recreate also the working tree of ~/project inside ~/public_html/bzr/project?
[16:20] <luks> fynn: no
[16:20] <luks> fynn: oops, yes if it's local
[16:21] <luks> fynn: in that case run `bzr remove-tree` in ~/public_html/bzr/project
[16:21] <luks> fynn: but if it's a different server, you won't need it
[16:22] <fynn> luks: right, and it looks like 'bzr remove-tree' in a branch makes it a "working-copy-less" branch, i.e. what git calls "a bare branch"
[16:22] <luks> fynn: yes, but in case of pushing over network if will not create the working tree
[16:23] <luks> fynn: it happens only if you push to a local location
[16:23] <fynn> so it's the same concept, and the same outcome, just that in bzr for local branching, it's a two-step process (push and remove-tree) while in git it's a single step with a switch (clone with the --bare flag.
[16:24] <fynn> luks: thanks a lot, all clear now.
[16:24] <fynn> luks: ah, there's another small different.
[16:24] <fynn> *difference
[16:24] <luks> note that it will remember the "no working tree" flag, so if you push the next time it will be all fine
[16:24]  * fynn nods
[16:25] <fynn> in git, if you create a bare branch in ~/public_html/bzr/project, ~/public_html/bzr/project would contain the contents of ~/project/.git directly.
[16:25] <Odd_Bloke> sven: Sorry, I've been called away.
[16:25] <Odd_Bloke> Someone else here should be able to help you though.
[16:25] <fynn> in bzr, it would contain ~/project, it's just that if you also did remove-tree, it would only contain .bzr inside, and no working files.
[16:28] <sven> Odd_Bloke, hmm, actually, from looking at the code it seems like you need not only dbus, but the bzr-dbus plugin. a bit hard to tell from the error message though
[16:48] <sven> hi! i'm having trouble using the latest bzr-gtk development branch, because it depends on the dbus plugin, which fails to compile for me with the message "libxml-2.0 >= 2.6.0... configure: error: No XML library found, check config.log for failed attempts". i have the version 2.6.31-dfsg-2ubuntu1.2 libxml2 package installed
[16:49] <sven> or rather, dbus fails to configure
[16:59] <jam> guilhembi: ping
[17:43] <emmajane> beuno, ok there's your bug for today. :)
[17:44]  * beuno looks
[17:45] <beuno> emmajane, I have some work done already which addresses that  :)
[17:45] <emmajane> woo!
[17:45] <emmajane> I should double check that the other bug that I commented on (that mpt commented on) makes sense as well...
[17:46] <emmajane> it's sort of the same problem...
[17:46] <beuno> yeah, navigation needs re-working
[17:46] <beuno> it's high on my list
[17:46] <emmajane> cool
[17:47] <emmajane> I think my biggest problem with LP is the navigation. And it's hard to interact with the site when I can't find things. :)
[17:49]  * emmajane goes back to boring work now.
[17:49] <beuno> emmajane, so is mine!  :)
[17:49]  * beuno goes back to fun work
[17:50] <emmajane> :)
[18:06] <guilhembi> jam: sorry I missed your ping; going to dinner now, bbl
[18:06] <jam> guilhembi: np
[18:07] <jam> Just wanted to talk about the upgrade stuff
[18:24] <EarthLion> hey how can i get a list of all the files that have been changed between revno x and revno y?
[18:25] <beuno> EarthLion, bzr log -r X..Y -v --short?
[18:26] <EarthLion> many thanks
[18:26] <james_w> "bzr st -r X..Y" as well
[18:27] <beuno> oh, status has revisionspec
[18:27] <beuno> interesting
[18:27] <EarthLion> bzr st -r 86..91 actually works better in this situation because i get a summary list rather then a revision to revision breakdown
[18:28] <beuno> yeah, james_w is much smarter
[18:29] <james_w> heh :-)
[18:29] <beuno> and today is his birthday, so we have to be extra nice to him
[18:29]  * emmajane sings the birthday song to james_w 
[18:30] <emmajane> without tune, but with appreciation for his bzr cleverness. :)
[18:31] <Peng_> Oh, really? Happy birthday. :)
[18:32]  * awilkins sends james_w a cookie
[18:33]  * beuno avoids singing. Even on IRC
[18:33] <james_w> thanks everyone :-)
[18:35]  * gour is singing...happy birthday to you, happy birthday to you...happy birthday dear james_w, happy birthday to youuuuuuuuuuuuuuuuuuuuuuuuuuuuu
[18:36] <jam> hey, let me join in... happy b-day james_w
[18:41]  * gour sends nice cake to james_w http://www.iskcon.net.au/kurma/2008/02/20#a4566
[18:42] <NET||abuse> hi guys,.. just did a series of stuff for the first time with bazaar and svn, the process so far looks a little like the following=>  bzr branch svn+ssh://blah.... ; hack; bzr commit; hack; bzr commit; bzr merge; bzr commit; hack; bzr commit; bzr merge; bzr commit; and i'm finally trying to do bzr push; but it says it doesn't have a remembered location
[18:46] <james_w> gour: that is a very nice cake, thanks
[18:50] <emmajane> Where can I find documentation on how to accept a proposed "code" change in launchpad? I'm going to be helping the training team, but I've never done this before...
[18:51] <emmajane> we'll be using bzr to push changes to LP... and then ... what happens next?
[18:52] <beuno> emmajane, nowhere yet, it's work-in-progress
[18:52] <beuno> but, basically, you push, go to the branch, "propose for merge", do the reviewers dance
[18:52] <beuno> and merge
[18:53] <beuno> LP will mark it as merged when it seessss the tip of the proposed branch in trunk
[18:53] <emmajane> yeah, it's the reviewer's dance that I need to know about.
[18:54] <beuno> ah, well
[18:54] <beuno> by default
[18:54] <beuno> the review will be requested to the owner of the targetted branch
[18:54] <gour> james_w: i'm glad you like it. i bought kurma's DVD set (11 disc) fulle of great vegat. dishes...
[18:54] <emmajane> beuno, https://wiki.ubuntu.com/Training/KnowledgeBase <--- what happens after step 7
[18:54]  * beuno looks
[18:55] <gour> james_w: see http://kurma.net/videos/index.html and bon appetit ;)
[18:55]  * emmajane rewrote the instructions last night with popey. Suggestions welcome if I'm missing or wrong about anything. :)
[18:56] <beuno> emmajane, well, the reviewer bit really just concerns the reviewer, mostly
[18:56] <beuno> once you file the merge proposal
[18:56] <beuno> you have to wait for the reviewer to approve it
[18:56] <emmajane> beuno, yup. and the reviewer instructions won't be included on this page...
[18:56] <beuno> (you don't really have to, it's a social constraint)
[18:57] <beuno> once he reviewed it, you'll get an email saying so
[18:57] <beuno> and if he approved
[18:57] <emmajane> my reviewer doesn't know how to use LP. I need to teach her. :)
[18:57] <beuno> well... usually the reviewer merges it into trunk
[18:57] <beuno> ah, double the fun
[18:57] <emmajane> yes :)
[18:58] <emmajane> we taught the team how to branch the documentation from LP last night.
[18:58] <emmajane> next we we're teaching how to push back up. but I also need to help out with how to accept merges.
[18:59] <beuno> ah, I see
[18:59] <beuno> hrm
[18:59] <beuno> I can send you something
[18:59] <emmajane> that would be great. :)
[19:14] <fynn> is there a way to convert a git repo to BZR?
[19:23] <lifeless> fynn: yes, fastexport it
[19:23] <lifeless> there is info on the bzr wiki
[19:25] <fynn> lifeless: thanks.
[19:40] <thrope> so the rc1-3 windows installer tortoisebzr seems to work - but I still can't find a way to add a file from the context menu
[19:40] <thrope> am I missing something?
[19:40] <Odd_Bloke> bzr-buildpackage should be able to work out when I'm building a native package from the changelog, right?
[19:40] <Odd_Bloke> james_w: *catches up with scrollback* Happy birthday. :)
[19:46] <lifeless> garh spammers
[19:56] <maco> hi, i want to use bzr on a directory.  i'm not sure which bzr ____ command to use though.
[19:56] <james_w> Odd_Bloke: thanks.
[19:56] <james_w> Odd_Bloke: it doesn't detect it from the changelog, you have to use --native or set it to native mode
[19:56] <lifeless> maco: what is ____ ?
[19:57] <lifeless> Odd_Bloke: people have been known to upload as native non-native packages and vice versa
[19:57] <maco> lifeless: well i *think* i have to put something after "bzr" since in the manpage there's like "bzr add" and "bzr branch" and all that...
[19:57] <lifeless> maco: have you read the tutorial ?
[19:57] <maco> ive only ever branched from things that were already in bzr
[19:58] <maco> um...where?
[19:58] <lifeless> maco: http://doc.bazaar-vcs.org/bzr.1.9/
[19:58] <lifeless> if you've used bzr before, and you just want to know how to make a brand new project - just 'bzr init project-root'
[19:59] <lifeless> where project-root is the path to the existing project files (and if omitted defaults to '.')
[19:59] <maco> lifeless: thank you
[20:01] <emmajane> maco, http://doc.bazaar-vcs.org/bzr.1.9/en/mini-tutorial/index.html <--- skip to that one. the other pages are scary. :)
[20:04] <maco> aha
[20:06] <maco> emmajane: thanks, the part where it mentions +junk just explained the cryptic error i got trying to push to lp :P
[20:06] <maco> this "bzr: ERROR: Generic bzr smart protocol error: Permission denied: "/~maco.m/fusa"
[20:07] <maco> doesn't really explain much
[20:07] <emmajane> maco, ahh
[20:07] <emmajane> maco, have you told bzr about your LP account?
[20:08] <emmajane> bzr launchpad-login LPLOGINNAME
[20:10] <maco> emmajane: it was upset by "fusa".  i had to expand it to fast-user-switch-applet
[20:10] <emmajane> maco, all solved now?
[20:10] <maco> yep
[20:10] <emmajane> WOO!
[20:11] <maco> still dont think that error message is terribly helpful though
[20:11] <emmajane> maco, that I can't help with :/
[20:11] <lifeless> jml: ^ is there are bug?
[20:11] <emmajane> maco, are you on the mailing list? You could suggest an improved message...
[20:12] <lifeless> emmajane: its a launchpad error
[20:12] <emmajane> lifeless, heh. Good ol' launchpad.
[20:13] <thumper> what about launchpad?
[20:13] <thumper> lifeless: I feel like I've missed something...
[20:13] <lifeless> thumper: the error on an unknown project in a branch path
[20:13] <thumper> lifeless: oh, I'm about to talk to bkor about gnome
[20:13] <lifeless> thumper: permission denied is less informative
[20:13] <thumper> lifeless: on a conf call, want to join us?
[20:13] <lifeless> thumper: skype?
[20:13] <thumper> lifeless: my conf call number
[20:13] <lifeless> oh hmm
[20:14] <lifeless> its 7am, got getting up things to do;
[20:14] <lifeless> if you'd like me there I'll join, but I don't think I'm critical
[20:14] <thumper> lifeless: if something comes up I may ping
[20:15] <lifeless> sure
[20:15] <lifeless> do that
[20:50] <NET||abuse> hmm, bzr push's back to the svn repo make a lot of notes come up in the rss report
[21:21] <lifeless> NET||abuse: I believe that some of the default change->notification scripts are overly sensitive
[21:21] <lifeless> there was a thread about this recently on the list
[21:22] <NET||abuse> really? hmm,
[21:22] <lifeless> (on the svn side)
[21:28] <NET||abuse> so on the server i can tone down the notification scripts
[21:29] <NfNitLoop> Woo!   I got the OK to do a presentation about bzr/bzr-svn here to try to convince people to adopt it.
[21:30] <lifeless> sweet
[21:30] <lifeless> NET||abuse: should be able to filter it out yes
[21:30] <lifeless> also the first one is the worst AIUI
[21:48] <NET||abuse> NfNitLoop: if you do a full blown presentation, you should publish any notes or slides or even video the thing
[21:48] <NET||abuse> vimeo rocks.
[21:54] <NET||abuse> hmm, can you use bazar as teh server, and svn as a client?
[21:54] <NET||abuse> in a mixed svn/bzr client base
[21:59] <dobey> no, i don't think so
[22:04] <dobey> you can use bzr-svn to interact with an svn server, i don't think there is an svn-bzr to do the reverse
[22:09] <NET||abuse> hmm, ok
[22:13] <LarstiQ> well, there is ish
[22:14] <LarstiQ> but it's not as mature as bzr-svn
[22:14] <lifeless> jam: let me know if you want to chat re: those things in the repository branch
[22:14] <lifeless> dobey: 'bzr svn-serve', a jelmer production
[22:15] <dobey> oh
[22:15] <dobey> n/m then
[22:15] <dobey> i guess you can do that
[22:16] <LarstiQ> dobey: in practicality I think you're right, unless I have severely missed development on svn-serve
[22:17]  * LarstiQ goes to bed, ciao
[22:36] <lifeless> spiv: ping
[22:36] <lifeless> spiv: I've pushed
[22:36] <lifeless> spiv: can you send again?
[22:37] <spiv> Ok.
[22:38] <lifeless> thanks
[22:48] <lifeless> spiv: ping
[22:48] <lifeless> spiv: how are you generating that bundle?
[22:49] <lifeless> spiv: is it using your local mirror, o r my branc on people, or something else a gain?
[22:49] <jam> poolie, lifeless: What do you think about creating a bzr.dev mirror that would be in 1.9 format?
[22:49] <jam> My back-of-the-envelope numbers show it being a pretty big win for me
[22:49] <jam> and even if I upgrade my local repo, I don't really get the benefit
[22:50] <lifeless> jam: I'm fine with that
[22:50] <lifeless> alternatively, wait for 1.10 or 1.11 and upgrade bzr.dev
[22:50] <Peng_> How often would the bzr.dev mirror be updated?
[22:50] <jam> lifeless: well, I think it would be good to have someone/some people actively using it before we make it primary branch
[22:50] <spiv> lifeless: your branch on people'
[22:50] <Peng_> Better performance would be cool, but I'd use the most up-to-date repo instead.
[22:51] <Peng_> s/repo/branch/
[22:51] <jam> Peng_: well, we used to do the same thing for the weaves => knits and then the knits => packs upgrades
[22:51] <lifeless> spiv: its included changes to Makefile
[22:51] <spiv> lifeless: "bzr send http://people.ubuntu.com/~robertc/baz2.0/repository/"
[22:51] <jam> I think it was updated each time pqm committed
[22:51] <jam> if not, < every hour
[22:51] <Peng_> That works then.
[22:51] <Peng_> How do the smart server and LP factor into this?
[22:52] <Peng_> I mean, what's optimal?
[22:52] <jam> Peng_: I'm not quite sure what you are looking for.
[22:52] <lifeless> today httpw/btrees is probably optimal pull
[22:52] <jam> I can't tell LP to mirror a branch into a different format
[22:52] <lifeless> future is smart server for sure
[22:52] <jam> and if I could, it still only allows 1 mirror of a public branch
[22:53] <lifeless> jam: I think peng is asking about performance and so on, not about making mirrors :P
[22:53] <lifeless> Peng_: lp will support 1.9 formats soon
[22:53] <Peng_> Right.
[22:53] <jam> Peng_: So in working on: https://answers.edge.launchpad.net/bzr/+question/38599
[22:53] <jam> I worked out that the new index format can often transmit < 1/8th the data the old format used
[22:53] <Peng_> Wow
[22:53] <jam> and that is when both are performing "optimally"
[22:54] <jam> which the new format has a much better time getting to
[22:54] <jam> the big issue is log2(N) for bisection, versus log100(N) for btree
[22:54] <jam> both are logarithmic, but the constant factor is a big deal
[22:55] <Peng_> How relevant are btree indexes when pulling over the smart server? Do they even get accessed over the vfs?
[22:55] <lifeless> Peng_: today, they are directly read
[22:58] <Peng_> lifeless: FWIW, I wrote a trivial patch to work around one Python 2.6 warning in bzr-search. (I don't know if there are others.) http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/
[22:58]  * Peng_ shrugs
[22:58]  * fullermd can't help thinking that SS VFS support was a mistake...
[22:58] <Peng_> heh
[22:58] <lifeless> http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6 is permanently redirected to /loggerhead/bzr-search/py2.6/changes
[22:59] <lifeless> http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/ is permanently redirected to http://bzr.mattnordhoff.com/bzr/bzr-search/py2.6/
[22:59] <Peng_> :D
[22:59] <Peng_> Oh.
[22:59] <Peng_> The bzr branches are at /bzr and Loggerhead is at /loggerhead. I did a small hack to redirect /loggerhead/.../.bzr/ to /bzr/.../.bzr/, but I guess it wasn't enough for everything.
[23:00] <lifeless> Peng_: oh it worked
[23:00] <lifeless> just a bit, circuitous
[23:00] <lifeless> Peng_: anyhow, my osutils has no md5 symbol
[23:00] <Peng_> It's rather new.
[23:00] <lifeless> Peng_: right, so this will break compatibility with older bzr's
[23:00] <Peng_> Yeah.
[23:01] <Peng_> Might be better to live with the warning or do a try/except ImportError yourself.
[23:01] <lifeless> try:
[23:01] <lifeless>     from bzrlib.osutils import md5
[23:01] <lifeless> except ImportError:
[23:01] <lifeless>     from md5 import new as md5
[23:01] <lifeless> from bzrlib.osutils import split_lines
[23:02] <lifeless> seems to work, except jam's index changes cause the whole test suite to barf on the lower range map not being parsed
[23:03] <lifeless> Peng_: future reference, please put something in NEWS :)
[23:03] <spiv> lifeless: I've done another send, it might work better for you
[23:04] <jam> lifeless: ?
[23:04] <lifeless> Peng_: how do you prefer your name in NEWS - Matt Nordhoff ?
[23:04] <lifeless> jam: https://bugs.edge.launchpad.net/bzr-search/+bug/293906
[23:05] <Peng_> lifeless: Oh. Yes.
[23:06] <Peng_> jam: Nice job on your "back of the envelope" calculations.
[23:07] <Peng_> Might be useful to put them in the docs somewhere.
[23:08] <jam> lifeless: ah, sounds like you need to switch over to _nodes from time to time.
[23:08] <jam> though I thought you were using btree indexes for bzr search anyway
[23:09] <lifeless> jam: no, I need to implement key-element-prefix-iteration to do that
[23:09] <lifeless> search is damn fast anyway, because it's use pattern doesn't fragment index buffers
[23:11] <lifeless> jam: interestingly, using _nodes is probably going to be slower in some cases here :P - because the parsed key map is sorted
[23:11] <lifeless> jam: so what I'll probably be doing is backing out your heuristics in the subclass
[23:12] <jam> lifeless: anyway, I'm done for the night
[23:12] <lifeless> jam: sleep well
[23:14] <lifeless> spiv: thanks, commit+pushing
[23:26] <lifeless> spiv: it is pushed btw