[00:01] <poolie> spiv, hello
[00:01] <poolie> spiv, lifeless, igc, jam, call in a sec
[00:05] <jelmer> 'morning spiv, poolie
[00:05] <jelmer> how should I figure out what the parent revisions of an existing file text revision are?
[00:06] <jelmer> CommitBuilder.record_entry_contents() doesn't take any text_parents arguments
[00:14] <jelmer> lifeless: ^
[00:21] <jml> abentley: how come I have to do 'bzr up' rather than 'bzr co' in the branches that export-loom makes?
[00:22] <lifeless> jelmer: it assigns the value itself
[00:23] <jelmer> lifeless: what if the text wasn't changed but inherited
[00:23] <jelmer> ?
[00:23] <lifeless> it may or may not assign a new one based on the per file graph
[00:23] <poolie> hello jelmer, lifeless
[00:24] <poolie> spiv, oh well that was probably a good place to wrap up
[00:24] <lifeless> what's the goal here, reimplementing this, or using it ?
[00:24]  * jml waves
[00:24] <poolie> good luck
[00:24] <spiv> poolie: :)
[00:24] <jelmer> lifeless: but there's no way for CommitBuilder to figure out what the parents of a text are when recording an existing text
[00:24] <lifeless> jelmer: it has the parent trees as state
[00:24] <lifeless> jelmer: read the code :P
[00:24] <jelmer> lifeless, The parents of the text I mean
[00:24] <jelmer> lifeless: If you commit a merge for example and the merged revision is a ghost
[00:25] <jelmer> lifeless, and one of the texts wasn't changed
[00:25] <lifeless> then it cannot calculate it correctly because the ghost data is absent
[00:25] <jelmer> lifeless, is there no way to determine what the parents of the text are?
[00:25] <lifeless> so it calculates it based on the available data
[00:25] <lifeless> jelmer: you keep repeating this, but I'm really not understanding if you are asking a question, making an assertion, or seeking help solving a problem
[00:25] <jelmer> all three
[00:25] <lifeless> the statment doesn't make sense to me
[00:26] <lifeless> perhaps you could unpack whats going on so I'm not guessing at quite so much at once
[00:26] <jelmer> So, let me start by explaining the issue I'm trying to solve
[00:27] <jelmer> bzr-svn needs to make sure that the parents recorded for a text revision are correct
[00:27] <jelmer> generally, it will induce the parents for a specific text from the information in svn
[00:28] <jelmer> if that doesn't help, it'll look a specific svn property
[00:34] <jelmer> lifeless, Never mind, I just answered my own question
[00:34] <lifeless> :P
[00:34] <lifeless> jelmer: so commit builder has enough state to look in each inventory that is available to determine the files presence, and last-changed, in that inventory
[00:35] <lifeless> jelmer: doing a commit with ghosts should never happen except for an importer from tla
[00:35] <lifeless> ghosting is something that happens deliberately, after revisions are created, not adhoc
[00:35] <jelmer> lifeless: The thing is, bzr-svn uses the commit code also when pushing
[00:35] <lifeless> jelmer: when pushing, there should be no ghosts though
[00:35] <jelmer> lifeless: There can be - when pushing into svn you're not necessarily pushing merged revisions as well
[00:36] <lifeless> also, there is a hole in our ghost support infrastructure; a last-changed value in an inventory which is the value of a ghost will cause checkout/export to fail
[00:36] <jelmer> yes, several people have hit that using bzr-svn
[00:36] <lifeless> yah
[00:37] <lifeless> back shortly, food calls
[00:37] <lifeless> spiv: please let me know if my branch hook patch was sufficient unto the tests
[00:38] <spiv> lifeless: I'll take a look now
[00:38] <jelmer> lifeless: thanks for playing soundboard (hope that's a correct translation)
[00:41] <lifeless> jelmer: sounding board is probably more common, but soundboard is totally understandable :P
[00:42] <spiv> lifeless: looks ok to me.  I can't think of any other worthwhile unit tests to add.
[00:43] <lifeless> spiv: well, its approved once trunk unfreezes
[00:43] <lifeless> spiv: I was more meaning 'does it do what you need'
[00:49] <spiv> lifeless: Oh I see.  Yes, I think so.
[01:02] <lifeless> right, its now yours, enjoy.
[01:03]  * LaserJock crosses his fingers
[01:03] <LaserJock> darn
[01:03] <LaserJock> lifeless: james_w set me up with a little hacky script to import both debian and ubuntu source packages
[01:04] <LaserJock> I got one to work fine
[01:04] <LaserJock> but 2 have died
[01:04] <mwhudson> ah, hi LaserJock
[01:05] <LaserJock> hi mwhudson
[01:05] <mwhudson> LaserJock: i didn't do anything about the matplotlib vs python2.4-matplotlib thing
[01:05] <LaserJock> oh?
[01:05] <mwhudson> LaserJock: i just confused about what the right thing would be
[01:05] <lifeless> LaserJock: oh, shame.
[01:06] <mwhudson> oh, wrong channel
[01:06] <mwhudson> except you're not in #launchpad :)
[01:06] <LaserJock> mwhudson: I'll join #launchpad
[01:09] <LaserJock> lifeless: well, it would be fun if it just worked without any problems
[01:09] <LaserJock> lifeless: but it looks like I might be able to help debug bzr-builddeb
[01:09] <LaserJock> so that's good anyway :-)
[01:13] <lifeless> LaserJock: cool
[01:14]  * markh cheers lifeless on his review-athon :)
[01:17] <jelmer> oops
[01:17] <jelmer> 95 % of the memory usage of bzr-svn appears to be in reading ~/.subversion/config
[01:19] <RAOF> jelmer: That's with respect to the crazy "eat 1GB of ram on multi-pull" bug?
[01:19] <jelmer> RAOF: Yep
[01:20] <spiv> jelmer: whee!
[01:20]  * RAOF wonders how one can blow 1gb resident on reading a config file :)
[01:20] <jelmer> it's parsing ~/.subversion/ for reading every file multi-pull tries to open
[01:20] <jelmer> and multi-pull tries to open a lot of files
[01:20] <RAOF> Aaah.  And no GC gets done?
[01:24] <jelmer> RAOF, Nope
[01:25] <jelmer> RAOF, Ok, that fixes it..
[01:26] <markh> lifeless: in the abspath mail you said to add a test that "sets sys.platform to something windows" - can you please elaborate?
[01:26] <markh> did you mean *checks*?
[01:27] <LaserJock> anybody got an idea of what http://paste.ubuntu.com/44717/ means?
[01:27] <LaserJock> it looks like it's trying to make a path with non-ASCII characters
[01:28] <markh> LaserJock: or possibly even any parent being non-ascii
[01:29] <LaserJock> is that anywhere in the bzr branch?
[01:29] <LaserJock> or does that just apply to the root directory of the branch
[01:30] <lifeless> markh: no, I mean sets
[01:30] <lifeless> markh: you have conditional code based on the platform right?
[01:31] <markh> so set sys.platform for the benefit of other platforms to be able to test it?
[01:31] <poolie> yay bubba :)
[01:31] <lifeless> markh: set sys.platform so that other platforms test that case, yes.
[01:31] <markh> heh - I'd figured that might be a dangerous thing to do, but OK...
[01:32] <lifeless> markh: look for sys.platform in the osutils tests
[01:32] <markh> will do, thx
[01:32] <lifeless> probably can be cleaner than that is, but its an example
[01:33]  * markh goes to wait in line for an hour at the chinese embassy...
[01:34] <lifeless> markh: off to china?
[01:34] <markh> yeah - brother getting married there next month!
[01:35] <markh> I was actually visiting him there earlier this year - quite amazing - but you really need someone who speaks the language close by :)
[01:35] <markh> (which he does)
[01:43] <jml> markh: does he *read* the language?
[02:48] <lifeless> markh: when you get back, I have a branch I'd appreciate your testing
[02:51] <Verterok> a7p: still around?
[02:55] <a7p> jep
[02:55] <a7p> but I won't last more than another 30 minutes
[02:55] <Verterok> ok
[02:56] <Verterok> I'll make it short enough :)
[02:56] <Verterok> a7p: I can't reproduce the crash, also I don't see any related error in the log
[02:56] <Verterok> a7p: could you check ~/Library/logs/Java?
[02:56]  * a7p starts up a terminal
[02:57] <Verterok> if the jvm crashed, there should be a log there
[02:58] <a7p> jep, got a couple of eclipse-crashfiles here
[02:59] <a7p> should I attach one to the bug?
[02:59] <Verterok> a7p: please :)
[03:01] <a7p> Verterok: done
[03:02] <Verterok> thanks! I'll keep digging
[03:04]  * a7p keeps supplying useless treasuremaps
[03:11] <Verterok> a7p: not so useless :)
[03:12] <a7p> ;)
[03:12] <Verterok> a7p: it seems like a bug was fixed in Eclipse 3.3
[03:13] <a7p> would be pritty bad, if they only introduced new ones... *g*
[03:13] <Verterok> a7p: http://lists.apple.com/archives/Java-dev/2007/Nov/msg00014.html
[03:15] <Verterok> a7p: sorry, "it seems that a similar bug was fixed in 3.3"
[03:16] <a7p> looks, pretty much like my problem.
[03:20] <Verterok> a7p: the widget used in the commit dialog will be replaced, pretty soon. it's a work in progress
[03:21] <a7p> wounderful, nice to hear
[03:21] <a7p> if i understood correctly, this is a osx 10.5 issue - other platforms won't suffer from it.
[03:22] <Verterok> I'll try to rollout a new build as soon as possible
[03:27]  * a7p looks happily forward to it - Thanks Verterok, that's Bugreporting the way I like it.
[03:27] <a7p> and now I'm going to put my tired head to rest
[03:29] <lifeless> fooding
[04:14] <Peng_> I should just try this myself, but what does Bazaar do if, when using HTTP, a /.bzr/ directory redirects somewhere else?
[04:14]  * Peng_ tries it himself.
[04:19] <lifeless> spiv: http://marc.info/?l=linux-netdev&m=122091500114869&w=2
[04:21] <lifeless> spiv: details on why coalescing the bytes written to the socket helped
[04:23] <Peng_> Oh, good, it works.
[04:24] <spiv> lifeless: that's a nice clear description of things
[04:25] <spiv> lifeless: It's a pity I learned that stuff the hard way rather than by reading about it :)
[04:25] <lakin> Is there a pdf version of the html guide?
[04:25] <lakin> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[04:25] <lakin> ?
[04:27] <lifeless> Peng_: you can redirect a branch, redirecting a repository is likely to die horribly
[04:28] <markh> jml: apparently well enough to read signs and stumble through things, but not well enough to comfortably read a newspaper for example
[04:28] <markh> lifeless: how can I help?
[04:28] <lifeless> markh: test my patch
[04:28] <markh> which one? :)
[04:28] <lifeless> the one I cc'd to you
[04:28] <lifeless> that prominently asks for help :P
[04:28] <markh> _walkdirs
[04:28] <markh> oh :)
[04:29] <jml> markh: when I visited, I found the inability to read the language much more frustrating than being unable to speak it.
[04:30] <markh> jml: I doubt we would have survived ordering in some of the places we ate at, for example.  We would have ended up having a much more "westerners" experience I think
[04:31] <markh> I remember once thinking "surely I can order a coffee" - and failed misterably :)
[04:32] <markh> the "coffee" part was understood, but trying to explain I wanted it to take away was a sticking point :)
[04:32] <lifeless> just get it, then walk out the door
[04:33] <markh> yeah, and just keep walking :)
[04:33] <lifeless> well no, stop and let them change it around now they get the message :P
[04:37] <Peng_> lifeless: Well, I'm redirecting both the branch and repo (from /foo/... to /bar/...). Hopefully it'll be okay.
[04:39] <Peng_> lifeless: BTW, this is very trivial, but I think bzr-search's cmd_index wastes a transport. It opens one, and then passes the URL to index_url, which opens it again.
[04:39] <lifeless> Peng_: patches appreciated :P
[04:41] <Peng_> lifeless: Heh. But what should I change it to do? Make index_url accept a transport? Rename index_url to index_transport or something?
[04:46] <lifeless> Peng_: I think there is a transport taking helper already
[04:47] <lifeless> Peng_: if there isn't, split the current one in two, and call the helper
[04:54] <markh> lifeless: is there a subset of the tests I can specify?  Otherwise things get lost in the noise...
[04:54] <lifeless> ./bzr selftest --no-plugins osutils win32 walkdirs
[04:55] <markh>   File "O:\src\bazaar\bzr\bzr.lifeless\bzrlib\tests\branch_implementations\test_parent.py", line 95, in test_win32_set_parent_on_another_drive
[04:55] <markh>     base_url = b.abspath('.')
[04:55] <markh> AttributeError: 'BzrBranch6' object has no attribute 'abspath'
[04:56] <markh> x7 times
[04:56] <lifeless> heh
[04:56] <lifeless> well thats unrelated :P
[04:59] <uniscript> anyone know a way of using bzr on an svn project, but with local storage but not the whole history?
[04:59] <markh> lifeless: they are the only errors
[05:00] <Peng_> Hmm, I think it winds up opening the branch twice too.
[05:01] <lifeless> markh: cool
[05:01] <lifeless> markh: care to review it ? :)
[05:01] <markh> having a quick look now
[05:01] <lifeless> uniscript: branch --stacked
[05:02] <uniscript> but the docs say that that's just a light checkout or am I reading it wrong?
[05:02] <uniscript> i.e. can I branch, ci merge etc. with such a branch locally with no access to the svn repo?
[05:03] <uniscript> and then just push / merge upstream later?
[05:05] <markh> hrmph - I'm not testing much as I haven't run a build
[05:06] <markh> things are a little uglier when I do :(
[05:08] <markh> lifeless: http://pastebin.com/m27ccab4c
[05:10] <lifeless> markh: could you fix?
[05:10] <lifeless> markh: the intent should be pretty obvious
[05:10] <markh> not today :(
[05:10] <lifeless> sure
[05:11] <lifeless> No windows dev environment here at the moment, so I can't
[05:11] <markh> np
[05:11] <lifeless> uniscript: no, no-access requires full history copied, today.
[05:11] <uniscript> OK thanks, at least I know not to go chasing after the wind :)
[05:12] <lifeless> uniscript: partial-local-storage is what you asked for :P, sorry that its not enough
[05:12] <uniscript> you say "today" is  it in the pipeline?
[05:12] <lifeless> long term plans, nothing to hold breath over :)
[05:13] <uniscript> I can imagine that people would like to join an svn repo from some revision onwards
[05:13] <uniscript> Or I suppose it can be part of the ability to consolidate bzr repos
[05:13] <uniscript> does that exist?
[05:13] <lifeless> I'm not sure what you mean
[05:13] <uniscript> clear out irrelevant history?
[05:14] <uniscript> say I have 1000 revisions in my repo
[05:14] <uniscript> and I don't want all that history kept, can I say merge 200-300 as one revision and dump all that history?
[05:15] <Peng_> Wait, it's just a one-line change to fix this.
[05:16] <Peng_> Well, that's to stop it from wasting one transport. There are others too.
[05:21] <Peng_> lifeless: Do you mind if I pass "foo/" to index_url instead of an URL like "file:///path/to/foo/" or whatever?
[05:29] <lifeless> Peng_: for testing?
[05:41] <lifeless> bug 248275
[05:41] <lifeless> poolie: ^ is that a bubba alias?
[05:42] <mwhudson> i think it's probably a different mentally ill person
[05:44] <Peng_> lifeless: No, because it's the least-invasive way to get rid of that wasted transport (it's just used like get_transport(url).base)
[05:45] <lifeless> Peng_: oh. well foo/ isn't a url, its a url fragment or possibly a unicode path
[05:45] <lifeless> I'd rather not pass paths to url functions, bad things tend to eventually happen
[05:47] <Peng_> ok
[07:01] <vila> good morning bazaar !
[07:18] <lifeless> man I hate libc maintainers sometimes
[07:19] <lifeless> st_mtime is a         def __get__(self):
[07:19] <lifeless>             return self._mtime
[07:19] <lifeless> bad paste sorry
[07:19] <lifeless> st_mtime is a defined macro from bits/stat.h now :(
[07:27] <lifeless> ok
[07:27] <lifeless> 10% shaving by using a compiled stat object
[08:21] <jonnydee> hi, I
[08:21] <jonnydee> 've got a question:  I've got a checkout and did a "bzr ci --local" yesterday. Today I did a "bzr up" and now my local commit from yesterday shows up as a pending merge. Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge?
[08:22] <jonnydee> (for the case my last sentence got cut):  Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge?
[08:23] <jonnydee> and what effects does a "bzr update" have on the local repository if it contains local commits?
[08:26] <Peng_> jonnydee: (Your last sentence didn't get cut. IRC's line length limit is closer to 500 chars, and many/most IRC clients handle it sensibly.)
[08:28] <Peng_> jonnydee: Sorry, but I don't have experience with checkouts, so I can't really answer your question.
[08:28] <jonnydee> Peng_: ok thanks for your feedback
[08:29] <bob2> it's a lightweight checkout?
[08:29] <jonnydee> no, a normal checkout
[08:29] <jonnydee> does it make any difference?
[08:29] <jonnydee> (in my case)
[08:31] <Peng_> jonnydee: My wild guess would be that you can't avoid a merge, because it would require rebasing, and bzr isn't big on that.
[08:31] <Peng_> But I don't know the mechanics of local commits in checkouts, so that may be wrong.
[08:33] <jonnydee> probably you are right... So I'll do a merge... Thanks a lot for your help :)
[08:39] <jml> lifeless: you raiding tonight?
[08:49] <sabdfl> bzr diff -r date:2008-09-09,09:00:00
[08:49] <sabdfl> doesn't seem to work
[08:49] <sabdfl> any suggestions?
[08:55] <uws> sabdfl: bzr diff -r date:2008-09-09T09:00:00
[08:55] <spiv> sabdfl: seems to work ok for me
[08:56] <uws> with a comma it works for me as well
[08:56] <sabdfl> ./bzr diff -r date:2008-09-09TO09:00:00        ~/software/bzr.dev
[08:56] <sabdfl> bzr: ERROR: Requested revision: u'date:2008-09-09TO09:00:00' does not exist in branch: BzrBranch7('file:///home/mark/software/bzr.dev/')
[08:56] <uws> TO?
[08:56] <uws> sabdfl: it's a 0, not O
[08:56] <spiv> sabdfl: There probably isn't a revison after that time, hence the "no such revision" error.
[08:56] <uws> but with comma it works fine for me as well, as I said
[08:57] <sabdfl> doh
[08:57] <spiv> I don't think there's been any commits to bzr.dev since  2008-09-08 07:18:35 +0100
[08:57] <uws> yeah, I get it with dates in the future as well
[08:58] <uws> but the error message is at the very least misleading
[08:58] <spiv> (And "-r date:..." calculates using your local timezone, so comparing is often confusing....)
[08:58] <spiv> Yeah, the error message could definitely be better.
[08:59] <bob2> and different output for "no commits since that time to compare to" and "no commits at or after that time at all"
[10:04] <lifeless> jml: shutdown night
[11:45] <LeoNerd> lifeless: So.. I mailed the mailing list about my "log" range ideas... no response.. :/
[11:54] <kinkie> Hi all.. I've made a little mess, by inadvertently deleting a branch from a repo. I have the branch pushed-to in launchpad, is there a way to recover the branch in my repo without branching and merging again? Thanks
[11:56] <uws> kinkie: if you branch it again, it will (re)use the revisions from your local repo, so it's cheap
[11:56] <awilkins> kinkie: bzr heads --all will show all tips in your repo
[11:56] <awilkins> And uws is also correct
[11:57] <uws> awilkins: What is the difference between "dead" and "alive" heads?
[11:57] <awilkins> My way is tricksier but requires no network connection ; his way is easy and requires minimal network
[11:57] <awilkins> uws: "Dead" heads are ones that are not in a branch
[11:57] <uws> awilkins: well, if you ask on irc i assume a network connection is available ;)
[11:58] <uws> awilkins: how does it know?
[11:58] <awilkins> uws: I presume it recurses, but I'm not sure.
[11:58] <awilkins> uws: I'm going to try it now :-)
[11:58]  * awilkins randomly deletes a branch
[11:59] <awilkins> Yup, dead heads are ones with no branch, but still listed by all
[11:59] <uws> awilkins: it can't know if I have branches somewhere on my machine (or on another machine) that are on that specfic head, right?
[11:59] <uws> e.g. a checkout on another machine
[11:59] <uws> eh, s/checkout/branch/
[11:59] <awilkins> uws: I think it restricts itself to branches within that repo
[11:59] <uws> ah, that makes sense (common setup anyway)
[12:00] <awilkins> Probably very wuick in a no-trees repo
[12:00] <kinkie> awilkins: ok, I found the head. What then? (I'm not so big on bzr recoveries yet ;)
[12:00] <awilkins> Pretty quick in a trees repo too ; it only has to check .bzr folders
[12:00] <kinkie> trunk is 'trunk'
[12:00] <kinkie> let's call the branch 'foo'
[12:01] <awilkins> You should be able to branch it from the listed revid:
[12:01] <kinkie> should I just 'bzr branch trunk foo'? And as long as the name matches, it'll just revive the branch?
[12:01] <awilkins> bzr branch trunk -r revid:<myrevid> foo   ?
[12:02] <uws> awilkins: heads --all shows me a bunch of revisions that have been committed/merged into my branch ages ago. how come?
[12:02] <awilkins> uws: because they're all tips of branches that no longer exist in your repo
[12:03] <awilkins> uws: I suspect if you branch your trunk into another repo and try again they'll disappear
[12:04] <uws> awilkins: I still don't know how it figures that out
[12:05] <awilkins> uws: The help says "revisions without descendants"
[12:05] <uws> awilkins: yeah, but they're merged, so they have revisions on top of them
[12:06] <kinkie> awilkins: that did it. THANKS A LOT!
[12:06] <uws> awilkins: (but indeed, creating a new repo makes them disappear_)
[12:06] <awilkins> There may be more to it than meets the eye then
[12:07] <awilkins> kinkie: Thanks for helping me practice that, never done it before
[12:08] <kinkie> I honestly hope it's an one-shot affair ;-)
[12:09] <awilkins> kinkie: I had a small doubt that it might not work with a revision that was never merged into the branch I'm instructing it to branch, but I just tried it and that works just fine
[12:11] <uws> awilkins: hmmmm. it could be that revisions I've uncommitted show up as heads
[12:11] <awilkins> uws: Aha, yes, I think you've put your finger on it
[12:12] <uws> awilkins: I was triggered by the exceptionally high number of typos in the commit messages :)
[12:15] <Leonidas> maybe I am too stupid, but somehow bzr commit -x does not exclude anything.
[12:56] <poolie> night all
[14:40] <james_w> Leonidas: it works for me, but it doesn't affect the diff shown by --show-diff, which I will file a bug on, is that all you were looking at, or did you look at the committed diff?
[14:41] <Leonidas> james_w: when I committed it has included the file in the output, so I think it has committed it as well. I did an uncommit, but I'll test it again when I find some time to make sure it is not because I'm too stupid to use it.
[14:42] <james_w> Leonidas: I saw it was in the diff, but not the "modified foo" lines it prints, and "bzr diff -c -1" afterwards shows only the changes that I wanted
[14:50] <james_w> bug 268135
[16:02] <james_w> that's not good: "branch.lock_read()" deleting the branch, there's something fishy going on here
[16:04] <Peng_> I was just messing around because of the slow startup thread on the mailing list, I ran "bzr revert" on a single file, and it took like 5 seconds. :(
[16:04] <james_w> ah no, just me being stupid it seems
[16:04] <Peng_> Stupid hard drives.
[16:23] <james_w> I have a problem with code I am writing
[16:24] <james_w> it does "revid = tree.commit()" and then "other_branch.fetch(tree.branch, last_revision=revid)"
[16:25] <james_w> this works fine when the branches are in separate repositories, but fails when they share one
[16:25] <james_w> as the fetch detects that it is fetching to the same repo, and just checks that the last_revision is present
[16:26] <james_w> this check is what fails
[16:26] <james_w> if I use pdb to pause just before the fetch "bzr log" and "bzr heads" from another process outside can see the revision in question
[16:27] <james_w> do I need to do something to make the current process see the just committed revision, or am I missing something else?
[16:27] <foebrian> morning all
[16:27] <foebrian> is there a way to remove a project from bazaar? to unregister it?
[16:29] <Odd_Bloke> foebrian: Why do you want to?
[16:29] <james_w> hi Odd_Bloke
[16:30] <Odd_Bloke> james_w: o/
[16:31] <james_w> Odd_Bloke: how's the job?
[16:31] <foebrian> Odd_Bloke: well i setup bazaar on my home server, and missedtyped the project path, so now 6 projects are considdered one, so i want to unregister it, then fix by adding just one project. if that make sense
[16:31] <Odd_Bloke> james_w: Not bad.
[16:32] <Odd_Bloke> Currently work on OO.o. D:
[16:33] <Odd_Bloke> foebrian: What do you mean by 'projects'?
[16:34] <foebrian> Odd_Bloke: well i have a single project folder /storage/projects then below that i have my project 'branches' like /project1   /project2  /project3, so now all the folders are commited to one 'branch' even though they are seprate projects
[16:35] <foebrian> does that make sense?
[16:36] <Odd_Bloke> foebrian: Right, move /storage/projects/.bzr to somewhere else (just as a backup), and then 'bzr init' in each of the separate project directories.
[16:36] <Odd_Bloke> If the projects are related, you should consider running 'bzr init-repo /storage/projects' beforehand, it'll save space.
[16:37] <foebrian> Odd_Bloke: so the removal of .bzr will remove it then? unfornately they are not related, seprated things
[16:38] <Odd_Bloke> foebrian: Yeah.
[16:42] <foebrian> Odd_Bloke: awesome, it worked! thanks Odd_Bloke!
[16:42] <foebrian> chaos is removed!
[16:42] <james_w> bug 264705 if anyone has any ideas about my problem
[16:43] <Odd_Bloke> foebrian: No worries.
[16:48] <Odd_Bloke> james_w: Are you still working on versioning all of Ubuntu?
[16:49] <james_w> Odd_Bloke: yup
[16:49] <Odd_Bloke> james_w: How's it going?
[16:50] <james_w> Odd_Bloke: it's coming along, spending a week or two bug fixing at the moment before Ubuntu beta freeze, and then back to importing and documentation
[16:50] <Odd_Bloke> james_w: Ah, cool.
[17:00] <LeoNerd> By the way guys: I've just built myself a WinXP VM in VirtualBox. First thing I did was installed Bazaar, which has TortoiseBZR. I'd like to report it JustWorks. It's lovely ;)
[17:01]  * kinkie is away: see you later/tomorrow
[17:04] <Odd_Bloke> kinkie: If you could disable away messages, for this channel at least, that would be appreciated. :)
[17:53] <jam> lifeless: ping me when you wake up, I need you to make a 1.7 branch so I can do 1.7rc1
[18:03]  * justizin wonders why the OSX 10.5 installer is an older version of bzr (1.5) than the OSX 10.4 installer (1.6)
[18:03] <justizin> does the 10.4/1.6 not work on leopard?
[18:11] <Verterok> justizin: the installers are builded by the community
[18:11] <justizin> fair enough :)
[18:11] <justizin> looks like 1.6 installer wants python 2.5 on 10.4, complains i need python 2.5 even though i have it on leopard
[18:11] <Verterok> justizin: I build the 10.4, and 'ld like to build the 10.5 too, but no leopard nor mac-intel here :(
[18:12] <justizin> Verterok: can i run the build for you? ;)
[18:12] <justizin> i've got three intel macs here running leopard.
[18:12] <Verterok> justizin: the 10.4 installer depends on a user installed python. 10.4 only provides python2.3 by default
[18:12] <justizin> love to help..
[18:12] <justizin> yeah i figure as much..
[18:13] <justizin> how does the checking work?
[18:13] <justizin> seems it should be possible to look for python in /System/Library/Frameworks as well as /Library/Frameworks or ~/Library/Frameworks...
[18:13] <Verterok> justizin: let me check
[18:13] <justizin> but i know this is a challenge for many mac / python installers..
[18:13] <justizin> np
[18:14] <justizin> 1.5 will serve my needs for now but i'd love to help make available better installers for mac any way i can.
[18:14] <Verterok> justizin: the 10.4 installer checks CFBundleShortVersionString property in /Library/Frameworks/Python.framework/Versions/2.5/Resources/Info.plist
[18:15] <justizin> is it possible to configure alternative checks, or does it only allow one location to provide a dependency?
[18:16] <Verterok> justizin: I think it's possible, but I dont' know if its going to work
[18:16] <justizin> hm
[18:16] <justizin> is source for the installer accessible?
[18:16] <Verterok> justizin: all the C extensions are compliled against 10.4 dynlibs
[18:17] <justizin> fair enough
[18:17] <justizin> i suppose we can just port it to 10.5
[18:17] <Verterok> justizin: I think phanatic builds the 10.5 installer, and have all the required bits
[18:18] <Verterok> justizin: check Issues section at http://bazaar-vcs.org/MacOSXBundle
[18:18] <justizin> got it
[18:22] <newz2000> in eclipse using bzr-eclipse I've found that if I check out my work into a subfolder of the project (for example, trunk) then eclipse doesn't recognize the project as being managed by vcs. Does anyone know a workaround?
[18:23] <Verterok> justizin: if you don't have a reply, please let me know and I'll push my installer branch to some public location
[18:23] <Verterok> newz2000: Eclipse only support project level team provider mappings
[18:23] <newz2000> oh, too bad
[18:24] <Verterok> newz2000: what is the layout you need?
[18:24] <justizin> Verterok: i'd like if you published it..
[18:25] <Verterok> justizin: at your service ;) http://verterok.com.ar/code/bundle-10.4/
[18:25] <newz2000> well, I was taught an interesting way to manage my project... create a folder, keep my main trunk branch in a sub-folder, and when I'm fixing problems create a branch for the fix and work on it there.
[18:25] <newz2000> I've been using it lately and its working out nice
[18:26] <Verterok> justizin: the pmproj file is a work in progress (tm) to include bzr-svn, just remove both bzr-svn entries and it 'll build ok :p
[18:26] <newz2000> so my project might include these folders: trunk/ add-openid/ jquery126/
[18:26] <justizin> ok
[18:26] <newz2000> all branches
[18:26] <justizin> i was thinking about that challenge myself.
[18:27] <justizin> are you just including a copy of svn 1.5 or wha?
[18:27] <Verterok> justizin: most of the work is there, just need the glue :)
[18:27] <Verterok> justizin: I acctually build bzr-svn against both versions of subversion (1.4 and 1.5)
[18:28] <Verterok> justizin: and adds a check like the python-2.5 one
[18:28] <justizin> interesting..
[18:28] <justizin> 1.4 needs to be patched to work, though, eh?
[18:28] <Verterok> justizin: not any more, bzr-svn now provides it own bindings
[18:28] <justizin> ah-ho
[18:28] <justizin> neato
[18:29] <newz2000> oh, Verterok, you're Guillermo! Nice to meet you and nice work on the project.
[18:29] <justizin> i've just been using bzr-svn on my ubuntu box, then grab a copy using straight bzr from mac or other servers like RH which don't have bzr-svn yet
[18:29] <justizin> still will keep doing that but it'd be nice to have bzr-svn around other places sometimes :)
[18:29] <Verterok> newz2000: thanks! it's greatly appreciated! :D
[18:30] <Verterok> newz2000: maybe your need can be solved if bzr-eclipse provides a way to branch directly from a project
[18:30] <newz2000> I wonder if it would be better to file a bug/feature request on eclipse, though I'm not sure how responsive they are
[18:30] <newz2000> so that vcs can just live in sub folders
[18:30] <Verterok> newz2000: like: right click on on trunk --> branch as new Project. and create add-openid project
[18:31] <newz2000> ah
[18:31] <Verterok> newz2000: that could work for your workflow?
[18:31] <newz2000> yeah, that would work, but the only prob is the directory structure might become a mess
[18:31] <newz2000> let me think it through for a second
[18:32] <Verterok> newz2000: you cound place the new project in any directory you want, i.e: like a share repo
[18:32] <newz2000> so for example, I'm working on a project called XYZ
[18:32] <newz2000> it would go into workspace/XYZ
[18:33] <newz2000> and that would be the root of my project (no trunk/ folder)
[18:33] <Verterok> justizin: poke me if you need some help to get the whole build process working (I know it need documnetation)
[18:33] <newz2000> and to add a feature I branch from there to a new project at workspace/XYZ-feature23/
[18:33] <newz2000> does that sound right?
[18:33] <justizin> np doing a few things atm but will prod a bit and see what errors i get if i try a build
[18:34] <Verterok> newz2000: that is one approach, actually, you could do taht with current bzr-eclipse
[18:34] <newz2000> yes, I believe so
[18:34] <Verterok> newz2000: also, you can place the projects inside /whatever/path/you/like :)
[18:35] <newz2000> oh, really? I just use the default options usually
[18:35] <newz2000> then let me try that, it is probably the easiest solution
[18:35] <newz2000> and fixes another problem I'm about to experience since the python-path in pydev is set per-project
[18:36] <Verterok> newz2000: also, if you want the "branch from project into a new project", please file a bug :)
[18:36] <newz2000> ok, thanks for your time Verterok, I appreciate the help
[18:37] <Verterok> newz2000: np, glad to help
[18:37]  * newz2000 just tried it - it works!
[18:39] <Verterok> great!
[19:54] <ericvw> If I have standalone branch, but I want to migrate it into a centralized development work-flow because I will be on multiple computers, how would I go about migrating?
[19:55] <fullermd> Push it up to your central location, and use 'bind' or 'reconfigure' to turn its current location into a checkout of the central branch.
[19:56] <ericvw> fullermd: and it will know from the push where to update from and commit to?
[20:08] <sabdfl> hey beuno
[20:10] <beuno> hey sabdfl
[20:10] <beuno> how's it going?
[20:10] <sabdfl> groovy here, thanks. you?
[20:10] <beuno> better now that I have internet again  :)
[20:14] <fullermd> ericvw: No, from the bind/reconfigure.
[20:14] <fullermd> ericvw: The push just sets up the data in the central location.
[20:30] <ericvw> fullermd: thanks!
[20:53] <strk> can a repository be downgraded to an older version to be compatible with older bzr clients ?
[20:56] <jelmer> strk, generally, yes
[20:56] <jelmer> strk: "bzr upgrade --old-format" (where old-format is the name of the format to downgrade to)
[20:56] <strk> Could not load movie 'http://request/remote.php?theme=touchscreen.swf'
[20:57] <strk> (sorry)
[20:58] <willyyam> any reason why bzr is a bad choice as a backend for a versioned backup system?
[20:58] <strk> willyyam: it's too new for debian stable users :)
[20:59] <strk> is also slower then CVS
[20:59] <willyyam> or, to put it another way, are twice-daily large binary blobs a problem over a long time (5+ years)
[20:59] <willyyam> actually, I use it on debian stable daily
[20:59] <strk> that one ships 0.11 it seems
[21:00] <strk> we're using 0.16 and somewhat lost compatibility
[21:00] <strk> so you can't fetch gnash sources from debian stable, unless you upgrade bzr
[21:00] <strk> it sucks
[21:00] <jelmer> strk: Lenny will be out soon hopefully :-)
[21:00] <jelmer> strk, performance is pretty bad with old formats though
[21:00] <strk> soon == few monts
[21:01] <strk> jelmer: I'm talking about performance with 0.16 unfortunately
[21:01] <jelmer> strk: but yeah, bzr upgrading to an older format should work
[21:01] <strk> I guess downgrade would make it even slower ?
[21:01] <strk> it takes from 15 to 30 minutes for a simple commit on a GPRS connection
[21:01] <strk> about 1 minute on a DSL
[21:02] <strk> the GPRS experience makes you hate it :)
[21:02] <strk> but you can commit to a local branch while out-of-the-office and merge when back on high bandwidth, which is a bit harder with CVS
[21:54] <beuno> pickscrape,
[21:54] <beuno> "ping"
[21:54] <beuno> is this what I'm suppose to be looking at?  lp:~pickscrape/loggerhead/directory_breadcrumbs
[22:00] <beuno> mwhudson, I'm trying to remember what was wrong with lp:~pickscrape/loggerhead/directory_breadcrumbs
[22:00] <beuno> but everything seems fine
[22:00] <beuno> do you remember why we didn't merge that in the end?
[22:03] <pickscrape> beuno: yes, I think that was it
[22:03] <lifeless> jam: made
[22:03] <jam> lifeless: thanks
[22:03] <beuno> pickscrape, it looks fine to me. You fixed everything, didn't you?
[22:03] <lifeless> the losas have that documented too FWIW
[22:03] <pickscrape> Probably some hideous use of METAL that would have made the loggerhead codebase horrible :)
[22:04] <pickscrape> I think I did, but it probably needs a really good test and review to make sure I didn't miss anything or code it into a hole or anything like that
[22:04] <beuno> pickscrape, fire off the merge request, I'll take a look at the code
[22:04] <beuno> I've been using it, and can't find any problems with the UI at all
[22:05] <pickscrape> merge request via LP right?
[22:06] <beuno> yeap
[22:10] <mwhudson> beuno: maybe i just haven't got aroudn to looking at the lastest version
[22:10] <beuno> mwhudson, yeah, me neither, but trying to get up-to-date today with LH stuff  :)
[22:10] <beuno> thanks
[22:10] <mwhudson> beuno: good idea
[22:10] <pickscrape> Merge request sent
[22:11] <pickscrape> Just reading my commit comments on that branch, I was concerned about having to create an inventory object for the annotate view.
[22:14] <ivantis> hello
[22:14] <ivantis> how do i log in with bzr to launchpad? i need to push some code
[22:14] <ivantis> i already have an account
[22:15] <beuno> ivantis, https://help.launchpad.net/BzrHowto
[22:15] <ivantis> thx
[22:17] <kwah> hi everyone
[22:17] <kwah> I tried to ask on a mailing list... https://lists.ubuntu.com/archives/bazaar/2008q3/047006.html
[22:17] <kwah> but got no reply
[22:18] <kwah> either I could not find relevant information myself
[22:18] <kwah> or it is the lame question
[22:18] <kwah> any comments?
[22:19] <mwhudson> kwah: well, if you have a shared repo upgrading the repository is a separate thing from upgrading the branches
[22:20] <mwhudson> kwah: the main negative impact of upgrading is that people using older versions of bzr won't be able to access your branches
[22:20] <kwah> mwhudson, and what about branches that were checked out?
[22:20] <kwah> not branched, I mean
[22:21] <mwhudson> the branch/checkout distinction is basically irrelevant here
[22:21] <mwhudson> or do you mean lightweight checkouts?
[22:22] <kwah> I am wondering, because some people are working with repo and I do not know, what they will see
[22:22] <mwhudson> either way, the only impact would be better perfomance :)
[22:22] <kwah> error message upon checking in
[22:22] <mwhudson> no
[22:22] <kwah> no, not lightweight
[22:22] <mwhudson> ah
[22:22] <mwhudson> actually, the conversion process is kind of slow
[22:23] <mwhudson> so using a knit branch that's a checkout of a packs branch, say, might be a little tedious
[22:23] <mwhudson> but it would _work_
[22:23] <kwah> so it will be just transparent for the user?
[22:24] <mwhudson> right
[22:24] <kwah> hm... I guess I have to experiment myself more.
[22:24] <kwah> anyway, it would be nice to have some points about this in documentation
[22:24] <kwah> help messages are kinda cryptic
[22:25] <mwhudson> file a bug, maybe?
[22:25] <kwah> mwhudson, thanks for the explanation
[22:25] <kwah> mwhudson, I may try
[22:25] <mwhudson> np
[22:34] <jam> lifeless: you created the 1.7 branch, but didn't give me authorization to commit to it.
[22:34] <lifeless> jam: fixing
[22:35] <lifeless> 7am :P
[22:35] <lifeless> done
[22:37] <jam> np
[22:37] <jam> thanks
[22:38] <lifeless> you forgot to time just python
[22:38] <lifeless> to get the delta for locale
[22:41] <jam> lifeless: sure, replied
[22:54] <beuno> mwhudson, http://launchpadlibrarian.net/17058288/loggerhead_changes_path.diff
[22:55] <beuno> related to: https://bugs.edge.launchpad.net/loggerhead/+bug/260363
[22:55] <beuno> we're doing that everywhere else in LP
[22:55] <beuno> +1 to apply that patch?
[22:55] <beuno> s/LP/LH
[22:55] <beuno> I'm starting to get dizzy  :)
[22:55] <mwhudson> beuno: s/not path is None/path is not None/
[22:56] <mwhudson> and if we're really doing that EVERYWHERE in LH, i guess it should be in TemplateView
[22:56] <beuno> I knew this wasn't going to be that easy...
[22:56] <beuno> let me see how this can be refactored...
[22:59] <mwhudson> beuno: it seems all the views a pretty consistent about how they handle 'args'
[22:59] <mwhudson> either it's <revid>/path
[22:59] <mwhudson> or they ignore it
[22:59] <mwhudson> so we could change the signature from
[22:59] <mwhudson> get_values(self, h, args, kwargs, response)
[22:59] <mwhudson> to
[23:00] <mwhudson> get_values(self, h, revid, path, kwargs, response)
[23:02] <beuno> mwhudson, good idea. Let me change that and see how it looks
[23:02] <mwhudson> beuno: thanks :)
[23:05] <beuno> mwhudson, LH seems to be acting up again: http://bazaar.launchpad.net/~bzr/bzr/trunk/annotate/3697?file_id=setup.py-20050314065409-02f8a0a6e3f9bc70
[23:18] <beuno> Verterok, w00t!
[23:18] <beuno> thanks for that
[23:18] <Verterok> beuno, mwhudson: ^
[23:19]  * Verterok just send the review request
[23:19] <mwhudson> ?
[23:19] <mwhudson> ah right
[23:19] <Verterok> mwhudson: Bug #243415
[23:20] <poolie> good morning
[23:20] <beuno> morning poolie
[23:20] <Verterok> mwhudson ,beuno: the template needs some love, but it would be great to get some early feedback
[23:21] <james_w> hi poolie.
[23:21] <Verterok> hi poolie
[23:21] <beuno> Verterok, I can give it some love. That's the easy part  :)
[23:21]  * poolie feels welcome
[23:22] <james_w> poolie: a friend told me that the "topics" thing on the mailing list doesn't seem to be working correctly, merge requests seem to be delivered even if the merge topic isn't desired.
[23:24] <lifeless> abentley: bb is down?
[23:24] <james_w> hey lifeless
[23:24] <Verterok> beuno: it would be *really* appreciated
[23:25] <abentley> lifeless: restarted
[23:25] <beuno> Verterok, I'll try and get to that after the refactor I'm doing
[23:25] <lifeless> abentley: thanks
[23:26] <Verterok> beuno: no hurry. thanks :)
[23:26]  * lifeless waves around
[23:26] <poolie> hello lifeless
[23:27] <beuno> howdy lifeless
[23:27] <lifeless> turns out that the vodafone system allows their helpdesk line to be put in as the 'notify me that a bill has been emailed' number
[23:27]  * lifeless is satisfied
[23:29] <james_w> if I have two branches which share a repository, and commit to one, should the commit be instantly visible in the branch.repository of the other?
[23:29] <james_w> https://bugs.edge.launchpad.net/bugs/264705
[23:29] <mwhudson> pickscrape, beuno: i think that now History objects only last for the duration of a request, get_inventory should cache the inventories it returns
[23:31] <lifeless> james_w: if the other branch drops its read lock to 0, then ups it, yes
[23:31] <lifeless> james_w: but while locked the other repo may not refresh its indices list
[23:32] <lifeless> jam: ping
[23:32] <pickscrape> mwhudson: my worry was whether the breadcrumbs code adds an inventory object to the annotate page that was not needed before
[23:32] <mwhudson> pickscrape: it was created anyway
[23:32] <pickscrape> mwhudson: in that case I'm not worried :)
[23:32] <mwhudson> pickscrape: in annotate_file, and possibly in get_file_path
[23:33] <mwhudson> pickscrape: but it would be better to create it only once, hence the caching suggestion
[23:33] <james_w> lifeless: thanks. Any suggestions for how to solve this bug?
[23:33] <pickscrape> mwhudson: oh, you mean it doesn't actually do the caching at the moment?
[23:33] <mwhudson> pickscrape: right
[23:34] <pickscrape> ok
[23:34] <lifeless> james_w: what bug
[23:36] <james_w> lifeless: 264705
[23:37] <lifeless> james_w: as I said, drop the references to the branch after the merge operation
[23:37] <Yasumoto> I'm working with the fiveadayapplet, does anyone happen to know what error code 104 is?
[23:37] <lifeless> no idea, we don't use numeric error codes
[23:38] <lifeless> so its either not related to bzr, or coming from the OS
[23:38] <james_w> lifeless: doesn't that introduce a race condition?
[23:38] <Yasumoto> kk, that'd make sense why Google wasn't showing anything related to bzr, thank you :)
[23:38] <lifeless> james_w: you say you have branch A and B, you do something on A, and then B fails to see the data?
[23:39] <james_w> Yasumoto: /tmp/5-a-day-applet.txt may help you to debug
[23:39] <lifeless> james_w: if B is locked prior to doing the task on A, B will not see new data introduced by A until B has been unlocked
[23:39] <lifeless> james_w: what races are you worried about ?
[23:40] <Yasumoto> james_w: awesome, thanks for the heads up
[23:40] <james_w> lifeless: well, if B is unlocked and locked again isn't there time for the branch to be modified leading to trouble
[23:41] <lifeless> is B write locked or read locked?
[23:41] <james_w> write locked, it needs to do a merge of this new revision
[23:42] <lifeless> and sure, someone else could grab a write lock
[23:42] <james_w> perhaps I don't need the fetch there, and can move it up a function
[23:42] <lifeless> but if you do rev = B.tip, B.unlock();b.lock_write(); check B.tip == rev
[23:42] <lifeless> you can be sure noone has altered the tip
[23:43] <lifeless> I don't understand why you would mutate branch A while holding a write lock on B
[23:43] <lifeless> which branch are you actually working on :P
[23:43] <mwhudson> pickscrape, beuno: i made a few more changes: https://code.edge.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs
[23:43] <mwhudson> take a look?
[23:44] <mwhudson> pickscrape, beuno: here's the diff of all of em http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/216?remember=211&compare_revid=211
[23:44] <james_w> lifeless: A is the "upstream" branch and B is the "packaging" one, this command commits the new upstream, and then merges it to the packaging one, so we need to write to both
[23:45] <james_w> lifeless: it locks B early to check there are no uncommitted changes, and get some info from it, but it could do the unlock I think.
[23:45] <lifeless> james_w: to me they are separate steps, is there any need to make the aggregate atomic ?
[23:45] <beuno> mwhudson, lovely.  +1
[23:46] <mwhudson> beuno: i guess i'll merge
[23:46] <james_w> lifeless: I think having it as one command makes sense. Is that what you mean by atomic?
[23:46] <lifeless> no
[23:46] <poolie> abentley, thanks for reading and replying to my mail
[23:46] <beuno> mwhudson, yes please!
[23:46] <lifeless> atomic - all-or-nothing
[23:46] <abentley> poolie: np
[23:46] <lifeless> indivisible etc
[23:47] <poolie> i have to admit the content of the reply was at first discouraging
[23:48] <james_w> lifeless: it doesn't really need to be. However the upstream branch is ephemeral, so currently it "disappears" on any error.
[23:48] <lifeless> james_w: ok, well I'd either patch bzrlib to have a public refresh-view method to trigger a refresh, or drop and reacquire the lock
[23:49] <lifeless> poolie: what email was discouraging?
[23:49] <pickscrape> mwhudson: all looks ok to me
[23:49] <mwhudson> pickscrape: good, because i just merged it :)
[23:49] <mwhudson> pickscrape: thanks!
[23:49] <pickscrape> hehe :)
[23:50] <poolie> aaron's re what do we do now
[23:50] <abentley> poolie: I'm sorry for any hurt feelings.  I felt it was important to be frank.
[23:50] <poolie> it is
[23:50] <pickscrape> Funny how someone who is picky about whitespace can be picked up on whitespace by someone else who is also picky about whitespace :)
[23:50] <james_w> lifeless: thanks, it's late now, but you've probably given me enough to fix this tomorrow, thanks.
[23:50] <poolie> i'd prefer that to folks just smiling and nodding
[23:52] <lifeless> poolie: ah right
[23:52] <lifeless> hadn't found that reply at that point
[23:52] <lifeless> hmmm food, that will make me smile and nod
[23:53] <abentley> poolie: I was a bit surprised at your suggestion, because I thought we agreed that too many cooks contributed to our problems with stacking.
[23:53] <Verterok> mwhudson: I added a --reload option to serve-branches (mainly to ease dev's life :): http://bazaar.launchpad.net/%7Eguillo.gonzo/loggerhead/reloader/revision/220
[23:54] <beuno> Verterok, :O
[23:54] <mwhudson> Verterok: ah, you look like someone that knows somethign about paste!
[23:54] <beuno> Verterok, gazillion thanks!!!!
[23:55] <Verterok> mwhudson: not at all :)
[23:55] <beuno> mwhudson, we need that merged. Now!
[23:55] <beuno> millions of hours spent restarting LH....
[23:55] <Verterok> mwhudson: just readed some docs, and the source ;)
[23:55] <mwhudson> beuno: you have the powah
[23:55] <mwhudson> Verterok: :)
[23:55]  * beuno excercise it
[23:56] <beuno> mwhudson, don't believe Verterok. He knows plenty, he's just shy
[23:56] <Verterok> beuno: before merging, let me update serve-branches.1
[23:57] <Verterok> beuno: hehe
[23:57]  * Verterok hides
[23:57] <beuno> Verterok, sure. Push, I'll pull, etc
[23:58] <igc> morning
[23:58] <james_w> morning igc
[23:58] <beuno> morning igc!
[23:58] <igc> hi guys
[23:58] <beuno> all the cool people are around today
[23:58] <Verterok> beuno, mwhudson: it's the --reload help description ok?
[23:58] <Verterok> hi igc
[23:58] <igc> hi
[23:59] <poolie> hello igc!
[23:59] <mwhudson> Verterok: i guess it should be clear that the application gets restarted when the application changes
[23:59] <igc> hi poolie
[23:59] <mwhudson> Verterok: you could possibly think that it was something to do with the branch changing
[23:59] <beuno> Verterok, and, I'd also add this is only really useful for development