[00:04] <poolie> lifeless, what has regressed
[00:04] <poolie> jam-laptop, hi
[00:04] <jam-laptop> hi
[00:04] <jam-laptop> poolie: 'bzr update' in a checkout
[00:04] <poolie> the error for trying to commit to a readonly branch?
[00:04] <lifeless> poolie: no
[00:04] <poolie> what jam said
[00:05] <lifeless> 'bzr checkout http://people.ubuntu.com/~robertc/pack-repository.knits', wait while I push a new rev, 'bzr update' && boom
[00:05] <lifeless> I know you looked at this
[00:05] <poolie> iirc there is still a bug open on it
[00:05] <poolie> i haven't fixed it
[00:05] <lifeless> oh, ok.
[00:05] <lifeless> ipso facto I was confusedo
[00:05] <poolie> it may have been working at some time in the past
[00:05] <poolie> but, it wasn't tested :)
[00:06] <poolie> i have written some format docs on packs
[00:06] <poolie> will send them shortly
[00:06] <poolie> and have done the non-structural review cleanups
[00:06] <poolie> i am going to see whether the structural cleanups i wanted can be done easily or not
[00:07] <poolie> if not easy, they can just be turned into todos or bugs or forgotten maybe
[00:07] <poolie> jam-laptop, ll may have already suggested it, but
[00:07] <dash> oh. is --forget-merges not in 0.91 either? :(
[00:07] <poolie> maybe you would look at making interpack fetch make sure that the text delta basis is in the destination
[00:08] <nDuff> ...odd, initial incremental commit is acting like it isn't using the C extension -- massive amounts of CPU time used while collecting changes.
[00:08] <poolie> dash, it'll be in 0.92
[00:09] <dash> i guess I can just write my own script for now
[00:09] <lifeless> revno 2000 merged support for --lightweight with http checkouts
[00:09] <dash> =/
[00:09] <lifeless> dash: heh, sorry :)
[00:10] <lifeless> and 2019 claimed to fix it for heavyweight checkouts :(
[00:10] <lifeless> ok no its right
[00:10] <lifeless> there have been no commits that claim to make heavyweight checkout updates work over http
[00:11] <lifeless> 2088 did that for lightweight, so I'd say it was a 'just worked' thing initially
[00:12] <dash> huh. after "bzr revert" i'm not seeing a pending merge. i guess that's sufficient.
[00:12] <lifeless> jam-laptop: what do you think of a dirstate iterator which _sha_from_stat advances, in commit ?
[00:12] <lifeless> dash: you'll also have lost your changes ...
[00:13] <dash> lifeless: which is OK
[00:13] <nDuff> lifeless: 15m52s wall-clock for first incremental, 15m27s of that being user time.
[00:13] <lifeless> nDuff: that really is suspect isn't it.
[00:13] <lifeless> do we list the C extensions anywhere yet ?
[00:14] <lifeless> nDuff: when it went faster before, how fast was it ?
[00:15] <lifeless> poolie: call ?
[00:15] <poolie> in 5m?
[00:15] <lifeless> sure
[00:18] <nDuff> lifeless: out of my scrollback buffer right now, sadly, and I didn't record it. that said, recommit (of the same thing that just took ~16min) is completing in 1m52s.
[00:18] <lifeless> grah
[00:18] <lifeless> the only thing that makes sense to me is the C extensions not being picked up
[00:19] <lifeless> perhaps we should make that a nag
[00:20] <nDuff> ...hmm. seems odd that it would happen only on initial incremental commit and not on recommit. Is there significant work done (prone to throwing an exception based on tree state) while the module is first being loaded?
[00:24]  * nDuff looks at the code, and yeah -- looks like only an ImportError should result in fallback.
[00:25] <nDuff> would trace.mutter() append to .bzr.log under normal conditions, or should I be doing something else to instrument?
[00:26]  * nDuff looks in trace.py, and decides that warning() is more appropriate to the case anyhow.
[00:36] <nDuff> 1m11s initial commit; 12.2s status w/ bad cache (and new files unknown), 7.6s status with good cache (and new files unknown), 25.4s to add unknowns, 12.1s/9.9s initial/subsequent status after adding unknowns... and now the 15min incremental commit isn't reproducing itself.
[00:37] <igc> morning all
[00:40] <jam-laptop> lifeless: would you use a full iterator, or just another "this was the last cached lookup" like you just added
[00:41] <lifeless> nDuff: trace.mutter does to th elog
[00:42] <lifeless> jam-laptop: I'm thinking a full generator. Basically lsprof is claiming 10% in _get_entry
[00:42] <jam-laptop> lifeless: I would wonder if it could actually keep exactly in sync with commit
[00:42] <jam-laptop> (partial commits, etc have an effect here)
[00:42] <lifeless> jam-laptop: an alternative would be an equivalent of inventory.iter_entries_by_dir(specific_file_ids=XXX)
[00:43] <lifeless> with yield_parents=True
[00:47] <jam-laptop> iter_entries_by_dir() seems like a good route to me
[00:48] <nDuff> ...hrm, cancel that; still a 15 minute commit, and none of the logging directives I put in in case of an ImportError on the C modules triggered. Time for a callgrind run, I suppose.
[00:58] <nDuff> appears to get slower near the end of the change-collection process, incidentally.
[01:00] <lifeless> jam-laptop: the iter_entries_by_dir will need to return the disk data; thats really the disconnect we're dealing with.
[01:00] <lifeless> jam-laptop: I don't think this is a 2-day piece of code; particularly with win32 sadness.
[01:00] <lifeless> jam-laptop: so I'll send a mail right now
[01:00] <jam-laptop> well, the _sha_sum... do you honestly think that would be reasonable?
[01:01] <jam-laptop> It just seems like it is iterating at a very different layer
[01:01] <jam-laptop> and you are expecting it to stay in sync
[01:01] <jam-laptop> I suppose if you pass in the path
[01:01] <jam-laptop> and you know you are always "incrementing" in path
[01:01] <jam-laptop> then it can fast forward until it finds what you need
[01:01] <lifeless> well
[01:01] <jam-laptop> But we don't have plain python generators that take more data
[01:02] <lifeless> we don't need one
[01:02] <jam-laptop> (until 2.5 or later)
[01:02] <jam-laptop> I guess _sha_... could do the fast forwarding
[01:02] <lifeless> iter_entries_by_dir on inventory returns inventory objects
[01:02] <lifeless> we need one that returns the key fields and the path_content_summary details
[01:03] <lifeless> hmm
[01:03] <lifeless> I'll test doing a cache lookup; one second
[01:08] <lifeless> jam-laptop: hmm, do I need to update the _id_index in my update_basis patch ?
[01:14] <lifeless> jam-laptop: I'm just building a dict of all the stats
[01:14] <lifeless> jam-laptop: won't be so hot for partial commits, but ...
[01:15] <lifeless> possibly a threshold of lookups to trigger changing form
[01:16] <lifeless> nDuff: commit feedback is per-dir, if you have larger dirs at the end that would explain the apparent slowdown, or it may be list accumulation overhead
[01:17] <lifeless> still, its two seconds faster on incremental commits
[01:21] <lifeless> initial commit down to 1m29
[01:21] <lifeless> wall clock :0
[01:30] <nDuff> lifeless: I've got a .callgrind file; anywhere particular you'd like it uploaded?
[01:30] <lifeless> mail me or give me a url
[01:30] <lifeless> they gz well
[01:34] <nDuff> lifeless: in the mail.
[01:34] <lifeless> thanks!
[01:39] <jam-laptop> lifeless: I don't think you want to try to update _id_index, since there is too much stuff going on (some entries will be in the removed parents, etc)
[01:39] <jam-laptop> lifeless: But you probably should reset it
[01:39] <jam-laptop> I think self._id_index = None is fine
[01:47] <lifeless> nDuff: holy fuck. is_inside_any is taking 90% time
[01:47] <lifeless> nDuff: what parameters did you give commit ?
[01:48] <nDuff> lifeless: bzr arguments: [u'--lsprof-file', u'../upstream-portage-tree.current.first_incremental_commit.callgrind', u'commit', u'-m', u'first incremental commit', u'--quiet']
[01:48] <lifeless> nDuff: do you have many deleted paths ?
[01:48] <nDuff> probably; let me check.
[01:49] <lifeless> thats likely it
[01:49] <lifeless> is_inside_any is not that cheap; my strategy to date has been to avoid calling it as much as possible.
[01:49] <lifeless> looks like we need a smarter structure than linear searching. e.g. bithection
[01:49] <lifeless> brb, food time
[01:50] <lifeless> jam-laptop: another dirstate patch for your consideration :)
[01:52] <nDuff> lifeless: 8045 removes, 35597 adds, 24211 modifications.
[01:52] <lifeless> nDuff: that will be it
[01:52] <lifeless> we could make this a list
[01:53] <lifeless> deletes[bisect_left(deletes, path)].starts_with(path)
[01:53] <lifeless> or a dict matching the tree structure
[01:53] <lifeless> jam-laptop: ^ I think bisect is probably good enough, or possibly even best.
[01:53] <lifeless> we're going to have to do 100K lookups into this
[01:54] <poolie> lifeless, pack doc sent
[01:54] <lifeless> another thing is we know when we're going to have to lookup again - when we add a delete, or when we change directory
[01:54] <lifeless> nDuff: Anyhow, I a) know where the problem lies, b) can definately fix it.
[01:54] <nDuff> nifty!
[01:54] <lifeless> nDuff: its the number of deletes that you have in your tree during the commit.
[01:54] <lifeless> thank you for the callgrind
[01:55] <nDuff> np. thank *you* for putting up with all my fumbling around.
[01:57] <nDuff> know when you might have a chance to address this one? if it'll be a while, I'd like to open a ticket so I can get notice after it's happened.
[01:57] <lifeless> please open a ticket
[01:58] <lifeless> it may not be a while
[01:58] <lifeless> but its worth noting
[01:58] <lifeless> I've put the stat cache improvements into pack-repository.knits too, revno....
[01:59] <lifeless> 2853
[01:59] <AfC> In my Darcs days, this sort of thing would trigger the Red Giant bug, but since it was exponential you could usually get around it be making smaller commits with less files/deletes/whatever. Would that be the case here?
[01:59] <AfC> [Not that you really want to bandy that about]
[01:59] <lifeless> AfC: nah, I'll just fix it
[02:00] <lifeless> :)
[02:05] <nDuff> lifeless: https://bugs.launchpad.net/bzr/+bug/156491
[02:05] <ubotu> Launchpad bug 156491 in bzr "bzr-packs: commit with many deletes spends much time in is_inside_any" [Undecided,New]
[02:05] <fullermd> That's no fun.  It's hard to feel like your software is working hard, if you don't have to occasionally pander to it.
[02:06] <spiv> fullermd: ah, so you recommend that our tool should be so bad it causes stockholm syndrome? :)
[02:07] <fullermd> Well, there are people still using arch...   _you_ connect the dots   :p
[02:07] <nDuff> lifeless: btw, I'm curious, if the explanation is accessible to folks who don't know the codebase -- why is this case hit only on an initial commit, but not on a recommit or other operations which need to determine what is scheduled to be committed/deleted/etc (ie. status)?
[02:10] <ubotu> New bug: #156491 in bzr "bzr-packs: commit with many deletes spends much time in is_inside_any" [Undecided,New] https://launchpad.net/bugs/156491
[02:11] <poolie> spiv, hi
[02:13] <spiv> poolie: good morning
[02:13] <lifeless> nDuff: well, its hit on the first incremental case
[02:14] <lifeless> nDuff: when both FOO and all the children of FOO are deleted, we like to report only 'FOO deleted'
[02:14] <lifeless> thats a significant factor in this
[02:16] <lifeless> nDuff: I'm going to review a patch then do the changes review asked for in one of my patches
[02:16] <lifeless> then I'll see what I can do about this
[02:17] <nDuff> graci
[02:17]  * nDuff wanders off to do some clustering work.
[02:29] <poolie> spiv, wow, you're right
[02:29] <poolie> i thought i'd checked that this revision was referenced by its own inventory but in fact it is not
[02:29]  * lifeless grins
[02:30] <poolie> which is why it's good to check
[02:30] <spiv> poolie: yeah.  That had me confused for while :)
[02:31] <spiv> I'd assumed that if its own inventory didn't refer to it, then no others could.
[02:31] <lifeless> spiv:  in theory that is right.
[02:32] <lifeless> spiv: I suggest making 'bad' into a fulltext for now,
[02:32] <lifeless> with inventory reassembly in the future.
[02:32] <spiv> lifeless: right.  But reconcile of course is dealing with broken files...
[02:32] <lifeless> this is oooold data
[02:32] <spiv> lifeless: ah, that's a clever idea.
[02:32] <spiv> inventory reassembly is going to be very slow without a fair bit of effort I fear :/
[02:32] <lifeless> right
[02:33] <lifeless> not to mention hard
[02:33] <spiv> Hmm, I think I can see how to do it reasonably efficiently.
[02:34] <poolie> so just making it a fulltext is not, by itself, going to totally exclude this problem
[02:34] <poolie> as we talked about on the phone
[02:34] <spiv> But it's not a trivial amount of work...
[02:35] <spiv> poolie: why's that?
[02:36] <poolie> call one of the revisions that references it "bad"
[02:37] <poolie> um, "dependant" (typo)
[02:37] <poolie> suppose the destination already has the revision "bad"
[02:37] <poolie> it probably won't have known to pull that text version
[02:37] <poolie> then, when it comes to pull "dependent" it will think it doesn't need to pull the text version
[02:38] <spiv> I see.
[02:39] <lifeless> poolie: but ifi t has bad already, then it has the text already.
[02:39] <spiv> You're now doing checks when pulling to make sure the parent is available, though?
[02:39] <lifeless> poolie: *if it has bad already*.
[02:39] <spiv> So this would only happen if the repo was constructed before you added those checks?
[02:39] <lifeless> IMO yes
[02:41] <poolie> lifeless, are you sure it will have detected to copy this text when pulling 'bad', even though it's not apparently modified?
[02:42] <poolie> i guess this is easy to test
[02:42] <lifeless> I guess we're talking slightly different corner cases.
[02:42] <lifeless> What I'm trying to say is 'if andrew makes the text a full text we will not encounter headaches with bzr.dev'
[02:44] <poolie> well, that would be good for now
[02:44] <poolie> even if it may not cover every case
[02:45] <lifeless> garh bloody lawn mowers
[02:47] <lifeless> jam-laptop: good call on the parent swap test; found a bug
[02:48] <lifeless> jam-laptop: ping though
[02:51] <lifeless> poolie: doco reviewed
[02:53] <poolie> thanks!
[02:53] <poolie> re your last point about the pack-names file
[02:54] <lifeless> igc: can yu review 'use a dict to access stat cache' ?
[02:54] <poolie> the requirement is that, every pack listed there must exist
[02:54] <lifeless> igc: also, what part of commit are you hacking on at the moment, so we don't collide.
[02:54] <lifeless> poolie: yes, every pack in that file must exist. Every pack that exists *may* be in that file.
[02:54] <poolie> but it is possible to have a window where about-to-be-removed packs are present but not listed
[02:54] <igc> lifeless: I'll review that soon
[02:54] <lifeless> poolie: also during insert, we put the pack before we add to the names list.
[02:54] <poolie> so, you could recreate it, but this might be reintroducing redundant copies of the file
[02:55] <poolie> oh i was going to mention the file sizes too
[02:55] <lifeless> poolie: but in that case its arguable that we should add them if we were to notice.
[02:55] <igc> I'm currently working on bug 115601
[02:55] <ubotu> Launchpad bug 115601 in bzr "no clean abort after bzr+ssh:// connection timeout. ERROR: exceptions.AssertionError: end of file reading from server." [High,Confirmed] https://launchpad.net/bugs/115601
[02:55] <igc> as requested by poolie
[02:55] <lifeless> igc: coolio :)
[02:55] <igc> code done - just the tests to do now
[02:55] <lifeless> poolie: You might also be introducing inconsistent data in a post-reconcile scenario
[02:55] <lifeless> poolie: or data that is being deliberately removed.
[02:56] <lifeless> poolie: so I'd really encourage the concept that 'the pack-names file is authoritative, precious, and not reconstructable'
[02:57] <poolie> sure
[02:57] <poolie> that's just the kind of thing i want to capture
[02:57] <poolie> i guess for the iix it is graph parents first too, then compression base
[02:58] <poolie> like for tix?
[02:58] <lifeless> yes
[02:58] <lifeless> I should have been more explicit
[02:58] <poolie> np
[02:58] <poolie> just brain slippage, i had seen them in the other order
[03:30]  * igc food
[03:46] <poolie> lunch for me too.
[03:50] <spiv> Good idea.
[03:50]  * spiv -> food
[05:41] <indraveni> hi all
[05:41] <lifeless> hi
[05:41] <indraveni> i have configured the loggerhead as per my bzr branch
[05:41] <indraveni> but now i am not knowing how i can view it through the browser
[05:42] <indraveni> how to configure it in apache web server
[05:45] <i386> http://dharmatech.onigirihouse.com/atari-forth.jpg
[05:46] <poolie> lifeless, i'm not so sure that having unlock raise an error if a write group is underway is the best thing, as i said in my review
[05:46] <poolie> i have another reason which is that it tends to hide errors
[05:47] <poolie> to raise exceptions from things expected to be called from finally blocks
[05:48] <lifeless> poolie: fair enough, I can buy that, though its good from a correctness point of view
[05:48] <lifeless> perhaps a debug option or smething
[05:49] <poolie> or a warning, which can be caught by -Werror
[05:52] <igc> lifeless: I'll review the 'dict to access stat cache' patch now
[05:57] <indraveni> i need help in setting up loggerhead
[05:57] <poolie> indraveni, is there really no documentation?
[05:57] <lifeless> is there documentation is loggerhead itself?
[05:58] <indraveni> poolie, i couldn't find any good document
[05:58] <poolie> indraveni, mwh is the new maintainer, he should be online in a bit
[05:58] <indraveni> except the commented content in the conf file
[05:58] <indraveni> ok
[05:58] <lifeless> theres no README? or INSTALL?
[05:59] <indraveni> lifeless, there is a README which says
[05:59] <indraveni> that everything is similar to Tubergears
[05:59] <indraveni> and i dont have experience with tubergears
[05:59] <indraveni> and for apache conf some steps are given, but i am not able to udnerstnad how it works
[06:02] <lifeless> well
[06:02] <lifeless> AIUI turbogears can run as its own webserver or as a fastcgi script
[06:02] <lifeless> you can probably find out more via google
[06:03]  * nDuff is generally familiar with turbogears.
[06:04] <nDuff> typically, you've got a file start-<yourproject>.py, and a config file with all your installation-specific settings
[06:04] <nDuff> ...so starting the server is along the lines of running "start-<yourproject>.py foo.cfg"
[06:04] <nDuff> can't say anything about loggerhead specifically, though.
[06:05] <nDuff> if you're running through apache, of course, it gets more complicated (unless you're doing it the easy way and using mod_proxy).
[06:08] <nDuff> lifeless: hmm, just tried pushing from my local (packs-based) tree to a "bzr serve" instance on the LAN (working against a packs-based shared repo). bzr: ERROR: Could not understand response from smart server: ('error', "<bound method GraphKnitRepository.leave_lock_in_place of GraphKnitRepository('chroot-47750944724688:///.bzr/repository/')>")
[06:09] <lifeless> nDuff: oh, looks like bad marshalling.
[06:09] <nDuff> full stack trace from the server at http://pastebin.com/d26bd26fa
[06:09] <lifeless> please file a bug
[06:09] <lifeless> it won't be hard to fix, the problem is that this is an optional method, and one that packs don't support
[06:10] <lifeless> because they don't use the previous locking model.
[06:14] <nDuff> lifeless: https://bugs.launchpad.net/bzr/+bug/156546
[06:14] <ubotu> Launchpad bug 156546 in bzr "unable to push to packs-based smart server" [Undecided,New]
[06:15] <lifeless> thanks!
[06:21] <ubotu> New bug: #156546 in bzr "unable to push to packs-based smart server" [Undecided,New] https://launchpad.net/bugs/156546
[06:25] <lifeless> spiv: ^
[06:27] <lifeless> ok, think I have the pieces put back together again.
[06:27] <lifeless> one more run then onto nDuff's performance issue
[06:28] <lifeless> poolie: spiv: I think it would be nice to have some way to be sure the remote server handles optional protocols (like leave_lock_in_place) correctly
[06:38] <poolie> do you mean a way to test it?
[06:48] <sabdfl> morning all
[06:49] <poolie> hi sab
[06:50] <lifeless> hi sabdfl
[06:51] <igc> hi sabdfl
[06:53] <igc> lifeless: review sent to the list now
[06:56] <lifeless> poolie: is it ok to merge the stat lookup via dictionary patch ?
[06:57] <lifeless> poolie: thats the 5 second win on incremental commit
[06:57]  * poolie looks
[06:58] <poolie> i'd like to merge the pack branch with the small changes, then put the larger ones up for separate review
[06:58] <poolie> ok?
[06:58] <lifeless> well this is a trivial change
[06:58] <lifeless> not packs per se
[06:58] <igc> and I've reviewed it poolie
[06:58] <lifeless> ''trivial'' conceptually, code wise its something like 20 lines
[06:59] <lifeless> right, I'm asking you with your RM hat.
[06:59] <poolie> it looks ok to me
[06:59] <poolie> sure
[06:59] <lifeless> poolie.hats().switch("RM")
[06:59] <lifeless> :)
[07:04] <lifeless> bbiab
[07:06] <poolie> packs branch sent up
[07:08] <lifeless> to pqm ?
[07:09] <poolie> yes
[07:09] <lifeless> awesome
[07:09] <vila_> tada !
[07:09] <poolie> indeed
[07:09] <lifeless> sabdfl: ^^^ :)
[07:09] <spiv> Woo!
[07:10]  * vila_ send some champagne
[07:11] <lifeless> poolie: does it have the same disk format string ?
[07:11] <poolie> yes, still the same
[07:11] <poolie> and still just called 'experimental'
[07:12] <lifeless> ok
[07:12] <poolie> is there any test framework support for checking that an assertion other than a deprecationwarning is raised?
[07:12] <poolie> (obviously the format and name needs to be changed)
[07:14] <sabdfl> *pop* goes the champagne :-) great work lifeless et al
[07:15] <poolie> hm that kind of sucks, the python warning module does not make it very easy to catch them
[07:15] <lifeless> I'll wait till friday for the champagne :)
[07:15] <poolie> qantas champagne?
[07:15] <lifeless> no, but we're all together friday night
[07:15] <lifeless> FSVO friday :)
[07:16] <lifeless> also I don't think we get champagne in economny class :(
[07:24] <igc> hi hi hooray lifeless - well done
[07:25] <ubotu> New bug: #156557 in bzr "Bazaar does not obey setgid on Linux" [Undecided,New] https://launchpad.net/bugs/156557
[07:29] <lifeless> current figures are stable - 1m31 wall initial commit, 0m15 incremental, 0m10 partial
[07:31] <EzeeGuy> hello
[07:33] <lifeless> hello
[07:48] <lifeless> poolie: you forgot kthxbye on your commit message :)
[07:48] <poolie> heh
[07:48] <poolie> i should have
[07:48] <lifeless> looks like it's copacetic though, deep in the ascii tests
[07:49] <poolie> huh?
[07:49] <lifeless> it looks like it will land and not bounce
[07:50] <poolie> http://en.wikipedia.org/wiki/Copasetic
[07:53] <lifeless> yes, thats the definition
[07:53] <lifeless> righto, I forgot I was going out tonnight
[07:53] <lifeless> ciao
[07:54] <poolie> bye
[08:01] <lifeless> actually cancelled
[08:01] <lifeless> too tired
[08:03] <igc> reviewing the lp-login patch currently
[08:04] <lifeless> woot?! has it landed?!
[08:09] <indraveni> mwh, hi, are u tehre
[08:10] <lifeless> you want mwhudson
[08:11] <indraveni> yes lifeless
[08:11] <indraveni> i need help in loggehead, yesterday he was helping me
[08:13] <mdke> morning / evening lifeless
[08:13] <mdke> svn-import finished successfully yesterday :)
[08:14] <lifeless> mdke: excellent
[08:14] <mdke> but now I just have .bzr directories, I can't see the files anywhere...
[08:14] <mdke> is there another step I need to do?
[08:14] <lifeless> mdke: you can get a working tree in any branch by doing 'bzr checkout .'
[08:14] <lifeless> or you can make new branches from these and treat the current directly like a cvs or svn repository
[08:14] <mdke> righty ho
[08:15] <mdke> so bzr branch /local/url new/branch?
[08:17] <lifeless> mdke: yup that will work
[08:18] <lifeless> mdke: then bzr push /local/url to push back to /local/url
[08:18] <lifeless> mdke: or you can do 'bzr checkout /local/url new/tree/' which will make it work like svn - when you commit /local/url gets the changes
[08:20] <mdke> aha, clever
[08:20] <mdke> lifeless: thanks. I will branch then push the branches to LP, once I'm done with that I'll abandon /local/url
[08:28] <vila> wikipedia says: 'Copacetic may be a descendant of the Hebrew phrase "hakol beseder"', which I read 'How cool bzr' is :)
[08:29] <vila> well, you have to read bzr with a french accent though, but wikipedia also says that one possible origin is creole, so I think I'm ok :)
[08:32] <Peng> Cool!
[08:33] <sabdfl> a tour de force, lifeless. very well done indeed.
[08:34] <poolie> indraveni, mwh should be awake soon
[08:34] <indraveni> poolie, thankyou
[08:34] <indraveni> poolie, will wait for him
[08:35] <lifeless> sabdfl: thanks!. And boy do we have ideas to improve on this improvement.
[08:36] <lifeless> sabdfl: though as I said a while pack, the very core disk layout is now solid IMO (the pack disk format itself).
[08:37] <igc> pack on the brain eh lifeless - s/pack/back/ :-)
[08:37] <lifeless> indeed
[08:39] <mwhudson> indraveni: hello
[08:40] <indraveni> mwhudson, hi
[08:40] <indraveni> mwhudson, good morning
[08:41] <indraveni> mwhudson, i have edited the loggerhead conf file accordingly but now i am struck with how to make it acess with apache
[08:41] <indraveni> ?
[08:41] <indraveni> i have apache installled and i have a vhost entry for my bzr repo
[08:43] <Lo-lan-do> http://bazaar-vcs.org/BazaarFormats doesn't mention packs...
[08:43] <AfC> Lo-lan-do: so add it
[08:43] <lifeless> :)
[08:43] <Lo-lan-do> I'd gladly paste from the output of bzr help formats, but even that doesn't mention them.
[08:44] <lifeless> they are still considered experimental
[08:44] <AfC> Lo-lan-do: so write a patch adding documentation for it.
[08:44] <lifeless> we have a small amount of work to do to make them be exposed
[08:44] <AfC> Lo-lan-do: in other words, chill, dude.
[08:44] <mwhudson> indraveni: you need to use ProxyPass or similar
[08:44] <indraveni> mwhudson, yes, i saw about it in my README file
[08:45] <lifeless> well, I like the enthusiasm
[08:45] <Lo-lan-do> AfC: I'm totally chilled (especially now jelmer helped me fix my bzr-svn problem), I'm just looking for info on this new shiny format that everyone seems so excited about :-)
[08:45] <indraveni> but how do i need to access it through browser ?
[08:45] <lifeless> Lo-lan-do: if you want to play, or add docs to the wiki, if you look at my mails to the list about dogfooding they are still valid
[08:45] <mwhudson> indraveni: here's what we (will) use for testing: http://rafb.net/p/1PMHGs81.html
[08:45] <lifeless> Lo-lan-do: its just that you don't need anything other than bzr.dev to experiment
[08:46] <mwhudson> you need to have "127.0.0.88 codebrowse.launchpad.dev" in your /etc/hosts file
[08:47] <indraveni> mwhudson, but in this where is the info about the bazaar repo ?
[08:47] <mwhudson> indraveni: there isn't
[08:48] <indraveni> mwhudson, then how does the apache know where os bazaar
[08:48] <indraveni> mwhudson, even there is ocnf related to loggerhead location
[08:48] <mwhudson> indraveni: um
[08:48] <mwhudson> indraveni: loggerhead runs an http server, listening on some port or other, 8080 by default
[08:49] <mwhudson> the conf file i pasted above tells apache to forward requests for codebrowse.launchpad.dev to this loggerhead process
[08:50] <lifeless> Lo-lan-do: in bzr.dev
[08:50] <indraveni> but where is loggerhead folder in that case in ur system
[08:50] <mwhudson> indraveni: it doesn't matter!
[08:51] <lifeless> there is a new doc - doc/developers/index lists it, which describes packs.
[08:51] <indraveni> mwhudson, how does apache know where is loggerhead ?
[08:51] <Lo-lan-do> lifeless: Thanks, I'll read up on that.
[08:52] <lifeless> np
[08:53] <mwhudson> indraveni: why does it need to?
[08:53] <mwhudson> it's not running as a cgi script
[09:00] <indraveni> mwhudson, when i give bzr.indraveni ( which is my servername in apahce file) its showing nothing
[09:01] <indraveni> i am not understanding how loggerhead, apache and bazaar are related
[09:01] <mwhudson> indraveni: what are you actually trying to acheive here?
[09:02] <indraveni> mwhudson, when i configure my apache file with vhost like http://pastebin.ca/747691
[09:02] <mwhudson> are you trying to show your branches to the wider internet, just to a few people in your team, just browse them yourself?
[09:02] <indraveni> mwhudson, i am able to see the bazaar repos content in browser, using bzr.indraveni as url
[09:02] <indraveni> and now , i want to use loggerhead GUI to view the bazaar repo content
[09:04] <indraveni> mwhudson, i want to show to some people in team, if it works well then wider in internet
[09:04] <mwhudson> indraveni: ok
[09:05] <mwhudson> so if you start loggerhead and browse to localhost:8080, does it work?
[09:07] <indraveni> mwhudson, oops i forgot to start loggerhead
[09:08] <indraveni> mwhudson, and now statring loggerhead, is showing an error message
[09:09] <indraveni> mwhudson, this is the erorr when i am starting loggerhead http://pastebin.ca/747697
[09:11] <mwhudson> indraveni: you need to install turbogears
[09:11] <indraveni> mwhudson, is it must ?
[09:12] <mwhudson> indraveni: yes, for now
[09:12] <indraveni> mwhudson, ok, from source i need to install ?
[09:12] <Lo-lan-do> Hm.  Can I switch a lightweight checkout to another branch?
[09:12] <mwhudson> you don't have to install it system wide, i think
[09:12] <mwhudson> indraveni: what OS are you running on?
[09:12] <Lo-lan-do> I did bzr bind $otherbranch, but bzr info still tells me about the old one in "repository checkout root"
[09:12] <indraveni> mwhudson, debian
[09:13] <mwhudson> indraveni: apt-get install turbogears should work then
[09:13] <indraveni> mwhudson, there is not such file, there is only, python-turbogears
[09:13] <indraveni> shall i install that /
[09:13] <mwhudson> yes
[09:17] <Lo-lan-do> Erm.  bzr complains it can't acquire a lock, because it's held by the very same bzr process?
[09:28] <igc> night all
[09:32] <poolie> nigth
[09:32] <poolie> igc, thanks for the ssh bugfix
[09:35] <igc> poolie: np. I thinks it's pretty low risk so I'll merge it if you like once it's reviewed
[09:36] <lifeless> Lo-lan-do: on the smart server ?
[09:36] <poolie> i have some tweaks
[09:36] <igc> cool
[09:36] <Lo-lan-do> Nope, local branches stored in a shared repo on the same disk
[09:36] <Lo-lan-do> But I removed the branch and checked it out again, seems to be over.
[09:43] <Lo-lan-do> Ah, no, it happens again.
[09:49] <Lo-lan-do> Damn, this time it even survives an rm -rf + checkout :-(
[09:52] <lifeless> Lo-lan-do: do you know about bzr break-lock ?
[09:52]  * Lo-lan-do tries that
[09:52] <lifeless> Lo-lan-do: also, it is possible for the same process to mutual-exclude in bzr, so its likely the specific operation you are doing
[09:53] <Lo-lan-do> bzr break-lock gives me a backtrace ending in "RuntimeError: maximum recursion depth exceeded in cmp"
[09:53] <lifeless> grah?!
[09:54] <Lo-lan-do> And the specific operation I was attempting to perform was a "bzr pull" from another local branch
[09:54] <lifeless> that definately should not mutual exclude because the source is only readlocked
[09:54] <lifeless> the only way I know that thsi can be confused is if the tree you are in is a symlink/lightweight checkout of the source branch
[09:56] <Lo-lan-do> http://paste.debian.net/40520
[09:57] <lifeless> so its trying to lock /home/roland/debian/bzr-repo/gforge/
[09:57] <Lo-lan-do> "find -name lock | xargs ls" tells me there are two files called */lock/held in the repo, in .bzr/repository/lock and debian/sid/.bzr/branch/lock
[09:57] <lifeless> right
[09:57] <lifeless> 'bzr break-lock /home/roland/debian/bzr-repo/gforge/'
[09:57] <lifeless> should clear the locks
[09:58] <Lo-lan-do> If I ^C, the lock files disappear
[09:58] <lifeless> if it doesn't, please file a bug, because this is an important command (which is well tested, so I'm not seeing why ..)
[09:58] <lifeless> hmm
[09:59] <Lo-lan-do> break-lock doesn't do anything (since the files aren't there after a ^C)
[09:59] <fullermd> Didn't we just have one of those bugs reported?
[09:59] <lifeless> what is 'bzr info /home/roland/debian/bzr-repo/gforge/upstream-svn/trunk/' ?
[10:00] <Lo-lan-do> http://paste.debian.net/40521
[10:00] <fullermd> It's a lightweight co of a branch in the .../bzr-repo/gforge/ repo, ans the branch trying to be pulled from is also in that repo?
[10:00] <indraveni> mwhudson, now i getting this error while running loggerhead after installing turbogers
[10:00] <indraveni> mwhudson, http://pastebin.ca/747721
[10:01] <Lo-lan-do> fullermd: Yes
[10:01] <indraveni> mwhudson, I dont know anything about pythob
[10:01] <sabdfl> lifeless: hi, have some initial pack feedback for you!
[10:01] <lifeless> cool
[10:02] <indraveni> mwhudson, are u there ?
[10:02] <mwhudson> indraveni: one moment
[10:03] <indraveni> ok
[10:03] <Lo-lan-do> Hmm.  If I try to merge/commit instead of pulling, I get another error: http://paste.debian.net/40522
[10:04] <mwhudson> indraveni: apt-get python-sqlite should fix that i think
[10:04] <mwhudson> indraveni: but it's a bit bad of me, you don't need sqlite bindings unless you're using the caches
[10:05] <mwhudson> so it should work without them installed
[10:05]  * mwhudson files a bug
[10:05] <fullermd> Oh ho.  Circular binding.
[10:06] <fullermd> That could be the source of the initial trouble...
[10:08] <Lo-lan-do> Strangely, other branches stored in the same repo and whose parent is also upstream-svn/trunk do behave properly.
[10:08] <fullermd> Yes, but the problem is in that debian/sid branch.
[10:08] <Lo-lan-do> But whatever.  How can I fix that?
[10:08] <fullermd> Go into it and 'bzr unbind'
[10:09] <fullermd> Then pull and all should get back to working normally.
[10:09] <Lo-lan-do> Yay, it works :-)
[10:10] <Lo-lan-do> Now how do I prevent that from happening again?
[10:10] <fullermd> Don't make branches that are checkouts of themselves   ;)
[10:10] <Lo-lan-do> Erm, I generated that checkout with "bzr checkout --lightweight /home/roland/debian/bzr-repo/gforge/debian/sid/ gforge-sid"
[10:11] <fullermd> Nono, the problem wasn't the gforge-sid checkout.  It was the debian/sid branch, which considered itself a [heavyweight] checkout of the debian/sid branch.
[10:11] <Lo-lan-do> I see.
[10:12] <Lo-lan-do> Maybe I caused that when I was trying to switch a lightweight checkout from one branch to another.
[10:12] <Lo-lan-do> I did play a bit with bind and unbind at that time.
[10:12] <Lo-lan-do> (And didn't find a working process...)
[10:12] <fullermd> Well, it's all path based.  So if you made a heavy checkout of debian/sid somewhere, then just mv'd it over to debian/sid...
[10:13] <fullermd> But you could have pulled it off manually with bind too; probably the more likely case.
[10:14] <Lo-lan-do> Probably.
[10:14] <Lo-lan-do> Is there a proper way to switch a lightweight checkout across branches then?
[10:15] <lifeless> bzr switch
[10:15] <mwhudson> Lo-lan-do: bzrtools defines a 'switch' command
[10:15] <Lo-lan-do> Ah, I need to install bzrtools again then.
[10:15] <Lo-lan-do> Apparently a bzr.dev installed in ~ doesn't use the plugins installed system-wide :-/
[10:18] <fullermd> lifeless: How could I easily tell whether bzr was sucking in celementtree?
[10:18] <lifeless> fullermd: do you mean finding it ?
[10:19] <lifeless> fullermd: I think it goes in bzr.log
[10:20] <fullermd> Mmm.  Doesn't seem to...
[10:26] <bialix> packs have landed! w00t! I don't believe to my eyes
[10:27] <bialix> will try on win32 tonight!
[10:27] <bialix> lifeless: congrat!
[10:27] <lifeless> thanks bialix
[10:28] <bialix> :-)
[10:32] <indraveni> mwhudson, in loggerhead.conf, do we need to mention the branch path or the main central repo path ?
[10:35] <mwhudson> branch path
[10:36] <indraveni> mwhudson, now i am getting a message like, port not free
[10:36] <indraveni> when i am starting loggerhead
[10:36] <indraveni> where as i have only apache running in 8080 and no other
[10:36] <indraveni> which port dows loggerhead use ?
[10:39] <mwhudson> 8080 by default
[10:40] <indraveni> mwhudson, i have apache running in that port
[10:40] <indraveni> http://pastebin.ca/747741
[10:40] <indraveni> mwhudson, http://pastebin.ca/747741
[10:40] <mwhudson> well, change the port loggerhead runs on then
[10:40] <mwhudson> it can be done in the config file
[10:41] <indraveni> mwhudson, got it
[10:44] <indraveni> mwhudson, but the content is not propely displayed in the web browser
[10:45] <indraveni> mwhudson, i have some more content in the my_project folder which are created using bzr add, and commited, but those are not visible in this
[10:48] <mwhudson> indraveni: well, i'm not sure how i can help you with that
[10:48] <indraveni> mwhudson, ok i will try to reosolve this
[10:49] <indraveni> mwhudson, i think my branch and conf file need some thing to be done
[10:49] <mwhudson> if you have specific questions i can answer them, but i don't know what your directory layout is like
[10:59] <mDuff> lifeless: as a general rule, should I be assigning packs-related bugs I file to you?
[10:59] <lifeless> nDuff: no, but please tag them packs
[10:59] <lifeless> the ones I work on I'll assign to me, but its not a one-person effort, so assigning to me would be a net negative
[11:01] <mDuff> thank you -- I was previously unaware launchpad's tagging support.
[11:05] <lifeless> np
[11:23] <mDuff> Is there an existing syntax for having a single string specify both a repository URL and a revnum or revid?
[11:24] <fullermd> To what?
[11:25] <sandrot> so...what's the best way to distribute in a distributed model? =)
[11:25] <mDuff> fullermd: I'm looking to fully qualify the path to a specific revision of a piece of code -- both where to contact the server, and what to ask it for. I could just pass the URL and the revision specifier space-separated, but I'm wondering if there's another preexisting, recognized method.
[11:25] <fullermd> sandrot: Broadly.
[11:26] <sandrot> heh
[11:26] <fullermd> mDuff: For bzr?  No.  I'm sure there are URL templates for loggerhead or bzr-webserve...
[11:27] <sandrot> I'm working with a small team used to svn, in general I think a central server works pretty well for pushing and pulling updates, is that recommended?
[11:28] <fullermd> Well.  I would say that what's "recommended" is what works best for your situation.  You have a range from everybody working lockstep on a single branch, out to everybody working in individual branches merging full-mesh, and a lot of spots in between.
[11:29] <lifeless> mDuff: we have planned one but not implemented iot
[11:29] <lifeless> mDuff: url;revno=xxxx
[11:29] <lifeless> and url;revid=xxxx
[11:30] <sandrot> hmm
[11:31] <lifeless> sandrot: you can work just like you do in svn
[11:31] <lifeless> sandrot: and experiment as you grow familiar with the available tools and processes that bzr offers
[11:31] <fullermd> sandrot: Usually, the 'best' answer for a given case is somewhere in the middle.
[11:31] <sandrot> over http?
[11:31] <lifeless> bzr+http is a little tricksy; but you can pull and update over http
[11:32] <lifeless> bzr+ssh or sftp will work just fine
[11:32] <sandrot> yeah, I'd like the make the transition for my designer as easy as possible
[11:32] <lifeless> mDuff: I expect a fix for your deletes-during-commit bug tomorrow
[11:32] <fullermd> lifeless: Incidentally, did I read that bzr+ssh is going to be suffering relative to sftp for packs?
[11:32] <sandrot> currently I just bzr init locally and push it to my server...then branch and pull on my laptop
[11:32] <lifeless> fullermd: yes, right now it doesn't work :)
[11:32] <lifeless> night all
[11:33] <mDuff> lifeless: graci.
[11:33] <mDuff> ...and g'night.
[11:33] <fullermd> Ah.  Minor details...
[11:36] <sandrot> will bzr+ssh always prompt for password unless public key is on the server?
[11:37] <LeoNerd> It'll just do the same SSH login as any other ssh into the machine
[11:37] <sandrot> thanks
[11:38] <LeoNerd> (Given as.. er.. it is ssh.. and doesn't have any choice but to...)
[11:43] <sandrot> in the centralized workflow doc it states that commits happen both locally and remotely. how does bzr know that the working tree is in a centralized environment? is it because of the shared repo?
[11:44] <mDuff> sandrot: if you use "bzr checkout" instead of "bzr pull", that creates a bound branch, which has the behavior in question.
[11:44] <fullermd> No, because you're working in a dir created by 'checkout' rather than 'branch' (not _quite_ precisely right, but close enough)
[11:45] <sandrot> huh...
[11:45] <LeoNerd> 'checkout' == 'branch' + 'bind'
[11:45] <sandrot> neato!
[11:45] <LeoNerd> A 'bound' branch is simply one that atomically pushes every commit upstream, when committed locally
[11:45]  * fullermd drives an extra stake through the heart of 'bind', just to be sure.
[11:45] <sandrot> I've been using branch all along (Which is good for being able to commit whenever I want) and then pushing...
[11:46] <sandrot> but you're saying I could have substituted branch with checkout and been bound
[11:46] <LeoNerd> Ya.. or just 'bzr bind' it now
[11:46] <LeoNerd> Same effect
[11:46] <sandrot> you can unbind as well right
[11:46] <sandrot> so you could checkout, unbind for a bit, bind again
[11:46] <LeoNerd> Indeed
[11:46] <LeoNerd> You can also  'bzr commit --local ...' if you want to do a one-off local commit to a bound branch
[11:46] <LeoNerd> Then push it later.
[11:46] <LeoNerd> (e.g. useful for sometimes-offline laptops)
[11:46] <sandrot> interesting
[11:47] <sandrot> and if you're working with a simple bzr init (no shared repo), then every checkout has a full history of the commits?
[11:47] <sandrot> sorry, every branch
[11:47] <fullermd> Well, every branch has the full history whether you're using a shared repo or not.
[11:48] <fullermd> It's just that if they're in a shared repo, they...   well, share it, instead of individually storing the same info.
[11:48] <sandrot> so if branch1 and branch2 have similar info they share it in shared repo?
[11:49] <fullermd> Right.  Saves space (and I/O copying stuff around).
[11:52] <sandrot> Hmm, I currently don't have a layout...just trunk which I host on my server...but I could bzr init a project with a trunk/ branches/ tags/ layout which then would be appropriate for using a shared repo?
[11:52] <LeoNerd> Er...
[11:52] <LeoNerd> That's more of a SVN way of thinking..
[11:52] <LeoNerd> A 'tag' in bzr is just a friendly name for a revision.. it's not a separate filesystem entity
[11:53] <sandrot> hmm, thought that's how svn used them =)
[11:53] <LeoNerd> No
[11:53] <LeoNerd> In SVN everything is just a cheap referential copy
[11:53] <LeoNerd> Branches, tags, renames... don't exist
[11:53] <LeoNerd> They're just copies
[11:53] <fullermd> Let's not discuss how svn uses them.  I'm planning to eat soon...
[11:53] <sandrot> lol
[11:54] <LeoNerd> In bzr, a tag is just a friendly human name for a revision
[11:54] <LeoNerd> The same way that a hostname is just a friendly human name for an IP address
[11:54] <sandrot> everything is a branch =)
[11:54] <LeoNerd> A revision is just a point on a branch.
[11:54] <sandrot> ya
[11:54] <LeoNerd> A branch is just an ordered list of revisions
[11:55] <sandrot> so can I migrate a current branch into a shared repo?
[11:55] <mDuff> sandrot: yes.
[11:55] <mDuff> sandrot: just push it into the repository, and there it is.
[11:56] <sandrot> wouldn't my branch still be carrying around all it's repo data in branch/.bzr
[11:57] <fullermd> No, when you push/pull/branch/etc a branch into a repo, it stores the data in the shared repo, not a per-branch repo.
[11:57] <sandrot> very cool
[11:57] <sandrot> so turning my project into a "checkout commit" system is as simple as pushing my branch into a shared repo =)
[11:57] <fullermd> Of course, you could have a standalone branch that you 'mv' into a repo, and it will still store everything locally (since when it was created, it didn't know about any repos)
[11:58] <fullermd> There doesn't have to be a shared repo involved to checkout a branch.
[11:58] <mDuff> sandrot: you don't strictly need to do that; it's more of a space-efficiency thing.
[11:58] <LeoNerd> Umm... a "shared repo" only makes any use if you take multiple branches of something...
[11:58] <Lo-lan-do> LeoNerd: Um?  I thought a branch was also able to store diverged-then-merged revisions?
[11:58] <LeoNerd> Yes it is..
[11:58] <LeoNerd> But I mean, unless you actually _do_ that, a shared repo doesn't buy you anything in space savings
[11:59] <mDuff> sandrot: if you have multiple branches, a shared repository prevents duplicate storage -- but you can do checkouts and all that from a standalone tree.
[11:59] <Lo-lan-do> Then it's not quite an ordered list of revisions, is it?
[11:59] <LeoNerd> If you have 10 different separate branches with 10 revisions in each, you have 100 revisions in the repo.
[11:59] <sandrot> Okay, yeah, thanks, I understand that the shared repo is really just a nice extra
[12:00] <LeoNerd> Lo-lan-do: Yes... because it's only the merge point that matters... Two diverged branches are still just an ordered list.
[12:00] <LeoNerd> Lo-lan-do: When one is merged into the other, the target branch gets a special 'merged' revision, that contains sub-revisions of the changes that were merged
[12:01] <Lo-lan-do> Ah, I see.  I thought these sub-revisions were stored too, so you'd have a DAG with only a partial order.
[12:01] <Lo-lan-do> But if they're collapsed... then yes, it makes sense.
[12:01] <sandrot> On a filesystem level, where should I store my branches on my server. Currently they're in /home/me/Code/bzr but should I be worried about having multiple users reading in my home directory?
[12:02] <sandrot> fullermd: thanks for bringing up the standalone branch 'mv' thingie...that was a concern I had
[12:02] <LeoNerd> The subrevisions are stored as well, yes... they retain their individual identity in the stored data...
[12:02] <fullermd> Lo-lan-do: I think you're trying to read _WAY_ too much precision into an offhand statement   :p
[12:02] <LeoNerd> I keep mine in /var/bzr/$user
[12:03] <LeoNerd> (so I can point a webserver at them easily too)
[12:03] <Lo-lan-do> fullermd: Possibly, but since I thought I finally understand how pulling and merging work, I'd rather not have that understanding shattered.
[12:03] <sandrot> LeoNerd: so a user does an sftp://yourserver/var/bzr/$user ?
[12:04] <Lo-lan-do> It's currently shaken, not shattered, but I'll think about it some more.
[12:04] <indraveni> mwhudson, is there any default structure for the bazaar branch /
[12:04] <indraveni> ?
[12:05] <mwhudson> indraveni: i don't understand
[12:06] <fullermd> Lo-lan-do: Technically, a branch is just a set of revisions; the revs themself describe the ordering.  More technically, it's just a pointer to ONE revision, since each rev describes the whole set of revs leading up to itself.  But it's simpler to give a taste by saying 'a branch is a series of revisions'.
[12:06] <LeoNerd> Yes.. admittedly I hadn't considered merges when I made that statement
[12:06] <Lo-lan-do> So I wasn't mistaken, yay! *phew*
[12:07] <LeoNerd> I was just considering a simple linear branch
[12:07] <indraveni> mwhudson, i have my bazaar branch created ni the path
[12:07] <Lo-lan-do> One rev can have multiple parents, right?  Like in hg?
[12:07] <indraveni> /opt/bazaar_samples/my_project
[12:08]  * fullermd nods at Lo-lan-do.
[12:09]  * Lo-lan-do dances the joy-dance of understanding
[12:09] <indraveni> mwhudson, and my directory structure is like this
[12:09]  * fullermd quickly searches for some random tidbit to totally shatter Lo-lan-do's understanding.
[12:10] <Lo-lan-do> Don't you dare.
[12:10] <sandrot> so if my branch is not bound than bzr update tries updating with itself?
[12:10] <indraveni> mwhudson, my direcory structure and loggerhead.conf file is here http://pastebin.ca/747801
[12:10] <fullermd> Lo-lan-do: So, if we define each rev of the tree to be a quantum superposition, see...
[12:10] <indraveni> mwhudson, is my configuartion correct or not ?
[12:11] <LeoNerd> sandrot: Indeed.. otherwise it wouldn't know what to "update" from
[12:11] <fullermd> sandrot: 'update' updates your working tree to be up to date with its branch.  It doesn't much matter whether that working tree is colocated with the branch in a standalone tree, or separate from teh branch as a checkout.
[12:11] <Lo-lan-do> fullermd: You define revs as you like.  I'll use the old analogy, as long as it keeps working for me :-)
[12:12] <mwhudson> indraveni: the folder= line should give the path to a bazaar branch
[12:12] <mwhudson> it looks like you've given the path to a folder containing folders which contain bazaar branches
[12:13] <mwhudson> indraveni: ls -lAR would be better, perhaps
[12:14] <indraveni> mwhudson, http://pastebin.ca/747804
[12:16] <indraveni> mwhudson, yes, so my bazaar branch is /opt/bazaar_samples/my_project, so what i wrote in conf is correct ?
[12:17] <mwhudson> indraveni: oh, yes then
[12:18] <mwhudson> indraveni: so, what is going wrong?
[12:20] <sandrot> thanks everyone, super helpful! Earlier I was going to setup a svn repo and export my bzr to svn to make things easy on my designer...not anymore!
[12:20] <sandrot> bzr is easy enough on it's own =)
[12:23] <indraveni> mwhudson, what abt the other fields?
[12:23] <AfC> Someone should grab that and use it as a quote on a website somewhere
[12:24] <indraveni> whe I typed, localhost:8090 in browser
[12:24] <mwhudson> indraveni: they're not very important, cosmetic stuff only
[12:24] <indraveni> it opened up a page which has a link to bzr.dev
[12:25] <indraveni> and when i clicked that, it shows a page
[12:25] <indraveni> The path '/branches/bazaar/bzr_dev' was not found.
[12:25] <mwhudson> oh, one moment
[12:25] <mwhudson> indraveni: server.webpath = 'http://localhost:8220/branches' <- this seems wrong
[12:26] <mwhudson> this should be the path you type into your web browser
[12:26] <mwhudson> so probably localhost:8090 in your case
[12:26] <indraveni> mwhudson, sorry ,, i am accessing with localhost:8220
[12:26] <indraveni> so thats right
[12:27] <mwhudson> i still think you want to remove the "/branches"
[12:28] <indraveni> mwhudson, got it
[12:29] <indraveni> mwhudson, now it worked
[12:29] <mwhudson> indraveni: hooray
[12:30] <indraveni> mwhudson,thankyou
[12:30] <indraveni> mwhudson, is it like, only one branch can be pointed for one loggerhead ?
[12:30] <mwhudson> indraveni: no
[12:31] <indraveni> mwhudson, in the first page its showing like, bzr.dev on clikcing which shows me the summary of prev revisions
[12:32] <mwhudson> indraveni: you can have any number of top level sections (e.g. "[bazaar]") and inside each of these any number of branches (e.g. "[[bzr.dev]]")
[12:33] <indraveni> mwhudson, but here in my case, in the inital page itself ts  showing bzr.dev
[12:33] <indraveni> where as my bazaar branch name is my_project
[12:34] <mwhudson> indraveni: that's because it's inside a section called [[bzr.dev]]
[12:34] <mwhudson> change that to [[my_project]] or something
[12:34] <indraveni> mwhudson, tell me one thinf
[12:35] <indraveni> whats the difference between [xxx] and [[xxx]]
[12:36] <mwhudson> [project]
[12:36] <mwhudson> [[branch]]
[12:36] <mwhudson> as i said above
[12:55] <lifeless> jelmer: ping
[12:56] <jelmer> lifeless, pong
[12:56] <lifeless> packs are in bzr.dev
[12:56] <jelmer> lifeless: nice, thanks for let me know
[12:56] <lifeless> theres an additional commit performance patch in my repository branch
[12:57] <jelmer> ok - the one just discussed on the list?
[12:57] <lifeless> yes, the 'native dirstate update basis ...'
[12:59] <lifeless> jelmer: UDS and all hands are coming up
[12:59] <lifeless> jelmer: but if there is *anything* I can do to help the samba guys make the right choice :)
[12:59] <lifeless> I'd be delighted to e.g. meet up with samba folk in boston
[12:59] <jelmer> lifeless: Jerry, the driving force behind the git adoption, will be at UDS I think
[13:00] <lifeless> Jerry who?
[13:00] <jelmer> Gerald Carter
[13:00] <lifeless> perhaps you could mail him and poolie and I
[13:01] <lifeless> or even a general note to the samba list, I don't know - do what you think will have the best effect
[13:05] <jelmer> I'll bring it in in the internal discussions about git
[13:05] <jelmer> but I'll keep you informed
[13:05] <jelmer> when's UDS exactly?
[13:06] <lifeless> wiki.ubuntu.com has all the details
[13:06] <lifeless> basically though I'm in boston from friday till the 10th
[13:10] <lifeless> ok later
[13:10] <lifeless> mDuff: I think there is quite a simple fix for your performance bug; we currently maintain a set of deleted paths.
[13:10] <jelmer> lifeless: ok
[13:11] <lifeless> mDuff: but if we change this to a list, and trim paths from it when we move past them in the loop
[13:11] <lifeless> mDuff: then the list won't get 1000's of entries long, and in fact will in principle only ever be a single item long.
[13:16] <indraveni> mwhudson, if i am forgetting to stop loggerhead and again trying to start the loggerhead
[13:16] <indraveni> mwhudson, its syaing port not free
[13:16] <indraveni> and when i am seeing the processes, i dont find any loggerhead prcess running
[13:17] <indraveni> i am not able to kill the processs
[13:17] <indraveni> instead i am changing the port to anyother, which is  a bad practoce
[13:17] <indraveni> so, how can i kill the loggerhead processes ?
[13:17] <niemeyer> Would anyone know how to prevent the error bzr: warning: unsupported locale setting?
[13:19] <lifeless> ok damn that was easy
[13:19] <lifeless> niemeyer: set your locale correctly.
[13:19] <niemeyer> lifeless: You're brilliant
[13:19] <niemeyer> I wonder how I didn't think of that before
[13:19] <niemeyer> lifeless: Ok.. now, how do I do that?
[13:20] <lifeless> the LANG and LC_ variables IIRC
[13:20] <niemeyer> [niemeyer@burma ..ent/bound/trunk]% echo $LANG
[13:20] <niemeyer> en_US.UTF-8
[13:21] <niemeyer> They're all like that
[13:21] <lifeless> the probable cause is missing language resources then IIRC
[13:21] <lifeless> uhm
[13:21] <niemeyer> Which means ...
[13:21] <mwhudson> indraveni: ./stop-loggerhead.py should kill the process
[13:22] <indraveni> mwhudson, its not killing
[13:22] <indraveni> mwhudson, i am forcely killing the processes,
[13:22] <indraveni> mwhudson, now it worked fine
[13:22] <lifeless> niemeyer: is this in the DC ?
[13:22] <niemeyer> lifeless: No, locally
[13:22] <lifeless> hmm
[13:22] <mwhudson> the starting and stopping scripts are not amazingly robust
[13:22] <fullermd> niemeyer: The "right answer" probably varies by the particular system.  'locale -a' might list all the available options...
[13:23] <indraveni> mwhudson, i have two more doubts on this loggerhead, could u please bear with me for 10 more mins
[13:23] <lifeless> niemeyer: you might try locale-gen
[13:23] <niemeyer> [niemeyer@burma ..ent/bound/trunk]% locale -a | grep en_US
[13:23] <niemeyer> en_US.utf8
[13:23] <niemeyer> lifeless: Cool, will try it
[13:24] <fullermd> Well, there you go; it's just spelt a little differently than you have it.
[13:24] <niemeyer> Says "up-to-date", and still same problem
[13:24] <lifeless> niemeyer: basically in python terms we're trying to do 'str.encode('en_US.utf8')'
[13:24] <fullermd> I set $LANG in my shell .rc file...  you can probably override there.
[13:24] <lifeless> and python is throwing an error
[13:24] <fullermd> Oh, no.  You're trying to str.encode('en_US.UTF-8'); that's why the error.
[13:24] <niemeyer> >>> print "áéíóú".decode("UTF-8").encode("UTF-8")
[13:24] <niemeyer> áéíóú
[13:25] <indraveni> mwhudson, what is the difference b/w [xxx] and [[xxx]]
[13:25] <fullermd> niemeyer: Your system supports "en_US.utf8", and you're trying to tell it you're using "en_US.UTF-8", so it's flibbering all over itself.
[13:25] <mwhudson> indraveni: i've explained that twice
[13:25] <lifeless> niemeyer: thats UTF-8
[13:25] <lifeless> niemeyer: you have en_US.UTF-8
[13:25] <lifeless> niemeyer: which is different
[13:26] <lifeless> try
[13:26] <luks> en_US is not an encoding :)
[13:26] <niemeyer> fullermd: I don't think there is a difference..
[13:26] <niemeyer> fullermd: "UTF-8" and "utf8" should work the same way
[13:26] <niemeyer> fullermd: And I get the error both ways
[13:26] <lifeless> niemeyer:
[13:26] <lifeless> >>>
[13:26] <fullermd> Not if your system only has a locale def for "en_US.utf8" and you're trying to point it at "en_US.UTF-8".
[13:26] <lifeless> import locale
[13:26] <niemeyer> lifeless: en_US shouldn't be used in a Python decode/encode statement
[13:26] <luks> niemeyer, but python is probably missing the en_US.utf8 -> en_US.UTF-8 alias
[13:26] <lifeless> locale.getpreferredencoding()
[13:26] <indraveni> mwhudson, is it, sorry, i dint check, will check now
[13:27] <fullermd> You get the error with your LANG set to the proper value?
[13:27] <niemeyer> [niemeyer@burma ..ent/bound/trunk]% python -c 'import locale; print locale.getpreferredencoding()'
[13:27] <niemeyer> UTF-8
[13:27] <niemeyer> fullermd: My lang *is* set to the proper value, as far as I know
[13:27] <luks> LANG=en_US.utf8 bzr something
[13:27] <fullermd> If locale -a doesn't list the setting your have for LANG, it's not the proper one.
[13:27] <lifeless> on a machine that has the glitch for me, I get:
[13:27] <niemeyer> fullermd: It's an alias..
[13:28] <niemeyer> luks: Yes, fails the same way
[13:28] <lifeless>  $ python -c 'import locale;locale.getpreferredencoding()'
[13:28] <lifeless> Traceback (most recent call last):
[13:28] <lifeless>   File "<string>", line 1, in ?
[13:28] <lifeless>   File "/usr/lib/python2.4/locale.py", line 417, in getpreferredencoding
[13:28] <lifeless>     setlocale(LC_CTYPE, "")
[13:28] <lifeless>   File "/usr/lib/python2.4/locale.py", line 381, in setlocale
[13:28] <lifeless>     return _setlocale(category, locale)
[13:28] <lifeless> locale.Error: unsupported locale setting
[13:29] <lifeless> niemeyer: what about
[13:29] <lifeless> python -c 'import bzrlib.osutils; bzrlib.osutils.get_user_encoding()'
[13:29] <luks> niemeyer, is en_US.UTF-8 also in LC_ALL?
[13:29] <niemeyer> lifeless: Shows nothing
[13:29] <luks> or LC_*
[13:29] <lifeless> niemeyer: then its not erroring
[13:30] <niemeyer> luks: It is, all of them
[13:30] <lifeless> do you have an alias for bzr or something ?
[13:30] <niemeyer> lifeless: Nope
[13:30] <niemeyer> lifeless: It's a bzr update command.. does it make a difference?
[13:30] <indraveni> mwhudson, got it, thankyou
[13:30] <lifeless> well, an alias could be overwriting an env variable
[13:31] <niemeyer> lifeless: Over bzr+ssh.. may I be getting errors from the remote side?
[13:31] <lifeless> niemeyer: oh yes, that is coming from the remote side
[13:31] <lifeless> niemeyer: which I bet is the DC
[13:31] <niemeyer> lifeless: It's from chinstrap, yes
[13:31] <niemeyer> That's.. hmm.. weird :(
[13:31] <lifeless> niemeyer: /win 52
[13:32] <niemeyer> lifeless: Hm!?
[13:32] <lifeless> mistype
[13:33] <niemeyer> Getting a locale error due to a setting from the remote repository is super strange
[13:33] <lifeless> stderr is displayed locally by openssh
[13:34] <niemeyer> lifeless: Right.. I'm speaking from a user perspective
[13:34] <lifeless> right
[13:34] <lifeless> and I agree
[13:35] <lifeless> but it seems undesirable to hide it
[13:35] <niemeyer> I definitely desire it :)
[13:35] <niemeyer> Or at least change the wording of what's shown in these cases
[13:35] <fullermd> It would be nice to have some sort of indicator that "Hey, this is from the other side, silly!"
[13:35] <lifeless> you could file an RT ticket :)
[13:36] <lifeless> fullermd: indeed; that means intercepting stderr and selecting() rather than just reading etc etc.
[13:36] <fullermd> Well, we could just make nothing ever go wrong, if that's easier  ;)
[13:38] <niemeyer> Ok.. thanks for the help guys
[14:44] <Lo-lan-do> Is there a way to remove a branch from a shared repo?
[14:44] <fullermd> rm -rf, generally.
[14:44] <LeoNerd> You can rm it, but that'll not remove the individual revisions from the store
[14:44] <LeoNerd> This won't matter, except in disk space
[14:44] <Lo-lan-do> Exactly :-)
[14:46] <Lo-lan-do> So... no garbage collector to clean the unused versions?
[14:47] <LeoNerd> Not that I know of currently.. You can 'push' each branch to a new shared repo, then 'mv' swap them though
[14:47] <fullermd> I think lifeless hacked up something once upon a time that did some GC'ing.
[14:47] <LeoNerd> 'bzr vacuum' or something like that?
[14:47] <fullermd> But there's no standard, supported thing to do it, no.
[14:50] <Lo-lan-do> http://doc.bazaar-vcs.org/latest/developers/repository.html does mention GC, but rather vaguely
[14:52] <Lo-lan-do> lifeless: ^^^ anything you feel I should know? :-)
[15:00] <jelmer> we discussed a garbage collect command at the sprint this summer
[15:00] <jelmer> but afaik nothing like that has been implemented yet
[15:05] <Lo-lan-do> Okay.  I'll keep my temporary branches out of my shared repository then.
[15:07] <fullermd> Sounds like more trouble than it's worth, unless you start checking in ISO's or something.
[15:09] <Lo-lan-do> Dead files eating space on my disk make me uncomfortable.  And since it's actually simpler to start a local branch than put it in a repo than get a lightweight checkout of it, I see it as a net positive.
[15:10] <Lo-lan-do> Less trouble, *and* less discomfort.
[15:11]  * fullermd shrugs.
[15:11] <fullermd> I've got dead revs all over the place, from abandoned branches, or uncommit's.  I'm not gonna worry very much about a few hundred k of wasted space...
[15:12] <fullermd> I probably burn more space holding backup copies of scripts I wrote for use on systems that haven't existed in 10 years.
[15:15] <Lo-lan-do> Well, as you like, but I don't like institutionalised cruft.  It's like a memory leak, except permanent.
[15:36] <Lo-lan-do> Am I running into problems if I have a working tree that's both a lightweight checkout of a branch stored in a shared repo *and* a checkout of an SVN branch?
[15:37] <Lo-lan-do> I guess only the branch (in the repo) is bound to SVN, and the working tree is just something that happens to be a checkout of that branch, but I'd like a confirmation from the masterz :-)
[15:45] <Lo-lan-do> (If I'm not going to run into problems, then that's probably the setup I'm likely to use)
[15:45] <jelmer> I see no reason why that shouldn't work, if I understand the setup correctly
[15:47] <Lo-lan-do> Great
[15:48] <Lo-lan-do> You'll probably hear about it if it doesn't :-)
[15:49] <Lo-lan-do> Quite soon, even: I've just received a patch form the BTS, which I'm going to try and merge right now.
[15:57] <Lo-lan-do> Yay, it  seems to be working!
[15:58] <Lo-lan-do> I committed a patch in sid (pure bzr, light checkout), then pulled it into trunk (the one which is a light checkout of the branch bound to SVN).
[15:58] <Lo-lan-do> No error, and svn update in an svn checkout includes the patch.
[15:59] <Lo-lan-do> Yay yay yay :-)
[16:00] <Lo-lan-do> Hm.  Would it be possible to do without the SVN properties, or to keep them short?  The commit emails we get include the properties, and they're getting crowded...
[16:29] <Enquest> how do I put a directory on an ignore list?
[16:29] <Enquest> I want a certain directory not to be loaded.
[16:29] <Enquest> update
[16:30] <dato> Enquest: can you give an example of what you want?
[16:31] <Enquest> something lik bzr ignore www/uploads/
[16:31] <Enquest> how do I do this?
[16:31] <dato> other way than `bzr ignore www/uploads` ?
[16:33] <Enquest> when I type bzr add ... It starts to add all files. I don't want a directory included
[16:34] <dato> Enquest: is "www" at the same level as ".bzr" ?
[16:34] <dato> if it isn't, `bzr ignore www/uploads` will not work
[16:35] <Enquest> www is deeper
[16:35] <Enquest> dev/.bzr
[16:35] <Enquest> dev/www/upload
[16:36] <fullermd> Actually, I think ignore canonicalizes the path as necessary.  Not sure (I always just hand-edit .bzrignore)
[18:06] <jam-laptop> fullermd: it does not (yet), I thought there was a bug asking for this sort of thing, though.
[18:06] <jam-laptop> I think part of it is that you probably don't want to canonicalize: bzr ignore "*.foo"
[18:55] <mdke> lifeless: seeking your advice with something. Could you look at https://lists.ubuntu.com/archives/ubuntu-doc/2007-October/009758.html which sets out the naming scheme intended to be used for our project's branches on Launchpad. The question is, should we include all the svn revision history (now imported into bzr) in each branch, or just start new branches afresh, maybe keeping revision history from svn around in one of the branches to use if we need it. Uploa
[18:55]  * mdke hopes his irc client doesn't cut the end of long lines, the last word there should be "solution"
[18:56] <mwhudson> mdke: nope
[18:56] <mwhudson> "we need it. Uplo" was as far as we got
[18:57] <mwhudson> mdke: i should apologise for not replying to your emails, btw
[18:57] <jam-laptop> mdke: How much history are you talking about?
[18:57] <jam-laptop> (how many files, how many revisions, etc)
[18:57] <jam-laptop> I generally would keep history unless there is a real reason not to
[18:57] <jam-laptop> Oh, and lifeless is usually not for another couple of hours
[18:58] <jam-laptop> (.au time, I've seen him on in an hour, but that is about 5am his time)
[18:59] <mdke> mwhudson: that's ok.
[19:00] <mdke> jam-laptop: i think it's 3500 revisions
[19:00] <mdke> mwhudson: I wasn't expecting an instant response :)
[19:00] <jam-laptop> mdke: doesn't seem like too many, Bazaar has 14,519
[19:00] <mwhudson> mdke: i'll try to have a sensible reply by the morning
[19:00] <mdke> jam-laptop: well, uploading the first branch took about 3-4 hours this morning, and there will be something like 15 branches...
[19:00] <jam-laptop> Though at the moment we scale a little bit better with num revisions than we do with num files
[19:01] <jam-laptop> mdke: uploading from where? And were you using "sftp://bazaar.launchpad..." or "bzr+ssh://bazaar.launchpad"
[19:01] <jam-laptop> The latter has much better latency characteristics
[19:01] <mdke> jam-laptop: from my home. The latter
[19:01] <jam-laptop> (sftp:// requires 3 round trips, etc)
[19:01] <jam-laptop> mdke: well, if you want, I can "pre-seed" some branches for you
[19:02] <jam-laptop> If you have one uploaded, I can push it into neighboring ones
[19:02] <jam-laptop> from a much closer location
[19:02] <jam-laptop> And then your future pushes of the other branches should be fairly fast
[19:02] <fullermd> Yeah, I wish LP let you do that, if not actually support repos...
[19:02] <mdke> jam-laptop: that sounds really helpful. I'm still a bit concerned about the amount of downloading people would have to do to get multiple branches though.
[19:02] <jam-laptop> fullermd: there is quite a bit of discussion of server side branching, shallow branches, and what we might do for shared repos
[19:03] <mdke> Still, that may be solved by advising people not to download revision history
[19:03] <jam-laptop> mdke: If they have a shared repository (recommended) it won't copy everything
[19:03] <jam-laptop> Just the first time
[19:03] <jam-laptop> but not 1x per branch
[19:04] <mdke> jam-laptop: I understood that LP didn't support that. We're planning to use LP as a central server with a relatively centralised workflow
[19:04] <jam-laptop> mdke: LP doesn't have shared repositories on *its* side. It has nothing to do with letting you use them on your own machine
[19:05] <jam-laptop> (So you can't tell LP to share the repository between ~user/project/branch1 and ~user/project/branch2, but on your local machine you can.)
[19:05] <mdke> right... and that wouldn't affect a "bound branches" workflow?
[19:05] <jam-laptop> mdke: correct
[19:05] <mdke> very interesting
[19:05] <jam-laptop> "shared repositories" is just an optimization for how data is stored
[19:05] <jam-laptop> it doesn't change much else
[19:05] <mdke> right, I'll have to explore that definitely and look into the docs
[19:06] <jam-laptop> mdke: you might read http://bazaar-vcs.org/Tutorials/CentralizedWorkflow
[19:06] <jam-laptop> or even
[19:06] <mdke> will do
[19:06] <jam-laptop> http://bazaar-vcs.org/Workflows
[19:06] <mdke> jam-laptop: as for your kind offer to do the pushing, I'm very interested. I'll have to explain a bit more the structure
[19:07] <jam-laptop> mdke: can you give me the URL so I can start downloading?
[19:07] <jam-laptop> (Oh, and if you have troubles, you can always ask questions in IRC)
[19:08] <mdke> jam-laptop: https://code.launchpad.net/~ubuntu-core-doc/ubuntu-doc/ubuntu-hardy
[19:08] <mdke> jam-laptop: so the plan is to make xubuntu-hardy, kubuntu-hardy and edubuntu-hardy from that, and then make some amendments to those.
[19:09] <jam-laptop> I *think* I can register them under my name, and then assign rights to them to the ubuntu-core-doc group
[19:09] <jam-laptop> If not, can I get added to the ubuntu-core-doc group?
[19:10] <mdke> sure
[19:10] <mdke> jam-laptop: then we hope to do the same thing with each of the branches from the svn repository, ubuntu-gutsy, kubuntu-gutsy and so forth (I haven't pushed an equivalent
[19:10] <mdke> ... branch for those to Launchpad yet, but they share the revision history of the existing branch up there, as I understand it
[19:10] <jam-laptop> Well, it took 1m36s to download the 210MB from a very nearby server
[19:10] <Lo-lan-do> Do you guys keep every Ubuntu package under bzr?
[19:11] <jam-laptop> Lo-lan-do: not yet
[19:11] <jam-laptop> I believe things are being migrated over
[19:11] <jam-laptop> but it certainly isn't 100% of all packages
[19:11] <mdke> that's my understanding too
[19:11] <Lo-lan-do> Okay.
[19:11] <mdke> jam-laptop: added to ubuntu-core-doc
[19:11] <jam-laptop> mdke: (jameinel, right?)
[19:11] <mdke> :)
[19:12] <Lo-lan-do> (I'm manually keeping a bazaar branch for my package, and I was wondering whether I was duplicating work)
[19:12] <jam-laptop> so you want an ubuntu, xubuntu, kubuntu, and edubuntu for all of -hardy, -gutsy,
[19:12] <jam-laptop> mdke: what are the specific permutations, so I'll get them all
[19:12] <mdke> Lo-lan-do: see https://wiki.ubuntu.com/BzrMaintainerHowto
[19:12] <jam-laptop> (my basic plan is just to write a simple bash for loop, and do some pushing)
[19:13] <Lo-lan-do> mdke: Oh, but I am already keeping my package in bzr, it's the Ubuntu ones I track (in bazaar) by hand.
[19:14] <mdke> jam-laptop: the thing is, the ubuntu-hardy branch comes from the svn trunk. The plan is to add branches for each svn branch (so not the same material). As I understand it, they will all have the same revision history
[19:14] <jam-laptop> mdke: if they were branched around in svn they will likely share some history
[19:14] <jam-laptop> (probably not 100%)
[19:15] <jam-laptop> So am I right with (ubuntu, xubuntu, kubuntu, edubuntu) and (hardy, gutsy, feisty, edgy, dapper) ?
[19:15] <mdke> jam-laptop: ah, so the bzr history will be different?
[19:15] <mdke> I used svn-import to import the whole repository
[19:15] <jelmer> mdke: That means you'll have a shared repository already, locally
[19:15] <mdke> exactly
[19:15] <jam-laptop> Just that I would expect ubuntu-gutsy to have fewer revisions than ubuntu-hardy
[19:16] <mdke> I have to leave you for a bit, sorry to be rude
[19:16] <jam-laptop> and maybe a couple extra that -hardy doesn't have
[19:16] <jam-laptop> (well, assuming they aren't 100% the same code base, they can't have 100% the same revisions :)
[19:16] <jam-laptop> mdke: np
[19:19] <jam-laptop> Lo-lan-do: is your "official" source in Bazaar, or is it svn/cvs?
[19:19] <Lo-lan-do> jam-laptop: Upstream is in CVS, but I work on the packaging in bzr
[19:20] <jam-laptop> Lo-lan-do: k, you may want to register your project with vcs-import, and Launchpad will maintain a conversion from cvs => Bazaar for you (for at least the 'trunk' branch.)
[19:20] <jam-laptop> Though if you just register your project
[19:20] <jam-laptop> and push up your Bazaar branch as trunk
[19:20] <jam-laptop> you can use that too
[19:21] <Lo-lan-do> Uh, sorry, s/CVS/SVN/
[19:22] <Lo-lan-do> But I'm just asking, don't mind me.
[19:23] <Lo-lan-do> I'm quite satisfied with my branches so far, I was wondering if you had a branch for the package (so I could keep a copy and/or merge from it) or not.
[19:30] <jam-laptop> Lo-lan-do: what is the package ?
[19:31] <Lo-lan-do> gforge
[19:31] <jam-laptop> either way, if you read https://wiki.ubuntu.com/BzrMaintainerHowto it gives a pretty good description of how to integrate things with Launchpad
[19:32] <jam-laptop> Lo-lan-do: I don't see a 'gforge' project registered
[19:33] <Lo-lan-do> It's all right then.
[19:41] <jam-laptop> Lo-lan-do: so is gforge sort of like Trac?
[19:41] <Lo-lan-do> Broadly
[19:42] <Lo-lan-do> It's more like Sourceforge, actually, since it started as a fork of it
[19:45] <mdke> jam-laptop: ok, back. I've done a little explanation of what I have in my svn import (as a shared repository), and what I'd like to create on Launchpad, so that it's clearer. I think from what you said earlier that I actually have to upload one branch from here for each distribution, and you can't do all the work for me :)
[19:45] <mdke> http://paste.ubuntu-nl.org/41964/ <-- explanation
[19:46] <jam-laptop> mdke: what I *can* do is upload a fake branch for each one, which has all of the ubuntu-hardy revisions
[19:46] <jam-laptop> so that your future pushes only have to push the new/different data
[19:46] <jam-laptop> and not all of the common ones
[19:47] <mdke> but the ubuntu-hardy won't have the ubuntu-feisty revisions, is that right?
[19:47] <jam-laptop> mdke: it will have the ones that are in common
[19:47] <mdke> I'd previously assumed that bzr used the same revision history (from the shared repository) for them all
[19:47] <mdke> right
[19:47] <jam-laptop> when you make a commit in ubuntu-feisty that will not be in the ubuntu-hardy ancestry
[19:47] <jam-laptop> mdke: are the files on your home machine somewhere that I could access them?
[19:48] <mdke> I haven't made any commits since doing the svn-import
[19:48] <mdke> yes, I'd have to setup ssh though, give me a bit
[19:48] <jam-laptop> mdke: when you do "bzr push" from a shared repository, we don't push 100% of the revisions, only the ones in the ancestry of the branch you are pushing
[19:48] <mdke> jam-laptop: ok, it's cleverer than I thought, all clear
[19:48] <jam-laptop> So if you have a project with 10 revisions next to one with 10,000
[19:49] <jam-laptop> you don't push 10,010 revisions for just a 10 revision branch
[19:49] <mdke> would the "fake branch" solution be complicated by having revisions in ubuntu-hardy that aren't present in ubuntu-feisty? I.e. would me pushing the real ubuntu-feisty branch just result in those revisions being removed?
[19:50] <jam-laptop> mdke: they won't be removed, but they will stop being referenced
[19:50] <jam-laptop> so when someone downloads from the new ubuntu-feisty branch
[19:50] <mdke> is that acceptable?
[19:50] <jam-laptop> they won't get the superfluous ubuntu-hardy ones
[19:50] <jam-laptop> mdke: generally it is fine
[19:50] <mdke> i see
[19:50] <jam-laptop> I do it all the time here
[19:50] <mdke> I'll give you access and then I'm happy to be guided by you on that
[19:50] <mdke> lemme just tweak the router
[19:51] <jam-laptop> I personally use 1 shared repository for all of my Bazaar and plugin work
[19:51] <jam-laptop> (and a different one for other projects)
[19:52] <jam-laptop> mdke: so am I correct in saying you want a branch for all the permutations of (ubuntu, xubuntu, kubuntu, edubuntu) versus (hardy, gutsy, feisty, edgy, dapper) ?
[19:53] <mdke> jam-laptop: yes
[19:53] <jam-laptop> k
[19:53] <mdke> jam-laptop: although tell me if that doesn't make sense as a workflow too
[19:54] <jam-laptop> I'm not sure I understand why you want a separate branch for all of (ubuntu, xubuntu, kubuntu, ..)
[19:55] <mdke> they are separate packages and we want to store the debian directory for each in the same place in the directory structure. It will also allow us to remove unnecessary directories for each package
[20:10] <jam-laptop> So I'm a little concerned about disk storage consumption, since it is approx 200MB x 4 releases x 4 os's = 3.2GB on Launchpad
[20:11] <jam-laptop> (that is also one reason why LP is looking into how to have LP-side shared repositories.)
[20:11] <mdke> right
[20:11] <jam-laptop> Do you need the full set of permutations?
[20:11] <jam-laptop> Or would it be reasonable to just do 1 branch for edgy and dapper?
[20:12] <fullermd> So, are you saying we should get all those branches pushed up ASAP, in order to bump the priority of the LP-side repo feature?   ;)
[20:12] <mdke> jam-laptop: yes, we could do one branch for everything except hardy and see how it goes, maybe create more if we think it would be very helpful. Is storage spac a problem on Launchpad?
[20:13] <jam-laptop> I don't know that storage space is super critical
[20:13] <jam-laptop> but it is my understanding that if LP tried to host all of the LP branches on itself
[20:13] <jam-laptop> it would run out of disk pace
[20:13] <jam-laptop> space
[20:13] <jam-laptop> but LP is developed in a very distributed fashion
[20:13] <jam-laptop> so there are *lots* of branches
[20:13] <mdke> should I talk to someone about this?
[20:14] <mdke> mwhudson, for example?
[20:14] <jam-laptop> Well, we can summon him by name, but he may have gone home already
[20:14] <mdke> indeed
[20:14] <mdke> it was more of a general question
[20:15] <jam-laptop> yeah, but I think he might be someone who knows
[20:15] <jam-laptop> maybe spiv
[20:15] <dato> jam-laptop: (you mean storing all personal branches of people with commit access to launchpad itself? re the running out of space bit)
[20:16] <mdke> jam-laptop: an alternative would be to upload the derivative branches without revision history, i suppose
[20:16] <mdke> that might be preferable to not having derivative branches at all
[20:16] <mdke> although I suppose the disk space would gradually build up
[20:17] <jam-laptop> dato: right
[20:17] <jam-laptop> mdke: well, is the disk space usage because you have lots of history, or because you have a big tree?
[20:18] <jam-laptop> (If you have 100MB in a checkout, then the history cost is actually pretty small)
[20:18] <dato> jam-laptop: with trees, you mean? otherwise I'm having trouble grasping the idea.
[20:18] <mdke> if it's the latter, then we'll be pruning the derivative branches so they have much less overlap
[20:18] <jam-laptop> dato: LP stores an independent repository for each branch
[20:19] <mdke> a recent svn checkout of svn trunk is 39MB
[20:19] <jam-laptop> dato: and 1 lp repository is 400MB
[20:19] <dato> jam-laptop: ah, right
[20:19] <dato> jam-laptop: I must be still sleeping, since that piece of information was said right before :)
[20:19] <jam-laptop> dato: which is one of the reasons on the checklist for why to do some sort of shared repositories
[20:20] <jam-laptop> mdke: so I'm going ahead and making all of the -hardy ones
[20:20] <jam-laptop> And I have some stubs (with 10 revisions) for a bunch of them
[20:20] <mdke> what does that mean?
[20:21] <jam-laptop> https://code.launchpad.net/ubuntu-doc
[20:21] <jam-laptop> I created the permutations through feisty
[20:21] <jam-laptop> but only pushed 10 revisions
[20:21] <jam-laptop> now I'm going back and pushing the full history for *-hardy
[20:21] <jam-laptop> and then I'll push 1 for ubuntu-*
[20:22] <mdke> ah, the 10 revision thing is on purpose? it's not a problem?
[20:22] <mdke> phew
[20:22] <jam-laptop> mdke: right, I just wanted to get them started
[20:22] <mdke> hang on a sec
[20:22] <mdke> let's take this tree vs revision history thing further
[20:22] <mdke> a recent svn checkout of svn branches/gutsy is over 700MB...
[20:23] <mdke> so that would suggest the tree is very large
[20:23] <mdke> I don't know where all that is coming from
[20:24] <mdke> it may be that we can sort this out and have all the permutations, eliminate overlap in terms of tree size, and so cut down the disk space used
[20:24] <jam-laptop> well, SVN always creates 2 copies of your working tree
[20:25] <jam-laptop> (1 pristine copy is stored in the .svn/ directories)
[20:25] <mdke> I'm going to do an export to check
[20:25] <mdke> i.e. without the .svn directories
[20:26] <mdke> damn this slow computer
[20:32] <mdke> ok, gutsy is about 317MB in a clean export. That would be cut down to about 200MB in the kubuntu and ubuntu branches, and very small for edubuntu and xubuntu
[20:33] <mdke> jam-laptop: I don't mind what we do with dapper/edgy/feisty for now, let's just do what we can. I already have taken too much of your time
[20:33] <jam-laptop> Well, right now your total .bzr/repository is about 200 MB
[20:33] <jam-laptop> Also, I'm not sure that you can break it up quite that easily
[20:33] <jam-laptop> Just because in the past the branches had "X" which means that a conversion may preserve that
[20:34] <mdke> I don't follow that, can you give me an example?
[20:34] <jam-laptop> If I: bzr branch ...bzr.dev local; cd local; rm -rf lots of files; bzr commit -m "remove those files"
[20:35] <jam-laptop> when I 'bzr branch' this new branch with lots of removed files
[20:35] <jam-laptop> I still get the history for all the files which used to exist
[20:35] <jam-laptop> (since you can "bzr revert -r -10" and have it work)
[20:35] <mdke> true
[20:36] <mdke> so doing "bzr rm" will transfer the disk space from the tree to the history :)
[20:36] <jam-laptop> well, bzr rm won't remove it from history
[20:36] <jam-laptop> just the tree
[20:36] <jam-laptop> (it doesn't really "transfer" anything)
[20:36] <jam-laptop> So is the plan to reorganize all your branches?
[20:36] <mdke> what you're saying is that bzr rm directory won't save space, right?
[20:37] <jam-laptop> So that instead of having the "gutsy/ubuntu"
[20:37] <jam-laptop> you would end up with just "ubuntu-gutsy" ?
[20:37] <mdke> so if I go to the ubuntu-hardy branch and remove the "kubuntu" and "xubuntu" directories, then there won't be a space saving
[20:37] <jam-laptop> mdke: It only saves space in the Working Tree
[20:37] <mdke> ok, I'm following now
[20:37] <mdke> so we have a space problem still
[20:37] <jam-laptop> now this *might* be a reason to switch to a history-less conversion
[20:37] <jam-laptop> since you are doing some major restructuring
[20:38] <mdke> well, it's more of a split. The people working on kubuntu-hardy might want access to the revision history
[20:38] <jam-laptop> just fyi, your full conversion is 684MB
[20:39] <mdke> but I think the revision history is more of a luxury than a necessity, we can ditch it if it's important
[20:39] <jam-laptop> so there seems to  be a lot of stuff in branches/gutsy
[20:39] <jam-laptop> that isn't in trunk
[20:39] <mdke> correct, translations
[20:39] <mdke> these get added at the end of the release cycle for each branch
[20:39] <jam-laptop> to be clear, 470 MB of stuff :)
[20:39] <mdke> yes
[20:39] <jam-laptop> well, that may not be all in gutsy
[20:39] <jam-laptop> I suppose it could be the others as well
[20:40] <mdke> 319MB is a clean gutsy export
[20:40] <mdke> compare that with 16MB for trunk
[20:41] <jam-laptop> which should compress a bit, when it is stored in a repository
[20:41] <jam-laptop> but still, a rather large difference
[20:41] <mdke> in 6 months time, hardy gets the same bump up
[20:43] <jam-laptop> Any chance it will be approximately the same data as in gutsy?
[20:43] <mdke> jam-laptop: sure, a lot of it. Not exactly files though
[20:43] <jam-laptop> (I'm just guessing that you are creating new files, when they are closer to copies from the other branch)
[20:44] <mdke> the translations vary according to how much the original text varies from release to release
[20:44] <mdke> but broadly the majority of the text is likely to be present in both
[20:47] <mdke> jam-laptop: so, what's your recommendation? :)
[20:48] <jam-laptop> mdke: well, right now I'm going to batch upload your conversion to a machine that is closer to LP using a tarball
[20:49] <jam-laptop> Your 'ubuntu-hardy' branch isn't huge yet
[20:49] <jam-laptop> so I would get it cleaned up quickly
[20:49] <jam-laptop> (split into the actual sub-projects)
[20:49] <jam-laptop> so that when you go to add the big files
[20:49] <jam-laptop> you end up doing it in only the sub-projects
[20:49] <jam-laptop> Is there any development going on on the -gutsy/-feisty/etc branches?
[20:50] <lifeless> moin
[20:50] <jam-laptop> morning lifeless
[20:50] <mdke> I'll be updating translations, and possibly fixing any serious bugs if we find some
[20:50] <mdke> hi lifeless
[20:51] <mdke> jam-laptop: so yeah, we'll be touching the -gutsy/-feisty branches, but it wouldn't be the end of the world to just have a single permutation for them (since that is what we do in svn now)
[20:57] <jam-laptop> mdke: so I would probably go with that
[20:57] <jam-laptop> leave pre -hardy branches alone
[20:57] <jam-laptop> (having 1 branch for all versions)
[20:57] <jam-laptop> and then start the split at -hardy
[20:58] <jam-laptop> mdke: by the way, you weren't kidding P-III 600MHz
[20:58] <mdke> jam-laptop: alright
[20:58] <jam-laptop> (*my* server is a dual P-III *700*MHz)
[20:58] <mdke> jam-laptop: yeah, my laptop is broken, I had to dig this one out as an emergency measure
[21:00] <mdke> have to run Gnome on it and all
[21:14] <bialix> hi, have the question about dogfooding packs
[21:15] <jelmer> 'evening Alexander
[21:15] <bialix> hi Jelmer
[21:15] <bialix> I don't see any instructions about packs in bzr.dev
[21:16] <bialix> I know it's hidden
[21:16] <mDuff> bialix: --experimental on init or init-repo
[21:16] <bialix> aha
[21:16] <bialix> what's the fuzz about reconcile?
[21:16] <bialix> check don't suggest it for my non-bzr.dev repos
[21:18] <bialix> mDuff: branch into pack repo will do conversion w/o problem?
[21:18] <jelmer> bialix: yep
[21:19] <bialix> hmm, it seems that branch works blazingly fast
[21:19] <lifeless> bialix: cool
[21:19] <bialix> hi, our white mage
[21:20] <bialix> lifeless: have any suggestions what I should check on win32 (except running selftest)?
[21:20] <lifeless> let see, what things generally give headaches?
[21:20] <lifeless> bzr-svn stuff has long file ids
[21:20] <lifeless> if our minimum index read is too short that could fail
[21:20] <bialix> I don't use svn, can;t check
[21:21] <lifeless> what else
[21:21] <lifeless> is it better at being in deep directories/handling long paths/caps paths
[21:22] <bialix> will try
[21:23] <bialix> lifeless: may I ask you comment on this: https://lists.ubuntu.com/archives/bazaar/2007q4/033058.html
[21:25] <jelmer> lifeless: so far, packs work really well here. The only thing that I've hit so far is NoSuchFile exceptions when I was doing heavy writing to a repository /and/ reading from it
[21:25] <jelmer> but that was to be expected I guess, since it's moving files around
[21:25] <jelmer> to obsolete_packs
[21:30] <lifeless> jelmer: cool
[21:32] <bialix> lifeless: about deep directories/handling long paths/caps paths: I'm not sure what to test here, because knit file name is shorter that my very long file name for test (I create 127-symbol long filename, but in repository/knits there is 59 chars filename)
[21:32] <lifeless> bialix: reading it
[21:32] <lifeless> bialix: then it should be fine
[21:34] <bialix> lifeless: pack name is 37 chars long. so you win 59+3-37=25 chars
[21:36] <bialix> but for obsolete_packs directory this win is smaller by 10 chars
[21:36] <bialix> I don't see why packs should change situation for bzr itself. may be for bzr-svn... but I never used it, can't say anything
[21:37] <bialix> tomorrow I'm planning to run the whole test suite
[21:38] <lifeless> very cool
[21:40] <bialix> (it will take more than hour on my hardware, so I better do it on fast machine)
[21:40]  * mDuff hasn't found any new issues with packs since yesterday (other than some slightly different server-mode exceptions when running commands other than push).
[21:41] <lifeless> mDuff: I am working on that delete bug; we iterate directory-at-a-time so I need a little care (a simple string comparison isn't enough to trim the array of deleted items)
[21:43] <bialix> lifeless: my biggest performance problem with bz 0.91 and before is slow machine (CPU <1GHz). The slowest is first run (cold cache I think), and during branch  build phase takes a lot of time
[21:46] <jam-laptop> I had some work that improved text extraction time (for build_tree)
[21:46] <jam-laptop> It sort of conflicts with what lifeless has been doing
[21:46] <jelmer> LarstiQ: Hi
[21:47] <jelmer> LarstiQ, can you still reproduce bug 128496?
[21:47] <ubotu> Launchpad bug 128496 in bzr-svn "Unable to open native working tree with non-ascii filenames" [Medium,Triaged] https://launchpad.net/bugs/128496
[21:47] <bialix> lifeless: I think we should say now not simply "packs", but: "packs!(TM)" :-)
[21:48] <lifeless> bialix: :)
[21:49] <lifeless> jam-laptop: I've largely finished with knits, the only remaining change I have planned there is to decouple 'parents' and 'compression components'
[21:50] <bialix> guys, I'd like to make new windows standalone installer (with packs) for earlier adopters. any objections?
[21:50] <lifeless> jam-laptop: I'd *like* to make it arbitrary so we can do the sort of crazy stuff we sketched on the list
[21:50] <lifeless> bialix: I think that would be nice
[21:51] <bialix> ok
[21:51] <lifeless> jam-laptop: that will though impact fetching so we need some care that performance does not go out the window.
[21:56] <bialix> done
[21:57] <jam-laptop> lifeless: I was pretty close to getting the parents list into the data portion of packs
[21:58] <lifeless> jam-laptop: that and the noeol indicator would be good too
[21:58] <jam-laptop> The internal API changes aren't bad, but figuring out the implications to all the copying code will be a bit tricy.
[21:58] <jam-laptop> tricky
[21:58] <lifeless> I do think we should keep the cached index data
[21:58] <lifeless> about this
[21:58] <jam-laptop> sure, but make it redundant
[21:58] <jam-laptop> rather than precious
[21:58] <lifeless> right
[22:01] <bialix> packed repo is slightly bigger then knitted one
[22:02] <lifeless> thats unusual; we drop annotations and the indices are pretty close
[22:02] <lifeless> perhaps you have something in .bzr.backup, or already have .bzr/repository/obsolete-packs ?
[22:03] <bialix> well after initial branch from knits to pack I have 5038KB vs 5076KB for my own biggest repo
[22:04] <bialix> it's the size of .bzr/repository directory
[22:04] <lifeless> interesting
[22:04] <bialix> no, obsolete dir is empty
[22:05] <bialix> after initial branch I have only one pack with the size 4277KB
[22:05] <lifeless> hmm
[22:06] <bialix> and 818KB of indices
[22:06] <lifeless> oh, are you reporting apparent size or used disk size ?
[22:06] <lifeless> I did mos of my comparisons on used disk size, which includes wasted space in allocated block/clusters/inodes/whatever
[22:06] <lifeless> s/mos/most/
[22:06] <bialix> it's the size that I see in my FAR
[22:07] <bialix> usually it's real size
[22:07] <lifeless> right
[22:07] <lifeless> in which case yes I think this is a reasonable result
[22:07] <bialix> in my old knit repo size of directory .bzr/repository/knits is 3227KB
[22:08] <bialix> and inventor.knit 1250KB
[22:08] <bialix> if annotations should be dropped then packed repo should smaller?
[22:09] <bialix> should be smaller, typo
[22:09] <lifeless> so
[22:09] <lifeless> 3227 + 1250 + revision.knit + signature.knit ?
[22:10] <lifeless> 3227 + 1250 is 4470KB, which is larger than the .pack file :)
[22:10] <lifeless> add in revisions and it should be a bigger difference still
[22:12] <bialix> oh! just ran 'bzr check' in source branch and got: 1824 inconsistent parents
[22:12] <bialix> I need to run reconcile?
[22:12] <lifeless> if its not bzr.dev, it will probably run ok without reconcile
[22:13] <lifeless> if it is bzr.dev, you won't be able to branch from the pack version to another pack version.
[22:13] <bialix> no, it's my own repo
[22:13] <lifeless> I wouldn't worry about reconcile until andrew gets the additional fix done
[22:13] <lifeless> then push all your data to knits format, reconcile it there, and make a clean pack repo
[22:13] <bialix> but '1824 inconsistent parents' is scare me
[22:14] <lifeless> its likely that they are [A,B] vs [B,A] as at one point we didn't guarantee ordering.
[22:14] <lifeless> in bzr.dev we have worse
[22:15] <bialix> it scares me because I have 672 versioned entries and 942 revisions
[22:15] <lifeless> its per-file
[22:15] <bialix> ah
[22:19] <bialix> what's the simplest way to obtain real file size via python?
[22:19] <lifeless> os.lstat(path).st_size
[22:19] <lifeless> hmm, what module to put this in
[22:20] <lifeless> I'm writing a little object to handle deletes; it will be given every path, and given new deletes
[22:20] <lifeless> when a path is such that one of the deletes it's seen can not be a parent of any future path, it will drop it
[22:21] <jam-laptop> lifeless: did you see my possible alternate that used a dictionary?
[22:21] <jam-laptop> otherwise is_inside_any is an osutils function, IIRC
[22:21] <lifeless> jam-laptop: no. Just path split and walk a tre ?
[22:21] <jam-laptop> lifeless: basically
[22:22] <jam-laptop> most paths get rejected quite early
[22:22] <lifeless> have you tested this? is there a patch ?
[22:22] <jam-laptop> lifeless: no, it was just a suggestion
[22:22] <lifeless> so is_inside_any is osutils
[22:22] <bialix> lifeless: ok, so sum total of all knit files in old repo is 4601310
[22:23] <lifeless> I guess if I make a replacement is_inside_any osutils is the right place; I was thinking of a alongside-helper.
[22:23] <jam-laptop> lifeless: where where is it being used?
[22:23] <jam-laptop> In commit?
[22:23] <lifeless> yes
[22:23] <bialix> and pack has size 4379867
[22:23] <lifeless> bug 156491
[22:24] <lifeless> 100K commit, 8K deleted files, == 15 minutes to commit
[22:24] <bialix> pack smaller, but the whole repo slightly bigger
[22:24] <ubotu> Launchpad bug 156491 in bzr "commit with many deletes spends much time in is_inside_any" [Undecided,New] https://launchpad.net/bugs/156491
[22:26] <bialix> first error with packs: bzr: ERROR: Must end write groups before releasing write locks.
[22:26] <bialix> when I try to `bzr branch` second branch from knit to pack
[22:27] <bialix> if I clone treeless branch into shared-repo with trees enabled, it should work?
[22:29] <bialix> branch w/tree has the same error during clone
[22:29] <lifeless> it should; either something was using the write group api directly, or you had an exception occur somewhere that is missing a try:except:else:
[22:29] <lifeless> if you change that exception that is being raised to be a 'pass', you should see the real exception
[22:36] <bialix> sent to list
[22:39] <lifeless> bialix: right, you need to change the excpetion raise to a pass temporarily to debug
[22:39] <lifeless> bialix: it raises an exception because data loss can occur
[22:39] <bialix> where to change?
[22:40] <bialix> may be it's important detail: second branch is subset of first branch, i.e. all data is already cloned by first branch
[22:40] <lifeless> pack_repo.py 1538
[22:42] <bialix> PermissionDenied then
[22:43] <lifeless> right, thats the bug then :)
[22:43] <lifeless> could you please file a bug in lp, tagged packs, with the backtrace you got this time ?
[22:43] <bialix> ok
[22:45] <bialix> wait
[22:46] <bialix> this time it's error in raise error agin
[22:46] <lifeless> PermissionDenied sounds like a file system issue though?
[22:46] <lifeless> oh! I bet its the transaction cleanup. We have to close the file before removing.
[22:47] <lifeless> [22:47] <lifeless> --- bzrlib/repofmt/pack_repo.py 2007-10-24 05:17:39 +0000
[22:47] <lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-10-24 21:48:01 +0000
[22:47] <lifeless> @@ -274,6 +274,7 @@
[22:47] <lifeless>      def abort(self):
[22:47] <lifeless>          """Cancel creating this pack."""
[22:47] <lifeless>          self._state = 'aborted'
[22:48] <lifeless> +        self.write_stream.close()
[22:48] <lifeless>          # Remove the temporary pack file.
[22:48] <lifeless>          self.upload_transport.delete(self.random_name)
[22:48] <lifeless>          # The indices have no state on disk.
[22:48] <bialix> http://pastebin.com/m7ed4075c
[22:48] <bialix> lifeless: ^
[22:48] <lifeless> try that patch please
[22:49] <lifeless> if it fixes the problem, revert your other changes and just send it in :)
[22:49] <lifeless> (to pqm I mean - +1 from me and you should do it )
[22:50] <bialix> error 32 on windows it's: 32 The process cannot access the file because it is being used by another process.  ERROR_SHARING_VIOLATION
[22:51] <lifeless> bialix: yes, I think my patch will fix it
[22:52] <bialix> let me a couple of seconds
[22:53] <bialix> yeah, clone is successfull now
[22:53] <bialix> (when you linux guys teach yourself to close files explicitly?)
[22:54] <lifeless> hey now
[22:54] <lifeless> I used to be a core cygwin guy
[22:54] <lifeless> its taken me years to forget about files
[22:54] <bialix> :-D
[22:56] <bialix> so you want me to send this patch to PQM?
[22:58] <lifeless> that one liner yes please
[22:58] <lifeless> its trivially correct, and the test suite on windows will fail without it
[22:58] <bialix> ok, will do
[23:00] <bialix> anybody know is 'Linus Torvalds on Git' talk is available as text somewhere in the net?
[23:02] <dato> bialix: google "google video torvalds git"
[23:02] <bialix> I have video, I'd like to have plain text because I'm not very good in english
[23:03] <dato> bialix: aah, sorry. I missed the "as text" in your line, sorry.
[23:04] <bialix> it's nice talk, and I really like this guy, he talk very much about distributed system in generals, not about git tiny details
[23:05] <tchan> http://git.or.cz/gitwiki/LinusTalk200705Transcript
[23:05] <tchan> google search for "linus torvalds git transcript" and that URL pops up as the first response
[23:06] <bialix> tchan: wow, thank you, you save my day. I owe you beer
[23:07] <bialix> who this guy Andrew, who speaks first 10 secs?
[23:07] <tchan> the Google employee that arranged for Linus to give the lecture
[23:09] <bialix> thanks
[23:09] <tchan> perhaps its "Andrew Morton" also a kernel hacker god ?
[23:10] <bialix> "where is Linus, why hasn't he merged my tree -- he does not love me anymore". :-) probably
[23:14] <hendrixski> anybody have problems with pushing a bzr branch into an ftp server?
[23:14] <lifeless> hendrixski: probably your server does not support REST/APPE
[23:14] <hendrixski> I'm on version .15 (standard from ubuntu feisty because the one on the bazaar-vcs didn't want to work)
[23:15] <lifeless> hendrixski: you might try bzr.dev which has a new format you can use (currently labelled '--experimental') and this works much better on FTP
[23:15] <hendrixski> lifeless, oh... so just because I can ftp into it, doesn't mean I can push stuff on it?
[23:15] <lifeless> hendrixski: some FTP servers disable parts of the protocol
[23:15] <lifeless> hendrixski: for FTP, bzr 0.15 requires the REST/APPE commands to work
[23:16] <hendrixski> I C. and that's only fixed in the current dev branch?
[23:16] <lifeless> thats right
[23:16] <lifeless> new disk format that does not need the ability to append data to an existing file.
[23:16] <hendrixski> can I just FTP my folder with the bzr information using ftp and then can people can branch from that?
[23:16] <lifeless> sure
[23:16] <lifeless> that will work fine
[23:16] <lifeless> though you may get errors from your client
[23:17] <lifeless> for the same reason -
[23:17] <hendrixski> with a standard ftp send?
[23:18] <lifeless> yes, because bzr changes the content of files, and your client will need to know to delete the file at the remote end and upload the new one
[23:19] <hendrixski> ah.. you mean for when I over-write changes in the future
[23:19] <lifeless> yes
[23:19] <lifeless> nDuff: I think I have your fix.
[23:20] <hendrixski> I C
[23:20] <lifeless> nDuff: just profiling to make sure its not a regression in the common case
[23:27] <lifeless> nDuff: which it is somewhat
[23:44] <ddaa> jelmer: hello
[23:45] <ddaa> jelmer: I need your help as buddy for a bug in svn 1.4.4
[23:45] <lifeless> nDuff: ok, its fixed, pushing it in a second
[23:45] <ddaa> nDuff: hey nDuff
[23:45] <ddaa> (that was redundant...)
[23:46] <jelmer> ddaa: Hi
[23:46] <ddaa> jelmer: come to #svn?
[23:47] <ddaa> I exposed my problem there, but nobody seemed to care enough to reproduce it :/
[23:51] <lifeless> nDuff: its revno 2856 in the same branch you've been testing with
[23:51] <lifeless> nDuff: I'm popping out for a few minutes, its just reannotating into knit format at the moment.
[23:54] <pattern> are there any tools or docs that could help me migrate projects from RCS to bazaar?
[23:55] <ddaa> o.O RCS, as in /usr/bin/co ?
[23:55] <mlh> where's the best place to browse bzr source?  it's not obvious (to me) how to do it in launchpad
[23:56] <ddaa> mlh: https://code.edge.launchpad.net/~bzr/bzr/trunk
[23:56] <pattern> ddaa: yep :)
[23:56] <mlh> ah nevermind, found it
[23:56] <ddaa> then click on "Browse code"
[23:56] <mlh> "code" tab
[23:57] <pattern> i never bothered to learn cvs... so all my personal projects are in RCS
[23:57] <pattern> so now that i'm starting to get with the times, i'd like to migrate them to bazaar, if possible
[23:58] <ddaa> looks like you'll have to write your own conversion tool
[23:58] <ddaa> even Tailor does not appear to support RCS
[23:58] <pattern> **sigh**
[23:58] <mlh> pattern: you can convert from rcs with cvs2svn, then use bzr-svn
[23:58] <ddaa> maybe you can find something to convert RCS->CVS, then use Tailor?
[23:58] <pattern> well, can't say i'm surprised
[23:59] <pattern> ah yeah, that's a good idea, mlh
[23:59] <pattern> both of you :)
[23:59] <mlh> rcs is close enough to cvs that you can just put some (empty) cvs crap to convince tools that your rcs is actually cvs
[23:59] <mlh> there are howtos floating around somewhere