[00:16] <lifeless> jelmer: I wouldn't use chk_map unless you need updatable values
[00:16] <lifeless> jelmer: if you just need key:value and they are immutable use BTreeIndex
[00:17] <jelmer> lifeless: I need a big path -> tuple map that's different per revision but should have relatively small (line-based) differences between revisions
[00:17] <jelmer> lifeless: very much like an inventory
[00:17] <jelmer> s/line-based/path-based/
[00:17] <lifeless> ok for that you want chkmap
[00:18] <lifeless> you may want to look at chk inventories parent_id,basename->child_id map
[00:18] <lifeless> as a related use of chk_map
[00:18] <lifeless> we use two maps
[00:18] <jelmer> lifeless: What about the Pack container bits from bzr-search, where should i be looking?
[00:18] <lifeless> one for paths
[00:18] <lifeless> one for the data
[00:18] <lifeless> b.p.search.index
[00:19] <lifeless> basically to work with chkmap you need a VersionedFiles object that supports hash naming
[00:19] <lifeless> it might be possible to convince knits to do this
[00:19] <lifeless> I'm not sure it would be a good idea ;)
[00:19] <lifeless> so the layering is:
[00:19] <lifeless> chkmap->VF
[00:20] <lifeless> (KnitVersionedFiles|GroupCompressVersionedFiles)->(collection of btreeindex + pack files)
[00:20] <lifeless> and its that last bit that bzr-search has a smallish implementation of
[00:21] <jelmer> thanks
[00:21] <jelmer> this is all a bit new to me, VersionedFiles are still very much an abstract thing to me
[00:26] <lifeless> ok
[00:27] <lifeless> I think you should learn about the internals here
[00:27] <lifeless> its hampering bug fixing
[00:27] <lifeless> also our layers could be better
[00:27] <lifeless> got 20 minutes?
[00:29] <lifeless> jelmer: ^
[00:31] <jelmer> lifeless: if you can give a quick introduction that might help
[00:31] <lifeless> thats my plan
[00:31] <lifeless> so
[00:31] <lifeless> one sec
[00:36] <lifeless> jelmer: ok
[00:36] <lifeless> jelmer: so lets start with VersionedFiles
[00:37] <jelmer> lifeless: ok
[00:37] <jelmer> lifeless: fwiw I'm familiar with the API
[00:37] <jelmer> lifeless: just not how it works underneath
[00:38] <lifeless> sure
[00:38] <lifeless> so
[00:38] <lifeless> Weaves work by having a thunk class, not very interesting.
[00:39] <lifeless> more interesting is how Knits and Packs work for the KnitVersionedFiles clas
[00:39] <lifeless> bring up knit.py
[00:40] <lifeless> look for make_file_factory
[00:40] <jelmer> right, I think that's what I'm using right now for the file id map
[00:40] <thumper> hi people
[00:40] <lifeless> so this creates the two key objects KVF needs to work
[00:41] <poolie> hello all
[00:41] <lifeless> an index, which is responsible for locating bytes and storing the graph
[00:41] <thumper> is there documentation on using the merge sorted graph?
[00:41] <lifeless> and an access object, which is responsible for taking index descriptions of content and reading them back, or for writing and returning index descriptions
[00:41] <lifeless> hi thumper poolie no
[00:42] <jelmer> hi thumper, poolie
[00:42] <lifeless> jelmer: so _KndxIndex is the implemenetation of an index based on ,kndx files, and _KnitGraphIndex is the implementation of same building on the 'GraphIndex' interface
[00:43] <lifeless> likewise _KnitKeyAccess and _DirectPackAccess
[00:43]  * jelmer nods
[00:44] <lifeless> so, to use chk_map on .kndx and .knit files, we'd create a KVF much like make_file_factory does
[00:44] <lifeless> now if you look at KnitVersionedFiles itself
[00:44] <lifeless> this is the common logic that actually cares about knit deltas, their constraints and needs and so on
[00:45] <mwhudson> thumper: i can probably tell you more than you want to know :)
[00:45] <lifeless> so it knows about delta chains (we'd want 0), annotations (0 again)
[00:46] <lifeless> it also knows about fallbacks to other VF objects, which is much of how stacking works on the client
[00:46] <thumper> what is the easiest way to get the revision_id for any mainline (non-dotted) revno?
[00:46] <lifeless> branch.revno2revid
[00:47] <thumper> lifeless: no attribute called ...
[00:47] <lifeless> jelmer: ok, I'm not sure where to drill down into; we can look at how _DirectPackAccess and _KnitGraphIndex work
[00:47] <lifeless> thumper: its roughly that
[00:47] <lifeless> thumper: pydoc and / for the win
[00:47] <thumper> lifeless: there are revision_id_to_revno
[00:48] <lifeless> jelmer: or we can look at actually wiring up chk_map to .knit files for you
[00:48] <thumper> lifeless: but not the other way around
[00:48] <jelmer> lifeless: let's look at the latter first
[00:48] <thumper> mwhudson: where is your pydoc stuff for bzr?
[00:48] <jelmer> lifeless: actually working with this code should help
[00:48] <lifeless> dotted_revno_to_revision_id and get_rev_id and
[00:49] <lifeless> jelmer: ok
[00:49] <lifeless> so
[00:49] <lifeless> lets pop over to chkmap
[00:49] <lifeless> CHKMap wants a store, root_key and a search key func
[00:49] <lifeless> the search key func is for hashed keys
[00:49] <lifeless> we can ignore that for now
[00:50] <lifeless> root_key is something you need to store elsewhere
[00:50] <lifeless> its the 'id' of a given version of a dict stored in a chk_map
[00:50] <lifeless> so you'll need someplace to put that. perhaps another knit, or whatever.
[00:51] <lifeless> to bootstrap, when you first start, you use from_dict
[00:51] <lifeless> so -
[00:51] <lifeless> my_map = CHKMap.from_dict(store, {}) is the minimal call
[00:52] <lifeless> that will get a non-splitting map with single-element tuples as keys
[00:52] <lifeless> what you probably want is maximum_size=4096
[00:53] <lifeless> so to wire it up
[00:53] <lifeless> store = get_a_versioned_files()
[00:53] <lifeless> empty_map = CHKMap.from_dict(store, {}, maximum_size=4096)
[00:53]  * jelmer nods
[00:53] <lifeless> then you can stash stuff in it.
[00:54] <lifeless> you can individually map() and unmap()
[00:54] <lifeless> however its much better to use apply_delta
[00:54] <lifeless> because map and unmap write on each change
[00:54] <lifeless> apply_delta applies all the changes and then writes
[00:55] <lifeless> the get_a_versioned_files call should return a VF whose key width is 1
[00:55] <lifeless> and no graph
[00:55] <lifeless> so lets pop back to knit.py
[00:57] <lifeless> access = _KnitKeyAccess(transport, mapper); mapper=ConstantMapper('myknit'); index = _KndxIndex(transport, mapper, lambda:None, lambda:True, lambda:True)
[00:57] <lifeless> You want ConstantMapper because you want the same .knit and .kndx file for all keys
[00:58] <jelmer> ok
[00:58] <lifeless> the lambdas are for handling lock/unlock callbacks
[00:58] <lifeless> you should wire them up more carefully
[00:58] <thumper> kudos to the bzr developers for making an api even I find easy!
[00:59] <lifeless> before using with concurrent processes
[00:59] <lifeless> then its just
[00:59] <lifeless> store = KnitVersionedFiles(index, access, annotated=False, max_delta_chain=0)
[01:00] <jelmer> lifeless: ok, let me give that a try
[01:02] <jelmer> mwhudson: btw, I've "fixed" the bzr-git importing strange modes issue
[01:02] <mwhudson> thumper: http://starship.python.net/crew/mwh/bzrlibapi/
[01:02] <mwhudson> jelmer: cool
[01:02] <jelmer> mwhudson: it just means it won't be able to regenerate the sha map correctly if you remove it
[01:02] <jelmer> mwhudson: it'll also warn if it hits strange modes
[01:03] <jelmer> mwhudson: same thing for the XML-invalid characters that are escaped
[01:03] <mwhudson> jelmer: i'm not sure i understand
[01:03] <mwhudson> jelmer: remove what?
[01:03] <jelmer> mwhudson: git.[t]db
[01:04] <jelmer> mwhudson: which contains the information of which bzr revid/fileid maps to which git sha
[01:04] <mwhudson> jelmer: ok, but i still don't understand what that has to do with strange modes
[01:04] <jelmer> mwhudson: git works with shas everywhere
[01:04] <jelmer> mwhudson: so when we talk to it we need to tell it which shas we have
[01:05] <mwhudson> jelmer: currently, the git.db does not persist between runs
[01:05] <jelmer> mwhudson: we generate those shas from the bzr data we have by converting to git objects and shaing those
[01:05] <jelmer> mwhudson: if we can't regenerate the exact same git object we can't find a particular sha
[01:06] <mwhudson> jelmer: ahh
[01:06] <mwhudson> jelmer: so "persisting the sha data between runs" has become a bit more important?
[01:07] <jelmer> mwhudson: yeah, a bit. previously we would just flat out refuse to import anything with strange file modes, now we just warn
[01:07] <jelmer> mwhudson: we could store the file modes in revision properties at some point
[01:07] <jelmer> mwhudson: in which case we could regenerate the sha map correctly again
[01:08] <jelmer> mwhudson: s/file modes/unusual file modes/ (they're really rare)
[01:10] <mwhudson> jelmer: yes but the kernel is a pretty obvious target, i think we need to support that
[01:10] <mwhudson> (ultimately, not necessarily in the next release)
[01:10] <jelmer> mwhudson: sure
[01:11] <jelmer> mwhudson: Storing in revision properties should fix this, and keeping the sha map around works around the problem
[01:11] <jelmer> there's only 3 files in the kernel with unusual modes
[01:11] <lifeless> jelmer: so how did that work?
[01:15] <jelmer> lifeless: still working on it
[01:15] <lifeless> ok
[01:15] <lifeless> apply_delta is real simple
[01:16] <lifeless> I'm going to start working on these presentations
[01:16] <lifeless> gimme a shout anytime
[01:17] <lifeless> jam: wow bvg is very, uhm, brief
[01:20] <jelmer> lifeless: Hmm, CHKMap.from_dict() returns the new root key
[01:20] <jelmer> lifeless: so I just use CHKMap(store, root_key) to get it out again?
[01:21] <lifeless> yes
[01:21] <lifeless> apply_delta also returns a replacement key
[01:21] <lifeless> (from_dict is a shim around apply_delta)
[01:22] <jelmer> ok, that's working now
[01:22] <jelmer> lifeless: in the case of inventories, what do you use the key tuples for ?
[01:23] <jelmer> and is there any reason why I might want e.g. the individual directory names in the tuple instead of just a 1-tuple with a path?
[01:24] <lifeless> jelmer: size
[01:24] <lifeless> we store inventories as two dicts
[01:24] <lifeless> (parentid, child_name)->child_id
[01:24] <lifeless> (fileid,) -> serialized_entry
[01:25] <lifeless> the former gives us 'ls /foo/bar'
[01:25] <lifeless> the latter gives us tree.inventory['fooid']
[01:26] <lifeless> jelmer: what are you storing
[01:31] <jelmer> lifeless: I'm storing unicode_path -> (file_id, revision_id, created_foreign_revid)
[01:32] <lifeless> and on only ever lookup on path ?
[01:32] <jelmer> lifeless: no, lookup by file id is also possible
[01:32] <lifeless> s/on/you/
[01:32] <lifeless> ok
[01:32] <lifeless> so you'll need two maps
[01:33] <lifeless> if you want fast lookup on fileid
[01:33] <jelmer> lifeless: but lookup by file id is very rare ("bzr check" uses it)
[01:33] <lifeless> check is getting overhauled ;)
[01:33] <lifeless> this is for svn ?
[01:33] <jelmer> lifeless: You're overhauling bzr-svn's check too ? ;-)
[01:33] <lifeless> no, but the api calls bzr makes are being overhauled
[01:33] <jelmer> lifeless: yeah, bzr-svn does check too (it checks the consistency of the bzr metadata)
[01:34] <lifeless> so the access pattern is going to radically change
[01:34] <lifeless> alrighty, we cn ignore it at your risk:)
[01:34] <lifeless> so
[01:34] <lifeless> do you need to iterate paths ?
[01:35] <lifeless> or is it 'give me data for X'
[01:35] <lifeless> amd do you need to do case-insensitive matches
[01:37] <jelmer> I mostly need to just look at particular items
[01:37] <jelmer> by path
[01:37] <lifeless> so if you store every path you'll have a lot of duplicate data
[01:37] <lifeless> the trie will reduce some/much of o that
[01:38] <lifeless> but not all
[01:38] <jelmer> duplicate in the sense that duplicate revids are used?
[01:38] <lifeless> in particular leaf nodes have the full key of each item to allow finding the thing you asked for
[01:38] <lifeless> no duplicate in the sense that foo/bar and foo/gam both have foo/ in the key
[01:38] <jelmer> ah, right
[01:39] <lifeless> so you should zcat your knit and ahve a look, we had some optimisation plans and I don't recall exactly what items jam got to
[01:39] <lifeless> and what we deferred/didn't do.
[01:39] <lifeless> anyhow
[01:40] <jelmer> that's not worse than what we have now though
[01:41] <lifeless> you could hash the keys (via the key func), you could use two dicts (parent,child)->filed, fileed->(revid, foreignid)
[01:41] <lifeless> or you could say 'I'm happy as it stands'
[01:41] <lifeless> a more important thing though
[01:41] <lifeless> 'knits' load the full index always
[01:41] <lifeless> this sucks for doing little operations
[01:42] <lifeless> so when you hve this working we should look at backing it onto packs+btree indices
[01:43] <jelmer> ok
[01:47] <lifeless> man, I so want to code
[01:48] <jelmer> what's stopping you?
[01:48] <mwhudson> jelmer: thinking about it, i think relying on the sha map persisting is pretty smelly :)
[01:49] <jelmer> mwhudson: yes, it is. that's why we're warning
[01:49] <lifeless> jelmer: presentations to write
[01:49] <jelmer> lifeless: ah. uds?
[01:49] <lifeless> yes
[01:50] <lifeless> and bzr and git are hot topics
[01:50] <lifeless> likely ot have a hundred folk, I suspect
[02:24] <jelmer> lifeless: uhm, how do I get my data out of a CHKMap?
[02:24] <jelmer> other than iteritems()?
[02:24] <lifeless> any way you want ? :)
[02:24] <lifeless> iteritems
[02:24] <jelmer> ok
[02:24] <lifeless> and iter_changes
[02:25] <lifeless> iteritems(['path1'])
[02:25] <lifeless> is == __getitem__('path1'), if we had it
[02:25] <lifeless> we don't because its not cheap and the api should reflect the reality
[02:26] <jelmer> ValueError: Prefix has too many nulls versus width ?
[02:27] <lifeless> ('path1',)
[02:29] <jelmer> thanks
[02:33] <igc> morning (at last)
[02:36] <lifeless> igc: just :)
[02:36] <igc> lifeless: :-)
[02:36] <igc> hi
[02:36] <igc> thanks for the review
[02:36] <lifeless> no probs
[02:37] <lifeless> I think its not much work to do your approach at the right layer
[02:37] <lifeless> And I agree we can defer really deeply integrating it.
[02:37] <lifeless> I do think its important to have tests, and that they are really best written against the right layer.
[02:37] <igc> me too
[02:38] <lifeless> I hope I suggested a reasonable way to do that
[02:38] <igc> lifeless: I did
[02:38] <igc> lifeless: I would really like to leverage the specfiic files masking at the layer below
[02:38] <igc> while perhaps keeping the parent yielding ...
[02:39] <igc> and exclude masking a layer above
[02:39] <igc> lifeless: but I got a weird error from record_iter_changes when I tried
[02:39] <igc> is that fixed by parent yielding do you know?
[02:40] <lifeless> paste the error ?
[02:40] <lifeless> Git pull of dulwich: 2.43 MiB  in 0m53.437s
[02:40] <lifeless> Bzr pull of dulwich: 360KB in 0m36.602s
[02:40] <lifeless> woo
[02:40] <igc> lifeless: I'll need to change the code again and re-run. Will do later
[02:40] <lifeless> jml: I think jam and I have to rename our talk
[02:41] <lifeless> 'when bzr became faster than git'
[02:41] <jml> lifeless: that's a very nice result.
[02:41] <lifeless> igc: so, without seeing the error I can't do much more than guess
[02:42] <thumper> lifeless: are those numbers representitive of normal usage?
[02:42] <lifeless> thumper: 'bzr branch lp:~lifeless/dulwich/trunk-bbc
[02:42] <lifeless> thumper: vs 'git init; git pull git://gitorious.org/dulwich/mainline.git'
[02:42] <jml> lifeless: but were it me, I'd leave the talk with the same title and demonstrate its obsolescence with a big bar graph.
[02:42] <lifeless> thumper: so, I'd say yes
[02:43] <lifeless> jml: yes, I was jesting about the rename
[02:43] <lifeless> the title is nice and contentious
[02:43] <jml> lifeless: :D
[02:43] <jml> very good result though.
[02:43] <lifeless> I wanted to paste the result though
[02:43]  * jml is keen to see the results for the kernel
[02:43] <lifeless> I was thinking, 'lets get some numbers'.
[02:43] <lifeless> and boom.
[02:43] <lifeless> thumper: big histories may scale differently. I don't know precisely.
[02:43] <thumper> lifeless: very cool
[02:45] <lifeless> of course, over http it took 6 minutes to get dulwich bzr
[02:45] <lifeless> don't mention the war
[02:45] <thumper> lifeless: but git isn't using http is it?
[02:46] <lifeless> no
[02:46] <lifeless> git is using its native protocol
[02:46] <thumper> lifeless: so we are still comparing oranges with tangerines rather than oranges to fork lifts
[02:46] <bob2> is lp especially aggressive about packing things?
[02:46] <thumper> bob2: no
[02:47] <lifeless> thumper: yes, both protocols are fruity
[02:48] <jelmer> lifeless: nice!
[02:49] <jelmer> lifeless: do I explicitly have to remove entries from the chk map or is overwriting them fine as well?
[02:57] <poolie> thumper: want to catch up about nested trees sometime?
[02:57] <thumper> poolie: yes
[02:57] <poolie> now?
[02:58] <thumper> sure
[03:01] <lifeless> jelmer: use apply delta
[03:01] <poolie> thumper: call me?
[03:02] <johnf> lifeless: you about?
[03:02] <poolie> hello johnf
[03:03] <lifeless> johnf: sure am
[03:03] <johnf> poolie: howdy
[03:03] <johnf> lifeless: re bug https://bugs.launchpad.net/bzr/+bug/243391
[03:03] <lifeless> johnf: there's this theory I'm paid to do this sort of thing :)
[03:03] <poolie> igc: one small chore for you next week: please moderate the mailing list
[03:03] <poolie> it gets a ridiculous amount of spam but enough real posts are caught you do need to check it
[03:03] <igc> poolie: sure
[03:04] <johnf> I'm getting a similar error when an upstream router returns admin proibited. Would that be fixed or should I file another bug?
[03:04] <lifeless> johnf: bzr version ?
[03:04] <johnf> client 1.14.1 server 1.13
[03:04] <lifeless> johnf: new bug, that was 1.8
[03:05] <lifeless> johnf: I take it you've fixed your router though ? :>
[03:05] <johnf> lifeless: no it's normal. Happens if the VPN is down
[03:06] <lifeless> johnf: so, I suspect this is a variant of 'ssh tells us shit', unless you're committing over http
[03:06] <johnf> lifeless: this is using bzr://
[03:07] <lifeless> johnf: ok. please be sure to include that detail in your new bug report ;)
[03:07] <lifeless> johnf: root cause will be that we try to perform an operation on the protocol object while its still thinking its busy
[03:08] <johnf> lifeless:  I think I'll add to this bug as it seems to be the same problem https://bugs.launchpad.net/bzr/+bug/323456
[03:08] <lifeless> gimme a sec to read it
[03:10] <lifeless> yah, do it
[03:10] <lifeless> or just metoo the bug
[03:11] <lifeless> jelmer: can you suggest a midsize project with history in git and bzr - same history, as dulwich has
[03:11] <lifeless> jelmer: I'd like to do a slightly less 'new project' test
[03:12] <jelmer> lifeless: I'm using apply delta, but may be overwriting keys without removing the old data at the same key - is that a problem?
[03:12] <jelmer> lifeless: hmm
[03:12] <lifeless> jelmer: its expected
[03:13] <jelmer> lifeless: cool, thanks
[03:13] <lifeless> jelmer: you can't have a key repeated in a chkmap
[03:13] <jelmer> lifeless: Not sure about other projects. You could use one from gnome that's available in both svn and git
[03:13] <lifeless> jam: hi :)
[03:13] <lifeless> jam: gathering data for our talk, I found:
[03:13] <lifeless> 11:35 < lifeless> Git pull of dulwich: 2.43 MiB  in 0m53.437s
[03:13] <lifeless> 11:35 < lifeless> Bzr pull of dulwich: 360KB in 0m36.602s
[03:17] <lifeless> jelmer: I might ask a favour, if you're willing, as you have gitorious etc accounts
[03:17] <lifeless> jelmer: put together a similar sample case, but something that is say 10x the size of dulwich
[03:21]  * lifeless binds nose to ooo
[03:24] <igc> lifeless: is pqm broken? I just tried resubmitting a patch and it fails pretty well instantly grumbling about 'subunit' I think
[03:25] <lifeless> igc: forward to me please
[03:25] <lifeless> it shouldn't be, as subunit is optional.
[03:25] <igc> lifeless: I don't get an email either re success or failure as best I can tell
[03:25] <lifeless> igc: and to land a patch making it mandatory the patch would have to pass
[03:27] <igc> lifeless: I'll run the test suite on my integration branch and see if it's my fault
[03:27] <lifeless> bug in pqm
[03:27] <lifeless> it may be fixed i nwhich case we can just say 'spm please upgrade pqm'
[03:27] <lifeless> lets start with that
[03:27] <lifeless> spm: please upgrade pqm
[03:29] <poolie> igc, abentley, i read through the updated design doc and i have some comments
[03:30] <poolie> i know some of my questions on the user doc were answered in the design doc, but i wasn't always asking them for the sake of the answer
[03:30] <poolie> more to say they should be described here
[03:31] <igc> poolie: I'm planning to update the userdoc given the feedback from you and others
[03:31]  * lifeless taps the mic
[03:31] <lifeless> spm: ping
[03:31] <lifeless> igc: I'm sorry you haven't had feedback from me yet
[03:31] <lifeless> igc: feeling the crunch with allhands and 1.15
[03:32] <lifeless> igc: your branch is probably faulty btw, I think its a bug in pqm that you don't get told, not a bug in pqm causing it to fail
[03:32] <igc> poolie: but I don't think the userdoc is the critical path given abentley is working from the design doc
[03:33] <igc> poolie: except for how the userdoc impacts the design doc
[03:34] <spm> lifeless: sorry was on the phone. couple of minor family hassles atm. so upgrade pqm on balleny? I assume a bzr pull equiv would do the trick?
[03:35] <lifeless> spm: yeah, cd ~/source/pqm; bzr pull
[03:35] <lifeless> spm: then igc can try again
[03:35] <lifeless> and we see what breaks.
[03:35] <spm> oki. one sec or more...
[03:43] <spm> lifeless: igc: upgraded. go for it.
[03:50] <AfC> Is "1.9-rich-root" is the still the current public rich root format, or is there a newer one I should tell someone to use?
[03:52] <lifeless> AfC: its what --default-rich-root will create.
[03:52] <AfC> k
[03:52] <lifeless> AfC: if you need working tree filters you can use 1.14-rich-root, but only windows users are likely to be desperate for that
[03:52] <AfC> nah
[03:53] <lifeless> and if you want to help beta test the bbc format you can use --development-rich-root
[03:54] <lifeless> igc - thats what you hit in pqm https://bugs.edge.launchpad.net/pqm/+bug/340361
[03:57] <igc> lifeless: http://rafb.net/p/dMFRc592.html
[03:57] <igc> lifeless: anything obviously wrong?
[03:58] <igc> I trying to use a new integration branch fwiw
[03:58] <igc> one on lp as poolie has requested
[03:58] <lifeless> igc: your branch url is probably the problem
[03:58] <lifeless> igc: two things
[03:59] <lifeless> firstly, ~ianc/bzr/integration would be a better url
[03:59] <lifeless> no point having your personal integration branch a team branch
[03:59] <lifeless> secondly, I don't know if balleny can talk to lp
[03:59] <igc> well, except lp fails whether I try to push to ~ian-clatworthy/bzr/ianc-integration :-(
[03:59] <lifeless> spm: can you check that pqm user on ballent, outside chroot, can do 'bzr info bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/ianc-integration/'
[03:59] <lifeless> igc: it does, how ?
[04:00] <lifeless> igc: or rather, in what way
[04:00] <igc> grumbles about a read-only transport
[04:00] <igc> and breaklock doesn't fix it
[04:00] <lifeless> pastebin please
[04:01] <spm> lifeless: it can yes.
[04:02] <igc> lifeless: http://rafb.net/p/gnKmyI33.html
[04:02] <igc> lifeless: looks like ~ian-clatworthy/bzr/integration has worked though
[04:03] <lifeless> much nicer url :)
[04:03] <igc> lifeless: well, except for the vfs noise: http://rafb.net/p/CMcA4E84.html
[04:04] <lifeless> igc: yes, bzr is running 1.14
[04:04] <lifeless> 1.15 will remove that for a simple push
[04:04] <lifeless> dunno why you get that lock error
[04:04] <lifeless> readonly transport means that lp thinks *you* can't write to it
[04:05] <lifeless> file a question on launchpad-code
[04:05] <lifeless> I suspect a bug
[04:05] <igc> lifeless: ok, I'll try a http url to that new branch
[04:05] <lifeless> igc: bzr+ssh should be ok, spm has confirmed it works
[04:06] <lifeless> igc: what commit message were you giving pqm
[04:06] <lifeless> ?
[04:07] <igc> lifeless: see http://rafb.net/p/dMFRc592.html
[04:07] <igc> maybe the & is causing an issue?
[04:09] <lifeless> I would suspect so
[04:20] <igc> lifeless: so neither changing to a http URL, nor changing & => 'and' fixed the problem
[04:21] <igc> I added 'public_branch:policy' to branch.conf but that didn't help either
[04:21] <igc> the full test suite passes locally
[04:22] <igc> I don't have push_location:policy set to norecurse. Is that likely to cause an issue?
[04:22] <lifeless> jml - whats up with https://code.edge.launchpad.net/~jelmer/pqm/merge
[04:23] <lifeless> jml: I can't access it as 'lp:~jelmer/pqm/merge'
[04:23] <thumper> lifeless: that is because there is nothing there
[04:24] <lifeless> https://code.edge.launchpad.net/~jelmer/pqm/merge/+merge/6122 seemed to find something at some point
[04:24] <thumper> lifeless: or broken
[04:24] <lifeless> jelmer: ^^^^
[04:24] <thumper> lifeless: probably created with bzr send
[04:25] <lifeless> isn't that meant to create a working branch?
[04:32]  * igc lunch
[04:42] <bob2> no matter how many times I branch dulwich, git takes twice as long
[04:42] <thumper> did I recall seing that bbc branches stack in 1.15dev?
[04:44] <lifeless> yes
[04:44] <lifeless> bob2: :)
[04:44] <thumper> lifeless: cool
[04:49] <lifeless> or at least, jam has it mostly going and we're aiming for 1.15
[04:50] <lifeless> spm: please pull bzr from people.ubuntu.com/~robertc/pqm/trunk
[04:54] <jml> bob2: given that the git version is almost seven times bigger, that's not surprising :)
[04:54] <bob2> heh, even after a repack, it's 2x
[04:54] <lifeless> jml: 7 times data sent
[04:54] <lifeless> bob2: same history
[04:54] <jml> lifeless: oh.
[04:54] <lifeless> jml: ^ same history
[04:55] <jml> lifeless: that's actually quite interesting :)
[04:55] <spm> lifeless: balleny pqm update again?
[04:55] <lifeless> jml: its why I chose dulwich, jelmer keeps them in sync
[04:55] <lifeless> spm: please, from the url above
[04:55] <bob2> hm, 5x repo size
[04:57] <spm> lifeless: done. ddidn't restart the ui this time, appears unchanged.
[04:57] <lifeless> igc: please try again
[04:58] <lifeless> igc: I think you managed to have a revision that had a % in it. Odd though that may be. that or your url has a % in it
[04:59] <lifeless> igc: and thank you for the excuse to write some code :)
[05:21] <igc> lifeless: anytime :-)
[05:22] <lifeless> igc: so on commit
[05:23] <lifeless> igc: I think you should spend say 2 hours just doing it. At any blockage cry for a hand
[05:23] <lifeless> if at the end of that it looks like indefinite deferral, stop and I'll cave or something
[05:23] <lifeless> OTOH its in your head, and you've already figured out the bits needed.
[05:24] <igc> lifeless: well, I'm not convinced the layering is right to be honest
[05:24] <igc> record_iter_changes ...
[05:24] <igc> claims to take the results of iter_changes but it doesn't
[05:24] <igc> so you need to do the mssing -> delete dance for example
[05:24] <lifeless> by which you mean iter_changes isn't compatible with it ?
[05:25] <igc> so I wonder whether ...
[05:25] <igc> record_iter_changes ought to be handling that, and the parent yielding
[05:25] <igc> the trouble is ...
[05:25] <igc> record_iter_changes is *5* pages in length
[05:26] <igc> not exactly easy to hack on
[05:26] <igc> lifeless: I've had terrible pain these last 24 hours and the pain killers aren't working ...
[05:26] <igc> so apologies if I'm coming across grumpy
[05:26] <lifeless> igc: ouch :(
[05:27] <lifeless> not at all
[05:27] <igc> dentist tomorrow but it's prably chemo frug related :-(
[05:27] <lifeless> you raise a good point
[05:27] <igc> s/frug/drug/
[05:27] <lifeless> record iter changes is long, but mostly clear
[05:28] <igc> so, reporting aside, maybe ...
[05:28] <lifeless> the major data-assembly points can be turned into helpers without performance impact; its only the main loop we need to be really careful on
[05:28] <igc> fliter_iter_changes needs to move into commitbuilder
[05:28] <lifeless> commit.py needs:
[05:28] <lifeless>  - reporting
[05:28] <lifeless>  - awareness of missing->deleted changes so it can update the working tree
[05:29]  * lifeless tries to remember what 'missing' files will do when sent to ric
[05:29] <abentley> poolie: While those changes might improve the userdoc, I don't see that helping us decide how to move forward with nested trees.
[05:29] <lifeless> get_file_with_stat will fail
[05:30] <lifeless> igc: ok, so ric wants something that is a subset of iter-changes (no 'missing' status) and a superset ('add parents please')
[05:31] <lifeless> igc: I think reporting should stay outside
[05:31] <igc> me too
[05:31] <lifeless> igc: ok, let me rephrase what I really want
[05:31] <lifeless> I think its gotten lost
[05:32] <igc> and btw, iter_changes needs to do more for commit than it currently does, e.g. unknown checking
[05:32] <lifeless>  - specific tests for the handling of parent-adding and path-excluding
[05:33] <lifeless> given that the interface isn't as crystal as I recall, I won't ask that those things be in the iter_changes interface, and certainly not as a rush just before 1.15
[05:33] <lifeless> so I'm fine with them outside it.
[05:33] <igc> and I'm happy to add those tests but ...
[05:33] <igc> I don't think that ought to block my interim patch :-)
[05:33] <lifeless> I think its easier to test those things if they are not embedded in Commit
[05:34] <lifeless> igc: Given I think your patch has at least one bug which such tests will catch, I think it should
[05:34] <lifeless> you'
[05:34] <lifeless> ^typo
[05:35] <igc> I think the parent yielding and excludes can be a decorator as you outlined and tested as such
[05:35] <lifeless> great
[05:35] <lifeless> with that done I'll be happy to approve ;)
[05:35] <igc> do you want the missing -> delete dance done in the same decorator
[05:36] <lifeless> if you want to move it across, that would be fine with me. OTOH its orthogonal to what you are trying to achieve.
[05:36] <igc> do we know whether a pipeline of decorators is faster than one or vice versa?
[05:36] <igc> I know that's ...
[05:36] <igc> a bit like asking how long a piece of string is
[05:36] <lifeless> there is a cost
[05:37] <lifeless> OTOH specific file commits tend to be small anyway
[05:37] <lifeless> commit [list of 4000 files] is rare
[05:37] <igc> right
[05:37] <igc> that's why I felt pushing the code down wouldn't gain much performance wise
[05:37] <lifeless> the only really-big-list commits we see that people will notice a small percentage point on is first-commit
[05:38] <lifeless> oh, pushing it down is about clarity and reuse for 'diff' and 'status', not about further performance wins.
[05:38] <igc> and that won't have excludes and specific files most likely
[05:38] <lifeless> exclude may gain substantially by pushing into iter_changes
[05:38] <lifeless> (consider -x large-directory)
[05:39] <lifeless> even an unchanged large directory will be a lot cheaper if you don't stat it at all
[05:39] <lifeless> because you won't page it in from disk etc etc
[05:40] <igc> lifeless: so wrt diff and status ...
[05:40] <igc> neither take a -x flag do they?
[05:40] <igc> and neither care about parent yielding?
[05:40] <lifeless> no, because the code is trapped in commit :)
[05:40] <lifeless> status should show what commit will do; it can't at the moment.
[05:41] <lifeless> this was an oversight when the commit -x support was accepted
[05:41] <igc> so, IIUIC, you're arging that status and diff ought to gain -x options once iter_changes supports an exclude parameter?
[05:41] <lifeless> absolutely
[05:41] <igc> arguing
[05:42] <igc> and parent yielding? That still smells like a ric special need to me
[05:42] <lifeless> bzr diff foo/bar -> A foo\nRM bar\n
[05:42] <lifeless> iter_changes can't generate valid inventory deltas without parent yielding of new parents
[05:43] <lifeless> that sharply limits its reuse in the core
[05:44] <lifeless> I appreciate your arguments for doing less, now. But I think the reasons to push these things down to iter_changes at some point are pretty strong and valid
[05:44] <lifeless> exclude for performance, yielding new parents for correctness in tools like fast-export, ric itself, various custom bits of code.
[05:45] <igc> hmm - in some ways, CommitBuilder is the inventory-delta generator
[05:45] <lifeless> anyhow - like I say, I've backed off from insisting you do the move to iter_changes; unless you're considering doing it, we're just idly chatting
[05:46] <igc> lifeless: sorry, just trying to get the right long term layering clear in my mind
[05:46] <lifeless> yes, thats a prime component of CommitBuilder.ric
[05:46]  * igc heads back to coding
[05:47] <lifeless> igc: thats cool; I didn't want you to be feeling that I was still asking for it, was all.
[05:47] <igc> sure
[05:53] <lifeless> igc: have you tried pqm again?
[05:53] <igc> lifeless: looking much better thanks
[05:53] <lifeless> great
[05:53] <igc> thanks to spm too
[05:54] <spm> igc: us qlder's need to look out for each other. ;-)
[05:54] <igc> spm: absolutely :-)
[07:01] <vila> hi all
[07:05] <spm> morn vila!
[07:18] <lifeless> hi vila
[07:19] <lifeless> vila: how did you go with annotate?
[07:21] <vila> I'll really start to day, I was hoping to quickly finish fixing a bug but bmuped on a test coverage hole :-/ Then I prepared a talk for all hands...
[07:21] <vila> s/to day/today/
[07:22] <lifeless> what talk are you giving?
[07:25] <vila> lifeless: I don't know if I'm the one who will be giging it, but anyway, it's about mysql users
[07:26] <vila> lifeless: but if you have some template around I'll buy it
[07:30] <lifeless> lp:~lifeless/+junk/karmic_presentations
[07:35] <vila> lifeless: perfect, thanks
[08:54] <jnz__> Hi, bzr push --create-prefix raised an internal error after I've inserted the password:
[08:54] <jnz__> bzr: ERROR: exceptions.AttributeError: 'str' object has no attribute 'get'
[08:59] <jnz__> https://answers.launchpad.net/bzr/+question/69809
[09:20]  * igc dinner
[09:51] <awilkins> lifeless: The HTTP server seems to be broken for me as far back as 1.12
[09:51] <awilkins> lifeless: I'm rolling back through versions to see where it starts working again
[09:51] <Peng_> Whowhat is broken?
[09:51] <awilkins> Peng_: bzr+http:// server, on Win2k3 server / IIS / PyISAPIe
[09:52] <Peng_> Oh. What goes wrong?
[09:52] <Peng_> (Not that I can help, but I'm curious.)
[09:52] <awilkins> I'm geting "FileExists" exceptions
[09:52] <awilkins> When pushing
[09:53] <awilkins> Pulling appears to be fine
[09:53] <Peng_> Oh.
[09:54] <awilkins> Alas, different exceptions when I turn on server-side logging
[10:06]  * awilkins cusses loudly
[10:06] <awilkins> I upgraded the server to 1.14 and it stops working. I downgrade it back to 1.9, and it's still not working in exactly the same way.
[10:06] <lifeless> awilkins: file bugs
[10:07] <lifeless> awilkins: I'm about to start a social event, but I'll comment on them at a minumum tomorrow :)
[10:07] <lifeless> awilkins: [of course, debugging it yourself is great too]
[10:07] <awilkins> I don't think it's necessarily a bzr problem
[10:08] <awilkins> Yes, I think a few hours with a filesystem debugger and contemplating dark thoughts about people who install antivirus on servers is required
[10:08] <awilkins> It seems similar to a bug in the atomic rename thing
[10:08] <awilkins> Well, "bug"
[10:08] <awilkins> As in a "Windows is crap bug"
[10:09] <awilkins> Can you reindex a repository?
[10:10] <awilkins> I'm getting bzr: ERROR (ignored): GraphIndex('bzr+http://w .....
[10:10] <awilkins> But that's not where it stops
[10:15] <bialix> vila: hi
[10:15] <vila> bialix: Hi Alexander
[10:15] <bialix> bonjour monsieur
[10:16] <bialix> I need to test some unicode thing
[10:16] <bialix> please, tell me how you enter accented characters in French?
[10:17] <jml> like in café?
[10:17] <bialix> yes
[10:17] <jml> on my computer, I use the Compose key
[10:18] <bialix> Hm? I don't see compose key
[10:18] <vila> u"Cet été au café".encode('UTF-8')
[10:18] <vila> 'Cet \xc3\xa9t\xc3\xa9 au caf\xc3\xa9'
[10:18] <jml> Compose+' Compose+e
[10:18] <jml> bialix: it's kind of a virtual key, mine is bound to Right Alt
[10:18] <vila> jml: compose key on windows ? :-)
[10:18] <bialix> vila: I need to test command line behaviour
[10:18] <jml> on Windows... who knows.
[10:18] <bialix> maybe Vincent knows?
[10:18] <jml> on OS X its Option-' e IIRC
[10:19] <vila> bialix: I *never* use accented letters from command line, but the trick on windows I remember it via Alt-nnn sequences
[10:19] <bialix> oh; I see
[10:20] <vila> now, the sequence for accented letters... you may know better ? :-/
[10:20] <bialix> ╙
[10:20] <bialix> ╙▓
[10:20] <bialix> h,,
[10:20] <bialix> hmm
[10:21]  * bialix going to test alt codes
[10:21] <bialix> It seems like french keyboard layout very different from qwerty
[10:21] <vila> oh, yes
[10:21] <jml> I blame Napoleon :P
[10:22] <bialix> :-)
[10:22] <vila> é is on '2' with a french layou
[10:22] <vila> t
[10:23] <bialix> yes; it is
[10:23] <bialix> this will be enough for me, thanks
[10:24] <vila> ok, np
[10:26] <bialix> Français
[10:42] <jnz__> Hi, there are some trouble if I use python 2.6 to run bazaar? I see that there are some warning using deprecated lib and an error trying to use `get' method in `str' (that doesn't exist now).
[10:44] <james_w> jnz__: what's the full message?
[10:45] <jnz__> AttributeError: 'str' object has no attribute 'get' https://answers.launchpad.net/bzr/+question/69809
[10:45] <jnz__> it's the same bug I've reproduced
[10:46] <jnz__> (but on linux)
[10:47] <jnz__> the fact is that I can't remove svn plugin
[10:48] <james_w> I thought that had been fixed, but I can't find the bug number now
[10:50] <Peng_> That question links to the bug.
[10:50] <Peng_> jnz__: The AttributeError has nothing to do with your Python version.
[10:51] <Peng_> jnz__: If you're running a recent version of bzr, all of the deprecation warnings and other Python 2.6 issues should have been fixed. If you're still seeing any, they're probably in third-party libraries. In any case, file bugs if they haven't been fixed.
[11:38] <Spaz> 'ello
[11:38] <Spaz> i'm having a problem with loggerhead
[11:38] <Spaz> http://pastebin.ca/1421449
[11:38] <awilkins> "Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
[11:38] <Spaz> i get that on every request.
[11:38] <awilkins> That's from LP, on doing "bzr branch lp:bzr/1.14" ; oopsie
[11:47] <Peng_> Spaz: What version of Loggerhead?
[11:48] <Peng_> Oh, trunk.
[11:50] <Peng_> Spaz: As a workaround, you can revert a few revisions; that code was only added recently.
[11:50] <Spaz> ah ok
[11:50] <Peng_> (in r335)
[11:51] <Peng_> I honestly don't get it. branch_url is a method; it's defined 5 lines above!
[11:51] <Peng_> My only guess is that some file, perhaps serve-branches, is from an old version that does something funny.
[11:55] <Peng_> Oh, you're using start-loggerhead? I never tested that.
[11:55] <Spaz> yep.
[11:55] <Peng_> Hmm. I don't know the start-loggerhead code at all. :\
[11:56] <Peng_> branch_url never used to be called, so if it was set to the wrong thing, it wouldn't have been noticed until I started using it in r335.
[11:56] <Spaz> reverting r335 fixes it
[11:58] <Spaz> Peng_, ^
[12:00] <Peng_> Ah, I see where it goes wrong.
[12:01] <Spaz> Peng_, you're a loggerhead dev? :p
[12:02] <Peng_> Spaz: Allegedly.
[12:02] <Spaz> :P
[12:03] <Peng_> Um, I'm not sure what the solution should be, though. Easiest would probably just be renaming hte "branch_url" method so it won't get clobbered.
[12:03] <Spaz> occam's razor :p
[12:04] <Spaz> the simplest solution is usually the correct one
[12:04] <Peng_> Not necessarily.
[12:04] <Peng_> (Well, hence it saying "usually" instead of "always"...)
[12:04] <Spaz> it's not always, but most of the time it is
[12:04] <Spaz> at least i like to think so
[12:04] <Spaz> :)
[12:05] <Peng_> The method didn't have a great name anyway.
[12:14] <Peng_> Y'know, if you used serve-branches, it wouldn't be broken. ;D
[12:15] <Spaz> Peng_, start-loggerhead suits my needs better
[12:15] <Spaz> :p
[12:16] <Spaz> 1) looks better, 2) extremely small amount of projects
[12:16] <Peng_> It looks better?
[12:16] <Spaz> Peng_, see http://web-bzr.wilcox-tech.com :p
[12:16] <Spaz> for one project it looks a lot nicer
[12:17] <Spaz> oops awos-bzr.wilcox-tech.com
[12:18] <Peng_> Oh, nifty.
[12:19] <Peng_> But if people use start-loggerhead, I have to figure out how to use it so I can actually test it. :P
[12:19] <Peng_> Spaz: I filed bug 375948.
[12:21] <jelmer> I thought start-loggerhead was going away?
[12:21] <Peng_> jelmer: That's the plan.
[12:21] <Peng_> jelmer: But start-loggerhead can still do some things serve-branches can't.
[12:36] <Peng_> Spaz: I've pushed a workaround to lp:loggerhead
[12:37] <Spaz> thanks
[12:39] <Peng_> Well, the good news is that from now on I'll test start-loggerhead. :P
[12:51] <Spaz> hehe
[13:04] <Peng_> Well, after converting one branch to a stacked branch, I saved 2 MB of disk space, but I can no longer push. Perhaps not worth it?
[13:06] <jelmer> lifeless: ping
[13:07] <Peng_> What's a simple command I can use that will lock the branch? Without having to use some "python -c 'import bzrlib'" magic?
[13:08] <Peng_> (I don't want to leave the lock in place or anything, just see if one can be taken out.)
[13:13] <Peng_> Never mind.
[13:14] <Peng_> beuno: ping
[13:15] <awilkins> Peng_: I think you just need to create a file in the right place
[13:23] <awilkins> lifeless: ping?
[13:23] <awilkins> I found the problem ; it's creating the same pack twice
[13:24] <awilkins> Which win32 doesn't like because it's renaming a file from "upload" to "packs" but because they are named after their md5, the file is already there and on win32 you can't rename a file to an existing destination
[13:29] <awilkins> Deleting the pack appears to have expunged the problem. Maybe it was linked to the jailbreak thing...
[13:29] <awilkins> Maybe the jailbreak error puts the repo into this state.
[14:36] <beuno> Peng_, hi
[14:38] <Peng_> Ah, hello.
[14:39] <Peng_> beuno: I was just curious, in Loggerhead, what is BranchWSGIApp.branch_link? All it says is that it's only used by LP.
[14:39] <beuno> Peng_, I don't remember what we use it for
[14:39] <beuno> but I can find the glue code and figure it out
[14:41] <Peng_> beuno: Well, it's not important, so you don't have to bother.
[14:42] <beuno> Peng_, I think it was something about showing the branch URL in LH
[15:01] <igc> night all
[15:05] <Peng_> igc: Good night.
[15:08] <lifeless> awilkins: bzr is meant to not do that; ah
[15:08] <lifeless> awilkins: bzr hada  stale pack it didn't knowabout anymore
[15:08] <lifeless> awilkins: thats why the rename was being attempted at all
[15:08] <lifeless> awilkins: please file a bug
[15:08] <lifeless> awilkins: we should handle this case
[15:27] <Peng_> beuno: Thanks for the review. :)
[15:28] <beuno> Peng_, thanks for all the work
[15:31] <Peng_> :)
[16:58] <luke-jr_> blah, bzr-svn doesn't merge :<
[16:58] <SamB> luke-jr: say what?
[17:01] <luke-jr_> SamB: I can't merge svn commits and push my stuff to it
[17:01] <luke-jr_> it errors
[17:02] <jelmer> luke-jr_: what error do you get exactly?
[17:02] <luke-jr_> I need to make a new branch of the svn, merge my bzr repo into that, then push that
[17:02] <luke-jr_> bzr: ERROR: exceptions.AssertionError: Expected <CachingRevisionMetadata for revision 2422, path vxmlb/tags/no_spm_count_no_ext_grammars_no_playfile in repository 'f396537e-aa06-0410-a58a-90fff5392f0b'> got <CachingRevisionMetadata for revision 382, path tags/no_spm_count_no_ext_grammars_no_playfile in repository 'f396537e-aa06-0410-a58a-90fff5392f0b'>
[17:02] <luke-jr_> oops, forgot to edit paths
[17:02] <luke-jr_> don't store that in a bug report or such as-is please :)
[17:03] <jelmer> luke-jr_: there's an open bug about this, will be fixed before 0.6.0 (i.e. in a few days)
[17:21] <SamB> luke-jr: if there's some secret info in there, I can't imagine what it might be!
[17:21] <SamB> or are you just embarrassed?
[17:30] <phinze> seeking bzr one liner... how to determine when file "path/to/file" was removed?
[17:31] <Peng_> "bzr log"...might work? in recent versions? if the file was deleted recently?
[17:31] <Peng_> It won't be fast, since the only way to do it is to check each revision 1 at a time.
[17:32] <phinze> bzr: ERROR: Path unknown at end or start of revision range:  .... on 1.14.1
[17:32] <SamB> phinze: do you remember a revision where it was still alive ?
[17:32] <Peng_> Guess not, then.
[17:32] <phinze> yeah i've got one rev when it was alive
[17:32] <SamB> maybe that can help?
[17:34] <phinze> i'll try a bzr log $OLDREV.. --verbose --short | grep D | grep filename
[17:34] <phinze> something like that
[17:35] <phinze> and wait :)
[17:36] <Peng_> Like I said, with the current design it can't be fast. For that reason, it's not encouraged by the UI..
[17:36] <phinze> looks like it was in the last 20 revs
[17:36] <phinze> i'll narrow it down
[17:36] <phinze> might look into bzr-undelete plugin in the future
[17:37] <phinze> https://launchpad.net/bzr-undelete
[17:44] <SamB> did I mention the bisect plugin yet?
[17:51] <bmorris> Does anybody know of a good tutorial for setting up the pqm?
[18:50] <Ken69267> how does one checkout a branch from googlecode with bzr-svn? I can't seem to specify the username it wants for authentication
[18:51] <Peng_> Ken69267: Yeah, that's kind of a bug. When Bazaar tries to detect what type of branch it is, it asks for .bzr/smart, and Google asks for auth.
[18:52] <Peng_> Ken69267: You can use svn+http:// to work around it, depending on your version of bzr-svn.
[18:53] <Ken69267> yeah I tried svn+https://, but my username is different than my shell. svn+https://username@ doesn't seem to work
[18:54] <Peng_> Fortunately, I don't care about Google Code much, so I haven't bothered to solve this. Or bug jelmer much.
[18:54] <Peng_> Not so fortunate for you, though. :\
[18:58] <jelmer> Ken69267: if you don't specify a username bzr should ask you if you have a new enough bzr
[19:19] <Lo-lan-do> Hi all
[19:20] <jelmer> hey Lo-lan-do
[19:20] <Lo-lan-do> :-)
[19:21] <Lo-lan-do> I get different errors now... I'll pastebin them, shall I?
[19:21] <jelmer> Lo-lan-do: can you mail them perhaps?
[19:21] <Lo-lan-do> Sure
[19:23]  * jelmer back in ~30 min
[19:26] <Lo-lan-do> Mailed.  Take your time, I'm also struggling with an unrelated shared library problem :-)
[19:36] <Ken69267> jelmer: bzr 1.14.1 and bzr-svn 0.5.4 here, doesn't prompt for username :/
[19:50] <jelmer> Ken69267: you need bzr.dev I think
[19:52] <jelmer> Ken69267: does http://username@... work (no svn+) ?
[20:01] <Ken69267> jelmer: no, bzr bombs out with a pycurl error
[20:01] <Ken69267> (with https://user@)
[20:04] <jelmer> Ken69267: ah
[20:04] <Ken69267> allwell, I rarely use googlecode anyway
[20:04] <jelmer> Ken69267: so, this should be fixed in 1.15
[20:07] <jelmer> Lo-lan-do: replied
[20:12] <beuno> Peng_, ready for the rich-root-ization of LH?
[20:12] <beuno> (I won't do it *now*, but in a few hours)
[20:13] <Lo-lan-do> jelmer: Got it, thanks.
[20:13] <Peng_> beuno: Ready as I'll ever be.
[20:13] <Peng_> Upgrade stacked-on branches first, right?
[20:13] <beuno> Peng_, yes, the ones you care about
[20:13] <beuno> what I'm going to do
[20:13] <beuno> is upload a new branch
[20:13] <beuno> leave the current one as-is
[20:13] <beuno> and just change the developemnt focus
[20:14] <Peng_> Oh, why?
[20:14] <beuno> *maybe* that won't break stacked-on branches
[20:14] <Peng_> Ah.
[20:15] <Lo-lan-do> jelmer: s/graphwalker/graph_walker/ in dulwich/repo.py:231
[20:15] <beuno> Peng_, this is me trying to figure out the best upgrade strategy  :)
[20:15] <jelmer> Lo-lan-do: thanks, fixed
[20:16] <Peng_> I'm really apathetic at the moment, so I won't have any opinion unless someone makes a Rich-root-tan or something.
[20:16]  * beuno hugs Peng_ 
[20:17] <Peng_> :D
[20:17] <Peng_> Anyway, switching out the branches makes sense, though it'll be inconvenient for subscribers.
[20:17] <Lo-lan-do> jelmer: I still get NameError: global name 'BzrDir' is not defined; did you push?
[20:17] <beuno> yeah, not sure what the best inconvenience is yet
[20:18] <Peng_> And the linked bugs and merge proposals.
[20:18] <jelmer> Lo-lan-do: yeah
[20:18] <jelmer> Lo-lan-do: where are you pulling from?
[20:19] <beuno> Peng_, so what do you think?  break all stacked-on branches or loose linkage?
[20:19] <Peng_> I wonder if you could rename the branch, push a new non-rr branch as lp:~loggerhead-team/loggerhead/trunk, then upgrade the original branch to rr.
[20:19] <Peng_> Did that make sense?
[20:19] <beuno> ah
[20:19] <Lo-lan-do> jelmer: http://people.samba.org/bzr/jelmer/bzr-git/trunk or lp:bzr-git
[20:19] <Peng_> This sounds like a job for...staging.lp.net!
[20:19] <beuno> Peng_, that's interesting
[20:20] <Lo-lan-do> (And s/bzr-git/dulwich/ for dulwich)
[20:20] <beuno> Peng_, are you going to try that?
[20:20] <beuno> or want me to?
[20:20] <jelmer> Lo-lan-do: hmm, odd, that location should work
[20:21] <Peng_> beuno: Yeah, I'll try it.
[20:21] <jelmer> Lo-lan-do: oops, forgot to commit
[20:21] <jelmer> Lo-lan-do: sorry, pushed properly now
[20:21] <beuno> Peng_, \o/
[20:23] <Peng_> How do staging URLs work? lp://staging/~user/project/branch?
[20:23] <beuno> yeap
[20:23] <Peng_> Thanks.
[20:24] <beuno> lifeless, igc, should the traceback for VFS usage be sput out to stdout instead of .bzr.log?
[20:24] <Peng_> OK, what was my plan again? :P Blinkblink. Anyway.
[20:24] <Peng_> I should be doing this on my faster machine with the better connection.
[20:25] <beuno> Peng_, your amazing plan is:  rename trunk, push a non-r-r as trunk, upgrade old-trunk, rename old-trunk to new trunk, see if everything's alright  :)
[20:25] <ja1> beuno: I that only happens when you use -Dhpss, IIRC
[20:25] <Peng_> Crap, it tried to stack on lp:loggerhead, which obviously screwed up.
[20:25] <ja1> And I think there is argument where it should go
[20:25] <beuno> ja1, ah, makes sense
[20:25] <Peng_> Actually, it says "not a branch".
[20:25] <beuno> I have that set by default
[20:25] <ja1> I think someone mentioned that it should be muttered(), and then realized that it also helps force us to fix things :)
[20:25] <beuno> rockstar, how do you push to staging? mwhudson around yet?
[20:25] <Lo-lan-do> jelmer: Yay, progress.  New errors at http://pastebin.com/d27aef86d :-)
[20:25] <ja1> otherwise, I would think it should be 'noted' so it goes to stderr + .bzr.log
[20:25] <Peng_> Screw it, I won't use staging.
[20:25] <ja1> brb
[20:26] <rockstar> beuno, bzr push lp://staging/...
[20:27] <beuno> wow
[20:27] <beuno> HPSS calls: 46 (11 vfs) SmartSSHClientMedium(connected=False, username=u'beuno', host='bazaar.launchpad.net', port=None)
[20:27] <beuno> argh
[20:27] <Peng_> How do you force a push to not stack? Downgrade to Branch6?
[20:28] <beuno> I was about to ask that same thing  ;)
[20:28]  * beuno will try pushing to +junk and then renaming
[20:31] <Wyvern> Hey!
[20:31] <Peng_> What will upgrading to rich-roots do to all of the stacked branches in lp:~*/loggerhead? This may be a problem.
[20:32] <Wyvern> Question: How can I cancel an bzr add? That is before commit.
[20:32] <Lo-lan-do> bzr rm --keep
[20:33] <Wyvern> Thank you.
[20:35] <Peng_> Great, push was taking forever because I forgot that ssh-agent wasn't running! :P
[20:36] <Peng_> Using Branch6 did not prevent it from stacking.
[20:36] <Peng_> So I'm kind of stuck now.
[20:37] <Peng_> I suppose I could dig out bzr 1.5.
[20:39] <jelmer> Lo-lan-do: pushed another fix
[20:40] <Peng_> It may be possible to work around the default stacking policy by using a Branc6 mirrored branch.
[20:41] <Lo-lan-do> jelmer: Yay, cloning a git branch through bzr-upplad-pack now works :-)
[20:41] <jelmer> woot :-)
[20:41] <Peng_> beuno: These stacking issues are really killing my attention span. :P
[20:42] <beuno> Peng_, https://code.edge.launchpad.net/~loggerhead-team/loggerhead/rich-trunk
[20:42] <beuno> :)
[20:42] <beuno> (pushed to +junk, then moved it)
[20:43] <Peng_> Ah, clever.
[20:43] <beuno> Launchpad has trained me to be sneaky
[20:45] <Peng_> Heheh, push peaked at 731 KB/sec. >:D
[20:46] <Peng_> beuno: Wait, I didn't think this out. Could you do me a favor and subscribe to https://code.edge.launchpad.net/~mnordhoff/loggerhead/trunk ?
[20:47] <Peng_> Wait.
[20:47]  * beuno waits twice
[20:47] <Peng_> Yeah, that branch.
[20:47] <Peng_> Heh.
[20:48] <Peng_> It would've been better to use staging so I could link it to a bug report, but oh well.
[20:48] <beuno> Peng_, done
[20:48] <Peng_> beuno: Thanks.
[20:50] <Peng_> brb
[20:51] <bialix> jam: hi
[20:51] <bialix> yep
[20:51] <bialix> jam: hi
[20:51] <jam> hi bialix
[20:51] <jam> having some networking issues here, so I may come and go
[20:52] <bialix> I've prepared the patch for unicode cmd line @ win32
[20:52] <Peng_> Is it just me or does branch --stacked make a painful number of ssh connections?
[20:52] <bialix> jam: I suspect you're busy with other patches, I'm just hope you will be able to look at my patch
[20:53] <bialix> Peng_: 3 or 4?
[20:53] <Peng_> bialix: I killed it and fixed ssh-agent after 6.
[20:54] <Peng_> OK, *maybe* 5.
[20:54] <bialix> it does not sound right
[20:56] <Peng_> Reconciling over bzr+ssh is not so efficient. :P
[20:57] <beuno> Peng_, no, I did all of that locally  :)
[20:57] <jam> bialix: I'll try to give it a shot.  I'll mention that with my network going wonky, I'm not getting all of my email
[20:57] <Peng_> What's the easiest way to upgrade a remote branch? Doing it remotely? If so, and you need to do reconcile too...
[20:58] <jam> if you want to CC my gmail account, it may be a bit more trustworthy
[20:58] <Peng_> Anyway, this is just for fun anyway, and I hope LP won't mind wasting 30 MB of bandwidth. :P
[20:58] <jam> Peng_: *reconciling* is not so efficient
[20:58] <Peng_> So far it's at 18 MB of bandwidth. :D
[20:58] <jam> bialix: So is this the problem that qbzr is trying to pass unicode arguments to a bzr subprocess?
[20:59] <jam> and is going through "OEM" encoding
[20:59] <bialix> jam: I'm using gmane, what about http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cguf7hb%24k3h%241%40ger.gmane.org%3E
[20:59] <beuno> Peng_, it's called "research"
[20:59] <jam> which fails for certain unrepresentable bits?
[21:00] <bialix> jam: AFAICT, qbzr trying to pass unicode argumets to bzr. but any python program unable to retrieve unicode right, only as plain strings
[21:00] <jam> bialix: but this only helps when using CreateProcessW
[21:01] <jam> and *doesn't* do anything for the actual command line
[21:01] <jam> At least, I'm pretty sure "cmd.exe" has a specific encoding
[21:01] <jam> and isn't generic about Unicode support
[21:01] <bialix> jam: I've tested manually in cmd.exe shell
[21:02] <bialix> GetCommandLineW is able to get right unicode
[21:02] <jam> bialix: sure, but it would other ways, too
[21:02] <jam> My question is, can you type جوجو in your Russian cmd.exe shell?
[21:02] <bialix> "would other ways"?
[21:02] <jam> bialix: if the strings are passed in as OEM, and then they are decoded from OEM
[21:02] <jam> things should work
[21:02] <bialix> I don't understand Arabic
[21:03] <jam> bialix: you don't have to
[21:03] <jam> it is just a few characters for you to try
[21:03] <bialix> but I've learnt French, and I can type French in my shell
[21:03] <jam> well, IDLE doesn't like me. Giving: Unsupported characters in input
[21:04] <bialix> actually I have netbook with non-Russian Windows XP
[21:04] <Lo-lan-do> jelmer: Minor patch: http://pastebin.com/f5f7eb376
[21:04] <jam> bialix: so my point of using Arabic is that it is quite unlikely to be on a given code page
[21:04] <bialix> there I can type non-russian characters without problem
[21:04] <jam> unlike French characters
[21:04] <bialix> French is from cp1251
[21:04] <bialix> while Russian is cp1251
[21:04] <jam> bialix: well, on a 'non-Russian" windows, I would want to try Russion chars
[21:04] <jam> bialix: cp1251 == cp1251
[21:04] <bialix> cp1251 has no room for non-cyrillic
[21:05] <bialix> of course it works with Russian char
[21:05] <jam> bialix: can you type a couple cyrillic chars for me to test with?
[21:06] <jam> or give me their code points
[21:06] <Peng_> So far, upgrade over bzr+ssh seems disgustingly inefficient.
[21:06] <bialix> I'm just tested on my Russian Windows XP
[21:06] <bialix> I can type French here too
[21:06] <Peng_> I could probably twiddle with hitchhiker or sftp to accomplish the same thing, but that takes more thinking.
[21:06] <bialix> jam: here is Test in Russian: Тест
[21:07] <jam> bialix: any chance you could put that in hex codes for me?
[21:07] <jam> cygwin doesn't like it, and neither does IDLE
[21:07] <jam> and vim just gives me ????
[21:08] <jam> bialix: pasting those chars into cmd.exe gives me ????
[21:08] <bialix> jam: are you using vim wit console or GUI interface?
[21:08] <jam> bialix: vim w/ gui
[21:08] <Peng_> What will changing the developer focus do? Change what new branches automatically stack on? Will it change old branches too? Cuz that'd be a problem.
[21:08] <jam> It could just be Pidgin not copying them correctly
[21:09] <jam> If I do 'chcp 1251' in cmd.exe I at least get characters when I paste your cyryllic
[21:09] <bialix> jam: re cmd.exe: right-click on cmd.exe window button on task panel, select Properties -> Font -> Lucida Console
[21:09] <jam> but it comes out as: pi sigma +/- >=
[21:10] <bialix> Lucida is unicode font
[21:10] <Peng_> FYI? Upgrade over bzr+ssh is horribly slow. Using hitchhiker is definitely a better idea.
[21:10] <jam> bialix: ok, so it works if I 'chcp 1251' and then paste
[21:10] <bialix> it will show you right characters
[21:10] <jam> And it looks like Тест
[21:10] <jam> but with the default chcp (437) it fails
[21:10] <bialix> yeah, is it
[21:10] <bialix> try Lucida
[21:10] <jam> ah, it worked this time
[21:10] <jam> weird
[21:10] <jelmer> Lo-lan-do: thanks
[21:11] <bialix> default is OEM font it's not unicode
[21:11] <jam> bialix: however, it gives me just [] for Arabic
[21:11]  * bialix adding Arabic keyboard
[21:11] <Peng_> beuno: This upgrade will probably take half an hour. Unless I get bored, kill it and do it more efficiently, you'll have to wait that long to see how it pans out. Although I've probably done enough now.
[21:12] <beuno> Peng_, I have about half a million things to do today
[21:12] <beuno> so I'll probably be around here forever
[21:13] <bialix> jam: I have not Arabic keyboard settings on my Russian XP
[21:13] <Peng_> beuno: Although I'm not finished, I'm pretty sure my evil plan will work. So I'd vote for doing it on lp:loggerhead.
[21:13] <mwhudson> Peng_: loggerhead.apps.config is a terrible terrible thing
[21:13] <Peng_> mwhudson: :D
[21:13] <jam> bialix: you have Cut & Paste don't you?
[21:14] <beuno> Peng_, I think it will. If it does, I will create a document so everyone else follows this path
[21:14] <beuno> I'm willing to break everything in the name of research
[21:15] <bialix> jam: yes, I can, but it seems my Russian XP lacks of Arabic fonts. I see 4 squares instead of real chars
[21:15] <bialix> but Wordpad paste them OK
[21:16] <mwhudson> Peng_: also i don't care about it at all from a launchapd pov, so pleae feel free to do whatever you like to it :)
[21:16] <bialix> jam: will try with cmdline.py script
[21:16] <Peng_> mwhudson: OK, thanks. :)
[21:17] <jam> bialix: well, I *have* Arabic fonts installed, and I only see 4 squares in cmd.exe :)
[21:18] <bialix> jam: cmdline.py is able to see it!
[21:18] <bialix> C:\Temp>python cmdline.py جوجو
[21:18] <bialix> ['cmdline.py', '????']
[21:18] <bialix> [u'cmdline.py', u'\u062c\u0648\u062c\u0648']
[21:18] <bialix> ha!
[21:18] <jam> bialix: your public branch is a bit wonky
[21:18] <bialix> do you see it?
[21:18] <jam> C:/work...
[21:18] <jam> I don't know where 'cmdline.py' is
[21:18] <jam> but your paste here looks appropriate
[21:19] <bialix> http://launchpadlibrarian.net/26668118/cmdline.py
[21:19] <Peng_> OK, I think I've got it all worked out, though I've never fully put it together.
[21:19] <bialix> jam: my public branch is wonky 'coz I don;t have public branch
[21:20] <jam> hmm... using python25 I get:
[21:20] <jam> NameError: global name 'WINFUNCTYPE' is not defined
[21:20] <Peng_> beuno: You want the rich version of trunk to be called "trunk-rich"?
[21:20] <jam> ah, I know why
[21:20] <jam> just a sec
[21:20] <beuno> Peng_, I... don't care as much  :)
[21:20] <jam> k, I get:
[21:20] <bialix> C:\Temp>python -V
[21:20] <bialix> Python 2.5.4
[21:21] <jam> C:\Users\jameinel\dev\bzr\patches>C:\Python25\python cmdline.py جوجو
[21:21] <jam> ['cmdline.py', '????']
[21:21] <jam> [u'cmdline.py', u'\u062c\u0648\u062c\u0648']
[21:21] <jam> (I was accidentally just using 'python' which would be cygwin python)
[21:21] <jam> Anyway, I get [] in the console
[21:21] <jam> but it does seem to support those characters
[21:21] <bialix> the same here
[21:21] <jam> even if Lucida Console can't draw them
[21:21] <bialix> yep
[21:21] <jam> interestingly enough, I've already set my cygwin shell to use Lucida Console
[21:22] <jam> Though in that shell
[21:22] <jam> I can't write Arabic characters
[21:22] <jam> weird
[21:22] <bialix> IIRC in Vista there is another shell font used
[21:22] <jam> (chcp is also not found)
[21:22] <jam> bialix: there are only 2 choices
[21:22] <jam> Lucida, and RAster
[21:22] <jam> Raster
[21:23] <jam> just interesting that cygwin.bat mutates its shell enough
[21:23] <Peng_> beuno: Wait, you used "rich-trunk". Anyway, *I* like "trunk-rich". :P
[21:23] <bialix> IMO raster is non-unicode
[21:23] <beuno> Peng_, you've earned the right to name it whatever floats your boat
[21:23] <bialix> jam: yes, cygwin does wonly things
[21:25] <Peng_> beuno: Hehe, okay.
[21:26] <bialix> jam: just curious: how you type Arabic on Windows?
[21:26] <bialix> alt codes?
[21:29] <Peng_> beuno or anyone interested: Here's the sequence of commands that should do it: http://paste.pocoo.org/show/117139/
[21:29] <Peng_> It's not even that crazy.
[21:29] <beuno> Peng_, so it's done?
[21:30] <beuno> thanks for that, btw
[21:30] <Peng_> beuno: I haven't actually done it yet. I could, though!
[21:30] <Peng_> beuno: Do you want me to?
[21:30] <beuno> Peng_, yes!
[21:30] <beuno> go for it
[21:30] <beuno> let me know if I need to change the dev focus
[21:30] <beuno> or if you can
[21:30] <jam> bialix: no, I have an alternate keyboard layout
[21:30] <jam> and switch between them
[21:30] <jam> Alt+Shift+0 == arabic
[21:31] <jam> Alt+Shift+1 == qwerty
[21:31] <jam> Alt+Shift+2 == dvorak
[21:31] <Peng_> beuno: I've never done it before, but I probably can. Thanks, I'll ask you if I need to.
[21:31] <bialix> ok, I understand
[21:31] <jam> argh.... it seems when I contacted support to get my internet access working, they disabled my email account because I claimed not to use it
[21:31] <jam> which I don't
[21:31] <jam> but I use their server to forward my home email
[21:31] <jam> (relay)
[21:32] <Peng_> Whoops, I left that bzr upgrade over bzr+ssh running. It's at 56 MB of bandwidth and like 2/3 of the way through! :D
[21:36] <bialix> jam: do you want more unicode testing from me?
[21:38] <jam> bialix: I don't know any more I need right now
[21:38] <jam> I'll play with it a bit and let you know
[21:38] <bialix> thank you
[21:39]  * bialix going offline
[21:39] <bialix> bye
[21:41] <rockstar> abentley, I don't see a way to get a branch's repository format.
[21:42] <Peng_> Um, hmm. I may have just made lp:loggerhead stack on itself. Or something equally untoward. Oops.
[21:43] <abentley> rockstar: branch.repository._format ?
[21:54] <Peng_> beuno & mwhudson: lp:loggerhead has been upgraded to rich-roots. Here's the final list of commands, if I copied them down correctly: http://paste.pocoo.org/show/117145/
[21:54] <Peng_> ...I guess I should upgrade my local branches.
[21:55] <Peng_> Wait, you upgrade stacked-on before stacked branches, right?
[21:55] <beuno> the other way around  :)
[21:56] <Peng_> Oh, oops. OK, easy to fix.
[21:57] <beuno> hrm
[21:57] <Peng_> Yep, uh, that went disastrously.
[21:57] <beuno> branches still seem to work
[21:58] <beuno> https://code.edge.launchpad.net/~mwhudson/loggerhead/which-mainline-merged
[21:58] <Peng_> They're explicitly stacked on lp:~loggerhead-team/loggerhead/trunk, and hopefully that won't get changed.
[21:59] <beuno> well, the UI is wronk then
[21:59] <beuno> but yes
[21:59] <beuno> \o/
[21:59] <beuno> success!
[21:59] <beuno> Peng_, you've solved a very complicated problem for Launchpad
[21:59] <beuno> I will make sure you get a tshirt
[21:59] <beuno> please email me your address  :)
[22:00] <james_w> hey thumper
[22:00] <mwhudson> yeah, unfortunately stacked on is done by url on launchpad, not branch identity
[22:00] <Peng_> mwhudson: That's a good thing for us here.
[22:01] <james_w> launchpad has foxed me
[22:01] <thumper> hey james_w
[22:01] <james_w> https://code.edge.launchpad.net/~ubuntu-branches/
[22:01]  * thumper looks
[22:01] <james_w> I'm pretty sure these are supposed to be stacked
[22:01] <beuno> mwhudson, that's a good think  ;)
[22:01] <james_w> but apparently they aren't
[22:01] <Peng_> beuno: A t-shirt? For reals?
[22:01] <james_w> they're not development-rich-root
[22:01] <beuno> Peng_, absolutely!
[22:02] <mwhudson> so the thing to do now is upgrade all the stacked-on branches, then do the trunk switcheroo ?
[22:02] <thumper> james_w: lemmie check it out
[22:02] <james_w> thumper: if you can confirm that they're not stacked then I'll check my code
[22:03] <Peng_> Hmm, I'm not sure what users should do now. I guess they should upgrade to rich-roots then pull --remember lp:loggerhead again. That's a bit of a pain.
[22:03]  * beuno sents Peng_'s instrucitons to the list
[22:03] <thumper> james_w: I was just looking at the stacking code earlier
[22:03] <Peng_> And, since I went to effort to avoid violently breaking their branches, they'll never know they need to do it...
[22:04] <thumper> james_w: I think there needs to be a branch associated with the development version of the source package
[22:04] <thumper> james_w: and then that is used to stack
[22:04] <thumper> james_w: yes not stacked
[22:04] <james_w> yeah, I've tried to ensure I push and link the development focus branch first
[22:04] <Peng_> mwhudson: I guess so. You don't *need* to do a switcheroo, though; I'm not sure what would be best.
[22:04] <james_w> ok, thanks
[22:04] <thumper> james_w: the UI would say if it was
[22:05] <thumper> james_w: if it isn't stacking it is a bug
[22:05] <james_w> I fear that I have just done a naïve push, when I should do a push that optionally stacks
[22:05] <thumper> james_w: is your script using bzrlib? or shell to push?
[22:05] <james_w> bzrlib
[22:06] <thumper> james_w: it is possible then that you aren't pushing with the stacking policy
[22:06] <james_w> yeah
[22:06] <thumper> james_w: as the remote site (launchpad) suggests a stacking branch
[22:06] <thumper> james_w: but it is up to the client to use it
[22:06] <thumper> which it normally does
[22:06] <mwhudson> Peng_: well, you need to change the stacked on branch 'as' you upgrade
[22:07] <Peng_> mwhudson: Ooh, that sounds frightening.
[22:07] <Peng_> Hum.
[22:08] <mwhudson> https://code.edge.launchpad.net/~mwhudson/loggerhead/which-mainline-merged is now stacked on the right thing
[22:09] <mwhudson> but i had to fix it with sftp
[22:09] <Peng_> I'm nuking and repushing my one stacked branch, but it was already broken anyways.
[22:09] <Peng_> That's unideal.
[22:09] <mwhudson> yeah
[22:09] <Peng_> mwhudson: The easiest solution is leaving old branches  with plain roots.
[22:10] <mwhudson> yeah
[22:10] <Peng_> Crap, the branch is still broken. Never mind about stacking it, then.
[22:10] <mwhudson> but it would be good to have a non sucky way of upgrading your launchpad branch if you wanted to
[22:10] <Peng_> Yeah, I didn't think of that. :\
[22:10] <mwhudson> i guess there's a plugin in our collective future!
[22:11] <james_w> it's pretty annoying that you have to reimplement the logic of push if you want to push a branch
[22:11] <james_w> and means that your code can get out of date
[22:12] <mwhudson> i guess you can do get_command('push').run(...)
[22:13] <mwhudson> (or however that's spelt)
[22:16] <beuno> ok, I'mm all set up to be rich and root
[22:18] <Peng_> And this encouraged me to fix my broken stacky branch. :)
[22:19] <beuno> win-win
[22:19] <lifeless> moin
[22:19] <lifeless> beuno: yes
[22:19] <lifeless> beuno: -Dhpss triggers it
[22:19] <lifeless> beuno: end users will only be using -Dhpss on request
[22:20] <jelmer> lifeless: moin
[22:20] <jelmer> lifeless: I would be careful with the dulwich git repo, it's generated by dulwich not by git itself
[22:20] <beuno> lifeless, WFM. I like that you're putting the pressure on. How can I help?  filing bugs when I see VFS calls?
[22:20] <Peng_> Of course, due to bug whatever-it-is, the web page for lp:loggerhead won't show the new format until someone pushes to it...
[22:21] <jelmer> lifeless: the client that pushed it was bzr-git with dulwich I mean, not sure how much post-processing the server does
[22:21] <lifeless> beuno: you'll usually see them on lp when lp isn't running $today
[22:21] <jelmer> lifeless: actually, scrap that
[22:21] <jelmer> lifeless: as the server would generate a new pack when you clone it
[22:21] <lifeless> beuno: e.g. bug filing isn't very useful, you need to be running alpha server <-> nightly
[22:21] <jelmer> lifeless: please ignore the last 7 lines from me ^
[22:22] <lifeless> jelmer: :)
[22:22] <lifeless> jelmer: you send a pack, the server keeps it and can do as it wishes :)
[22:22] <beuno> lifeless, gotcha. I may be able to do that with my office server, but I don't use it much these days. Maybe I can do a few tests and file them based on that (server runs nightlies)
[22:22] <lifeless> jelmer: did you think about another project I can test with
[22:23] <lifeless> beuno: sure, its mainly for spiv and I to make 'X is slow' from a user easier to diagnose
[22:23] <lifeless> beuno: e.g. jelmers 'pushing cross-format is slow' [which is caused by IDS]
[22:24] <lifeless> beuno: I don't object to you filing bugs, but be prepared for most to be either dups, or wishlist (because we're not aiming at e.g. 'bzr log lp$FOO' to be VFS free in this cycle
[22:24] <jelmer> lifeless: you could try with etckeeper and the bzr etckeeper clone on staging that michael made
[22:24] <lifeless> mwhudson: where is this thing
[22:25] <jelmer> lp:~vcs-imports/etckeeper/trunk IIRC
[22:25] <jelmer> and git://git.kitenet.net/etckeeper
[22:25] <beuno> lifeless, my feelings won't get hurt, just trying to see how I can help. Maybe ping you/spiv before filing?
[22:25] <mwhudson> it's gone now i guess
[22:25] <lifeless> beuno: sure
[22:25] <lifeless> beuno: data is good
[22:25] <jelmer> lifeless: just install bzr-git and clone that git URL (-:
[22:26] <Peng_> Uh-oh, LP broke my mirrored branches, since they're still stacked on the non-rich-root loggerhead branch.
[22:26] <jelmer> lifeless: or http://people.samba.org/bzr/jelmer//etckeeper/trunk
[22:26]  * beuno hides
[22:26] <lifeless> jelmer: is that cronn'd?
[22:27] <mwhudson> Peng_: oh god
[22:27] <jelmer> lifeless: no, it's only kept up to date as I need it
[22:27] <Peng_> This may have been a bad plan. :D
[22:28] <Peng_> Well, the only problem is you have to change the stacked-on location. Which is definitely a problem on LP...
[22:29] <jelmer> lifeless: also, I think I found a bug in CHKMap..
[22:29] <mwhudson> Peng_: well, it probably makes sense to make the dev focus the new branch
[22:29] <mwhudson> but argh argh argh, no way to win
[22:31] <Peng_> mwhudson: The dev focus is the new branch.
[22:32] <mwhudson> Peng_: i think the next time your mirrored branches are updated, they will be stacked on the new branch tehn
[22:32] <Peng_> mwhudson: They aren't.
[22:33] <lifeless> jelmer: kinda needs the same DAG to be a vaguely fair test
[22:34] <jelmer> lifeless: bzr-git keeps the dag
[22:34] <mwhudson> Peng_: "Last mirrored:  	5 hours ago"
[22:34] <lifeless> jelmer: yes, but your copy isn't kept up to date, or so you just said
[22:35] <jelmer> lifeless: I'm not sure I follow what that has to do with the DAG
[22:35] <jelmer> lifeless: or are you looking at setting up some system to do continuous performance comparisons?
[22:35] <lifeless> jelmer: no, I'm just doing adhoc ones now
[22:36] <Peng_> mwhudson: Some of them have been mirrored.
[22:36] <lifeless> jelmer: but if http://people.samba.org/bzr/jelmer//etckeeper/trunk is days or weeks old
[22:36] <mwhudson> Peng_: got an example?
[22:36] <lifeless> then its rather unfair to git
[22:36]  * mwhudson digs out the code
[22:36] <jelmer> lifeless: I just pushed to it, so it should be current atm
[22:36] <lifeless> jelmer: also is your copy in dev6, and has a smart server?
[22:36] <Peng_> mwhudson: https://code.edge.launchpad.net/~mnordhoff/loggerhead/333797-debug-print
[22:37] <jelmer> lifeless: no, neither
[22:37] <lifeless> jelmer: :( I know the results already then ;)
[22:37] <lifeless> jelmer: however, I'll push a dev6 version to lp to test with
[22:37] <lifeless> so whats this bug
[22:38] <jelmer> lifeless: patch is on the way
[22:38] <mwhudson> Peng_: i think i'm going to take up crying as a hobby
[22:38]  * lifeless consoles mwhudson 
[22:41] <Peng_> mwhudson: Be sure to drink lots of fluids!
[22:41] <Peng_> Sorry about this.
[22:42] <beuno> Peng_, I've said it before, but you're a fantastic test suite
[22:42] <mwhudson> Peng_: not you fault, we were going to hit this sooner or later
[22:42] <lifeless> oh, did beuno upgrade to rich root?
[22:43] <beuno> lifeless, Peng_ did!
[22:43] <Peng_> :D
[22:43] <lifeless> Peng_: :)
[22:43] <james_w> Peng_, beuno: you rock
[22:43] <jelmer> lifeless: Another good test project might be samba if you're interested in trying something larger
[22:43] <jelmer> lifeless: I don't think there's a lot of projects that keep mirrors in bzr *and* git as part of their daily workflow though
[22:43] <lifeless> jelmer: bzr mirror with same dag of same ?
[22:43] <jelmer> lifeless: Yeah, just give me a few minutes to update the bzr mirror and push it
[22:44] <james_w> beuno: though your instructions require renaming a project branch to a junk branch in the UI?
[22:44] <lifeless> jelmer: also re: being careful of dulwich, seems to me that something hosted on e.g. gitorious is kindof required to keep the repo in good order for the users
[22:44] <Peng_> james_w: It's to get around LP's default stacking policy.
[22:44] <james_w> yeah
[22:44] <lifeless> any benchmark that starts 'now run repack --max-window --max-delta' ...
[22:44] <lifeless> ;)
[22:44] <lifeless> is broken
[22:44] <james_w> it's just the option to do that might be removed from the UI
[22:44] <beuno> james_w, yeah, and jml may remove that, but may also provide an API
[22:44] <jelmer> lifeless: Yeah, as I mentioned I don't think my comment earlier was valid
[22:45] <james_w> beuno: oh good, you're aware of it
[22:45] <jelmer> lifeless: If you were comparing local bzr and a local git repo created using dulwich it would be a different story
[22:45] <Peng_> james_w: ...That'd be unfortunate, I guess.
[22:45] <beuno> jml, ^^^^
[22:46] <lifeless> jelmer: dulwich doesn't generate optimal packs you mean?
[22:46] <jelmer> beuno: so what do I do now with my local loggerhead branches?
[22:46] <beuno> jelmer, either upgrade it to 1.9-r-r, or re-branch
[22:46] <beuno> you have a nice --recurse plugin for upgrade
[22:46] <beuno> which I used  :)
[22:46] <Peng_> jelmer: Plus, "bzr pull --remember lp:loggerhead" again; it's moved.
[22:47] <jelmer> lifeless: It should but might not perform as well for some reason.
[22:48] <jelmer> lifeless: I haven't verified that it generates packs as optimal as regular git. I know it generates valid packs though.
[22:50] <jelmer> beuno: thanks
[22:52] <jml> beuno: renaming a project branch to a junk branch?
[22:53] <beuno> jml, yes, and visa-versa
[22:54] <jml> beuno: yeah, so we'll add an API for that -- what's the use case?
[22:54] <beuno> jml, read the bzr mailing list
[22:54] <beuno> the "upgrade story"   :)
[22:55] <jml> it's already sounding uncompelling :)
[22:56] <beuno> jml, .
[22:56] <beuno> jml, At the same time, and only because I know lp won't have been getting
[22:56] <beuno> people to stack as there was only a 'mirrored' copy, it is migrating
[22:56] <beuno> directly to --development-rich-roots.
[22:56] <beuno> er
[22:56] <beuno> fail
[22:56] <beuno> http://paste.pocoo.org/show/117145/
[22:56] <beuno> that's what I get for selecting textg when reading
[22:57] <beuno> and linux clipboard stupidness
[22:57] <jam> beuno: I replied to you message, btw
[22:57] <jam> There is a bit of LP renaming trickery that you don't really need
[22:57] <beuno> jam, I saw
[22:57] <beuno> jam, part of the renaming
[22:58] <beuno> is to keep merge proposals and bugs linkage
[22:58] <jam> I suppose you might have to do something to avoid the recursive stacking problem
[22:58]  * beuno hasn't replied because he wants to vreify first
[22:58] <jam> beuno: oh, so you want bugs linked to .../trunk to now be linked to .../trunk-rich ?
[22:59] <beuno> jam, yeap
[22:59] <beuno> merge proposals, more importantly
[22:59] <beuno> subscriptions, etc as well
[23:00] <Peng_> jam: Pushing to +junk avoids the default stacking policy; that's the workaround I used.
[23:00]  * Peng_ fires up an email client
[23:01] <lifeless> Peng_: except renaming is about to be disabled ;)
[23:01] <lifeless> jml: ^ :P
[23:01] <jml> lifeless: yes.
[23:02] <jml> it'd be nice if bzr had an option to ignore the default stacking policy
[23:02] <lifeless> thumper: btw, lp:pqm was already 1.6 branch and repo; stackable.
[23:02] <lifeless> thumper: its because trunk wasn't hosted.
[23:03] <thumper> lifeless: that shouldn't matter
[23:03] <lifeless> thumper: ok
[23:03] <lifeless> thumper: mirrored branches don't have a private copy though
[23:03] <thumper> lifeless: I know
[23:03] <lifeless> thumper: so bzr+ssh can't stack locally
[23:03] <thumper> lifeless: trust me on this, it is tested
[23:04] <thumper> lifeless: we have custom transports
[23:04] <lifeless> ok
[23:06] <lifeless> question; how can I change https://code.edge.launchpad.net/%7Elifeless/pqm/trunk/+edit to be hosted
[23:06] <thumper> you can't
[23:06] <lifeless> I deleted the (optional) Branch URL
[23:06] <jam> lifeless: delete it and push ?
[23:06] <lifeless> jam: that deletes all the active merge proposals
[23:07] <lifeless> and bug links
[23:07] <jam> lifeless: shiny
[23:07] <lifeless> the former is valuable, the latter would be nice but is less valuable
[23:07] <lifeless> jam: in fact, I'm not even sure one can delete it with active merge proposals
[23:07] <jam> So it sounds like it falls back to "you can't"
[23:07] <lifeless> thumper: please advise
[23:08] <jam> Since I don't think there is any way to promote a mirrored branch to a hosted branch without deleting it
[23:08]  * lifeless tries just pushing anyway
[23:08] <jam> lifeless: you could rename it out of the way
[23:08] <jam> then everything ends up linked to the wrong thing
[23:08] <jam> but at least they are still there
[23:08] <lifeless> ah, readonly transport
[23:08] <james_w> Stacked on:  	 lp:ubuntu/karmic/asio
[23:09] <james_w> jml: I'm sorry I ever doubted you :-)
[23:09]  * thumper on a call
[23:10] <james_w> jml: https://code.edge.launchpad.net/~ubuntu-branches/ <- I'm going to kick of a big run tonight if that looks good to you
[23:10] <Peng_> jam: BTW, I tried having a team +junk branch; it was rejected.
[23:11] <jam> jml: ^^ what happened with that?
[23:11] <jam> Only on the staging server?
[23:11] <Peng_> That's entirely possible.
[23:11] <james_w> team's aren't allowed junk branches are they?
[23:12] <jml> they have been recently
[23:12] <james_w> ah
[23:12] <jam> Peng_, jml: http://code.mumak.net/2009/03/team-junk-branches.html
[23:12] <jml> but our branch creation policy code is in a few too many places.
[23:12] <Peng_> Well, I ran into that wall on the branch description page where I renamed it.
[23:12] <jam> btw jml, I want my bubble domes
[23:13] <Peng_> Bubble domes?
[23:13] <jml> Peng_: yeah, that makes a *lot* of sense.
[23:13] <jml> Peng_: the edit form had completely different set of logic.
[23:13] <jam> Peng_: read ^^, but it refers to a Simpson's episode, and talks about "not all designs are good ones"
[23:13] <jam> Such as "Separate Bubble Domes" on a vehicle
[23:14] <lifeless> oh yes
[23:14] <lifeless> it was hilarious episode
[23:15] <Peng_> I see.
[23:15] <Peng_> Not that there's anything wrong with it, but I've only seen a couple episodes of The Simpsons.
[23:17] <Peng_> jml: The Wikipedia image link in that post is broken.
[23:41] <mwhudson> Peng_: when did you upgrade your bzr.mattnordhoff.com branches?
[23:41] <poolie> hello all
[23:41] <poolie> jam, still around?
[23:42] <Peng_> mwhudson: Um. 20:55 -- ~1h45m ago.
[23:43] <Peng_> mwhudson: (Which is a few minutes after I upgraded lp:loggerhead.)
[23:44] <mwhudson> Peng_: ok
[23:45] <mwhudson> Peng_: this is really odd
[23:45] <mwhudson> Peng_: some of your branches are ok
[23:45] <mwhudson> e.g. https://code.edge.launchpad.net/~mnordhoff/loggerhead/new-style-classes
[23:47] <Peng_> mwhudson: Huh. You're right, that is bizarre.
[23:48] <Peng_> It looks like that branch was last mirrored right after I made the change.
[23:48]  * Peng_ shrugs.
[23:48] <Peng_> Maybe things'll work out in a few hours?
[23:49] <Peng_> mwhudson: Maybe some of my branches got caught in between the upgrade and lp:loggerhead getting renamed or something.
[23:49] <mwhudson> Peng_: yeah, that's my theory (hope!)
[23:49] <Peng_> Heh, right.
[23:50] <mwhudson> jelmer: please stop registering huge mirrored branches on launchpad for the moment
[23:50] <gutworth> how can I change my working copy back to an old version?
[23:50] <mwhudson> jelmer: it won't work and causes us problems
[23:50] <mwhudson> jelmer: (i'll fix it soonish)
[23:51] <mwhudson> gutworth: bzr revert -r -3
[23:51] <gutworth> ah
[23:52] <gutworth> I was messing around with checkout and switch
[23:52] <mwhudson> checkout and switch are to do with the relationship of working tree and branch
[23:52] <mwhudson> revert is a pure wt think
[23:52] <mwhudson> *thing
[23:53] <Peng_> mwhudson: One branch was remirrored just now, and it went correctly.
[23:53] <mwhudson> Peng_: ah, that was the one i hit try again on
[23:53] <mwhudson> Peng_: phew!
[23:53] <Peng_> Oh, heh.
[23:53] <mwhudson> i was really confused there
[23:54] <Peng_> I guess you can give up the crying, then? :D
[23:55] <mwhudson> somewhat
[23:55] <Peng_> Mind if I hit retry on the rest of the branches?
[23:55] <mwhudson> Peng_: go ahead
[23:56] <Peng_> Oh, good, there were only 3 left.
[23:56] <gutworth> is there a command line way to disable lazy import?
[23:57] <jelmer> mwhudson: ok
[23:57] <Peng_> gutworth: I don't know of one.
[23:57] <mwhudson> jelmer: thanks
[23:57] <mwhudson> gutworth: no
[23:57] <jelmer> mwhudson: feel free to remove whatever mirrored branches are there now from me if you have some automated way of doing so
[23:58] <Peng_> beuno: So, is the t-shirt thing still on? :D
[23:58] <beuno> Peng_, of course!
[23:58] <beuno> send me your address!
[23:58] <jelmer> mwhudson: (I have a plugin that automatically registers stuff if I push it to samba.org, have disabled that now)
[23:58] <mwhudson> jelmer: nah, they'll get disabled after a few tries
[23:59] <mwhudson> jelmer: thanks
[23:59] <mwhudson> jelmer: i'll let you know when it's safe again :)
[23:59] <Peng_> beuno: Are they shipped from somewhere in the U.S.?
[23:59] <beuno> Peng_, or the UK, not sure