[00:08]  * Foskasse Já tenho (sqrt(350)-0.7082869*cos(20)-0.4192478) ANOS!
[00:08]  * Foskasse Happy birthday to me guys!!
[01:56] <lifeless> hi
[01:57] <mwhudson> hi lifeless
[01:57] <mwhudson> lifeless: isn't it like 3am for you now?
[01:58] <lifeless> 4
[01:58] <bob2> ep?
[01:58] <lifeless> GYADEV
[01:58] <mwhudson> lifeless: eurg
[01:58] <Odd_Bloke> lifeless: Ah, are you at GUADEC?
[01:59] <Odd_Bloke> I'll take 'GYADEV' as a 'yes'. :p
[02:00] <lifeless> yes
[02:00] <lifeless> Currently jetlagging; and waking up jamesh
[02:00] <mwhudson> lifeless: just woke up, or still awake?
[02:01] <lifeless> just woke \
[02:02] <lifeless> poolie: on NEWS (420MB corpus), bit of a pathological case perhaps:
[02:02] <lifeless> gaip it all: 136MB
[02:02] <lifeless> bzip it : 36MB
[02:02] <poolie> hello lifeless
[02:02] <lifeless> our knit hunks in bzr.dev: 4.5MB
[02:02] <poolie> did you mean gzip?
[02:03] <lifeless> 7zip(lzma) the 420MB as one file ccatted together - 215KB
[02:03] <lifeless> poolie: yes
[02:04] <lifeless> git repacking at 200,200 638KB
[02:04] <bob2> how about rzip?
[02:04] <lifeless> my first attempt with my new compressor: 600KB
[02:04] <lifeless> bob2: dunno
[02:05] <lifeless> and its outputting some really badly chosen sequences thanks to sequence matcher
[02:09] <lifeless> lp:~lifeless/+junk/bzr-groupcompress
[02:12] <Odd_Bloke> A gnome-terminal extension that made those clickable would be awesome.
[02:21] <poolie> lifeless: nice
[02:22] <poolie> or an irc bot that expands them to http url
[02:31] <mwhudson> can i rename a thread in a loom?
[02:31] <lifeless> mwhudson: there is a bug, I would love a ptch
[02:31] <lifeless> mwhudson: it includs the workaround
[02:32] <lifeless> call to prayer has just starter
[02:34] <mwhudson> lifeless: i can't find the bug, although https://bugs.edge.launchpad.net/bzr-loom/+bug/203287 and https://bugs.edge.launchpad.net/bzr-loom/+bug/203203 are relevant to what i'm trying to do
[02:34] <ubottu> Launchpad bug 203287 in bzr-loom "unable to create a new bottom thread" [High,Triaged]
[02:35] <lifeless> mwhudson: basically make a new thread called newname and delete oldname
[02:35] <mwhudson> lifeless: but i want to create a new bottom thread
[02:35] <lifeless> mwhudson: you want to rename the bottom thread?
[02:35] <mwhudson> lifeless: yeah
[02:35] <lifeless> so do what I said
[02:36] <mwhudson> well, i just started again, the loom was about 10s old
[02:36] <lifeless> mwhudson: switch bottom && create-thread foo && swtich bottom && combine-thread
[02:37] <mwhudson> lifeless: ah right
=== Linnk is now known as Tank|Away
[03:23] <lifeless> wooo
[03:23] <lifeless> new version;
[03:24] <lifeless> 360181
[03:25] <lifeless> and 0.5 seconds to get it back
[03:25] <lifeless> which is 0.03 seconds slower than bzr.dev
[03:27] <lifeless> pushing now, trying to sleep again
[03:28] <Odd_Bloke> lifeless: Sleep well!
[05:08] <alecwh> I'm trying to push to a repository, and I'm getting this error: bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ephpns-team/phpns/head/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[05:08] <alecwh> the command I used: "bzr push lp:phpns"
[05:08] <mwhudson> bzr launchpad-login
[05:09] <alecwh> No Launchpad user ID configured.
[05:09] <alecwh> How do I fix this?
[05:10] <bob2> bzr launchpad-login yourlaunchpadusername
[05:11] <alecwh> mwhudson: bob2: Thanks a bunch, that worked!
[05:46]  * arjenAU prods igc
[06:17] <lifeless> poolie: how is stacking landing going?
[06:29] <stewart> i'm having an issue. bzr serve using recent 1.6 tree on linux, trying to "bzr branch" from the server on a Windows XP install of 1.5 and getting "Could not understand response from smart server: ('error', ",module' object has no attribute 'SmartServerRepositoryStreamRevisionsChunked'')
[06:37] <spiv> stewart: hmm, sounds like a bug.  1.5 is the version on the server?
[06:37] <poolie> hello lifeless, i'm debugging the anotate failures atm
[06:37] <poolie> arjenAU: he's sick today i think
[06:37] <stewart> spiv: no, 1.5 is client.
[06:37] <poolie> or away anyhow
[06:37] <arjenAU> poolie: he's awake and talking to me anyway ;-)
[06:37] <spiv> stewart: ah, hmm.  I'll just take a look
[06:37] <arjenAU> poolie: but tnx
[06:37] <stewart> spiv: i'm pulling latest dev tree for server now, i'll see if that helps.
[06:38] <spiv> stewart: I see the bug, and it's still in bzr.dev
[06:38] <spiv> stewart: I'll just send a patch to fix it, thanks for the report!
[06:38] <stewart> spiv: cool. easy fix by any chance?
[06:39] <stewart> spiv: can you cc me on the patch? stewart @ mysql dot com
[06:39] <spiv> Yeah, just deleting some lines from bzrlib/smart/request.py
[06:40] <spiv> (We unimplemented some RPCs in 1.6 as part of the fallout from the VersionedFiles reworking Robert did.  Performance impact should be minimal for pack format repositories.)
[06:40] <spiv> stewart: I'll do that.
[06:42] <stewart> spiv: thanks!
[06:43] <stewart> will try patch as soon as i receive it.
[06:49] <spiv> stewart: sent
[07:25] <arjenAU> stewart: can you be on im?
[07:25] <stewart> arjenAU: yepp... am now
[07:25] <arjenAU> good lad
[07:50] <stewart> spiv: now i'm getting (on client) "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this)". Is that intentional?
[07:51] <spiv> stewart: heh.  Yes, although that is a bit confusing it's unavoidable I think.
[07:51] <stewart> spiv: well, at least it's doing something now. i'll see how long the branch takes
[07:52] <spiv> stewart: thanks.  Let us know if it takes noticeably longer than having 1.5 on the server.
[07:58] <stewart> spiv: no disk space has been used on client yet :(
[08:03] <spiv> stewart: is that worse than before?  Damn.
[08:04] <stewart> spiv: haven't tried explicitly with 1.5 server... but would have expected quicker.
[08:05] <spiv> You could try "bzr -Dhpss ..." instead of "bzr ..." and looking at the ~/.bzr.log to see what it's doing.
[08:05] <spiv> Hmm...
[08:05] <stewart> spiv: it's a mysql tree, generally, over the internet branching it should take about 20mins. the majority of that being at about full speed of the network link. Now it's transferring something though... but only at up to about 200k/sec
[08:05] <stewart> sometimes bursts...
[08:05] <spiv> If it is dropping back to the <1.2 RPCs, it's probably going to take longer fetch graph data.
[08:07] <spiv> Part of the reason for the protocol changes in 1.6 is so we don't need unnecessary reconnections with mismatched client/server versions in future.
[08:11] <stewart> spiv: at least it's going... but not fast. at least, i'd expect faster considering on local network.
[08:12] <spiv> stewart: yeah, that doesn't sound good.  I think 1.5 is figuring that if the server doesn't support streaming pull, it also doesn't support get_parent_map
[08:13] <stewart> spiv: it's getting data now... but only 82.3MB so far
[08:13] <spiv> Streaming pull shouldn't matter too much with a pack repo, but get_parent_map still does.
[08:13] <spiv> (Especially if the repo hasn't been packed recently)
[08:14] <stewart> spiv: there's 15 pack,s one of which is 550MB
[08:14] <spiv> Some friction is unavoidable when client and server are different versions :/
[08:15] <stewart> spiv: yeah, no doubt. perhaps when 1.6 windows installers are up it'll be better...
[08:16]  * spiv nods
[08:16] <stewart> hopefully branching subsequent branches into the repository is a lot faster
[08:16] <spiv> I think mhammond posted a test 1.6b3 installer to the list.
[08:16] <spiv> Yeah, it should be.
[08:16] <stewart> 113MB now
[08:17] <spiv> Upgrading the client will definitely help, when that becomes possible for you.
[08:18] <stewart> spiv: is this what you meant: http://www.nabble.com/Experimental-1.6b3-windows-binaries-available-td18168374.html
[08:18] <spiv> Right.
[08:25] <AfC> Oh, for the love of...
[08:25] <AfC> Launchpad: The URI scheme "bzr" is not allowed.  Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp ... This is the external location where the Bazaar branch is hosted.
[08:25] <AfC> (when trying to add a remote branch)
[08:26] <andrea-bs> AfC: you have to use bzr+ssh:// or lp: , not bzr://
[08:27] <AfC> Ridiculous.
[08:29] <stewart> spiv: tried with new version. instead getting "socket.error: (10055, 'No buffer space available')". so this time it doesn't work at all :)
[08:29]  * stewart will try rebooting the windows client vm... it did say to do that in the installer...
[08:29] <spiv> stewart: woah!
[08:30] <stewart> darn non-operating operating systems
[08:30] <spiv> stewart: That's surprising.  I thought we'd squished all those.
[08:30] <spiv> And I wouldn't have expected the changes in 1.6 to cause that.
[08:30] <spiv> stewart: please file a bug with a traceback for that
[08:31] <stewart> spiv: will do.
[08:31] <spiv> stewart: past experience with that error suggests we know what to do about it once we get a traceback :)
[08:31] <stewart> will just double check
[08:48] <stewart> spiv: filed at https://bugs.launchpad.net/bzr/+bug/246180
[08:48] <ubottu> Launchpad bug 246180 in bzr "no buffer space available" [Undecided,New]
[08:50] <spiv> stewart: Thanks!
[08:50]  * spiv heads to the shops
[08:50] <stewart> now to go back to 1.5 so i can actually get the source tree there
[09:00] <arjenAU> stewart: funny how your bug ended up here and mine did not. it's #246178 also for bzr
[09:00] <stewart> joy... i just have to swear at windows a lot now...
[09:00] <stewart> gah
[09:26] <mathrick> so, what is the proper way of accessing bzr from non-python languages
[09:28] <beuno> mathrick, one way is using the xmloutput plugin
[09:36] <lifeless> beuno: hiya
[09:37] <beuno> lifeless, evening!
[09:38] <AfC> Ah, Launchpad, crashing my browser. I love it.
[09:41] <siretart> is there an easy (scriptable) way to report the latest revision of the current branch?
[09:41] <siretart> with revid, that is
[09:42] <spiv> bzr revision-info
[09:43] <RAOF> siretart: There was also a recent blog post about incorporating bzr into the build process; there was a bzr command to substitude various branch info in a string.
[09:45] <RAOF> Ah, right.  bzr version-info is what I'm thinking of.
[09:47] <siretart> aah, that's cool. thanks
[10:11] <mathrick> beuno: mhm, and is there some more systematic approach to calling into python from outside
[10:12] <mathrick> ?
[10:13] <beuno> mathrick, well, I suppose that depends on the language, it's bindings, etc
[10:14] <mathrick> beuno: yeah, but how do you bind from, say, C to python?
[10:14] <beuno> mathrick, I wouldn't know  :)
[10:14] <mathrick> particularly I'm interested in common lisp -> python, but C is good enough, I can manage from there
[10:14] <mathrick> beuno: oh
[10:15] <mathrick> so you were just saying without any actual background?
[10:15] <mathrick> I mean, the bindings etc. need to work somehow
[10:15] <mathrick> I guess it's #python time
[10:15] <beuno> mathrick, sounds like something outside of bzr's scope, yes
=== arjenAU2 is now known as arjenAU
[10:49] <Odd_Bloke> poolie: We could do with having a chat.  I'm currently pretty much on GMT+7 sleeping patterns, so sometime tomorrow morning for you would be best (as I'm pretty tired and about to head bedwards).
[10:54] <poolie> heh me too :)
[10:55] <poolie> well, not sleep, but go offline
[11:13] <lifeless> spiv: ping
[11:32] <Laibsch> How do I merge two bzr branches?  "bzr branch $branch1;cd $branch1;bzr merge $branch2" tells me that revision $XY is not present in object $YZ
[11:33] <Laibsch> The two branches are unrelated as far as bzr is concerned, there is no common ancestor or something like that
[11:36] <markh> Let's say I made a branch of bzr.dev, made local commits and pushed it to a *new* branch.  What is the fastest way to get a diff against the original branch?
=== Tank|Away is now known as Linnk
[11:37] <AfC> bzr diff -r ancestor:../path/to/branch
[11:38] <AfC> Can be quite useful
[11:38] <AfC> bzr diff -r branch:../path/to/branch
[11:38] <AfC> on other occasions
[11:38] <markh> ah, cool, thx.  'ancestor' is a special 'keyword'?
[11:38] <AfC> markh: whether that applies to you in your situation I couldn't say
[11:39] <markh> it gives me a clue I didn't have, so gives me something to read up on - thx!
[11:39] <AfC> markh: it's a namespace, yes. Like tag: and the others at
[11:39] <AfC> bzr help revisionspec
[12:12] <Stavros> hmm, bzr 1.5 crashes rather frequently :/
[12:12] <Stavros> is this a known issue?
[12:13] <fredo> Hello!
[12:14] <Peng> Stavros: Um, details?
[12:14] <Peng> Stavros: And, you mean that it exits with a traceback, right?
[12:15] <fredo> Just one question: Is it possible to integrate bzr into a python application? Let's say I want to write a version controlled wiki, can I interface bzr from within my app without calling it on the command line?
[12:15] <Stavros> Peng, yes, it crashed with various errors at least three times in the past two days
[12:15] <Stavros> i'm reporting one of them right now
[12:16] <Peng> Stavros: Good. You should report the others too. :)
[12:16] <Stavros> it just crashes too frequently for comfort, even during commits :/
[12:16] <Stavros> the others were reported already
[12:16] <Peng> fredo: import bzrlib
[12:16] <fredo> Peng: Thanks!
[12:16] <fredo> Where do I find the docs for bzrlib?
[12:16] <Peng> fredo: bzrlib is the entirety of Bazaar. The bzr script is just a simple wrapper that calls into bzrlib.
[12:17] <fredo> Ah, ok. Thanks!
[12:17] <Peng> fredo: Um, there are API docs somewhere. There's also other stuff in doc/ in the source and the website.
[12:17] <fredo> I'll have a look into this.
[12:17] <fredo> Yes, I think I found the API doc.
[12:18] <semslie> quick question about bzr-svn: I have some branches that were checked into subversion via bzr-svn (for the purposes of working with the other members of our team). I've noticed that when those branches are checked out into a new repository then "bzr visualise" doesn't show the branch history, but rather one flat line of history. However it obviously does know about its branch-point, because merging that branch into another will produce the correct history. 
[12:19] <jelmer> semslie: It doesn't push the right hand side revisions, though it does know about them
[12:34] <AfC> jelmer: do you have a minute? (pm)
[12:35] <jelmer> AfC, yeah
[12:35] <AfC> k
[12:35] <LarstiQ> stewart: out of interest, which bugs are those?
[12:35] <Peng> Oh, look. I've been having a problem with bzr-svn for a couple days, and I was just abotu to report it, but it works correctly now. :)
[12:35] <LarstiQ> ehm
[12:35] <semslie> jelmer: okay, I think that makes sense with that I'm seeing
[12:35] <LarstiQ> s/stewart/Stavros/
[12:36] <jelmer> semslie: if you pull in the changes from elsewhere (the original bzr branch for example) it will show them
[12:36] <LarstiQ> jelmer: when are you at guadec?
[12:37] <jelmer> LarstiQ: didn't make it
[12:38] <semslie> jelmer: the situation is that a work mate is getting interested in all the bazaar activity and gave it a try. The visualisation tool gives a tangible sense of the activity that has been taking place on the bazaar side, so he was a bit disappointed not to see it straight away.
[12:38] <LarstiQ> jelmer: hokay
[12:38] <LarstiQ> jelmer: I have a free bed here at EP ;)
[12:40] <Peng> Cool, bzr-svn is importing tags now too. :)
[12:42] <jelmer> semslie: see also bug 158883
[12:42] <ubottu> Launchpad bug 158883 in bzr-svn "ability to push non-lhs revisions" [Wishlist,Triaged] https://launchpad.net/bugs/158883
[12:42] <jelmer> LarstiQ: :-)
[12:44] <semslie> jelmer: nice to see its on the list. what are the challenges in pushing non-lhs revisions?
[12:45] <jelmer> semslie: They can't be pushed to the same location as the lhs revisions
[12:45] <jelmer> semslie: Since they don't have the same ancestry
[12:46] <jelmer> semslie: So they have to be pushed to /branches/foo
[12:47] <semslie> jelmer: so is it not just a case of storing metadata about the non-lhs revisions? I've noticed that if I made the branch in my bazaar repo, then push to svn, then check out again into the same repo then I see all the threads of activity.
=== fred1 is now known as fredo
[13:00] <jelmer> semslie: metadata about what the non-lhs revisions are is already stored
[13:00] <jelmer> semslie: the revisions themselves are just not stored
[13:00] <jelmer> semslie: You'll see that if you run "bzr log --show-ids" the non-lhs revisions are mentioned
[13:04] <semslie> jelmer: oh right, that makes sense and would explain why you then see those revisions as soon as they become available
=== Linnk is now known as Tank|Away
[13:57] <jelmer> beuno, ping
[13:57] <jelmer> semslie: Yep
[13:57] <beuno> jelmer, pong
[13:59] <jelmer> beuno: bzr-upload was rejected due to faulty upload
[14:00] <beuno> jelmer, hrm, so the DD uploaded wrong?  or was it an issue with the packaging?
[14:01] <jelmer> beuno: It was uploaded incorrectly
[14:02] <beuno> jelmer, ugh, I'll ping the DD and nag then, sorry
[14:02] <jelmer> beuno: No worries, the sponsoring is much appreciated :-)
[14:03] <lifeless> Jc2k: ping
[14:03] <Jc2k> lifeless: pong
=== tale is now known as tethridge
[14:05] <lifeless> Jc2k: so, JFDI huh? thought thats what we were doing :).
[14:06] <Jc2k> lifeless: they dont know that yet
[14:07] <Jc2k> i mean, we still need to jfdi for the supporting stack
[14:07] <Jc2k> wrong words
[14:07] <Jc2k> we need to fix bkors stuff :)
[14:07] <lifeless> Jc2k: totally; thought I get the impression hes given it a go and it just worked :)
[14:07] <lifeless> Jc2k: e.g. bonsai -> bzr-search :)
[14:08] <Jc2k> eh
[14:08] <lifeless> s/thought/though
[14:09]  * Jc2k looks forward to "Bazaar JFDI" post :)
[14:09] <lifeless> we need the precommit hooks trasnscribed
[14:10] <Jc2k> where are you guys at?
[14:10] <Jc2k> have retreated to hotel to hack for a bit
[14:10] <lifeless> I'm in the vcafeteria getting power
[14:10] <lifeless> the evolution talk was interesting
[14:15] <Jc2k> ahh i think i'd already left
[14:15] <Jc2k> DVCS DVCS Swag taxi hacking :)
[14:16] <lifeless> Jc2k: :)
[14:16] <lifeless> Jc2k: you're at the golden horn ?
[14:17] <Jc2k> lifeless: about 5 minutes away at hotel aslan
[14:18] <lifeless> in sultanahmet
[14:18] <siretart> is there a shortcut for 'bzr revert file -r"the branch I'm merging from"'?
[14:18] <siretart> in case of conflicts, that is
[14:19] <Peng> siretart: You can use the .OTHER file.
[14:19] <james_w> siretart: "mv file.OTHER file" ?
[14:19] <james_w> siretart: but other than that I don't think so (e.g. if you have resolved the file, or there weren't conflicts in the first place)
[14:19] <lifeless> Jc2k: cool
[14:23] <siretart> james_w: Peng: that doesn't resolve the 'conflited' state
[14:24] <Peng> siretart: Yeah, then you need to run bzr resolved $file.
[14:24] <siretart> Peng: bzr revert doesn't require that. but it is rather clumsy to loop up 'the other' revision id
[14:26] <quicksilver> maybe there shuld be
[14:26] <quicksilver> bzr resolve-other FILE
[14:26] <quicksilver> bzr resolve-this FILE
[14:26] <quicksilver> would be a trivial plugin.
[14:27] <siretart> bzr resolve --other would do it, I think
[14:29] <jelmer> Laibsch, ping
[14:31] <mathrick> jelmer: bzr: ERROR: Repository KnitPackRepository('file:///home/mathrick/Dev/python/.bzr/repository/') is not compatible with repository SvnRepository('svn+ssh://maciek@svn.gnome.org/svn/epiphany-extensions')
[14:31] <mathrick> which one is compatible?
[14:31] <jelmer> mathrick: bzr upgrade --rich-root-pack
[14:31] <mathrick> aha, thanks
=== thekorn_ is now known as thekorn
[14:45] <mathrick> jelmer: humm, how do I make the shared svn / bzr checkout?
[14:46] <jelmer> mathrick: How do you mean?
[14:48] <mathrick> jelmer: I want a dir that's both a valid svn working tree and a bzr branch
[14:49] <jelmer> mathrick: You mean something that has both a .bzr and .svn subdirectory ?
[14:50] <jelmer> you need to pass --no-plugins to bypass bzr-svn to do that
[14:51] <mathrick> jelmer: or alternatively, if I bzr commit to an svn working tree, will it do what I want?
[14:52] <jelmer> mathrick: Yes, committing in a svn working tree should work
[14:53] <mathrick> jelmer: good, and what happens if I svn up it behind bzr's back?
[14:54] <jelmer> that will work as well
[14:54] <mathrick> cool
[14:54] <jelmer> the only two things that don't work are merge and revert
[14:54] <mathrick> so bzr ci will be local, and svn will still work?
[14:54] <jelmer> bzr ci won't be local
[14:54] <jelmer> it will upload the changes to subversion
[14:55] <jelmer> (since there is no local branch)
[14:55] <mathrick> oh
[14:55] <jelmer> if you would like to use offline commits, use a bzr branch locally
[14:56] <jelmer> commit to that, and once you're done, "bzr push" into Subversion
[14:57] <mathrick> jelmer: the thing is that I wanted to work on stuff I manage with jhbuild, and which is in an upstream svn repo. So I wanted jhbuild to be able to do its stuff (ie. update the checkout and compile and install things), but have it also backed up by a local branch
[14:57] <mathrick> does it make sense?
[14:58] <mathrick> it would be no problem to have the local bzr branch if it wasn't for the fact that it's the svn working dir the source gets installed from
[14:58] <jelmer> mathrick: How hard would it be to add bzr support to jhbuild?
[14:58] <mathrick> dunno, I think it already does it
[14:59] <mathrick> right, I can just create a local moduleset
[14:59] <mathrick> jelmer: thanks for making me think straigtht :)
[14:59] <jelmer> (-:
[15:10] <Laibsch> jelmer: pong
[15:11] <lifeless> Jc2k: thumper would like to clone your svn update logic
[15:11] <lifeless> Jc2k: can you spare some time to tell him, or jamesh about this?
[15:15] <jelmer> Laibsch, Were you Rolf?
[15:16] <fredp> mathrick: Jc2k has his work on bzr-mirror support for jhbuild; but it is already possible to set bzr as the program to do svn checkout
[15:19] <lifeless> mathrick: also, http://bzr-mirror.gnome.org:8080/jhbuild/trunk/changes
[15:19] <lifeless> mathrick: (you can just pull jhbuild from there using bzr  :)) - hmm, actally remove the :8080, thats only the web viewer
[15:20] <fredp> also don't hesitate to report enhancement requests to jhbuild bugzilla
[15:20] <Laibsch> jelmer: Yes
[15:23] <mathrick> fredp, lifeless: ah, thanks, will look into it
[15:27] <jelmer> Laibsch: I was wondering whether there would be any chance you can try reproducing bug 245763 with a later bzr-svn
[15:27] <ubottu> Launchpad bug 245763 in bzr-svn "svn import fails" [Undecided,Incomplete] https://launchpad.net/bugs/245763
[15:28] <Jc2k> lifeless: sure
[15:29] <Laibsch> jelmer: later than 0.4.9-1?  Where to get it for hardy?
[15:29] <Laibsch> well, actually debian sid
[15:29] <Laibsch> this was on a remote machine
[15:29] <jelmer> Laibsch: Debian sid has 0.4.10-2 now
[15:29] <Laibsch> OK, I can try that
[15:30] <Laibsch> once I get a connection ;-)
[15:30] <Laibsch> right now the machine seems to be down
[15:35] <lifeless> Jc2k: we're heading to hotel now; but perhaps you could mail the scripts etc to them?
=== thekorn_ is now known as thekorn
[16:45] <fredp> is there any tool like cvs2cl or svn2cl, to produce a ChangeLog from bzr history?
[16:45] <fredp> bzr log --log-format=changelog would sure be nice.
[16:46] <jelmer> fredp: there is a plugin that does that I think
[16:46] <jelmer> It's probably listed on the plugin page (http://bazaar-vcs.org/BzrPlugins)
[16:46] <fredp> GNU changelog formatter for bzr log
[16:46] <fredp> nice
[16:47] <fredp> google had a lot of noise
[18:04] <jelmer> Laibsch: no hurry :-)
[18:05] <Laibsch> I'm afraid you might need to remind me
[18:05] <Laibsch> The machine is still down
[18:07] <jelmer> k, will do
[18:07] <CyberSnooP> Hi everyone. Am I supposed to be able to create tags in an bzr svn checkout?
[18:07] <jelmer> CyberSnooP: only when using the 0.4 branch, not in any released version
[18:08] <CyberSnooP> Ah, okay. Spend some time in the wiki, but couldn't find it as a limitation
[18:10] <jelmer> there is an open bug report about it
[18:16] <kdehoff> Hi.  I need to run an odd setup and I'm not sure if it's even possible.
[18:17] <leo2007> is there any convention how to write a log entry when checking in using BZR
[18:17] <jelmer> kdehoff: ?
[18:17] <kdehoff> I'm attempting to set up a set of repositories on an old sun server
[18:18] <CardinalFang> leo2007, for what project?
[18:18] <kdehoff> They need to be accessed from within and outside of a firewall, with HTTP/S being the only transport optin
[18:18] <kdehoff> But the users want to control who can and cannot read and/or write to their files
[18:18] <leo2007> just for general guideline, CardinalFang
[18:19] <kdehoff> From the documentation, it doesn't look promising, but access control isn't really touched on much
[18:20] <CardinalFang> leo2007, generally, make sure your log audience understands what you're doing.
[18:23] <james_w> leo2007: there isn't a general one, but keeping a short first line summary makes for better output with the line log formatter.
[18:24] <jelmer> kdehoff: I think there's indeed not an awful lot at the moment
[18:24] <jelmer> you may be able to use apache access control to some extend but I don't have experience with that
[18:27] <kdehoff> So for the HTTP server, the files are generally served as any other web page?
[18:29] <leo2007> james_w: thanks
[18:30] <jelmer> kdehoff: there are several methods
[18:30] <jelmer> kdehoff: you can use webdav to upload to .bzr/ using the webdav plugin for Bazaar
[18:30] <jelmer> kdehoff: or you can use the smart server which I think relies on mod_python
[18:31] <jelmer> kdehoff: with the webdav plugin you should be able to control who can read/write to a particular branch
[18:31] <jelmer> kdehoff: it wouldn't allow access control within the branch
[18:31] <jelmer> I'm not sure whether something like that is also possible with the smart server, it may well be
[18:32] <jelmer> the smart server will most likely be faster than the webdav plugin
[18:32] <jelmer> also, the smart server works out of the box for all clients whereas webdav would require the clients to install the webdav plugin first
[18:33] <kdehoff> would the apache "user" need write access for the smart server?
[18:33] <jelmer> I think so
[19:28] <Pieter> Jc2k: was the meeting bad?
=== Tank|Away is now known as Linnk
[20:07] <james_w> hey rockstar. You were after me the other day, sorry I missed you. Was it anything I can still help with?
=== mw is now known as mw|food
[20:39] <alf> Hello
[20:41] <alf> I was wondering what is the recommended way of handling trivial changes to a project
[20:43] <alf> eg is it better to have a 'trivial' branch instead of creating a feature branch for each small change
[20:47] <alf> or perhaps commit directly on the trunk?
[20:48] <beuno> alf, a trivial branch sounds fine
[20:48] <beuno> but it's so cheap making branches in a shared repo, I usually just do a branch
=== mw|food is now known as mw
[20:52] <alf> beuno, thanks, what about changing the (local branch of) trunk directly (svn style)
[20:53] <beuno> alf, well, that's cheaper I suppose, although for the workflow I have, that doesn't work
[20:53] <beuno> I have a branch of trunk locally
[20:53] <beuno> and pull regularly
[20:53] <beuno> and I don't change it so I don't have to merge
[20:58] <alf> beuno, you mean you don't have to merge with the remote trunk, just push?
[20:59] <beuno> alf, right, I pull a copy locally
[20:59] <beuno> and merge that into other branches
[21:01] <alf> beuno, and when you wang to publish changes you merge them directly to the remote trunk or through the local copy?
[21:02] <beuno> alf, I merge trunk into my feature branch, and push that branch into the mainline
[21:02] <beuno> I basically keep a mirror of trunk locally
[21:07] <alf> beuno, thanks, there are so many ways of using bzr and finding your own way can be a challenge :-)
[21:08] <beuno> alf, yeah, you may even find more then one that fits you well
[21:12] <alf> beuno, perhaps it would be useful if some of the experienced users/developers published their own ways (eg in the bzr wiki) so that newer users can see some alternatives
[21:13] <beuno> alf, there was a thread on the mailing list recently...
[21:13] <beuno> let me dig that up for you
[21:14] <beuno> hrm, can't find it
[21:19] <jelmer> beuno: if you have some time, any chance you can do more bzr-gtk reviewing?
[21:20] <beuno> jelmer, sure, I'll try and do some later tonight
[21:20] <alf> beuno, it's ok, i'll take a look myself and perhaps send an email to the list
[21:20] <jelmer> beuno: Thanks :-) I'll see if I can do that release at the end of the week
[21:21] <alf> beuno, you have been very helpful, thanks
[21:21] <beuno> jelmer, sounds great. I'll still be distracted this week, but hopefully I'll get some time in the hotel
[21:21] <beuno> alf, my pleasure
[21:23] <Verterok> beuno, jelmer: hi
[21:23] <jelmer> Verterok, hi!
[21:23] <beuno> hey Verterok!
[21:24] <Verterok> jelmer: thanks for bb:approve ;)
[21:25] <jelmer> Verterok: You're welcome :-) bzr-svn already uses that functionality if it's present
[21:27] <Verterok> nice! :)
[21:49] <mwhudson> hello
[21:49] <jelmer> mwhudson!
[21:52] <mwhudson> this seems a bit ominous
[21:54] <jelmer> oh noes, that's a dictionary word
[21:54] <jelmer> mwhudson: not to worry, I only filed a few more launchpad-bazaar bugs...
[21:55] <mwhudson> jelmer: oh, ok, i'm sure i'll get round to reading my bugmail folder at some point
=== Linnk is now known as Tank|Away
[22:02] <mwhudson> jelmer: the most recent one is a duplicate in fact
[22:02] <jelmer> mwhudson: oh, ok. sorry
[22:02] <mwhudson> np
=== Tank|Away is now known as Linnk
=== mw is now known as mw|out