[12:07] <lifeless> so I think I can save another 10 seconds
[12:07] <lifeless> robertc@lifeless-64:~/source/baz/misc-fixen$ python -m timeit -n 1 -r 1 -s 'from bzrlib.osutils import sha_strings' -s 'one_mb = ["A"*80] *800' 'for f in xrange(50000): sha_strings(one_mb)'
[12:07] <lifeless> 1 loops, best of 1: 35.9 sec per loop
[12:07] <lifeless> robertc@lifeless-64:~/source/baz/misc-fixen$ python -m timeit -n 1 -r 1 -s 'from bzrlib.osutils import sha_string' -s 'one_mb = "A"*80*800' 'for f in xrange(50000): sha_string(one_mb)'
[12:07] <lifeless> 1 loops, best of 1: 22.3 sec per loop
[12:24] <keir> lifeless, should i write my own toposort or use the existing one?
[12:25] <lifeless> the existing one is fast
[12:26] <lifeless> its a good starting point, if it doesn't fit the sort you need - if a different layout will be better, then we'll need to add another version of it or something to tsort
[12:27] <lifeless> keir: ok looking at your code, one thing bzr requires is copyright assignment for non-trivial changes
[12:27] <lifeless> theres a wiki page with the agreement, its referenced from HACKING
[12:27] <keir> lifeless, i know, i'll do that later
[12:28] <lifeless> ok
[12:28] <lifeless> theres a few things that are truely trivial that jump out at me
[12:28] <lifeless> we follow PEP-8 with a few extra guidelines
[12:28] <lifeless> your code doesn't currently do that
[12:28] <keir> oh, let's not worry about code formatting
[12:28] <keir> i'll cross that bridge when we're looking at integration
[12:28] <lifeless> like I say, truely trivial ;)
[12:29] <lifeless> a data point on performance for you
[12:30] <lifeless> python -m timeit -s 'def foo(_, _2):pass' 'for f in xrange(50000): foo()'
[12:30] <lifeless> python -m timeit -s 'def foo(_, _2):pass' 'for f in xrange(50000): pass'
[12:30] <lifeless> erm
[12:30] <lifeless> first one should be
[12:30] <lifeless> python -m timeit -s 'def foo(_, _2):pass' 'for f in xrange(50000): foo(1, 2)'
[12:30] <lifeless> anyhow, run those
[12:31] <lifeless> this will tell you something about function call costs
[12:31] <lifeless> for me its about 15ms per 50K calls
[12:31] <keir> it's 12 for me
[12:31] <keir> 2 for no function call
[12:31] <lifeless> so you have a function that takes (int, size) and does an if
[12:32] <lifeless> this is duplicate work - when you decide size you know the function that you need
[12:32] <lifeless> so I'd be inclined to assign to a variable the serialiser for a given thing
[12:32] <lifeless> e.g. when you determine key_length_size
[12:32] <keir> ok
[12:33] <lifeless> set  pack_key = a_callable_that_takes_one_int
[12:33] <keir> ah, right
[12:33] <lifeless> this is just as clean but faster
[12:34] <keir> the speed of packing and unpacking, i think will be slow
[12:34] <lifeless> this is confusing
[12:34] <lifeless> +    # each row is (keysize key valsize val pads) such that is row_length bytes
[12:34] <lifeless> +    rows = (''.join((pack_sized_int(len(items[0] ), key_length_size),
[12:34] <lifeless> +                     items[0] ,
[12:34] <lifeless> +                     pack_sized_int(len(items[1] ), value_length_size),
[12:34] <keir> they are prime targets for c
[12:34] <lifeless> +                     items[1] ))
[12:34] <lifeless> +            for items in items)
[12:34] <lifeless> 'for items in items'
[12:34] <lifeless> it only works because iter(items) is called before items is rebound
[12:35] <keir> wow, i can't believe i wrote that
[12:35] <lifeless> I need to go run a chore, back in about 20
[12:49] <poolie> hello
[12:49] <keir> hi
[12:49] <poolie> hi keir
[12:57] <lifeless> hi poolie
[01:22] <lifeless> jelmer: ping, waiting on reply from you
[01:23] <keir> lifeless, any other thoughts?
[01:26] <lifeless> Peng: btw I have found your glitch from yesterday
[01:27] <lifeless> Peng: some historical data in bzr.dev has changed (just in an index), its triggering a type error
[01:29] <lifeless> keir: on the code? yes, just tracking down a performance issue for a bit
[01:34] <lifeless> wow, mem copies really hurt
[01:35] <lifeless> 20 second difference in performance by introducing a single exra mem copy of the text of a file fo rinitial commit
[01:36] <keir> this does not bode well for my index code
[01:36] <lifeless> I was trying to use sha_string instead of sha_strings
[01:37] <lifeless> which is 10 seconds faster or so overall
[01:37] <lifeless> but the extra copy overrode
[01:38] <lifeless> so I'm going to have to try a bit harder to avoid it
[01:38] <igc> morning all
[01:42] <lifeless> hiya
[01:44] <lifeless> of course it could be something else, hard to be entirely sure ;)
[01:50] <poolie> lifeless, there's a question about dapper packages
[01:56] <lifeless> hmm?
[01:56] <poolie> is it possible to build bzr debs for dapper?
[01:56] <poolie> can we automate that?
[01:57] <lifeless> yes
[01:57] <lifeless> did we not chat about this on thursday?
[01:57] <lifeless> or was it friday?
[01:58] <poolie> i wanted to confirm that there was nothing special about dapper
[01:58] <poolie> as i recall it's just a matter of you setting up the right chroots?
[01:58] <lifeless> its not different to say gentoo or redhat
[01:58] <lifeless> the packaging has to be done to match
[01:58] <poolie> right, the python standards have changed
[01:58] <lifeless> I have the chroots
[01:59] <poolie> so it's a different system
[01:59] <jelmer> lifeless, sorry, just got back. will reply now
[02:00] <lifeless> poolie: have you reconciled bzr.dev with abentleys patch or something ?
[02:00] <jelmer> lifeless, in the mean time, did you see my pqm merge request and ping ? >-)
[02:00] <lifeless> yes
[02:01] <poolie> no
[02:01] <lifeless> thanks
[02:01] <lifeless> something wierd going on
[02:01] <lifeless> in my branch the revision robertc
[02:01] <lifeless> meh
[02:01] <lifeless> robertc@robertcollins.net-20070720032020-xiftpb5gqeebo861
[02:02] <lifeless> has two parents
[02:02] <lifeless>     parent: pqm@pqm.ubuntu.com-20070720015347-eaeqmggngaemmbde
[02:02] <lifeless>     parent: pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx
[02:02] <lifeless> but one of the files it altered
[02:03] <lifeless> has different per-file graph for me and bzr.dev
[02:03] <lifeless>  ('robertc@robertcollins.net-20070720005841-xnu6um6vx0n41h0k',), ['robertc@robertcollins.net-20070720005841-xnu6um6vx0n41h0k', 'pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx'] 
[02:03] <lifeless> left is my index, right is bzr.dev's
[02:04] <lifeless> whats strange is that this is a revision I created
[02:05] <lifeless> so I'm not at *all* sure why my index could be different
[02:05] <poolie> lifeless, do you want me to merge aaron's patch or something?
[02:05] <lifeless> %254e%2545%2557%2553-20050323055033-4e00b5db738777ff is the file id
[02:05] <lifeless> poolie: no
[02:06] <lifeless> spiv and I have been reviewing it
[02:15] <lifeless> oh, I know
[02:15] <lifeless> abentley: ping
[02:18] <igc> fyi, I'm looking into the commit bug reported by Alex now
[02:20] <latexer> i can't find an open bug about it.
[02:20] <latexer> but I just managed to "bzr push" a local branch into the a base repository path, instead of a subdiretory there.
[02:20] <latexer> and it seems it blew away the repo info, as "bzr info my_repo" just reports the branch info.
[02:20] <lifeless> thats a feature
[02:21] <latexer> uhh...
[02:21] <lifeless> bzr info -v my_repo will show the repo details
[02:23] <latexer> lifeless: interesting...
[02:23] <lifeless> you can get rid of the branch by deleting .bzr/branch (but be sure *not* to delete .bzr/repository, cause thats your repository right there)
[02:23] <latexer> lifeless: the feature being a repo and a branch in the same directory?
[02:23] <latexer> and now I'm seeing it.
[02:28] <latexer> lifeless: indeed. that worked wonders.
[02:28] <latexer> lifeless: thanks!
[02:39] <lifeless> vila: ping
[02:39] <lifeless> meh sorry vila
[02:50] <ubotu> New bug: #140563 in bzr "unicode command line options cause unicodeencodeerror traceback" [Low,Triaged]  https://launchpad.net/bugs/140563
[03:24] <igc> poolie: see my latest comment on bug 140419 please
[03:24] <ubotu> Launchpad bug 140419 in bzr "selective commit sometimes fails with `parent_id not in inventory` error" [Undecided,New]  https://launchpad.net/bugs/140419
[03:24] <igc> poolie: do you want the fix reapplied just to bzr.dev or 0.92 as well?
[03:25] <igc> I'll put the merge up in the next few minutes
[03:48] <poolie> igc, please do merge that for 0.92
[03:48] <poolie> i mean, 0.91
[03:49] <igc> sure. I meant 0.91 as well. :-)
[04:02] <fullermd> Some of the code around the patch for bug 115947 seems to have changed, but I'm not sure whether the problem is solved, still there, worked around elsewhere, etc...
[04:02] <ubotu> Launchpad bug 115947 in bzr "DirState.set_state_from_inventory() fails when we have common prefix paths "foo" and "foo-bar"" [High,Fix committed]  https://launchpad.net/bugs/115947
[04:40] <igc> ok - the reapplication of that fix has been sent to pqm for both 0.91 and bzr.dev now
[04:42] <lifeless> cool
[04:43] <lifeless> we should check that nothing else got reverted by that merge
[05:19] <poolie> http://bundlebuggy.aaronbentley.com/request/%3C46EF2B5C.3010208%40internode.on.net%3E
[05:20] <poolie> i think this looks reasonable but i'm not specifically sure why it's correct
[05:20] <poolie> s/why/that
[05:20] <poolie> actually i am pretty sure
[05:21] <lifeless> which patc is it ?
[05:21] <poolie> -        entries = work_inv.iter_entries()
[05:21] <poolie> +        entries = work_inv.iter_entries_by_dir()
[05:21] <poolie> that's the heart of it
[05:21] <lifeless> yup
[05:21] <lifeless> oh is this from ian ?
[05:21] <poolie> yes
[05:21] <lifeless> if so its just reinstating what jam reverted by mistake
[05:22] <lifeless> bad merge
[05:34] <poolie> spiv, how's it going? quick call?
[06:27] <jml> is there a clever bzr trick to move uncommitted changes from one branch to another?
[06:28] <fullermd> merge --uncommitted?
[06:28] <jml> that's probably it :)
[06:28] <jml> bzr rocks.
[06:29] <lifeless> ok
[06:29] <lifeless> bzr.dev has broken indices
[06:30] <lifeless> abentley: ^ ping
[06:30] <lifeless> abentley: I don't *know* that you ran reconcile, but its my best bet so far
[06:43] <lifeless> spiv: ping
[06:44] <lifeless> spiv: I'm going to ring you, hope thats ok
[06:44] <spiv> lifeless: ok.
[06:52] <abentley> lifeless: I have not deliberately run reconcile on my main bzr.dev
[06:52] <lifeless> ok thats very interesting
[06:53] <lifeless> *something* has added a parent though
[06:53] <abentley> I will run check.
[06:53] <abentley> It's possible I did it by accident, I suppose.
[06:53] <lifeless> I would expect your parents-modified check to error on the new file graph for NEWS if something else introduced this
[06:55] <lifeless> >>> from bzrlib.repository import Repository
[06:55] <lifeless> >>> r = Repository.open('..')
[06:55] <lifeless> >>> i = r.get_inventory('pqm@pqm.ubuntu.com-20070720015347-eaeqmggngaemmbde')
[06:55] <lifeless> >>> i2 = r.get_inventory('pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx')
[06:55] <lifeless> >>> i.path2id('NEWS')
[06:55] <lifeless> 'NEWS-20050323055033-4e00b5db738777ff'
[06:55] <lifeless> >>> fid = i.path2id('NEWS')
[06:55] <lifeless> >>> i[fid] .revision
[06:55] <lifeless> 'robertc@robertcollins.net-20070720005841-xnu6um6vx0n41h0k'
[06:55] <lifeless> >>> i2[fid] .revision
[06:55] <lifeless> 'pqm@pqm.ubuntu.com-20070705224207-7pslqt12ofh4vnzx'
[06:55] <lifeless> >>> i2[fid] .revision in r.get_ancestry(i[fid] .revision)
[06:55] <lifeless> True
[06:56] <lifeless> just veriified again
[06:56] <lifeless> that is, the per file change in my commit should have one parent only, as my mail said - I hadn't actually checked via the inventory before.
[06:57] <lifeless> abentley: your reconcile is the only thing I can think of that would change a file graph like that
[06:58] <abentley> I'm not really understanding the scenario, and it's late here.
[06:58] <abentley> But I'm paranoid enough to run "reconcile" only against temp branches until it hits mainline.
[06:59] <lifeless> abentley: ok. Well andrew has been looking at your patch anyway as its part of the hpss work
[06:59] <lifeless> so leave it with us; someone else may have run that reconcile
[06:59] <lifeless> e.g. vila or one of theother branches merged last night
[07:00] <abentley> I'll let you know about the "check" output, then off to bed.
[07:00] <lifeless> thanks
[07:00] <lifeless> sleep well
[07:14] <abentley> My home repository definitely has not been reconciled.
[07:18] <vila> lifeless: hi, still drinking first coffee, but never run reconcile
[07:21] <abentley> lifeless: Both my home and work repositories have lots of unreferenced text ancestors, so it seems impossible that they've been accidentally reconciled.
[07:21] <lifeless> this is bizarro
[07:22] <lifeless> bzr.dev has a new entry for that revision in that file
[07:22] <lifeless> as well as many others
[07:23] <lifeless> (many other replacement index entries)
[07:24] <abentley> Well, perhaps we can check for the bogus entries on all the branches that have been merged into bzr recently?
[07:24] <lifeless> yeah
[07:24] <lifeless> I was about to start doing that :)
[07:24] <lifeless> there's martin
[07:24] <abentley> Sorry I can't provide a shortcut by being at fault :-)
[07:24] <lifeless> this happened sometime yesterday far as I can figure
[07:25] <lifeless> vila
[07:25] <abentley> G'night.
[07:25] <vila> lifeless: pong
[07:25] <lifeless> dm watkins
[07:25] <vila> abentley: night
[07:25] <lifeless> jelmer
[07:25] <lifeless> keir
[07:30] <vila> hmm, bzr viz on http://bazaar.launchpad.net/~v-ladeuil/bzr/bzr.integration/ says pqm@pqm.ubuntu.com-20070917142923-f06edfgw1d0cvj4w was the tip when I merged my fix for #140055
[07:30] <vila> the commit message is 'Add reconfigure command'
[07:34] <lifeless> igc: you haven't run the new reconcile have you ?
[07:34] <igc> no - should I?
[07:34] <lifeless> no
[07:42] <lifeless> abentley: if you are still up, I've mailed the list a request for debug stuff; which you might like to do anyway - but no rush. I just won't merge bzr.dev for a bit.
[07:48] <poolie> igc, about docstrings
[07:49] <poolie> it seems hard to define ahead of time how much is enough
[07:49] <lifeless> I think one per non test-case method and one-per-class and one-per-module is desirable always
[07:49] <lifeless> because intent is rarely expressed in code
[07:49] <poolie> intent can be expressed in method names
[07:49] <lifeless> to some degree
[07:49] <lifeless> but I see docstrings as different to comments
[07:49] <poolie> lifeless, for example i've picked up, i think from you, the trend to have long test names
[07:50] <lifeless> self documenting code can be comment ftree
[07:50] <poolie> since you only have to write them once
[07:50] <poolie> agree
[07:50] <lifeless> yup :)
[07:50] <poolie> otoh i like more comments in test code
[07:50] <lifeless> yes, that too
[07:50] <poolie> because it is often not obvious *why* something is there
[07:50] <lifeless> I'm just saying that I support a policy of always having docstrings on code outside of .tests
[07:50] <poolie> and it's not like regular code where you can just remove such lines
[07:51] <lifeless> and inside .tests where the code is not a test itself :)
[07:51] <poolie> i do to, but having a docstring that just repeats the method name doesn't count
[07:51] <lifeless> right
[07:51] <spiv> poolie: Thinking of tests... http://martinfowler.com/articles/mocksArentStubs.html is the link I was talking about the other day, that talks about behaviour verification vs. state verification.
[07:51] <lifeless> spiv: you have seen my interface skew 'paper' right ?
[07:52] <spiv> lifeless: yes
[07:52] <lifeless> good :)
[07:52] <spiv> lifeless: but thanks for the reminder, it may be relevant to a blog post I'm slowly composing.
[07:57] <lifeless> ok, thats my 9 1/2 hours
[07:57] <igc> poolie: re "having a docstring that repeats the method name doesn't count" ...
[07:57] <igc> it *is* sometimes useful
[07:57] <igc> not for what it says, ...
[07:57] <igc> but for the fact that it doesn't add anything else :-)
[07:58] <poolie> i guess it can represent two things:
[07:58] <spiv> igc: then it should just directly say "I'm a slack developer." ;)
[07:58] <poolie> "i thought about this and i'm sure there's no more to say" or "i didn't think very much"
[07:58] <poolie> :)
[07:59] <igc> spiv: :-)
[07:59] <poolie> are we testing the developer's state or their behavior? :)
[07:59] <spiv> igc: because docstrings should express intent rather than just stating the obvious about the implementation ;)
[07:59] <igc> both :-)
[08:00] <Stevage> hello
[08:00] <Stevage> how do you find the history of all files in a directory?
[08:00] <Stevage> or one file, for that matter?
[08:00] <lifeless> bzr log PATH
[08:00] <lifeless> gives one file at a tie
[08:00] <lifeless> *time*
[08:00] <Stevage> "bzr log dirname" seems to only give revisions for the directory itself
[08:00] <lifeless> right
[08:01] <lifeless> there isn't a --recursive option for it yet
[08:01] <Stevage> well I just want files in that dir
[08:01] <Stevage> not necessarily subdirs
[08:01] <lifeless> the obvious way to express that to me is 'bzr log dir/*'
[08:02] <lifeless> (that doesn't work, I'm speculating on UI right now)
[08:02] <Stevage> ah
[08:02] <Stevage> yeah, it didn't work :)
[08:02] <Stevage> also, can anyone explain why bzr is case sensitive on windows?
[08:02] <spiv> lifeless: that UI sounds good to me too.
[08:02] <fullermd> You'd need a --no-recuse dir/*
[08:02] <lifeless> Stevage: because windows is case sensitive
[08:02] <Stevage> it's sort of bizarre
[08:02] <fullermd> Since it's likely that * will encompass subdirs....
[08:02] <Stevage> lifeless: since when?
[08:02] <lifeless> bleh
[08:03] <Stevage> "dir pfx" works for a dir called PFX, so why doesn't "bzr log pfx"?
[08:03] <lifeless> did I mention I'm about 6 hours past lunchtime with no food
[08:03] <fullermd> (unless you make recursion non-default, but I think that would be Wrong(tm))
[08:03] <lifeless> Stevage: oh I see. Please file a bug, we can fix that.
[08:03] <poolie> Stevage, i'd say it's because we're case sensitive everywhere
[08:03] <Stevage> coolies
[08:03] <Stevage> well perhaps the UI could be case insensitive
[08:03] <poolie> it would be better if we were case-insensitive internally on platforms where the user would expect that
[08:03] <poolie> right
[08:04] <Stevage> where's the bug tracker?
[08:04] <spiv> bugs.launchpad.net/bzr
[08:05] <poolie> i think 'state verification' is a really poor name, implying that it's for testing things that mutate state
[08:05] <poolie> something like 'result verification' would be better
[08:06] <igc> lifeless: emailed you the results from my repo btw
[08:07] <poolie> it's a good system of naming in other regards though
[08:07] <poolie> spiv, what bothers me a bit about some of the remote tests is that they are very mock-based,
[08:07] <poolie> and i guess i am not a mockist
[08:07] <poolie> i would rather test against a fake object and observe the results
[08:07] <poolie> hm
[08:08] <poolie> also, even for a mock object they're one-sided in that they check only inputs, not results, or vice versa
[08:13] <poolie> i'd like to use http://martinfowler.com/bliki/ObjectMother.html in more tests
[08:13] <poolie> in particular it would be a neat way to make either everything or nothing use unicode filenames
[08:13] <poolie> for examlpe
[08:20] <Stevage> hey can anyone tell me why bzr.exe is so slow?
[08:20] <poolie> what in particular is slow?
[08:20] <Stevage> it takes on the order of 2 seconds just to return "bzr help"
[08:20] <Stevage> it's a problem for me because I need to call it approximately 50,000 times
[08:21] <poolie> !
[08:21] <poolie> yeah
[08:21] <poolie> this is for your importer?
[08:21] <Stevage> yep
[08:21] <poolie> for comparison on my linux machin it's about 0.1s
[08:21] <Stevage> sucks
[08:21] <Stevage> so it's a windowsy thing
[08:21] <poolie> are you running it under cygwin?
[08:21] <poolie> i'm not sure
[08:21] <Stevage> no
[08:21] <Stevage> native
[08:21] <poolie> can you try it with bzr --profile-imports help
[08:22] <Stevage> ok what to do with the output?
[08:22] <Stevage> 281.0 it lists for 'cum' of bzrlib
[08:23] <Stevage> hmm, seems when I run it a few times in a row it's quicker, but still close to a second maybe
[08:24] <spiv> Stevage: paste the output at http://rafb.net/paste and we can take a quick look at it
[08:26] <Stevage> http://rafb.net/p/XMjBKk33.txt
[08:32] <spiv> Stevage: hmm, nothing jumps out at me except for that fact that all imports are pretty uniformly slow.
[08:33] <spiv> Stevage: I wonder if it's something to do with the way bzrlib is packed bundled into a zip file by the win32 installer?
[08:33] <poolie> Stevage, how long does it take to do
[08:33] <poolie> python -c "import bzrlib"
[08:34] <spiv> Stevage: I suppose you could compare running from the source distribution.  (download and unpack the source tarball, install the standalone python if you haven't already, and run "python path\to\unpacked\bzr --profiled-imports help")
[08:34] <poolie> that would be good
[08:40] <Stevage> python -c "import bzrlib" took about half a second. is there a way to time it?
[08:42] <Stevage> poolie: the first two numbers are 219 and 172 (instead of 281 and 172). want me to paste it?
[08:42] <spiv> Even "import sys" takes 15ms according to your --profile-imports output!  (Maybe that's just because the resolution of time.time() on win32 is so poor?  time.clock() is better on win32)
[08:42] <Stevage> yeah I tihnk it's resolution
[08:43] <Stevage> all the times are listed as 0, 15, 16, 31...
[09:01] <poolie> Stevage, i suspect it's something windows-specific as it's so much slower than here
[09:01] <poolie> aside from anything else you should probably post to the list so alexander and co can look at it
[09:01] <poolie> also running from source as spiv says would be good
[09:03] <Stevage> running from source is faster than running from precompiled?
[09:04] <Stevage> I'm semi-running from source (due to my change)
[09:04] <Stevage> or can I compile it myself, will that go faster?
[09:05] <poolie> there are two orthogonal things here - whether you have the extensions compiled
[09:05] <poolie> and whether you're using bzr from inside a zip file, or from separate files on disk
[09:05] <poolie> i think spiv was thinking that using a zip file might be much slower
[09:06] <Stevage> ah
[09:06] <Stevage> how do I check?
[09:06] <Stevage> ok, bazaar\lib contains library.zip
[09:06] <Stevage> if I unzip that will it be faster?
[09:06] <Stevage> and if so, do I just dump the files in lib?
[09:07] <poolie> probably the best thing would be to download the 0.91rc2 tarball
[09:07] <poolie> extract that, then run from in there
[09:07] <poolie> i realize that won't have your changes but let's at least see how it compares
[09:07] <poolie> i assume this is a reasonably new machine?
[09:08] <Stevage> not especially new, why?
[09:09] <Stevage> it's a P4 2.4Ghz
[09:09] <poolie> i mean if it's an 800Mhz pentium
[09:09] <poolie> ok
[09:09] <Stevage> heh yeah
[09:10] <Stevage> ok, why do you do want me to download .91rc2? is it a lot faster than .90.0?
[09:12] <Stevage> is that equivalent to bzr.dev?
[09:20] <ubotu> New bug: #140614 in bzr "selftest noise re _http_start" [Undecided,New]  https://launchpad.net/bugs/140614
[09:22] <poolie> bzr.dev would also be ok
[09:22] <poolie> Stevage, it may be faster, but i think the speed problem may be something specific to your tree
[09:22] <poolie> i'm not familiar with the library.zip thing and i wonder if that's causing a problem
[09:31] <ubotu> New bug: #140615 in bzr "get_reverse_tag_dict" [High,New]  https://launchpad.net/bugs/140615
[09:38] <Gacha> hi
[09:38] <Gacha> I want to create  a repository, like /repository then project1, project2 ...
[09:39] <Gacha> I need to call "bzr init" in the repository or there is some more to know?
[09:43] <poolie> Gacha, init-repo for the repository, then init for each project
[09:44] <Gacha> thanks
[09:44] <Gacha> and how can I get a clean copy of a project, without the .bzr dirs?
[09:44] <Gacha> with "bzr get"?
[09:47] <mlh> Gacha: you need the .bzr
[09:47] <mlh> unless you don't want to use bzr  -- you could export in that case
[09:47] <Gacha> but when I want to use my software for production, not for editing
[09:48] <mlh> that's usually done with your build tool
[09:48] <mlh> but if there's nothign to build you can 'bzr export ... ' or rsync --ignore=.bzr
[09:48] <Gacha> thanks
[09:49] <mlh> er, that'd be rsync --exclude=.bzr   (I was going from memory)
[09:49] <mlh> what scm/vcs did you use before bzr?
[09:50] <Gacha> none
[09:50] <Gacha> this is my first try to use versions :)
[09:50] <mlh> how did you deploy to production then?
[09:51] <mlh> just a copy?
[09:51] <Gacha> with rsync
[09:51] <mlh> ah
[09:51] <Gacha> I had test, production and bacula for safety
[09:52] <mlh> you could have a tiny Makefile or 'deploy' script which ensured that there were outstanding changes and no rubbish before you rsync'd
[09:52] <mlh> '' that there were NO outstanding changes ..'   taht should read
[09:54] <Gacha> I was coding alone so there was no problems, but now I feel the need for versions and branches
[09:54] <Gacha> the hardest would be to lern this to my boss
[09:55] <mlh> I know exactly what you mean
[09:55] <Gacha> he likes to open files as root, edit and thats it
[09:55] <Gacha> and I cant say anything :)
[09:56] <mlh> :-)
[09:56] <fullermd> Oh, don't say anything.  Just overwrite his changes.
[09:56] <fullermd> When he starts bitching, you look him in the eye and say "They weren't in version control, so they never happened."
[09:56] <mlh> hook up aide or tripwire with a script that copies changes to a bzr repo
[10:00] <Gacha> now when I called "bzr init-repo repository" I need to create the projects. I should create them with mkdir and call "bzr init" in the project folder, and nothing in the repository folder?
[10:02] <mlh> see the example in 'bzr help init-repo'
[10:03] <Gacha> I did
[10:03] <mlh> I theeenk you almost always want --no-trees  but I'm far from an experienced bzr'er
[10:04] <mlh> oh, and you did everything up to the 'cd trunk-checkout' ?
[10:04] <fullermd> You always want --no-trees, except when you don't.  Then you want --trees, which you always want, except when you don't.
[10:04] <Gacha> right
[10:06] <Gacha> and whats the difference between --no-trees and trees? What would be the "working trees by default" ?
[10:09] <mlh> Gacha: for one project, the repo and the working tree are in the same place
[10:09] <Gacha> I need repo for many projects
[10:09] <fullermd> No you don't.
[10:09] <mlh> in the init-repo/checkout --lightweight model, they're in different places
[10:09] <Gacha> repository/project1/trunk/.....
[10:09] <mlh> Gacha: it's not a problem to have a repo for each project
[10:10] <Gacha> http://doc.bazaar-vcs.org/latest/en/user-guide/shared_repository_layouts.html#id4
[10:10] <Gacha> I want the 1.1
[10:10] <fullermd> There's no real gain in storing unrelated branches in a repository (there's not any real loss either, but there's no gain)
[10:11] <igc> night all
[10:11] <fullermd> You may be mislead by comparisons to other VCSen.
[10:11] <mlh> Gacha: right, note the separate repo for each project; this contrasts with the SVN layout
[10:12] <mlh> in 1.1 svn has 1 repo for 2 projects; bzr has a repo for each project
[10:12] <Gacha> so, I need to create the repository with the --no-tree or without? The project dirs I can create with simple mkdir or there is some other way?
[10:13] <mlh> again, I think (but stand to be corrected) that all branches/trunks in a bzr init-repo repo should be closely related, i..e branches of one another
[10:13] <Gacha> so, I need to do "init-repo" in each project dir?
[10:13] <fullermd> Well, the answer is yes and no.  It depends on how you want to work.
[10:13] <mlh> Gacha: don't sweat over no-trees
[10:14] <Gacha> but I dont understand the difference
[10:14] <mlh> if you do the lightweight checkout, you're creating a working tree elsewhere and clearly don't need trees in the repo
[10:14] <Gacha> from the one statement in docs
[10:14] <fullermd> The difference is in where your working files are.
[10:14] <fullermd> With --trees, your branches in the repository have working trees colocated in them.  With --no-trees, they don't, and you have to check them out elsewhere to work on.
[10:15] <Gacha> 2nd option looks better
[10:15] <mlh> the other thing is you don't have to decide now.
[10:15] <fullermd> Quite.  You can always change your mind and shift stuff around later.
[10:15] <mlh> just mkdir proj1; cd proj1; bzr init
[10:16] <mlh> you can forget abotu init-repo for the moment
[10:16] <mlh> bzr is easy to start with
[10:16] <fullermd> The question of repositories and where working trees are are pretty ephemeral; you can change all that around any time.
[10:17] <Gacha> I have a remote server where I want to make the repository, but the editing will be on my work computer and home computer.
[10:17] <fullermd> Are you sure you want the repo remotely?  You end up having to go across the network every commit then.
[10:18] <Gacha> how I understand, I need to use Heavyweight Checkout
[10:18] <mlh> indeed
[10:19] <Gacha> I'm a web developer and the changes should be visible every time I commit them
[10:19] <fullermd> Well, that won't happen regardless.
[10:19] <fullermd> Commiting a new revision into the branch won't update some other working tree.
[10:20] <mlh> if you want to do a checkout/export/deploy for every commit, that might be possible with a hook (don't know) or you can have a cron job os seomthing poll the repo
[10:20] <fullermd> I'm pretty sure the SS doesn't exec any hooks, so you're down to manually or cronally triggered.
[10:21] <mlh> but having everything deployed the second it hits the repo is not the design use of a vcs
[10:21] <Gacha> I will execute the pull every time is needed
[10:21] <mlh> you want to use bzr as a replacement for bacula/rsync/whatever
[10:22] <Gacha> :D
[10:22] <Gacha> I want to edit files on my local machine
[10:22] <Gacha> then with small script push them to remote server
[10:22] <mlh> :-) which is a common but discouraged mode of use for any vcs. Certainly the svn and cvs mailing lsits get this kind of request all the time
[10:23] <mlh> In anything more than a one person shop, you should deploy to a demo/test/qa server and run some tests
[10:23] <mlh> and only deploy to production if they pass
[10:23] <mlh> there's also code review of course
[10:23] <mlh> anyway
[10:23] <mlh> enough of software engineering 101 :-)
[10:24] <fullermd> Man, don't tempt me to go on a rant over testing web apps...   I already did that this week.
[10:24] <mlh> I'm in the the thick of it now
[10:24] <mlh> what do you use?
[10:24] <mlh> jmeter and opensta look useful
[10:24] <fullermd> What, for testing?  Nothing, because I've never found a solution.
[10:24] <mlh> heh
[10:24] <fullermd> Hence, the rant.
[10:25] <mlh> wel besides the above, selenium and watij/watir might be worth looking into as they drive a real brwoser
[10:25] <mlh> there's something in pythin around to, which I can't recall
[10:25] <fullermd> Driving a browser sounds like throbbing pain...
[10:27] <mlh> ah the python thing is 'twill'
[10:27] <Gacha> so what should I use, the init or the init-repo?
[10:27] <mlh> fullermd: http://www.advogato.org/article/874.html
[10:27] <fullermd> jmeter looks nothing like what I'd need...
[10:27] <mlh> Gacha: just init for now, make life easy for yourself
[10:28] <Gacha> ok
[10:28] <fullermd> Neitehr does opensta...  these are just stress testers.
[10:28] <mlh> yeah stress testing is what I'm doing .. functional tests by others
[10:29] <mlh> but most stress testers don't udnerstand ajax which may or may not matter
[10:29] <fullermd> Yeah, I need functional tests.
[10:30] <fullermd> Manually stepping through multi-step processes trying various inputs to try and cover all the cases to test a change is a nightmare, and holey as hell.
[10:32] <mlh> my mission is to force developers to write/add to the tests and test before they commit
[10:32] <mlh> fat chance
[10:34] <fullermd> That wsgi stuff in twill sounds like a load of crud I don't need.  I'd just test it against a web server.
[10:35] <fullermd> My problem is I fear any solution is just going to be miserable to use, since I have to define multi-stepping, then going to the right place to check stuff   :|
[10:40] <mlh> He surveyed the website, and all gladness left him and a deep melancholy settled down upon his spirit.   Life to him seemed hollow, and existence but a burden
[10:40] <mlh> (misquoting tom sawyer)
[10:41] <fullermd> Mmm.  Doesn't seem to do anything for the picking apart forms on the viewing side   :|
[11:24] <poolie> ok that's it for me
[01:12] <Kinnison> Is there a command to give me the log --short info about a revision, and also the list of affected filepaths?
[01:12] <lifeless> log --short -v ?
[01:12] <dato> log --short -v ?
[01:12] <lifeless> ciao
[01:13] <Kinnison> perfect, thanks
[01:14] <Gacha> is there a way to specify the user as argument when commiting ?
[01:21] <Peng> Gacha: Starting with the next vversion of Bazaar, there's a --author argument to bzr commit.
[01:21] <Peng> an.
[01:22] <Gacha> nice
[01:22] <Gacha> when it will be?
[02:29] <lifeless> Gacha: we release monthl
[02:30] <Gacha> why the ubuntu package is so outdated?
[02:30] <jdong> it's not THAT outdated
[02:30] <jdong> it's like 1 version behind stable...
[02:30] <Gacha> it would be safe to install from source the new version?
[02:30] <jdong> Gacha: there is a deb repository at bazaar-vcs.org
[02:30] <jdong> you can always get the latest bzr from there for your Ubuntu/Debian release
[02:32] <Gacha> right, I forgot that already installed the newsest from your repository, sorry :)
[03:57] <ignas> hi
[04:02] <Odd_Bloke> ignas: Hi.
[04:55] <alfborge> Can anyone explain pending merges in an easy way?
[04:56] <alfborge> And why do I have to merge when there are no conflicts?
[04:57] <dato> you have to merge (instead of pull) when you have commited a revision of your own
[04:59] <alfborge> thanks
[05:00] <gabe_> ppl
[05:00] <gabe_> what is the best way to backup a no-trees bzr repo? Just tar and bz2 it?
[05:00] <dato> for example
[05:00] <gabe_> i remember with svn i made a dumpfile...?
[05:01] <dato> right. there is no such thing in bzr.
[05:01] <gabe_> k tar and zipping is most straightforward
[05:05] <Zindar> I think the simplest thing is to push it to another machine
[05:05] <Zindar> bzr push = instant backup :)
[05:05] <Zindar> (I know, that might not be what you want for a number of reason... but it's good enought for me)
[05:05] <Peng> Unless the bzr repo gets corrupted. :)
[05:13] <gabe_> Zindar: that's a good idea
[05:13] <Zindar> peng: yes :)
[05:13] <gabe_> problem is I make copious use of sftp
[05:13] <gabe_> Zindar: but bzr doesn't push over sftp properly
[05:13] <Zindar> gabe_: bzr push sftp://path
[05:13] <Zindar> what?
[05:13] <Zindar> why not?
[05:13] <Zindar> I use sftp all the time
[05:13] <Zindar> never had any problems for at least a year
[05:13] <gabe_> i use sftp all the time, it pulls
[05:13] <gabe_>  and checks out
[05:14] <gabe_> but not push
[05:14] <radix> gabe_: you're probably just misunderstanding what "properly" means :-)
[05:14] <radix> gabe_: it does push quite fine over sftp
[05:14] <Zindar> gabe_: what happens?
[05:14] <gabe_> at least in the man it says it won't push working trees
[05:14] <Zindar> never had any problems with it
[05:14] <Zindar> yes
[05:14] <Zindar> but you don't need that
[05:14] <radix> gabe_: yes, it doesn't update the working tree, but all the data is there in the .bzr
[05:14] <gabe_> right
[05:14] <gabe_> aha that's ok then
[05:14] <Zindar> you can always login and do "bzr update" to recreat then
[05:14] <gabe_> it's true i don't need working tress
[05:14] <radix> or just branch it back, etc
[05:14] <gabe_> for example
[05:14] <Zindar> exactly
[05:15] <gabe_> if i push to another machine I will have a treeless repo...
[05:15] <gabe_> if i log in to that machine and cd to the repo
[05:15] <gabe_> how can i make trees from the .bzr?
[05:15] <radix> bzr update
[05:15] <Zindar> the reason is simply that working trees is something that can change.. so if you would want to update that, you would have to run diff and stuff like that over sftp.. which is not fun
[05:15] <Zindar> you just run "bzr update"
[05:16] <gabe_> and it updates from the local copy?
[05:16] <radix> actually, you may need to run "bzr checkout ." if it's the first time? or maybe that's not necessary any more
[05:16] <gabe_> that's awesome
[05:16] <radix> gabe_: yes
[05:16] <gabe_> i'll try it :P
[05:16] <gabe_> cheers
[05:16] <radix> ok :)
[05:16] <gabe_> makes more sense than tarring and zippin
[05:17] <gabe_> just today i moved the last of my projects over from svn
[05:17] <gabe_> now i'm figuring out the best way to back it all up
[05:20] <Peng> I think it's a good idea to tar it up occasionally, just in case the repository gets corrupted or something.
[05:22] <gabe_> Peng: good idea, perhaps about once a week will be cool
[05:26] <Peng> Yeah.
[05:43] <gabe_> ummm
[05:43] <gabe_> not sure what to do...
[05:44] <gabe_> I have a bzr repos, it is called 'bazaar' :)
[05:44] <gabe_> i mounted a backup destination via NFS
[05:44] <gabe_> bzr co /usr/var/bazaar/ /media/backup/
[05:44] <gabe_> bzr: ERROR: Not a branch: /usr/var/bazaar/.bzr/branch/
[05:45] <gabe_> it is a --no-trees repo with many branches beneath it
[05:45] <gabe_> what is the easiest way to backup the entire thing?
[05:46] <dato> gabe_: you can't 'co' a repo, only a branch. and since you presumably have several branches in the repo, you'd have to 'co' each of them.
[05:46] <dato> so it's better to run tar+gz, or rsync
[05:46] <gabe_> ah damn
[05:47] <dato> rsync would work best if you have the old copy lying around (i.e. if you run it periodically over the same directory)
[05:47] <dato> in any case, backuping .bzr is the same as backuping any other directory in the filesystem
[05:48] <gabe_> ok so that makes it a bit easier
[05:48] <gabe_> hmmm freebsd don't have rsync by default - cripple!
[06:05] <gabe_> cheers, rsync worked a treat on all those thousands of knit files!
[06:10] <sri> sup
[06:13] <gabe_> sri: yo
[06:53] <sri> yo
[08:12] <james_w> could someone please get me the output of bzr info -v bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk I don't have my ssh key around.
[08:12] <james_w> I just need the format lines really, in particular the branch.
[08:14] <james_w> ah, no need, grep saves the day again.
[08:31] <corporate_cookie> i'm trying to build a bzr-17 rpm with python2.4 setup.py bdist --fromats=rpm ...and it errors at /bzr-0.17.0/bzrlib/__init__.py", line 46 complaining of 'invalid syntax'
[08:31] <corporate_cookie> any ideas ?
[08:32] <corporate_cookie> line 46 is bzrlib.symbol_versioning import (deprecated_function,
[08:41] <ignas> hi
[08:41] <corporate_cookie> hi : )
[08:43] <ignas> my checkout weights ~70 mb, is there a way to make working with it through the network a bit easier?
[08:43] <ignas> i mean just pushing the branch to launchpad takes ages
[08:43] <ignas> makes me think twice before creating a public feature branch :/
[08:55] <cr3> when I bzr push, I get: No push location known or specified. So, where can I specify a push location?
[08:55] <ignas> bzr push [LOCATION] 
[08:56] <ignas> can i get bzr tell me more information about progress of such looong operations as "bzr push"?
[08:56] <cr3> ignas: thanks, I wonder why that location wasn't preserved when branching
[08:56] <ignas> well, *pushing* a branch into the place which you branched from
[08:57] <ignas> is not what you want 90% of the time
[08:57] <ignas> usually you *branch* and then *merge* the changes back
[08:59] <ignas> hmm, bzr push sftp://some-place-in-launchpad -v is not giving me anything more than the same old progress bar :/
[09:13] <james_w> corporate_cookie: you need python 2.4, it looks like you are running python 2.3.
[09:14] <corporate_cookie> james_w: when I issue python2.4 -V ...it tells me i'm running Python 2.4
[09:17] <james_w> corporate_cookie: ah, sorry, I missed you were explicitly running with 2.4
[09:17] <james_w> corporate_cookie: does the line in question not start with "from"?
[09:20] <corporate_cookie> james_w: it dose indeed start with from
[09:20] <james_w> corporate_cookie: what is the previous line?
[09:21] <corporate_cookie> james_w:      version_string = '%d.%d.%d%s%d' % version_info
[09:21] <corporate_cookie> __version__ = version_string
[09:21] <corporate_cookie> its an else clause
[09:25] <james_w> I'm not sure then.
[09:25] <corporate_cookie> alas ..that makes two of us
[09:25] <corporate_cookie> thanks for the help though
[11:37] <AnMaster> I have been searching the website for info about the command "sign-my-commits" and how it is used but have been unable to find anything useful in the way of documentation
[11:37] <AnMaster> I would like some more info about how it works
[11:44] <lifeless> AnMaster: it triggers the normal gpg signing for all revisions that match
[11:45] <lifeless> and are not signed
[11:45] <AnMaster> lifeless, hm? and how does the normal gpg signing work
[11:45] <AnMaster> that is where I can't find any info
[11:46] <lifeless> doc.bazaar-vcs.org/bzr.dev/en/user-guide/configuration.htm
[11:46] <lifeless> sorry, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/configuration.html
[11:52] <AnMaster> lifeless, hm, one problem, how does it select gpg key
[11:52] <AnMaster> I would have several that would match
[11:52] <lifeless> it users your default, unless you override the signing command to supply it
[11:53] <AnMaster> ok
[11:53] <AnMaster> lifeless, I'm not sure what my default one is, as I use GUI frontends like kgpg
[11:53] <lifeless> gpg --clearsign foo
[11:53] <lifeless> wll probably tell you
[11:54] <lifeless> if kgpg accepts gpg commands you can use kgpg from bzr
[11:54] <lifeless> I use gnome-gpg for instance
[11:54] <lifeless> which means I get a gui prompt
[11:54] <AnMaster> hm
[11:54] <lifeless> gpg_signing_command = gnome-gpg
[11:54] <lifeless> in my bazaar.conf
[11:55] <AnMaster> hm
[11:56] <AnMaster> now this is odd, I just checked against key server and some one I got no idea who it is has signed my key. hm
[11:56] <AnMaster> oh well doesn't belong in this channel