[00:15] <Peng> Ack!
[00:15] <Peng> Paste's CLF-like log lines don't go in the log file either.
[00:15] <Peng> Paste--
[00:20] <Peng> I should just use 'tee'.
[00:20] <Peng> That actually worked.
[00:38] <lifeless> tee is love
[00:45] <lifeless> abentley: around?
[00:46] <lifeless> abentley: I think that what I'm proposing can be done using 'mpdiff' at least in part; if the accumulation of A,->B,->C etc is done without including the diff instructions - just including the new lines
[00:48] <lifeless> then I can hold  basis line #->(parent #, line #), and output mpdiff instructions; reconstruction will only ask for the lines included in that set so we can avoid creating intermediary objects beyond creating a ParentText object that has a view on the aggregate basis lines.
[00:49] <lifeless> this will mean that one of the incremental deltas is a well formed mpdiff delta, and we can grab it own its own and reconstitute it locally (the first in such a chain we'd need to do scatter-gather IO to put together its base texts, but after that we'd be laughing)
[00:50] <lifeless> the only problem is that the parents list will grow, so I wouldn't really want to include it per se with each diff, I'd want to have it at the front of some region
[00:57]  * Peng replaces sys.stdout and sys.stderr with a file. Beat that, Paste!
[00:59] <mwhudson> Peng: os.write(1, ...) ?
[01:00] <mwhudson> Peng: which log lines are you complaining about?
[01:00] <Peng> :(
[01:00] <mwhudson> (oh, and you're using some prehistoric paste anyway, right?)
[01:00] <Peng> mwhudson: The ones formatted like an Apache log file.
[01:00] <Peng> mwhudson: Probably.
[01:00] <mwhudson> Peng: they should go to the 'wsgi' logger by default
[01:00] <Peng> I'm using Ubuntu Hardy's Paste 1.6-2.
[01:00] <mwhudson> oh
[01:00] <mwhudson> no then really
[01:01] <Peng> Should I upgrade?
[01:06] <blueyed_> I was just using bzr-builddeb (from trunk; with bzr 1.5.0) and did "merge-upstream". This caused a "ConflictsInTree" error (basically because of a wrong, empty upstream file). So, I did "bzr revert" to get back to the old state, but this reverted the tree back to revision 1! (I just had committed r8 before).
[01:07] <lifeless> james_w: ^
[01:08] <mkanat> Isn't there some idiom for "copy this file"?
[01:09] <blueyed_> "bzr info -v" says "8 revisions" in "Repository", but only "1 revision" in "Branch history"
[01:09] <lifeless> mkanat: we don't support copies-with-history yet
[01:09] <mkanat> lifeless: Ah, okay.
[01:09] <mkanat> I was thinking of svn, which has the reverse idiom (one for mv).
[01:09] <lifeless> mkanat: so 'cp + bzr add'
[01:09] <mkanat> lifeless: Fair 'nuf.
[01:10] <lifeless> mkanat: unless its between branches, then we can treat it as a mv after all ;)
[01:10] <mkanat> Heh.
[01:16] <mwhudson> Peng: no, the messages should go to the 'wsgi' logger
[01:17] <Peng> mwhudson: What about exceptions?
[01:18] <mwhudson> Peng: dunno, sorry
[01:18] <mwhudson> utsl? :)
[01:18] <Peng> Heh.
[01:20] <Peng> So...logging.getLogger('wsgi')?
[01:21] <mwhudson> yeah
[01:21] <mwhudson> look at what start-loggerhead.py does for one approach
[01:21]  * mwhudson is no longer here
[01:22]  * lifeless pokes mwhudson 
[01:23] <Peng> Hmm.
[01:26] <Peng> mwhudson: Thanks for the help.
[01:27] <blueyed> lifeless, james_w: I've filed bug 245718 about the issue above
[01:28]  * blueyed should not use "bzr revert" anymore.. ;/
[01:29] <blueyed> Any chance that the data can be restored (from the "8 revisions" mentioned for the repository)?
[01:29] <lifeless> usre
[01:29] <lifeless> bzr heads
[01:29] <lifeless> its a plugin
[01:29] <blueyed> displays nothing
[01:29] <lifeless> try -a
[01:30] <lifeless> erm --all
[01:30] <blueyed> ..this displays the revision, which I've committed last.
[01:31] <lifeless> so
[01:31] <lifeless> I have to go catch a plane
[01:32] <lifeless> what you need is 'bzr pull -r revid:XXXX --overwrite .' - this will reset you to an arbitrary revision id
[01:32] <lifeless> you just need to figure out what that id is
[01:32] <lifeless> bye!
[01:32] <blueyed> lifeless: thx, bye.
[01:33] <blueyed> I guess the revid would be the one displayed by "heads --all"?
[01:34] <blueyed> yes, it worked. phew.
[01:53]  * Peng crosses his fingers.
[05:05] <nnutter> Can anyone link a (graphical) benchmark comparison of recent versions of bzr and hg? Everything I'm finding seems to be pretty ancient.
[05:19] <nnutter> Well, thanks anyway. Bye.
[09:25] <awilkins> _damn_, bzr is faster on Linux
[09:26] <beuno> *way* faster  :)
[09:26]  * awilkins goes to try out the 34,000 file tree that is usually quite sluggish on Windows
[09:27] <awilkins> Hmm, that seems to be slightly more challenging for it
[09:28] <awilkins> real1m8.739s
[09:29] <awilkins> I suppose it was off a USB stick
[09:29] <awilkins> Whee, cold status, 4 seconds, hot status, 0.9
[09:30] <awilkins> I almost feel like going in on Monday and claiming that Windows has a fatal data corruption error in it
[10:37] <Laibsch> hi
[10:37] <Laibsch> bzr-svn does not save the location to pull from for an import via "bzr get $URI"?
[10:54] <james_w> blueyed_: yeah, sorry, it's the result of a silly decision in the past.
[11:47] <savvas> How do I change file permissions in bazaar? I've changed the file permissions from -rwxr-xr-x to -rwxr--r--, tried to remove and re-add the file, but the file is still there with the 755 permission. Is there another way to do it?
[11:49] <jelmer> Laibsch: Not in earlier versions
[11:49] <Laibsch> OK
[11:57] <awilkins> savvas: AFAIK it tracks the x bit but not the other permissions
[11:59] <awilkins> savvas: And not group permissions, from the look of things
[11:59] <savvas> hmm thanks
[12:00] <awilkins> savvas: If you remove the public "r" access, then I presume they can't execute it?
[12:08] <savvas> awilkins: so if I remove the file, commit, (wait a bit), re-add and commit, it won't change it?
[12:09] <savvas> let me try it again, doesn't hurt heh
[12:09] <awilkins> savvas: I think the permissions are the default ones for your folder, except the x bit, which is either set or unset for all three groups or
[12:09] <savvas> ah
[12:10] <awilkins> savvas: It's not entirely unreasonable behaviour ; if you can read the file, you can copy it to a location where you have permission to set the x bit, and run it there, so it possibly doesn't make it very much more secure
[12:12] <awilkins> .. to be able to set the x bit on a per-group basis
[12:13] <savvas> ok thanks
[12:27] <savvas> awilkins: so if I got it right, I can add or remove the x bit, but not group-specific? either the file is executable for all groups or it's not, correct?
[12:34] <savvas> well.. I tried removing the file and re-added it with no x bit
[12:34] <savvas> better this way, at least during development :)
[12:35] <savvas> thanks a lot for your help!
[15:53] <vgeddes> is anyone having problems with `bzr log bzr+ssh://...' with bazaar 1.5?
[15:54] <vgeddes> bazaar terminates with a lot of debug messages after I run that command
[15:55] <vgeddes> here's the error: http://paste.debian.net/9426/
[15:56] <Peng> All I can say is that it WFM with bzr.dev.
[15:57] <vgeddes> WFM?
[15:57] <pygi> works for me
[15:57] <vgeddes> ah
[15:57] <vgeddes> hmm
[15:58] <pygi> tried 1.6b2?
[15:59] <vgeddes> no, i haven't
[15:59] <pygi> try it :)
[16:00] <vgeddes> hmm, is it stable enough?
[16:01] <Peng> The Bazaar developers do a very good job of making sure it always works.
[16:01] <vgeddes> ok
[16:01]  * pygi is using it :)
[16:01] <Peng> "WFM" isn't widely-known, but I just got lazy, and it's not like I make sense anyway. ;P
[16:12] <vgeddes> yup, 1.6 works for me :)
[16:24] <pygi> vgeddes, great
[16:27] <tacone> hello, wha't's the best way for a 1-time import of a svn repo into bzr ?
[16:30] <lifeless> tacone: bzr-svn has a svn-import command tat works well
[16:31] <tacone> I am manually installing right now, the repo version doesn't supporto bzr 1.50 and seems not to be present in bzr ppa
[16:33] <tacone> Unable to load plugin 'svn' from '/home/tacone/.bazaar/plugins'
[16:34] <tacone> mh, pysvn bindings :-)
[16:40] <lifeless> tacone: I'm told that 0.4 is the right branch of bzr-svn to use; it has its own bindings and is faster and less problematic
[16:40] <lifeless> tacone: jelmer here is the author, and the FAQ has info
[16:41] <lifeless> I have to catch the next leg of my flight; ciao :)
[16:41] <tacone> I'll check the faq
[16:41] <tacone> I am using 0.4.10
[16:42] <tacone> from the tar.gz which is likely to be the problem
[16:42] <tacone> I'll try to check out from the branch. thanks
[17:18] <leo2007> hi folks, I am trying to migrate from tortoisesvn to bazaar. One nice feature of tortoisesvn is that it can diff .doc files. any similar feature for bzr?
[17:47] <ScottK-laptop> I am trying to push local changes back to launchpad using bzr and get this error: "bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ekubuntu-members/guidance/powermanager-ubuntu/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()".
[17:48] <tacone> ScottK-laptop: looks like you need authentication
[17:48] <ScottK-laptop> Would someone please point me in the right direction for how I do this?
[17:48] <ScottK-laptop> OK. That makes sense.
[17:48] <tacone> have you registered an ssh key for that laptop ?
[17:48] <tacone> otherwise no https, so fallback to http happens and bla bla bla
[17:48] <ScottK-laptop> No.  Are there alternative methods?
[17:48] <ScottK-laptop> Right.
[17:49] <tacone> with launchpad, not to my knowledge, but I asked the same question here some day ago :-)
[17:49] <ScottK-laptop> OK.
[17:49] <ScottK-laptop> Thanks.
[17:49] <tacone> np
[17:50]  * ScottK-laptop marks bzr + lp off as still to hard and figures maybe next year.
[18:40] <Stavros> hello
[18:40] <Stavros> how can i check which revision my WC is in?
[18:41] <tacone> bzr revno ?
[18:41] <Stavros> ah
[18:41] <Stavros> thanks
[23:20] <mathrick> ahoy
[23:21] <mathrick> word on the street is that bzr-git is back from the dead
[23:21] <mathrick> is that true?
[23:21] <Peng> I heard that too.
[23:22]  * mathrick hopes it is