#bzr 2008-06-16
<igc> more info later
<lifeless> igc: thank you!
<igc> bbl - few errands to run
<bpeterson> are there plans to add svnmerge.py-like merge blocking to Bazaar?
<lifeless> 'merge blocking' ?
<poolie> spiv_: are you coming down to the vibe too?
<bpeterson> sort of like bzr merge --record-only
<bpeterson> just a little nicer
<lifeless> what would it do differently
<bpeterson> I'd like to be able to run bzr block [revision] and bzr unblock [revision]
<beuno> lifeless, you rock, open_index_branch solved all my problems
<beuno> pushing a more usable branch now  :)
<lifeless> thats fantastic
<lifeless> Jc2k: have you chatted with beuno about what you wanted for loggerhead @ gnome ?
<Jc2k> lifeless: not
<beuno> Jc2k, feel free to whenever you want
<Jc2k> ythx beuno, neet a while to come round..
<beuno> lifeless, pushed LH + search changes. It now needs code to index the branches and do something reasonable if it hasn't been indexed yet
<lifeless> I would reverse the order there :P
<lifeless> beuno: e.g. do something reasonable is first thing
<beuno> mwhudson, now that I got this off my mind, I'm going to start removing revision caches, unless you think there is something else on the top of the list
<lifeless> bbiab, -> train
<beuno> lifeless, right, seems reasonable  :p
<mwhudson> beuno: no, that seems like a good thing to do
<jelmer> 'evening
<mwhudson> hi jelmer
<beuno> mwhudson, lp:~beuno/loggerhead/remove_caches
<beuno> I think I covered everything
<beuno> removed revision and full text caches
<beuno> just left the files changes one
<beuno> would you like me to send that in as a patch to the list?
<beuno> I'm going to go back to the clean url branch and tweak a few places where it still uses revids
<Noia> if I want to run bzr update without CD-ing into the directory, how would I do that?
<Peng> "bzr update some/directory"?
<Noia> hmm, cool
<thumper> where is the official 1.4 branch?
 * thumper can't find it
<Peng> Bazaar 1.4?
<Peng> http://bazaar-vcs.org/bzr/
 * Peng wanders off.
<thumper> Peng: ofcourse, thanks
<thumper> I was looking on LP
<poolie> thumper: really 1.4?
<poolie> back btw
<thumper> poolie: I'm looking for the version where pqm stopped working
<poolie> and did you find it?
<poolie> uh it's not there
<poolie> i'll register it
<poolie> hey the lp ui for this is now pretty understandable :)
<poolie> done
<poolie> thumper: interesting, someone still using bzr 0.90 (which is pretty old) got confused in trying to use an lp: url to push to launchpad
<thumper> poolie: yeah, saw it
<thumper> poolie: somewhere between 1.4 and 1.5 the function that pqm uses in its tests was removed
<spiv_> thumper: which function?
<thumper> spiv: https://bugs.edge.launchpad.net/pqm/+bug/240288
<ubottu> Launchpad bug 240288 in pqm "PQM tests do not support bzr 1.6" [Undecided,New]
<thumper> cannot import name smart_add_tree
<jamesh> thumper: you probably want tree.add()
<jamesh> or tree.smart_add(), actually
<thumper> are we going to kill support for older bzr versions by changing to that?
<thumper> and do we care?
<jamesh> they can use old versions of PQM, right? :)
<spiv_> What jamesh said.
<spiv> thumper: pre 1.0 versions I'd expect
<spiv> thumper: MutableTree.smart_add has been present since at least 0.18rc1
<thumper> ok
<thumper> I'll look to fix this then :)
<thumper> although perhaps tonight
<lifeless> beuno: so how does it perform sans cache?
<igc> hi guys
<igc> poolie: did you want a call today?
<beuno> lifeless, yeap, revision cache was only useful for old versions of bzr
<beuno> it's very nice to bring up LH and now have it kill my CPU until it caches all the revisions
<lifeless> 'not' ? :P
<beuno> heh, yes, "not"
<beuno> I finally bought a wireless router for my place, so I'm experimenting with new places to work
<beuno> hence my increased typos  :)
<lifeless> nice
<beuno> as for caches, the only remaining one is one for files changed, which only gets filled when needed
<beuno> the difference between having it and not is still too big
<lifeless> k
<lifeless> lunch apparently, bbiab
<igc> poolie: am I right to merge the rules-based preferences stuff or do you want to wait until after stacked branches and VFs land?
<thumper> igc: is that abentley's stuff?
<igc> thumper: no, part of my work on end of line support
<thumper> igc: ah, ok
<thumper> igc: how are the stacked reviews going?
<igc> thumper: I did a round of them last week and poolie/jam/others have been reviewing my reviews
<thumper> :)
<thumper> quite a lot of lines as I understand it
<igc> yeah - and the VersionedFiles stuff is another 17k worth of patch
<igc> many deletions in there though (which is good of course)
 * thumper nods
<lifeless> back
<lifeless> more trains...
<bob2> from chatswood?
<Peng> Canonical needs to start supplying teleporters.
<thumper> Peng: that would be handy
<Peng> Bazaar t-shirts are nice, but teleporters would be *awesome*.
<igc> night all
<spiv> igc: g'night
<lifeless> bob2: milsons point
 * Jc2k vaguely remembers IRC at sleepy o clock
<Jc2k> bueno: my main interest is theming loggerhead so that it has the GNOME look you can see at http://bzr-mirror.gnome.org/
<Jc2k> lifeless: would you always suggest bzr smart server over vanilla HTTP if its possible?
<Jc2k> i havent enabled it for bzr-mirror.gnome.org yet
<beuno> Jc2k, that should be easy enough. Have you set it up yet?
<lifeless> I would hold off
<lifeless> more in a bit, I have to run
<Jc2k> beuno: i've not yet, i've been scared off by earlier mention of its dependencies
<beuno> Jc2k, we're trimming them pretty quickly, and I'd expect a lot of improvements to go into it in the following weeks
<Jc2k> awesome :)
<beuno> currently, IIRC, it's turbogears, python-sqlite and simpletal
<Jc2k> thats not so bad
<beuno> nah, we just want to make it better  :)
<Jc2k> :)
<beuno> anyway, I'll be happy to help out with getting it running and theming it properly
<beuno> so let me know when you take the plunge
<Jc2k> i'm readying a big bzr-mirror.g.o push
<Jc2k> so soon :)
<beuno> cool, I'm usually around, so just give me a ping
<Jc2k> beuno: where do the  most recent instructions live :)
<beuno> Jc2k, hrm, they don't  :/
<beuno> updating the setup and README is on my ToDo list
<beuno> I'll try and get that done tomorrow and bribe mwhudson into getting that intro trunk, or I'll post it on the bazaar wiki somewhere
<mwhudson> beuno: are you up early or late? :)
<beuno> mwhudson, late. Aaaaaaaaaaalways late
<beuno> (it's a holiday here tomorrow)
<mwhudson> beuno: ah
<Jc2k> beuno: excellent, i wont start just now then :)
<mwhudson> Jc2k: the dependencies will probably shortly change to python-paste rather than turbogears fwiw
<mwhudson> Jc2k: when you talk about a "big push" what's the timeframe?
<mwhudson> a few days, a couple of weeks, ... ?
<Jc2k> as soon as i can, really
<mwhudson> ok
<beuno> mwhudson, trunk + cache removal should work pretty decent for now, no?
<beuno> probably should get that in before the clean URL bit
<mwhudson> yeah, i'm not feeling intelligent enough to review the clean url stuff
<mwhudson> because i think the branch changes behaviour in some ways, but i'm not sure whether it makes more sense before or after :)
<beuno> ah, right, that happend to me too  :)
<beuno> I had to go back and forth a few times before I could tell the differences
<mwhudson> beuno: remove_caches seems to be based on the cleaner urls branch?
<beuno> mwhudson, uhm, yes. Although it shouldn't really change much from trunk, as it doesn't touch templates at all
<beuno> I can send you a patch based off trunk if you'd prefer
<mwhudson> please
 * beuno pets his clean urls branch and starts making use of bzr's magic
 * Jc2k watches
<beuno> mwhudson, sent
<beuno> Jc2k, I'd say it's worth waiting a few days for these changes to settle in. Does that work for you?
<Jc2k> beuno: sure, i'll need at least that long to work out my jhbuild patch with the maintainers
<beuno> Jc2k, cool, I'll make sure I ping you, and help you get through the initial setup  :)
<mwhudson_> beuno: changecache.py looks a bit mangled
<mwhudson_> beuno: in particular i'm pretty sure FakeShelf.close should not look like that :)
 * beuno looks
<beuno> I shouldn't of changes anything for FakeShelf
<beuno> argh
<beuno> vim screwed with me again
<mwhudson_> i also think that bits of fakeshelf can go
<mwhudson_> like update
<Jc2k> beuno: can loggerhead list all of the repositories in a folder, or am i responsible for that?
<Jc2k> (we have a lot of modules, so (2) is probably better?)
<beuno> Jc2k, you can specify a folder and loggerhead looks for al branches in it
<beuno> or, manually
<beuno> as you wish
<mwhudson_> something i am looking to encourage with my rewrite of this end of this things is for serious end users (e.g. gnome) to write little bits of code for this sort of thign
<Jc2k> so if we let loggerhead do it, would it show all branches over *all* projects, or will they be like seperate instances?
<mwhudson> so if you want to have a list of repositories in a text file or something, that should be easy
<mwhudson> Jc2k: not sure i understand what you're asking?
<Jc2k> well, if you look at http://bzr-mirror.gnome.org/
<Jc2k> there are many individual repositories
<Jc2k> and each folder has many branches
<mwhudson> oh right
<Jc2k> how does loggerhead work in this setup, basically :)
<mwhudson> not very well :/
<Jc2k> :D
<beuno> mwhudson, re-sent without the nonsense code and removing update too
<mwhudson> you can point loggerhead at the directory containing the repositories, but the results won't be very pretty
<Jc2k> can i have a loggerhead for each repository?
 * mwhudson hmms
<mwhudson> surely should be possible
<Jc2k> i have a script that is updating the mirrors each time someone checks in to SVN
<Jc2k> can extend it to poke the loggerhead bits too
<Jc2k> and update some kind of master index
<beuno> I wonder how hard it would be to fix LH so it *won't* get confused with multiple levels of branches
<Jc2k> oh, would loggerhead get confused by the SVN style layout?
<mwhudson> beuno: easier on my wsgi-ify branch :)
<Jc2k> e.g. $MODULE/{trunk,brances/$BRANCH,tags/$TAG} ?
<mwhudson> yes, basically
<beuno> mwhudson, heh, well, even more reason to land that ASAP  ;)
<mwhudson> Jc2k: what time is it where you are?
<Jc2k> 10:16 AM
<mwhudson> oh ok, so you'll be around for a bit :)
<Jc2k> yeah :)
<Jc2k> got another 12 hours in me, aside from lunch and commuting :p
<mwhudson> i'll see if i can slap something together you can test
<Jc2k> wicked :)
<mwhudson> beuno: all those lovely -s :)
<mwhudson> beuno: i think i can add a few more though :)
<beuno> heh
<beuno> go crazy
<beuno> the less the merrier!
<mwhudson> man util.Container needs to be stabbed
<beuno> ah, get_revision_history_matching should go to
<beuno> *too
<mwhudson> ah yes
<mwhudson> what happens now for a text search?
<beuno> it always returns "no results found"
<beuno> although, at the rate lifeless's plugin is going, I think we should be able to make that plugable pretty soon
<mwhudson> heh heh
<mwhudson> fair enough :)
<lifeless> beuno: what do you need ?
<beuno> lifeless, for now, just time to work it into LH properly
<beuno> I didn't want to imply that *you* had work left to do  :)
 * mwhudson is confused
<mwhudson> beuno: do you know where fix_year went?
 * beuno looks
<mwhudson> i think i shall use bzr-search to find out :)
<lifeless> :)
<beuno> it seems it's gone in trunk too...  :/
<mwhudson> beuno: right...
<beuno> mwhudson, seems revno 128.18.2
<mwhudson> uh uh uh
<mwhudson> http://pastebin.ubuntu.com/20570/ :(
<lifeless> -lines in patches are not yet indexed
<lifeless> though I think they would be interesting to index
<mwhudson> uh, they sure would be here :)
<mwhudson> beuno: what branch is that revno in?
<lifeless> file a bug :)
<beuno> mwhudson, trunk
<beuno> revid: michael.hudson@canonical.com-20080310040805-sp0j98ristv9znvm
<mwhudson> lifeless: for the bzr-search thing or the bzr traceback?
<mwhudson> beuno: uh, no?
<mwhudson> -    params = { 'file_id': navigation.file_id }
<mwhudson> +    params = { 'filter_file_id': navigation.filter_file_id }
<mwhudson> is all in that revid
<beuno> well, bzr-search is lying then...  :/
<beuno> loggerhead/util.py in revision 'michael.hudson@canonical.com-20080310040805-sp0j98ristv9znvm'. Summary: 'def fix_year(year):'
<lifeless> mwhudson: for - lines
<mwhudson> lifeless: ok
<mwhudson> ah, it was the date formatting changes
<lifeless> beuno: bzr cat -r revid:michael.hudson@canonical.com-20080310040805-sp0j98ristv9znvm loggerhead/util.py | less
<beuno> lifeless, ah, right, it's in the file
<beuno> utils.py was changed at that revision, so it looks in there. Makes sense
<beuno> mwhudson, you found where it was changed?
<mwhudson> beuno: yeah
<mwhudson> beuno: r152
<beuno> oh, a while ago
<lifeless> beuno: it gets false positives where a snapshot occurs
<beuno> ok, I'm starting to make even less sense. It's probably a good idea for me to call it a day
<beuno> Jc2k, I'll read the backlog and see what mwhudson cooked up for you, and we can talk theming once it's up and running   :)
<lifeless> mwhudson: you had a traceback ?
<mwhudson> lifeless: http://pastebin.ubuntu.com/20570/
<mwhudson> beuno: good night
<Jc2k> good night, beuno
<beuno> g'nights!
<lifeless> mwhudson: file a bug on that traceback too
<mwhudson> oh, it's in before:$invalid_dotted_revno
<mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/240346
<ubottu> Launchpad bug 240346 in bzr ""exceptions.ValueError: get_parent_map(None) is not valid" in before:$invalid_dotted_revno" [Undecided,New]
 * mwhudson merges remove-caches to trunk
<Peng> mwhudson: "if revid_list and len(revid_list) > 0:" <-- Wouldn't revid_list evaluate to false of its length was 0?
<mwhudson> Peng: uh, yes indeed
<mwhudson> oh well, can't get rid of all the cruft in one go i guess :)
<mwhudson> Jc2k: how much do you mind being a guinea pig for half-baked software? :)
<Jc2k> mwhudson: as long as it runs uninstalled, then i know no limits
<mwhudson> good good
<Jc2k> did i mention the server is running etch..
<mwhudson> can you get simpletal and paste installed?
<mwhudson> or at least on $PYTHONPATH?
<Jc2k> i havepython-paste 1.0.1-1
<Jc2k> and simpletal 4.1-6
<mwhudson> great
<tro> lifeless: about the error i was getting before ("bzr: ERROR: Repository KnitPackRepository('https://myusername@server.org/bzr/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/tro/code/asdf/.bzr/repository/')"), yes, i ran bzr info -v on the branch repo i'm pushing to. it's as i posted before
<lifeless> tro: thats really strange then.
<lifeless> tro: I'm a little tied up now, perhaps you could file a question on launchpad and I'll put together some python to try and diagnose this in more detail
<tro> lifeless: will do. thanks for helping so far. :)
<mwhudson> grr
<mwhudson> time to add DontZap to the x config again...
<mwhudson> Jc2k: ready to test something? :)
<Jc2k> mwhudson: go on then
<mwhudson> Jc2k: grab this branch https://code.edge.launchpad.net/~mwhudson/loggerhead/wsgi-ify
<mwhudson> Jc2k: and run it from the directory that contains the repositories
<mwhudson> then browse to port 9876
<kilner> hi, I'm running a bzr checkout of an svn repo, I made 2 local commits and then updated.  Is there a way to "reapply" the pending merges that it has created so that I can do an svn-push or similar.
<kilner> basically I want to save the commits and their logs as separate entities
<Jc2k> mwhudson: i need turbogears?
<mwhudson> Jc2k: i hope not :)
<Jc2k> pkg_resources.DistributionNotFound: TurboGears
<Jc2k>   File "/home/john/wsgi-ify/start-loggerhead.py", line 4, in ?
<Jc2k>     pkg_resources.require("TurboGears")
<mwhudson> Jc2k: oh
 * Jc2k removes said require :)
<mwhudson> don't run start-loggerhead
<mwhudson> sorry
<Jc2k> oh
<mwhudson> run path/to/loggerhead/wsgitest.py
<mwhudson> sorry, it's getting a bit later here
<Jc2k> hehe
<Jc2k> my paste is too old
<Jc2k> i guess
<Jc2k>   File "/usr/lib/python2.4/site-packages/paste/translogger.py", line 100, in make_filter
<Jc2k>     from paste.deploy.converters import asbool
<Jc2k> ImportError: No module named deploy.converters
<Jc2k> or rather
<Jc2k> my paste is broken
<mwhudson> maybe you need paste.deploy installed?
<mwhudson> but yeah
<Jc2k> ahh, python-pastedeploy :)
<Jc2k> does it only serve on localhost?
<mwhudson> hm, looks like it :)
<mwhudson> change the host='127.0.0.1' to ... something
<mwhudson> at the end of the file
<Jc2k> kk :)
<mwhudson> i guess host='' will work
<mwhudson> hm maybe an external ip would be better
<Jc2k> i had to put host='bzr-mirror.gnome.org'
<Jc2k> http://bzr-mirror.gnome.org:9876/
<lifeless> or host=* perhaps
<mwhudson> Jc2k: oh, you want to remove the EvalException wrapper btw
<Jc2k> wassat?
<mwhudson> sorry meant to remove that before committing...
<mwhudson> Jc2k: insecure debugging aid :/
<lifeless> well, its plain, but its there :P
<mwhudson> yeah, the file listing is, uh, simple
<lifeless> what branch is Jc2k running?
<lifeless> http://bzr-mirror.gnome.org:9876/yarrr/trunk/changes?q=walters didn't do much :P
<mwhudson> lifeless: https://code.edge.launchpad.net/~mwhudson/loggerhead/wsgi-ify
<Jc2k> mwhudson: where is this wrapper i need to delete :)
<mwhudson> oh, i didn't merge remove-caches either
<mwhudson> Jc2k: http://pastebin.ubuntu.com/20594/
<Jc2k> ahh
<Jc2k> :)
<Jc2k> cool :)
<mwhudson> so this is all totally horrible code, but it works, eh?
<Jc2k> seems so :)
 * mwhudson is practising his kiwi dialect
<Jc2k> i can kill it, though :)
<Jc2k> http://bzr-mirror.gnome.org:9876/tracker/branches/indexer-split/revision/svn-v3-trunk0:13f93fa3-e725-0410-a08d-a391da2ecc01:branches%2Findexer-split:1537?start_revid=svn-v3-trunk0:13f93fa3-e725-0410-a08d-a391da2ecc01:branches%2Findexer-split:1537
<mwhudson> hm, urlquoting, what's that?
<Jc2k> hmm?
 * Jc2k pops out for lunch
<mwhudson> i need to be more careful when constructing urls
<Jc2k> :D
<mwhudson> hm, maybe that's not it
<mwhudson> Jc2k: try revision 175 of my branch
<mwhudson> or rather 176
<mwhudson> Jc2k: i'm going to bed soon, but please send any comments to michael.hudson@canonical.com
<semslie> fwiw: kilner (who is sitting next to me) solved his problem with the pending merge by committing the merge, then branching off the resulting tree at the revno just before the merge (the last commit that was a part of the merge), which created a new tree with all the merged revisions as part of the same branch, which meant that an svn-push didn't lump the revisions involved in the merge together.
<lifeless> jelmer: ^;2~
<jelmer> lifeless, hi
<jelmer> lifeless, what's up?
<lifeless> see semslie's note is all, thought it might be relevant to you :)
<jelmer> semslie, what's it exeactly that you were trying to work around?
<semslie> jelmer: when an update comes in on top of local commits, those commits are converted to a pending merge, and you can then commit the merge. That would be fine if everyone in our team was using bazaar - they would still see each individual revision and its changelog as part of a merge. However, when an svn-push happens our subversion colleagues only see the merge-commit: ie: the results of the merge, not each individual change that made it up.
<sven_> hi! after 'bzr merge', when there are conflicts, i get file.THIS, file.BASE, file.OTHER. is there a way to figure out which revision file.BASE is from?
<jelmer> semslie, this is docemented in the FAQ. you may want to use rebase
<semslie> jelmer: we effectively wanted to 'replay' the changes in the pending merge on top of the tree after it had been updated, and we found that this was one way to simulate that behaviour.
<semslie> jelmer: rebase is indeed an excellent tool, but we got worried that we were stuck with a merge once those local revisions had become a pending merge. Would a rebase have resolved the pending merge do you think?
<jelmer> semslie, no, but you can throw away the pending merge with "bzr revert"
<semslie> jelmer: ah, so would rebase replay the changes in the pending merge on top of the new base as well (I had thought that these would not be included)?
<jelmer> semslie, yes
<semslie> jelmer: thanks! giving that a try now
<james_w> sven_: "bzr find-merge-base . .../other_branch" should do it
<matholio> do I need to use a specific verion of bzr to utilise launchpad ?  I have v0.11.0 and am getting... bzr: ERROR: Unknown branch format: ''
<james_w> matholio: which branch?
<matholio> this is the command I used to start one : bzr push sftp://matt-joyce@bazaar.launchpad.net/~matt-joyce/scrabbly/dev
<james_w> and that gives tou the error?
<matholio> It does.
<mwhudson> 0.11.0 is pretty ancient!
<matholio> Debian Etch.
<matholio> Happy to add an apt source.  is there one?
<james_w> matholio: backports
<james_w> matholio: that branch works fine for me
 * mwhudson goes to bed
<james_w> matholio: was it the second push that gave the error?
<matholio> the first push.
<james_w> matholio: can you run again with "bzr -Derror" please?
<matholio> 'no such option: -D'
<james_w> ah, sorry, too old for that
<james_w> can you look in your ~/.bzr.log then, and fish out the relevant section please?
<james_w> you'll find a stanza for each invocation, and near the top is the arguments
<james_w> I'd like the traceback, but the whole staza would probably be enlightening
<matholio> woo, theres a fair amount of stuff...
<matholio> pastebin ?
<lifeless> AfC: http://nixos.org/nixos/ <- you might find that interesting
<AfC> looking
<matkor> Hi ! Is there any bzr executed commands history available ? (per working tree ? ) TIA
<AfC> As yes, nix. I was there when this was first presented at LISA 4 years
<AfC> I have a lot of respect for what they did.
<AfC> It solves a lot of packaging problems.
<AfC> I did point out to them a) that they had effectively taken on the challenge [ie, hassle] of becoming a distro, and
<matholio> http://pastebin.com/m635c8448
<AfC> b) suggested that they might have a look at some of the things the Gentoo does along similar lines.
<AfC> [specifically as related to package description formats]
<AfC> ï»¿Turns out they had studied Gentoo (as it then was, this is some years ago) and agreed that their biggest problem was the fact that they had to reinvent packges from scratch
<AfC> which is a shame. Otherwise, their idea has a *lot* of appeal from the systems operations don't fucking hammer my linking side of things.
<lifeless> cool
<lifeless> matkor: not as such
<sven_> james_w, thanks!
<lifeless> matkor: there is ~/.bzr.log whicn you could post-process
<AfC> [a major theme in large systems being the need to exactly recreate specific environments. Embedding link targets in ï»¿content addressing style leads to an impressive degree of robustness in this regard]
<matholio> james_w: oh dear.  I installed bzr from backports, v1.5 deleted the old .bzr and bzr init a new one.  same error.
<matholio> http://pastebin.com/m214aa475
<matkor> lifeless: thanks !
<matkor> Is it possible to checkout/branch only part of other branch ?  Like checkout only one directory  ? Or checkout only files matching given pattern like *.spec ?
<awilkins> bzr split ?
 * fullermd blinks.
<fullermd> Not really the same thing...
<awilkins> Possibly not, but the closest I could think of
 * matkor reads about bzr split ...
<matkor> not really ...
<matkor> I still want keep files in sync ...
<matkor> Any VCS (except cvs) allows  checkouting only subsets of branches ?
<lifeless> svn
<lifeless> and thats it AFAIK
<lifeless> we have some plans to do so
<fullermd> I presume p4 can.
<lifeless> but have not implemented
<lifeless> fullermd: I assumed FOSS
<fullermd> There's probably one or two of the more obscure CVCSen that can too, but yah, CVS/SVN are AFAIK it for major contenders.
<pygi> lifeless, will that be implemented by hiding the rest of the repo?
 * pygi remembers reading something
<lifeless> pygi: broadly speaking, yes, though s/repo/branch/ and there are some complications on merge/update/pull vis-a-vis conflicts
<matkor> Perhaps wrong place to ask but is svc capable of checkouting only *.txt from repo ?
<lifeless> matkor: that I don't think so
<fullermd> I don't know of anything that can officially do that.
<gour> what is the benefit of doing it?
<fullermd> With CVS, you could do Evil Sh...tuff(tm) behind its back and pull it off I s'pose.  But somebody would have to shoot you for it.
<gour> isn't that task for some other tool and not (D)VCS?
 * pygi thinks he could just list remote branch/repo contents, grep for "*.txt" and then checkout only those files :P
<pygi> but then again, what do I know :)
<gour> ;)
<lifeless> pygi: say a file is in a dir
<lifeless> pygi: do you then checkout the dir? and if not where does the file go if there is a name collision
<pygi> lifeless, well, you checkout the dir with only that file
<gour> pygi: use rsync :-8
<pygi> lifeless, I dont have a use-case for such a thing anyway, so ^_^
<pygi> lifeless, and seem that m-l ate my post about Akademy :-/
 * gour thinks bzr dev-time should be spent on more useful stuff
<matkor> I am just thinking of (D)VCS as alternative to cvs keeping rpms build data (spec, patches, data, or even sources)  for many projects ...
<lifeless> matkor: the usual suggestion for that is to do one branch per project
<matkor> But still be able to do mass operations over all *.SPECS
<pygi> matkor, Ubuntu does that for some packages
<pygi> lifeless, ++
<pygi> gour, hehe :)
<lifeless> matkor: and nested trees to tie the configuration together
 * matkor reads about nested trees ...
<matkor> is http://bazaar-vcs.org/NestedTreeSupport current status of nested trees ?
<pygi> matkor, I'd say that is a specification from year 2005
<pygi> :)
<pygi> so no, that isnt the status
<Leonidas> uhm, how to get a specific file at revision 94? I'd like to dig into the history and find out why some code is the way it is.
<matkor> bzr cat <file> -r <rev> ?
<Leonidas> just perfect!
<Leonidas> thanks a lot, works exactly as I want
<matkor> OK. Assuming I have <repo_root>/<project>  I can't really see way how to get versioned access to <project>/*.spec without checkouting/branching all projectes ... :/
<matkor> Even using ideas from nested trees ...
<lifeless> gnight
<james_w> matkor: nope, nested trees can't help you to get specific files from a group of projects.
<james_w> night lifeless
<james_w> matkor: it's feasible you could get that with nested trees and partial checkouts at some point, but I don't know whether it would just be a paon.
<james_w> s/paon/pain/
<mdz> is there any way to tell bzr to use a key other than the default (or an agent) for bzr+ssh:// ?
<mdz> if someone tells me, I promise to add it to http://bazaar-vcs.org/Bzr_and_SSH
<james_w> hi mdz
<james_w> bzr will follow ~/.ssh/config, so you can set up anything you want in there.
<james_w> Stanzas including IdentityFile2 is what I use to do this.
<mdz> james_w: lies!  my ~/.ssh/config is set up correctly, and ssh works fine, but not bzr
<james_w> ah wow, can you check that ~/.bzr.log reports it is using OpenSSH?
<mdz> james_w: I will poke about, didn't realize this was supposed to work
<mdz> james_w: my claims of ~/.ssh/config being set up correctly were exaggerated
<mdz> james_w: I politely withdraw the accusation of lying :-)
<mdz> I forgot that branch moved to Launchpad
<james_w> no problem
<Ursus> Is there a way to run a script after running a bzr update, and is there a way of storing the password when using ssh+bzr:// as I need to automate the fetching and moving of some files
<LeoNerd> Use an SSH Key
<Ursus> LeoNerd, ?
<LeoNerd> "storing the password" => set up SSH keys between the boxes
<gour> ssh-agent or keychain
<LeoNerd> Don't even need them.. just a plain key is sufficient
<lamont> why oh why does bzr diff grab the *(^*^( lock so that I can't do anything until it's done?
<Kinnison> is it not a readlock?
<lamont> Kinnison: if someone is doing bzr diff, and I say 'bzr rm --keep', it fails waiting for the lock
<Kinnison> the locking is perhaps a touch high-level then :-(
<dash> hi! i'm wodnering if bzr can help me solve a problem
<dash> i've got a patch somebody write for twisted 2.5 and I want to bring it up to date with the latest revision of twisted. i've got an up-to-date bzr branch. would it be reasonable to make a new branch from the revision of the 2.5 release, apply the patch, then merge?
<Peng> (That person should've used bzr, not a plain patch...)
<dash> Peng: they didn't use a patch
<dash> they just changed their local install. :p
<Peng> Heh.
<Peng> Anyway, that sounds decent.
<Peng> commit has an --author arg so you can credit him/her/it.
<dash> ok! just making sure I understand the theory. ;)
<Peng> (Apply the patch, commit, then merge it into your other branch, you mean, right?)
<dash> right
<Peng> Sounds good to me.
<fullermd> ...  When did viz stop letting you resize the columns?
<pagenoare> hello
<pagenoare> anybody using bzr with trac ?
<pagenoare> or it's possible?
<gour> pagenoare: have you considered redmine?
<jelmer> pagenoare: yes, there is a trac-bzr plugin
<pagenoare> jelmer: elmohave u any doc, how to configure it ?
<pagenoare> have"
<jelmer> pagenoare, there is a README file included with it I think
<pagenoare> AttributeError: 'NoneType' object has no attribute 'log'
<pagenoare> jelmer: can u help me? "This should include "tracbzr.* = enabled" ", where?
<pagenoare> http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/jelmer%40samba.org-20080614232856-t81kc24suzkh73wt?file_id=readme-20061211191445-unb1b1y5dhltbwy7-2
<pagenoare> oh, yea, i like his bzr links ;D
<pagenoare> this'
<abentley> lifeless: ping
<visik7> is there something like git-filter-branch ?
<MvG> Hi, I'm the one who just sent an email requesting his "setlocale" branch to be merged, in case anyone wants to discuss it here.
<beuno> MvG, very cool, thanks. Since there is quite a lot of things going on right now (stacked branches, big release coming up), it may take a day or two for people to review the patch
<MvG> beuno: It's OK, as long as I don't have to spend those days adjusting the patch, I'm in no hurry.
<fdv> uhm.. I was wondering whether http://bazaar-vcs.org/HistoryHorizon is still on the horizon? :)
<beuno> fdv, that's "stacked branches"  :)
<jelmer> pagenoare: in the components section of your trac configuration
<beuno> which is targetted for 1.6
<beuno> it seems to have many names
<pagenoare> jelmer: i haven't it O_o
<jelmer> pagenoare, see the trac documentation for details
<fdv> beuno: so then one will actually be able to branch only some subset of the total set of revisions in a repo? do you know if it will work for bzr-svn, too?
<beuno> fdv, yes, only the last N revisions. I don't know about bzr-svn, that's jelmer's "terf"
<fdv> ok
<fdv> the branch I've taken out of svn at work is close to 8GB
<fdv> it's slightly painful
<fdv> especially when its all of a sudden corrupted with a kniterror :p
<beuno> yes, having stacked branches will be great
<beuno> just a few more weeks to go, if they can go through lifeless' 16k line patch  :p
 * fdv holds his breath
<fdv> jelmer: do you know if these "stacked branches" will work with svn as well?
<jelmer> fdv: Not immediately, but at some later point ,yes
<fdv> ok, thanks
<scorpioxy> Hey guys. I am trying to do a bzr co in a treeless branch created on my server using a push. But it says error, file exists on the .bzr dir. Am i doing something wrong?
<Peng> Could you pastebin the full traceback?
<Peng> Also, you might have to do "bzr co .", not just "bzr co".
<scorpioxy> Peng: There isn't any traceback, just a nice error saying file exists. Also, they are both behaving the same way
<Peng> I dunno then.
<Peng> What file exists?
<scorpioxy> Peng: .bzr
<Peng> Oh.
<Peng> There's a misunderstanding somewhere.
<Peng> What version of bzr?
<scorpioxy> Peng: 1.5 i believe
<Peng> "bzr version"
<scorpioxy> Peng: yup, 1.5. I have this branch via a bzr push
<scorpioxy> Peng: and i need to create its working tree.
<scorpioxy> Peng: i know that a bzr co <somewhereelse> works, but i need the working tree in that branch.
<Peng> scorpioxy: Well, it works fine for me, using bzr.dev and not pushing.
<Peng> WFM pushing too (not that it should matter).
<scorpioxy> So the docs say that if i have a treeless branch, a bzr co . will create the working tree. But i am doing that, and it seems to want to create a new .bzr when there already is one from the branch which is causing an error.
<Peng> A plain "bzr co" also works for me.
<Peng> Maybe it's a bzr 1.5 problem.
<james_w> scorpioxy: can you run with "bzr -Derror co ." and pastebin the traceback please?
<fullermd> I always do 'co .' just by reflex, and I haven't seen it fail yet...
<fullermd> What all is in .bzr?
<scorpioxy> Alright, hold on, i am pushing again. The repo isn't that big anyway.
<scorpioxy> hmmm...it works when i cleaned up everything and pushed again. The only difference is that i used the --use-existing-dir before and some of the files were already there.
<mwhudson_> i see someone is filing bugs saying "loggerhead should be like viewvc" :(
<ToyKeeper> ... speaking of being more like other tools...
<ToyKeeper> If I added a diff panel to 'bzr vis', is that change likely to get accepted?
<ToyKeeper> I suppose I could at least fix the issue where it refuses to resize smaller than its initial size.  That's an easy one.
<bkor> ToyKeeper: I'd like something like that (not a dev)
<scorpioxy> ToyKeeper: I am just a user, but i for one would like to see something like that. If you need any dev help or backup, send your thoughts to the list and we'll chime in.
<scorpioxy> and FYI, i think its a good idea, and i tend to use it in gitk. But i don't like git. So don't think about this as being like other tools, think about it like being the best-of-breed.
<bkor> ToyKeeper: btw, if you click the down pointing arrow (not green).. the popup incorrectly shows a mnemonic if the branch name has a _ (shows removecaches with c underlined instead of remove_caches)
<ToyKeeper> Well, that was a 1-line fix.
<ToyKeeper> I hope the existing diff dialog is organized to let me reuse it easily.  :)
<lifeless> abentley: pong
<nosecow> would anyone be willing to help a newbie trying to migrate from Visual Source Safe?
<lifeless> sure, I thinkeveryone here will offer advice
<nosecow> okay. in a nutshell, we have a new ubuntu server. I set up BZR on it. Committed my initial import.
<nosecow> I am trying to figure out how I would do, what in VSS would be called a checkout to my local development machine, so I can work on the code and then check it in later
<nosecow> local dev machine being windows as an addt'l complication
<lifeless> well, for starters install bzr on the local dev machine :)
<bob2> bzr co sftp://ubunutuserver/path/to/branch/
<nosecow> okay, lifeless, i was just looking at that... do i have my ideas backwards?
<lifeless> nosecow: bzr is both client and server, you need to install it on every machine that is working on code
<nosecow> aha! (ding)
<nosecow> lifeless: now that bzr is installed on local windows machine, what is next step?
<lifeless> nosecow: as bob2 said - you can perform a checkout to work on the code you committed by doing 'bzr co sftp://hostnameofuubuntumachine/path/to/branch LOCALOUTPUTPATH'
<nosecow> o-o-o-o-o-kay
<nosecow> I think I see
<nosecow> sweet! Thanks! Now I have to fix the authentication errors, but that's not bzr stuff.
<nosecow> to checkin, do i use an update command?
<bob2> if you use 'co', then your local checkout is 'bound' to the branch you checked out from - when you commit or checkin, the change is immediately propagated to the server
<nosecow> How cool! so if I do a commit from the DOS command line, then it is propogated to the server automatically?
<bob2> yes, just like cvs/svn
<lifeless> nosecow: yes it is. Also you use update if commit tells you the branch is out of date (which can happen when other people commit)
<nosecow> bob2: haven't used those; coming from ms/vss so have a whole world to exploare
<lifeless> nosecow: now, this is only the surface of what bzr can do - but get comfortable here first, then start exploring the tutorial, online help etc
<nosecow> thank you both very much!!!
<igc> morning
<lifeless> hi igc
<igc> hi lifeless. You guys sprinting this week?
<lifeless> I'm at home today working on VF's
<abentley> lifeless: pang
<ToyKeeper> Hmm, I suppose this is a start, at least:  http://toykeeper.net/tmp/bzrk-with-diffs.png
<lifeless> abentley: peng
<abentley> lifeless: I merged igc's stacking stuff into my stacking policy, and ran into a bug that I thought was in all_revision_ids, but turned out to be in BzrDir.clone
<lifeless> abentley: do you mean jml's?
#bzr 2008-06-17
<lifeless> oh, igcs updated loom, right
<abentley> Yes, the patches igc submitted recently.
<igc> abentley: what was the bug?
<lifeless> didn't jml have a patch for clone already?
<jml> I did
<jml> it got merged into abentley's branch too.
<abentley> lifeless: yes, and it was my modification of that patch which exposed the bad behavior.
<abentley> lifeless: Anyhow, when I thought it was about all_revision_ids, I thought I should confirm that it should work across fallbacks.
<abentley> The bug is that we open a repository before opening a branch, and we attempt to use that repository even if we find a branch later.
<lifeless> oh yes, references won't like that
<abentley> Exactly.
<abentley> It doesn't follow branch references and it also doesn't set fallback repositories.
<abentley> Anyhow, I've got a fix now.  I only pinged because I misdiagnosed the problem at first.
<lifeless> abentley: sweet
<nosecow> another newbie question. just tried my first commit, and got this error: bzr: ERROR: Cannot lock LockDir
<beuno> nosecow, is this on a checkout?
<nosecow> beuno: no, the checkout was successful. created a test directory with one file, then tried to commit, and got that error
<beuno> nosecow, this was using a lp:~yadayada type for URL?  As in, from Launchpad?
<nosecow> beuno: no. bzr co ftp://myhost/var/www/mysite c:\apache\htdocs\mysite
<beuno> that's odd then.  Can you paste in the full error?
<nosecow> yes
<nosecow> bzr: ERROR: Cannot lock LockDir(ftp://linuxdev01/var/www/propertypartner/.bzr/re / pository/lock): File exists: '/var/www/propertypartner/.bzr/repository/lock/un7w / nlmbyp.tmp': 550 Create directory operation failed.
<beuno> nosecow, what version of bzr are you using?
<bob2> ms windows ftp server?
<lifeless> nosecow: thats strange. Can you use 'sftp' instead of 'ftp' - it is a much nicer protocol and less problematic
<nosecow> bueno: 1.5, just downloaded
<nosecow> lifeless: had trouble with setting up sftp; will go edit my conf file...can i just checkout again once i change?
<lifeless> nosecow: yes
<nosecow> lifeless: changed default scheme in authentication.conf to sftp; but bzr does not seem to be picking up the proper username - is still using it's 'guess'
<lifeless> nosecow: put the username before the url like:
<lifeless> sftp://USERNAME@hostname/.....
<nosecow> okeydokey
<nosecow> sigh: bzr: ERROR: File exists: u'C:/apache/htdocs/propertypartner/.bzr': [Error 183] C / annot create a file when that file already exists: u'C:/apache/htdocs/propertypa / rtner/.bzr'
 * igc back in a few hours
<nosecow> should i just delete it?
<nosecow> and, i really appreciate this help...
<lifeless> yes, you can just delete that if its where you want to checkout to
<lifeless> back in a little bit : food
<nosecow> Okay, sftp protocol used, checkout from linux server to windows machine works fine, adding a directory and attempting to commit yields:
<nosecow> bzr: ERROR: Cannot lock LockDir(sftp://nosecow@linuxdev01/var/www/project/.bzr/repository/lock): Permission denied: "/var/www/project/.bzr/repository/lock/ctb89f5sh3.tmp": [Errno 13] Permission denied
<Peng> nosecow: Does your sftp user have read/write access to the repo?
<nosecow> ooh good question. can you tell it's been a long time since I used unix? :)
<nosecow> peng: excellent advice, thank you
<nosecow> yesssssssssssss
<nosecow> peng,bob2,lifeless: thank you all for the help. i have the basics working now. I appreciate all of your help!
<Peng> :)
<nosecow> bye
<poolie> spiv: were you going to come down here today?
<spiv> poolie: yeah.  I'm just about to head out the door.  I slept badly, and was just trying to figure out if I was sick or just tired before I came down and possibly spread contagion :)
<spiv> poolie: it seems I was just tired, which is good (relatively speaking...)
<lifeless> beuno: what do you think of the new loggerhead bugs?
<mwhudson> lifeless: https://bugs.edge.launchpad.net/loggerhead/+bug/240504 is a bit interesting
<ubottu> Launchpad bug 240504 in loggerhead "Should not generate revisioned URLs unless specifically needed" [Undecided,Confirmed]
<mwhudson> because if you want to generate a link to "file X in rev Y" i think you need to load the inventory for rev Y
<mwhudson> which is a pain, probably
<lifeless> mwhudson: well
<poolie> spiv, oh np, just wondered
<poolie> glad you're not ill
<lifeless> mwhudson: first approximation: load the inventory for .tip. If the modification revision is the same as in .tip, then you don't need to specify a revision
<lifeless> mwhudson: anyhow, this is why bzr search has phrase searches for (file_id, revision_id) -> 'p', '', PATH
<mwhudson> ah interesting
<mwhudson> so if we demanded bzr-search, we could do this more quickly?
<lifeless> mwhudson: its how 'bzr search foo' can return README as a path
<mwhudson> (not sure this is sane, of course)
<lifeless> mwhudson: well, there are multiple answers. In particular I wanted to say to Olav that we agree its not friendly
<mwhudson> sure
<lifeless> right now I'd do the low hanging fruit
<lifeless> jam: spiv: I've mailed a sample of how to do it easily
<mwhudson> well, i think the priority with loggerhead is to get some of the branches floating around merged
<lifeless> jam: spiv: feedback + things that would make it easier appreciated
<lifeless> using tango stuff would be cute; cuter still if it was just an optional theme
<mwhudson> i don't think the visual stuff is going to be ready for merging for a while
<mwhudson> (well, a week or so, let's say)
<lifeless> mwhudson: :P
 * mwhudson is running on internet time
<lifeless> blog aggregators must die
<lifeless> http://www.asofterworld.com/oq-display.php?id=58
<lifeless> http://datacharmer.blogspot.com/2008/06/mysql-sandbox-122-and-joys-of.html
<mwhudson> lifeless: nice
<poolie> sweet
<poolie> lifeless: assertRaises where?
<lifeless> in the test
<lifeless> you raise a specific exception
<lifeless> and fail if its not raised
<lifeless> that fits assertRaises doesn't it ?
<poolie> hum
<poolie> i want to generate an ImportError
<lifeless> if it doesn't thats fine - but its close enough people will get confused IMO so a note to that effect would help clarity
<poolie> i don't see how assertRaises can do that for me
<poolie> possibly i should remove the 'else' clause; if for some reason that module is loaded it will fail in a different way
<poolie> the raise is just to generate the input for the real test
<poolie> which is the call to format_exception
<lifeless> right
<poolie> i guess i could pass a lambda to assertRaises but i don't see the point
<lifeless> there is a bit of action at a distance happening I think. Specifically - are the args to ImportError well defined across python versions? If they are why don't you just 'raise ImportError'
<poolie> i do...
<lifeless> if they are not well defined then presumably the code is fragile, or we need python version based conditional logic
<poolie> oh in the other test
<lifeless> +        try:
<lifeless> +            import ImaginaryModule
<poolie> it seems like this is more realistic and no harder than just raising ImportError
<lifeless> so I guess I'm saying I'd have done a test that 'import MissingModule' resulted in an ImportError with a specific value in the args, to catch python variations, and then all the other tests as 'raise ImportError(...)'
<lifeless> which is close to what you've done ;)
<poolie> ok
<poolie> that would also work
<poolie> that would be a bit more precise, i don't think it's needed here
<poolie> thanks for the prompt review
<lifeless> anyhow, its bb:approve'd
<lifeless> the rest is sugar
<poolie> can you also read my comment on https://bugs.edge.launchpad.net/bzr/+bug/205230
<ubottu> Launchpad bug 205230 in bzr "error message recommending incorrect setting of PYTHONPATH" [Low,Confirmed]
<poolie> at the end
<poolie> want to trivilaly fix that too
<lifeless> thats an improvement
<lifeless> a note though - folk with .zips (e.g. windows) may need 'bzr.zip' on the path.
<lifeless> 205230 is good as is
<lifeless> just speculating about potential further tweaks
<lifeless> time to pkill firefox
<lifeless> ah look, 20% cpu back just like that
<fullermd> That must be nice.  I get 100% (well, 100% of one CPU) back when I SIGSTOP it while not actively using it   :|
 * beuno looks at new LH bugs
<beuno> ah, fun
<beuno> mwhudson, I was thinking, it shouldn't be too hard for us to be able to optionally serve branches over http
<Verterok> beuno:  you have a few to look ;)
<beuno> would be a nice feature to have
 * mwhudson loves how fast bzr log --short | less starts up now
<beuno> hey Verterok
<mwhudson> beuno: um, true i guess
<mwhudson> beuno: broadly speaking, i would tend to leave serving static files to apache... but i guess it wouldn't be hard
<beuno> mwhudson, we could even provide URLs to branch ay any given point in time, for your copy'n'paste comfort
 * mwhudson hmms
<beuno> I agree, although as a plugin for bzr that would rock  :)
<mwhudson> yeah, interesting idea
<mwhudson> file a bug on that too :)
<beuno> heheh
<beuno> more bugs?  :p
<mwhudson> beuno: there's more stuff in my wsgi-ify branch now
<mwhudson> beuno: bugs are great
<beuno> absolutely, makes it clearer what to do!
 * beuno looks at the whisky branch
<beuno> also, we should have export on there. "Download tar.gz for this revision"
<mwhudson> that sounds resource intensive
<mwhudson> but, well, sure :)
<mwhudson> so long as we can turn it off for lp...
<beuno> probably, but, well, generate it once, keep it forever :)
<mwhudson> well, that just consumes a different resource
<beuno> storage is cheaper, but yes, all these things should be optional
<lifeless> getting a tar is not expensive
<lifeless> compressing it is somewhat
<beuno> mwhudson, what do you think about setting a milestone for 1.3 in LP, and filing bugs on what we absolutely want for it, and target them. That way it should be easier to focus
<mwhudson> beuno: i think that's a good idea
<beuno> mwhudson, cool, because only you can do that  :p
<mwhudson> beuno: i've just made you a 'driver', does that let you do it? :)
<beuno> mwhudson, heh, no  :)
<mwhudson> darn
<beuno> I wonder what that does anyway, I don't see anything new I can do
<mwhudson> maybe it means you can target bugs to milestones?
<beuno> not even
<mwhudson> beuno: do you think i should create a new productseries?
<mwhudson> beuno: you should apply to join the loggerhead-team, btw
<mwhudson> i'll poke robey to make me an admin
<poolie> jml: "i'd love to" cute :)
<poolie> like Robert's thing that "the code will do X" meaning "will after it's written" :)
<beuno> mwhudson, requested. I'm not sure about the series thing, that always confuses me. I think you *have* to
 * beuno applies
<mwhudson> i guess that it confuses me too points to a problem in launchpad...
<mwhudson> beuno: do we call it 1.3 or 2.0 do you think? :)
<jml> poolie: well, the first email was sent *before* I consulted my calendar :)
<beuno> mwhudson, 2.0 sounds cooler  :p    Maybe we can try releasing the same as bzr versions, to me it less confusing and obvious with what version it works with
<mwhudson> beuno: that's probably a good idea
<mwhudson> i guess that means 1.6 then as we'll probably release between 1.6 and 1.7
<beuno> yeap, sounds good
<beuno> I love how versioning is so flexible  :)
<poolie> hello beuno, mwh
<beuno> howdy poolie
<mwhudson> beuno: i think maybe you can "nominate a bug for the 1.6 release"
<beuno> mwhudson, nope, I can for bzr, not for LH
<mwhudson> beuno: how strange
<mwhudson> https://bugs.edge.launchpad.net/loggerhead/+bug/236702/+nominate says "The loggerhead release manager  is Martin Albisetti. " :)
<ubottu> Launchpad bug 236702 in loggerhead "No permalink to "latest revision of file" in Loggerhead" [Undecided,Confirmed]
<beuno> oh, I can access that link  :/
<mwhudson> releases, productseries and milestones do not have entirely obvious interactions in launchpad
 * mwhudson adjusts his understatement settings
<beuno> I can't find anywhere in the UI to do it...
<mwhudson> beuno: "nominate for release" in the actions portlet?
<beuno> ah, target to release
<beuno> and bzr uses "milestones"
<mwhudson> well, i can add a milestone to the 1.6 series
<mwhudson> i'm not quite sure if i want to though
<beuno> don't worry about it, I'll use that
<beuno> it's odd, in bzr it *does* say Nominate for...
<mwhudson> oh, maybe all i can do is nominate for a release
<mwhudson> but because you're the driver you can actually target it?
<beuno> but you're part of the group and I'm not
<beuno> but it makes sense
<beuno> sort of
<mwhudson> :)
<mwhudson> i could actually read the code to figure this out, but it feels rather like cheating
<beuno> right. " Bug nominations are evaluated by release managers and accepted or declined for fixing in a release. "
<beuno> hahaha, and, from the looks of it, you may get lost for a while  :p
<mwhudson> oh, https://help.launchpad.net/Projects/SeriesMilestonesReleases seems relevant
<beuno> mwhudson, bug #156453 probably should go away with the release of the zpt branch, right?
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Fix committed] https://launchpad.net/bugs/156453
<mwhudson> beuno: hope so, let's see
<poolie> lifeless: is it ok with you if i disable test_35_wait_lock_changing (patch for this on the list)
<lifeless> poolie: if you must; I thought we'd discussed a simple way using a closure to test it with being timing dependent or threading
<poolie> not as simple as this :)
<poolie> i do want to finish that but i don't want to detour into it too much
<lifeless> let me rephrase - no, I don't think its a good idea to disable it. Its (I estimate) < 2 hours to fix properly. If we disable it, just delete it because noone will ever fix it..
<poolie> hm
<poolie> should i fix it now or read the VF patch?
<lifeless> lets ask spiv where is review is up to
<poolie> (biab)
<lifeless> spiv: where is your review up to
<poolie> lifeless: he was working on his hpss version handling patch
<poolie> we are both going back to that now
<lifeless> poolie: so, I don't know the answer to 'should i fix it now or read the VF patch?'
<spiv> lifeless: fwiw, I'm reading your knit.py changes atm
<lifeless> beuno: :)
<lifeless> ok, sending an incremental diff with the stuff I've improved so far
<poolie> spiv/lifeless, i'm reading log.py
<poolie> lifeless: i'll read it now and do this
<poolie> will try to fix it properly later
<poolie> if its timeslice expires i will just disable the test though
<igc> poolie: can I help with the VF review?
<igc> otherwise, I'll review jam's annotate patch
<poolie> merge.py
<poolie> igc, hi!
<poolie> i think it's ok with spiv and me
<igc> hi poolie!
<mwhudson> time to stop for me today
<mwhudson> beuno: another day without reviewing your urls branch, sorry about that :(
<lifeless> poolie: I'd like a chat with an intelligent teddy bear
<beuno> mwhudson, no problem. wsgi thing is more important. I still have a few tweaks to add to it. I'll try and get those done tomorrow so you can review all if it in one batch
<mwhudson> ok
<lifeless> poolie: so I'm going to ring you :)
<spiv> lifeless: be careful with intelligent teddy bears
<spiv> lifeless: they can talk back!
<beuno> mwhudson, I reorganized the bugs a bit, but feel free to change around anything you'd like. I targeted more or less what we've been discussing. I assume we're going to release with the new theme, right?
<mwhudson> beuno: i think we should
<mwhudson> so new templating engine, new look, new http front end, ...
<mwhudson> anything left for us to change? :)
<beuno> tests  :p
<mwhudson> most of history.py isn't changing i guess
<mwhudson> ah yes, good point :)
<beuno> no, but I saw you have a blueprint to replace that with something more sensible
<beuno> maybe we can discuss that after this release, and work out a plan for that
<mwhudson> oh, er, that blueprint is way out of date
<mwhudson> the idea behind it is still good perhaps
<beuno> it's worth looking in to. I get the impression we should change it too, so we should have a talk about it after we get this release out, and see if it still makes sense
<beuno> and, well, tests. Which can be the main focus of the next release, apart from maybe bug fixing   :)
<poolie> (back)
<igc> poolie: jam asked this morning if you'd send an email to the list at the close of your day explaining where you and spiv were up to in reviewing the VFs stuff. That way, he can pick it up overnight. He'd also said it was fine if you completed the review before then. :-)
<poolie> heh thanks :)
<poolie> ok
<poolie> i think we can probably finish it today
<poolie> i should send an update mail anyhow
 * beuno is off to bed.   Night all
<poolie> lifeless: in so many places the key list is the mapping of a function over some other list it kind of seems like there should be a more direct idiom
<poolie> like that you should pass in a closure that does the mapping
<poolie> however i suppose this would not actually make it any cleaner
<lifeless> I think it would make it less clean
<lifeless> because it would pollute the interface
<poolie> mm
<poolie> it was not a suggestion, just a thought
<lifeless> yah
<poolie> merge.py done, looking at your incremental patch
<lifeless> I was just saying what I thought of the thought :)
 * lifeless eats lunch
<poolie> > +    Tuple based apis below, string based, and key based apis above
<poolie> i don't understand that sentence
<lifeless> oh hmm
<lifeless> so I'm trying to say that below the line the code deals only with tuples
<lifeless> and above you have either plain strings
<lifeless> or for some apis (existing ones!) tuples that are types in that tuple[0] means 'fileid', tuple[1] means 'revisionid' (for that specific interface)
<poolie> lifeless: ok, some feedback sent; if you want me to take a stab at rephrasing it i can
<poolie> um
<poolie> there is the risk that by the time we get there i will just understand it and not need the docs
<poolie> but i think the initial review experience shows its worthwhile
<spiv> +            if content._lines and content._lines[-1][1][-1] != '\n':
<spiv> Ow :)
<lifeless> poolie: I think there is value in that yes
<lifeless> spiv: yes, but thats already in mainline :P
<lifeless> spiv: I think.
<spiv> lifeless: Not that my quick search of the diff finds :P
<spiv> lifeless: I blame AnnotatedKnitContent rather than you, though ;)
<lifeless> spiv: hmm, must have been pulled out with poolies other fix; I do recall not liking that line
<lifeless> spiv: I think we can delete it
<spiv> lifeless: awesome :)
<lifeless> oh, that reminds me
<lifeless> that bug is indeed fixed
<poolie> lifeless, spiv, some comments sent
<lifeless> thanks
<spiv> +                suffix_parents = self._kndx_cache[prefix][0][key[-1]][4]
<spiv> That's perhaps even more impressive ;)
<poolie> doing reconcile.py
<poolie> spiv, i guess you did all of remote.py etc
<spiv> poolie: My notes say I've done remote.py, smart/repository.py, branch.py, bundle/serializer/v4.py, bzrdir.py, check.py and fetch.py.  And just sent knit.py
<poolie> yay way to go
<spiv> poolie: oh, and annotate.py, builtins.py and inventory.py (which are all pretty trivial)
<poolie> ok will do revisiontree
<lifeless> poolie: asking now to avoid latency...
<lifeless> iter_topo_keys - why is it a good time now to fix a bug in existing code ?:P
<poolie> lifeless: in that it accepts keys=None?
<poolie> let's not add a new api that propagates problems
<spiv> Done knitrepo.py
<poolie> i suspect you can just delete those lines/words and it will work
<poolie> if not it's ok to leave it
<poolie> still on revisiontree
<poolie> ok reading store/__init__.py
<lifeless> poolie: I'm fairly sure I can't :P
<poolie> ok well don't then
<poolie> at least i'm sure it's never given one parameter
<poolie> you could do that
<poolie> it's possible it's sometimes indirectly given None
 * spiv starts reading tests/*
<poolie> lifeless: it's a new function and there's only a handful of callers that do seem to pass a value
<poolie> if it fals with that removed i guess it's not worth debugging
<poolie> at the moment
<poolie> lifeless: about the changes in store/__init__.py, changing _iter_files_recursive
<poolie> you changed the way escaping is done there
<poolie> ah, np
<poolie> the diff context is a bit misleading
<poolie> good night
<lifeless> gnight poolie
<james_w> In python if I create a variable holding a value and don't use it I assume it takes up memory until the next gc, is that correct?
<james_w> and if I immediately create another variable with the same value then that takes up the same amount of memory again?
<Leonidas> why does bzr blame display the email adresses instread of the names on the lines?
<Leonidas> I'd prefer to see the names there instead and maybe the initial would be even better
<Leonidas> (displaying the initials if the initials on a project do not clash)
<james_w> hi Leonidas, I'm not sure, you could file a bug requesting the change.
<Leonidas> james_w: on launchpad?
<james_w> Leonidas: yuppers
<james_w> https;//bugs.launchpad.net/bzr/+filebug
<james_w> almost
<james_w> https://bugs.launchpad.net/bzr/+filebug
<Leonidas> james_w: yeah, ok. It's not that important, though :)
<james_w> Leonidas: still nice to record these things.
<Leonidas> james_w: ok, writing it now.
<james_w> hanks
<james_w> thanks
<james_w> man, I should get off my ass and go to the shop to get some milk so I can have breakfast
<lifeless> james_w: when you do 'foo = bar'
<lifeless> james_w: 'foo' is bound to the result of evaluating 'bar'
<Leonidas> there it is: https://bugs.launchpad.net/bzr/+bug/240633 (lp does not allow me to set 'enhancement' on this)
<ubottu> Launchpad bug 240633 in bzr "Display names in bzr blame" [Undecided,New]
<Leonidas> breakfast sounds like a great idea.
<lifeless> james_w: if foo goes out of scope, then in CPython the ref count for whatever foo what bound to is decremented
<james_w> Leonidas: done, thanks.
<james_w> hi lifeless
<lifeless> james_w: if there are no cycles this results in it being freed immediately
<lifeless> james_w: if there are cycles then yes, a gc run is needed to free it
<lifeless> james_w: if you rebind foo, by doing 'foo = bar2'
<lifeless> then the old thing referenced by foo has its refcount decremented, see above
<james_w> thanks
<james_w> so a = foo; b = foo; would increase the chances of a MemoryError?
<lifeless> this is a long winded way of saying: yes|no to the first question and yes|no to the second
<james_w> this is for the patch I just sent if you didn't guess.
<james_w> :-)
<james_w> lifeless: if you're not heading off then I have a question about the package work.
<lifeless> shoot
<lifeless> i"m playing games
<james_w> I'm adding handling of native packages. The simple case is just that.
<james_w> the difficulty is when a package moves between native and non-native.
<lifeless> so I'm biased here
<james_w> I think non-native -> native should just import the native package as a merge of the packaging and upstream branches.
<lifeless> I think native packages are a premature optimisation and a bug in dpgs
<lifeless> *dpkg*
<lifeless> non-native->native should do a merge commit yes
<lifeless> and the reverse seems clear to me
<lifeless> to move from native to non-native there are two branches made, both which derive from the last commit on the native one
<james_w> I was leaning that way, I just wanted confirmation that it was sensible, thanks.
<lifeless> in the new upstream branch the packaging data is deleted
<lifeless> in the new packaging branch a merge from the new upstream is recorded, and the version metadata is changed
<lifeless> jam: hi
<james_w> yep, that sounds fine, I've just got to think about how to figure out what should happen from the history we have available, it shouldn't be too hard.
<lifeless> upstream content == tarball
<lifeless> upstream parent == last native
<lifeless> packaging content == tarball + diff
<james_w> the other question is how, and indeed whether, we should indicate that the package is native at that point.
<lifeless> packaging parents = [last native, upstream]
<lifeless> or perhaps the other way around
<lifeless> well, its not native now, its now non-native :P
<james_w> I think that's the right way round.
<lifeless> I dunno, I'd need to think :P
<james_w> yeah, sorry, indicate that the package is native when it is.
<lifeless> I think just the version number :P
<james_w> there's two things that impacts, one is when importing the next version so that we know to use the packaging branch as the upstream branch as well, and the other is when building.
<lifeless> there should always be a packaging branch, thats the one people get
<james_w> if only :-)
<lifeless> seriously, the version number is the only way to detect a native package AIU
<james_w> nope, a native package is a native package, i.e. the .dsc just describes a tarball, not a tarball and diff.
<james_w> this can happen at any moment, with any version number.
<james_w> e.g. lvm2 just goes native at something.something-1ubuntu4, and then back to non-native at the next revision
<lifeless> argh
<lifeless> see, native is a bug
<james_w> I think it's a bug in dpkg that you get a native just because you didn't have a correctly named tarball/directory in the parent directory.
<lifeless> native's _existence_ is a bug
<lifeless> so totally convinced of this
<james_w> well, trying to deal with this makes me dislike any variation, so I'd agree at this point.
<lifeless> ok
<james_w> what builddeb currently does is versions a file in the tree which just says "native = True"
<lifeless> so detecting native. hmm - think on it during your day, mail me if you don't have a good answer at the end :P
<james_w> I can detect native fine.
<lifeless> 20:01 < james_w> the other question is how, and indeed whether, we should indicate that the package is native at that point.
<lifeless> so, whatever you mean by ^^^
<james_w> ah, I meant indicate in the branch.
<james_w> the .dsc tells you fine, but we don't version that.
<lifeless> right
<lifeless> so the dsc represents a 'commit' to the 'debian vcs'
<lifeless> why don't we preserve it
<james_w> sounds reasonable, do you have any suggestions where?
<lifeless> revision properties perhaps
<lifeless> only need some of the dsc
<james_w> yeah, I was thinking of adding some from this information.
<james_w> this works fine for imports, so I'm happy to do that for now.
<james_w> however, what's not great about it is when you are building a new version of the package, the native property would be set on the last imported revision, but do we build the current package native?
<lifeless> well
<lifeless> I think that this is arguably something debian/control should answer
<lifeless> it would solve the bug of sometimes getting native when you don't want, etc
<james_w> I wouldn't mind enforcing the rule from the version number, but I wouldn't be surpised if there were packages out there that intentionally break the rule.
<james_w> yes, debian/control would be great.
<james_w> I think format 3.0 may actually do this.
<james_w> yeah, you specify "3.0 (native)"
<james_w> I don't think we could block on having 3.0 by default though.
<lifeless> indeed
<james_w> Am I right in thinking that bzr doesn't provide a mechanism that allows you to associate something with the branch rather than a revision?
<james_w> i.e. branch.conf isn't copied on "branch" is it? Or at least not all of it?
<lifeless> that correct
<james_w> and that wouldn't help too much, as we would want it to be versioned.
<lifeless> ash keybuk how he solved this
<james_w> hct? or Mom?
<lifeless> hct
<james_w> ok, thanks.
<lifeless> and I can think more about it but not tonight :P
<james_w> I've one last thing that I wanted to ask.
<james_w> when we chatted with jml and everyone else about branch naming we only discussed packaging branches.
<james_w> are we going to push the upstream branches to launchpad separately, or just extract them as needed from the packaging branches?
<lifeless> well
<lifeless> Mark wants to keep the two incompatible branch sets separate
<lifeless> so lets keep them implicit in the branch as tags only for now
<james_w> sure, easy enough.
<james_w> thanks for you time. I don't need to block on the native thing, but we need to get it right before making the branches available, so if you have any thoughts I'd appreciate it.
<lifeless> I suggest a mail on it when you've chatted with scott & perhaps colin
<james_w> sure, I'll start that today, thanks.
<james_w> you're going to be at the distro sprint again, is that right?
<lifeless> yes
<lifeless> guadec + london + wolverhampton
<james_w> ah, I'm doing the last two.
<Jc2k> lifeless: your at GUADEC?
<lifeless> Jc2k: I will be yes
<lifeless> Jc2k: the Gnome folk at UDS thought it would be good to be able to grill me with others at GUADEC :)
<Jc2k> for the DVCS stuff?
 * Jc2k hopes to get to wave his finger at the Git camp :)
<pygi> is there really a point in pointing fingers, instead of collaborating?
<Jc2k> i was joking, obviously, but the last time GNOME debated DVCS one of the Git users threatened to take their ball in.
<mwhudson> Jc2k: hi :)
 * mwhudson is not really here
<Jc2k> lo mwhudson :)
<Jc2k> oh dear..
<Jc2k> :)
<mwhudson> got my email?
<Jc2k> yes i did, and i've updated bzr-mirror with your latest :)
<mwhudson> and the annotate links work now, good
<mwhudson> olav filed a bunch of loggerhead bugs, so i guess you showed it to some of the gnome people :)
<Jc2k> just a couple
<asabil_> Jc2k: btw, thanks for setting up the bzr gnome mirror :)
<Jc2k> hehe, np asabil_
<Jc2k> asabil_: im working on making it easy to use from jhbuild, if thats of any use to you
<asabil_> Jc2k: that sounds very nice :)
<asabil_> I think what is still lacking is a branch hosting facility, similar to launchpad's branch hosting
<Jc2k> indeed, mark phoned me to discuss bzr-mirror and we are looking meant to be looking into that
<Jc2k> asabil_: watch this if your interested :) http://bugzilla.gnome.org/show_bug.cgi?id=538507
<ubottu> Gnome bug 538507 in general "Jhbuild should be able to use bzr-mirror.gnome.org" [Normal,Unconfirmed]
<asabil_> oh thanks
<asabil_> I am *very* interested
<Jc2k> :)
<lifeless> I showed that to jamesh, no comment so far :P
<lifeless> jam: ping
<Jc2k> :P
<mwhudson> Jc2k: do you have any loggerhead issues you'd want me to focus on particularly?
<mwhudson> (other than the reasonably obvious one of "get what you're running into trunk")
<Jc2k> mwhudson: anything that olav wants, nicer urls would be lovely (so i can guess a url if i know the layout of my project, for example) and some way for me to start giving it the GNOME skin
<mwhudson> ah yes, themable html
<mwhudson> that's beuno's department :)
<Jc2k> mwhudson, bueno: might be worth hanging out in #gnome-bzr on irc.gimp.org?
<mwhudson> you can supply your own css now of course, it's just a static file
<Jc2k> you too asabil_
<asabil_> oh oki
<mwhudson> but you'll probably want to hurt yourself before you got anywhere
<mwhudson> Jc2k: oh right
<asabil_> btw Jc2k, you are the conduit author right ?
<Jc2k> im one of the core devs, aye
<asabil_> we need to talk :D
<Jc2k> ace
<Jc2k> #conduit on gimpnet then ;D
<asabil_> :)
<lifeless> mwhudson: I did mention #gnome-bzr on gimpnet right ?
<mwhudson> lifeless: you did
<lifeless> :P
<mwhudson> i had some reason for not joining at the time you mentioned it, i forget what it was :)
<Jc2k> :P
<jelmer> :-( dak migrated to git
<lifeless> garh
<lifeless> who maintains dak?
<james_w> ftpmasters I believe
<james_w> http://blog.ganneff.de/blog/2008/06/16/byebye-bzr-hello-git.html
<lifeless> erm no browser
<lifeless> whats the summar ?
<james_w> As the title says - the Ftpmaster dak repository is now using git instead of bzr.
<james_w> I never did like bzr, so I recently asked what the rest of the team thinks of switching to git. Luckily I got no objections, so here we are, with a VCS thats not dead-slow.
<dato> lifeless: that the person doing most of the works nowadays just dislikes bzr, and no other member of the team opposed to moving to git
<dato> s/works/work/
<james_w> hi dato
<dato> hello james_w
<james_w> dato, jelmer: any thoughts on https://bugs.edge.launchpad.net/bzr/+bug/228298 ?
<ubottu> Launchpad bug 228298 in bzr ""common-post-build-indep" target in debian/rules became obsolete when bzr became arch-specific" [Undecided,New]
<lifeless> ok
<lifeless> search suggestions done
<lifeless> by done, I mean 'unit tested and works to the ui', not 'performant' or 'cleanly coded'
<jelmer> james_w: Looks like a genuine bug in the debian bits
<jelmer> james_w: The submitters suggestion looks reasonable
<lifeless> hi dato
<dato> james_w: yeah, I think as Jelmer
<dato> hello lifeless
<james_w> jelmer: cool, shall I file it in Debian as well to keep track of it, or just do it?
<jelmer> james_w: Should be trivial enough to just fix, but whatever works best for you is fine with me
<james_w> sure, I'm just doing some triage, I'll get to it after. Thanks.
<jelmer> james_w: thanks for your triaging work, btw, bzr itself is way behind on that :-(
<james_w> no problem. I noticed we were close to 1000 open bugs
<lifeless> gnight all
<Jc2k> night lifeless
<jelmer> gutenacht lifeless
<james_w> night lifeless
<lifeless> Jc2k: I've just mailed beuno a suggestion (and the necessary code in bzr-search) for some bling; if he does it - and he is attracted to shiny things - then the search will be seriously sexy
<Jc2k> orly?
 * Jc2k wraps bzr-mirror.gnome.org in glitter and throws it to beuno
<mtaylor> lifeless: if I have a revid, how do a get a revno from a branch?
<mtaylor> lifeless: (in the code, not in the command line)
<mtaylor> oh. damn. he's gone to bed
<mtaylor> anybody else? ^^
<bob2> branch.get_revision_id_to_revno_map()[revid]?
<mtaylor> bob2: is that better than branch revision_id_to_revno() ? (which I just noticed...)
<bob2> ah, I would say no :)
<mtaylor> uh...
<mtaylor> help?
<mtaylor> Two plugins defined the same command: 'cmd_parent'
<mtaylor> Not loading the one in <module 'bzrlib.plugins.mysql.parent' from '/home/mtaylor/.bazaar/plugins/mysql/parent.py'>
<mtaylor> Previously this command was registered from <module 'bzrlib.plugins.mysql.parent' from '/home/mtaylor/.bazaar/plugins/mysql/parent.py'>
<mtaylor> those look like the same place to me
<Jc2k> buggy plugin? can you not just move it out of the way?
<awilkins> I'm trying to ignore all files with the extension .txvClassDiagram20 *except* default.txvClassDiagram20 - the RE I think it should be is RE:.*(?!default)\.txvClassDiagram20  .. but this doesn't seem to work.. any pointers?
<mtaylor> Jc2k: yes. and I finally see the problem ... but WOW, what a weird error message
<Jc2k> mtaylor: i've seen python get the path wrong if you move *.pyc files around
<Jc2k> awilkins: if you bzr add a file, then it doesnt matter that its in .bzrignore *i think*
<awilkins> Jc2k: Yup, agreed, but these files are not already added.
<Jc2k> so add them? :)
<awilkins> Jc2k: It's the other way round, I want to PREVENT automatic adds of all txvClassDiagram20 files EXCEPT default.<blah>
<awilkins> So I want to ignore them apart from default...
<mtaylor> Jc2k: in this case, it was a "foo: %s" foo
<mtaylor> Jc2k: without a % between the string and the var :(
<Jc2k> mtaylor: eep
<Jc2k> awilkins: ahh ok, i figured there wouldnt be any new default.foo files to add
<awilkins> I think the .* is being too greedy
<awilkins> Bingo, I wanted .*\b(?<!default>\.txvClassDiagram20$
<awilkins> Don't you just love regular expressions .....
<Jc2k> write-only language :)
<awilkins> My old colleagues used to joke about some of mine achieving sentience and taking over the world.
<awilkins> They were'nt even very complicated as Regex go....
<abentley> awilkins: .bzrignore supports regexes.
<abentley> awilkins: Just prefix them with RE:
<Jc2k> abentley: he solved the problem with regexes just a few lines up :)
<Jc2k> 14:39 < awilkins> Bingo, I wanted .*\b(?<!default>\.txvClassDiagram20$
<abentley> awilkins: I didn't see that he knew he could use that regex.
<abentley> Or Jc2k, actually...
<Jc2k> :)
<catlee> Hello
<catlee> I've been trying to use bzr to work on a local branch of a svn repository
<catlee> But I've noticed when I push changes back to the svn repo, all of my intermediate merges from the svn repo are included in my commit.  Is there a better way to work with a svn repo than bzr merge / commit / push?
<awilkins> jam: There's a bug on lp that says you use bzr/cygwin, have you ever used a bzr/cygwin sshd to serve bzr+ssh://  ?
<jelmer> catlee: You can use rebase instead
<jelmer> catlee, (instead of merge)
<catlee> jelmer, ok I'll give that a try, thanks
<jam> awilkins: I use bzr/win32, I just run a cygwin shell
<catlee> got an AssertionError when I tried to rebase with no arguments
<jam> I've never run openssh server on cygwin
<jelmer> catlee, what version are you using?
<catlee> 1.5
<awilkins> jam: I think I just thought of a solution anyway... let me try it
<jelmer> catlee, sorry, what version of rebase ?
<catlee> jelmer, how do I tell?
<catlee> 0.3.0
<awilkins> jam: Problem I'm having is that the shell script is #!-ing a path to Python that Cygwin doesn't grok
<jelmer> catlee: If you specify a location explicitly, it probably works better
<jelmer> I think this issue as also been fixed in bzr-rebase, just isn't in 0.3.0 yet
<jam> awilkins: you could have a different bzr in your cygwin path, which it *does* understand
<jam> you just need it for the shell script
<jam> I use this:
<jam> #!/bin/ash
<jam> # Simple 'ash' script to thunk over to the real python
<jam> export BZR_PLUGIN_PATH='C:\Users\jameinel\dev\bzr\plugins'
<jam> exec /cygdrive/C/Python25/python.exe 'C:\Users\jameinel\dev\bzr\bzr.dev\bzr' "$@"
<catlee> jelmer, not sure if I've really messed up my branch now...bzr rebase errors out saying there are no common revisions
<jelmer> catlee: You really want the trunk version of bzr-rebase in that case
<catlee> jelmer, where is it?  the branch link from the Rebase wiki page is empty
<jelmer> catlee, That link should work, you can run "bzr branch <link> ~/.bazaar/plugins/rebase"
<catlee> http://people.samba.org/bzr/jelmer/bzr-rebase/trunk/
<jelmer> catlee, yes
<catlee> ah, I guess apache is hiding the .bzr directory
<catlee> I'll give it a try, thanks
<awilkins> jam: That works a lot better ; do bzr+ssh URIs understand "~" ?
<Peng> awilkins: No.
<jam> awilkins: not yet
<jam> but you can use the "contrib/bzr_access" script to change the meaning of /
<awilkins> Would using Cygwin Python be any easier, DYT?
<awilkins> How do you specify the path, I'm now guessing you can't use <URI_ROOT>/home/branch  ?
<awilkins> I got SFTP working nicely, but the completist in me wants to see bzr_ssh work
<awilkins> Aha, you just use the drive letter :-)
<awilkins> Blech, that's horrible
<awilkins> right ,time to go
<beuno> lifeless, is it expected I get this when pulling bzr.dev:  http://paste.ubuntu.com/20914/
<awilkins> jam: How do you get the smart server to serve branches that are not on the same drive as Python on windows?
<jam> awilkins: add a "cd ???" before starting the interpreter?
<jam> I would have thought bzr+ssh://host/D:/aoueaoeu would work
<jam> but if you are finding that it does not
<awilkins> jam: It doesn't... f you leave off the drive letter it can serve branches on the same drive (ie c:)
<awilkins> jam: But the chroot stuff is trying to read a path c:\c:\home\branch even if the drive letter is on the same drive
<uws> I'd like to
<uws> import a bzr branch to a newly created SVN repo
<awilkins> I think it needs a bit of a patch in request.py : translate_client_path
<uws> bzr push svn+ssh://..../trunk doesn't work since there are no common revisions (branches have diverged, but the svn repo is new, doh)
<uws> any clue how to do this?
<uws> And no, I'm not moving away from bzr. Actually I'm importing to Gnome SVN for i18n reasons, development will still be in bzr :)
<bkor> uws: you mean http://live.gnome.org/BzrForGnomeDevelopers
<bkor> ?
<jam> awilkins: is that using bzr_access or just plain bzr+ssh?
<jam> uws: 'bzr svn-push' to create a new branch
<awilkins> jam: that's bzr+ssh//, bzr:// (although different paths, same problem)
<uws> jam: trunk/ dir is already there...
<uws> bkor: that's the other way around
<uws> bkor: I already have a bzr history
<awilkins> jam: bzr+ssh:// is over local cygwin sshd ; sftp to the same branch works
<awilkins> (as long as you use the /cygdrive/ root to get to other drives)
<schierbeck> ahoy
<uws> bkor, jam: I tried removing trunk/, but gnome svn won't let me because it wants a MAINTAINERS file
<jam> uws: can you try pushing to another location (svn-push) and then something like copy them over?
<bkor> ehr, you shouldn't remove trunk
<jam> you might want to try on a local repo first
<jam> uws: another option
<jam> if there is only 1 revision in trunk
<jam> you can use
<jam> bzr merge -r 0..-1 .../trunk
<awilkins> jam: push-and-copy isn't going to work, alas, SVN repos being what they are.
<jam> bzr commit
<jam> bzr push trunk
<jam> I'm not sure what bzr-svn has to say about that
<jam> but it would work for bzr branches with diverged histories
<awilkins> I've done it for empty branches, I think
<uws> jam: first create a svn checkout and merge that from the to-be-imported-into-svn-bzr-branch?
<jelmer> uws: Hmm
<jelmer> uws: You may be able to merge the current trunk and then push
<uws> bzr merge -r0..-1 ../svn/trunk
<uws> That's what I just did in my bzr branch
<uws> the svn/ dir is a svn checkout (empty repo)
<uws> jelmer: ^
<jelmer> uws: If you commi that, can you then push?
<uws> jelmer: no
<jelmer> uws: What error, diverged branches?
<uws> elin:~/Computing/Projects/gnome-specimen/development > bzr merge -r0..-1 ../gnome-specimen.bzr-svn/
<uws> All changes applied successfully.
<uws> elin:~/Computing/Projects/gnome-specimen/development > bzr ci -m 'Merged Gnome SVN trunk'
<uws> Committing to: /home/uws/Computing/Projects/gnome-specimen/development/
<uws> Committed revision 205.
<uws> elin:~/Computing/Projects/gnome-specimen/development > bzr push svn+ssh://svn.gnome.org/svn/gnome-specimen/trunk/
<uws> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<uws> Oops, too many lines. sorry
<uws> jelmer: ../gnome-specimen.bzr-svn/ is a trunk checkout made using bzr-svn
<jelmer> Probably because it's not a lhs ancestor :-/
<uws> the common use case is to branch from svn, and commit back to svn
<uws> i want to import a bzr branch into svn :)
<uws> jelmer: fwiw, my bzr branch is linear (no merges)
<jelmer> yeah, the unfortunate bit here is that bzr-svn is a bit strict about where it can push to
<jelmer> I was planning to fix this in 0.5, but we're not there yet..
<jelmer> trying to think of workarounds..
<uws> jelmer: I'm now trying svn-push to a trunk-from-bzr dir
<uws> jelmer: That seems to work
<uws> (after committing a MAINTAINERS file to the completley empty just created real trunk/)
<uws> it's now pushing
<uws> I'll try to move trunk-from-bzr to trunk/ afterwards
<uws> http://svn.gnome.org/viewvc/gnome-specimen/
<jelmer> Ah, that's a nice idea
<uws> if you refresh you see it going :)
<uws> heh, "age:  very little time"
<Jc2k> uws: oooh
<uws> it's halfway done now.
<uws> Jc2k: ?
<Jc2k> this should be interesting, i wonder if bzr-mirror.gnome.org will pick it up automatically
 * Jc2k goes to watch the log unfold
<uws> Jc2k: I've done the regular    "ssh svn.gnome.org new-svn-repos gnome-specimen"   so it should be no different from another new svn repo
<awilkins> They have websites for that kind of thing
<uws> when this is done, I'll discard the original bzr branch in favor of a bzr-svn clone of the new trunk/
<uws> awilkins?
<jelmer> uws: There shouldn't be a need for that
<jelmer> uws: Since cloning the new trunk/ will create an exact copy of what you already have locally
<awilkins> ^^ watching the lgo unfold (a poor scat joke)
<uws> jelmer: I can keep pushing from the original bzr branch to turnk/
<uws> jelmer: even if it wasn't a svn checkout in the first plae?
<Jc2k> uws: i've never watched a new module be born, though :)
<uws> anyway, http://svn.gnome.org/viewvc/gnome-specimen/trunk-from-bzr/  seems to be ok now
<uws> let's try to move it
<jelmer> uws: Yes, since it was created with svn-push.
<jelmer> In hindsight, it may be useful to start out by pushing to branches/from-bzr rather than trunk-from-bzr
<jelmer> To avoid trouble with bzr-svn picking up the branching scheme
<jelmer> If it's easy to strart over, you may want to do that
<uws> hmm ok
<uws> bkor: still here?
<bkor> uws: sort of
<uws> jelmer, bkor: jullie houden net zo veel van voetbal als ik zeker? :)
<uws> bkor: can you rm -fr the gnome-specimen repos from svn.gnome.org now?
<jelmer> uws: idd (-:
<uws> bkor: I've just created it so there's no need to backup
<uws> bkor: I'll recreate and try the svn import in a correct way, like jelmer suggests
<bkor> uws: GOAL!
<bkor> uws: I mean.. done!
 * uws loves "direct lines" to people in OSS projects. bzr-svn trouble? ask the maintainer. Gnome SVN issues? ask bkor 
<Jc2k> :)
<uws> bkor: I would've heard a sound coming from the people on the street ;)
<uws> http://svn.gnome.org/viewvc/gnome-specimen/
<uws> and there is is agai n:)
<awilkins> Ben Collins-Sussman once very kindly uploaded a build of SVN to my SFTP server
<awilkins> IRC is great
<awilkins> Freenode in particular
<uws> awilkins: Colleagues make fun of me because I don't do the msn thingy. i know better though :)
<awilkins> IM networks are too fragmented
<awilkins> They won't be any use until it all does XMPP
<uws> awilkins: irc.gnome.org is even better than freenode for my particular case :)
<uws> bkor, jelmer: http://svn.gnome.org/viewvc/gnome-specimen/branches/import-from-bzr/  incoming! :)
<Jc2k> uws: can bkor and i lure you into #gnome-bzr on irc.gimp.org?
<Jc2k> :)
<uws> jelmer, bkor: ok, import in branches/import-from-bzr almost done
<uws> now how do I get this as trunk/ ?
<uws> I had to commit a MAINTAINERS file to trunk/ first btw otherwise the push commits would fail
<jelmer> uws: What's the exact post-commit script that's used in gnome svn?
<uws> jelmer: dunno, ask bkor
<jelmer> bkor: Still there?
<Jc2k> i can take a look
<Jc2k> i think
<Jc2k> if its in the rysncs
<uws> jelmer: msgfmt checks for .po files, and MAINTAINERS file in trunk/ methinks
<uws> Jc2k: Why do you use rsyncs?
<uws> jelmer: but apart from the commit hook (if it's a real problem we can ask bkor to disable it for like 2 minutes), how would I get this branch as trunk?
<bkor> jelmer: post-commit? why does it matter?
<jelmer> uws: it's probably easiest to just do a checkout of the repository root and then do a "svn rm trunk" followed by "svn mv branches/import-from-bzr trunk"
<Jc2k> uws: i had rsyncs of svn.gnome.org for the initial bzr-mirror conversions
<jelmer> bkor: I was mainly interested in how it checks for MAINTAINERS - does it make sure the MAINTAINERS file is there after the commit or does it actually look at the delta of the commit?
<bkor> jelmer: that is a pre-commit
<uws> bkor, jelmer: eh, pre-commit methinks
<uws> exactly
<uws> jelmer: Ok, but I have to commit after removing the trunk/, and before moving the branch into its place
<uws> but commiting the "svn rm trunk/" fails because of the pre-commit hook
<bkor> jelmer: http://pastebin.mozilla.org/462388
<bkor> it is on purpose
<uws> I like the   "`whoami`" != "ovitters"   part
<uws> bkor: could you type this for me:
<Jc2k> oh so its not just bzr-mirror that needs a workaround for gnomemm :)
<jelmer> uws: ahh, ok. It is possible to do such a change when using the svn API, guess it's just the UI that forbids it.
<uws> svn checkout svn+ssh://ovitters@svn.gnome.org/svn/gnome-specimen
<uws> cd gnome-specimen/
<uws> rm -fr trunk
<jelmer> uws,bkor: Disabling the hook and then doing the move would be easiest
<uws> svn commit -m "Removed trunk/ so bzr import branch can be moved into its place"
<jelmer> otherwise, I can come up with a python script that does it for you
<uws> jelmer: according to http://pastebin.mozilla.org/462388   bkor can avoid the checks
<uws> so if he removes trunk/ for me
<uws> I can move the branch back
<uws> methinks
<bkor> uws: svn rm svn+ssh://svn.gnome.org/svn/gnome-specimen/trunk is easier, and done
<uws> bkor: ah, didn't know that works as well
<Jc2k> its probably worth trying the replay idea, the next time this crops up
<jelmer> Jc2k: replay breaks all copies of the bzr branch you're pushing though
<jelmer> Jc2k: what we're doing right now doesn't
<Jc2k> ah
<uws> Yay
<uws> http://svn.gnome.org/viewvc/gnome-specimen/
<uws> it seems to have worked
<uws> jelmer, bkor: it seems ok to me.
<uws> jelmer: now  bzr push svn+ssh://svn.gnome.org/svn/gnome-specimen/trunk/    from my original bzr branch ought to work, right?
<jelmer> yep
<jelmer> or, actually - you have to pull first
<uws> yeah, pulled the "move" commit
<uws> which doesn't seem to change anything locally
<uws> jelmer: at least the output "bzr diff --verbose -r204..205" is empty
<uws> (r205 is the "Moved branches/import-from-bzr to trunk to (hopefully) complete the import." commit)
<jelmer> uws: Yep, that all looks fine
<LarstiQ> uws: btw, I still have books of yours
<uws> LarstiQ: Hmm. that's right. which ones?
<uws> LarstiQ: alphabet + brown, right?
<uws> LarstiQ: coming to guadec by any chance?
<uws> (that would be a ridiculous place to hand those back, btw ;>)
 * jelmer will most likely be at Guadec, btw
<uws> jelmer: You will? great. Chime in on #gnome-nl!
<LarstiQ> uws: yes, what/where?
<uws> LarstiQ: also coming to guadec?
 * LarstiQ rephrases more clearly
<LarstiQ> uws: Those two books indeed. I'm familiar with guadec, but I don't know when or where it is this time around?
<uws> LarstiQ: istanbul, July 6--13
<uws> anyway, dutch oss hackers should probably team up for a beer/other drink sometime
<uws> gnome and bzr ppl, for instance
<LarstiQ> no Guadec for me
<LarstiQ> uws: but totally agreed about drinking ;)
<Verterok> moin
<beuno> howdy Verterok
<Verterok> beuno: hi (I'm suffering a bit of lag :P)
<beuno> Verterok, ah, 11 minutes lag is going to be interesting  :)
<Verterok> beuno: hehe
<grantgm> does bundlebuggy actually perform requested merges, or does it just track them for code reviews?
<mwhudson> it tracks them
<mwhudson> pqm is what performs them
<grantgm> ok, thanks. Is pqm documented anywhere? the description at https://launchpad.net/pqm sounds pretty awesome, and I'd like to push for bzr (incl. bundlebuggy and pqm) to be used for our department
<grantgm> there seems to have been some discussion here: https://lists.ubuntu.com/archives/bazaar/2007q4/032572.html
<grantgm> does anyone know if there's been any progress towards packaging or documenting it since then?
<thumper> grantgm: I don't think so
<thumper> grantgm: but I'm actively fixing a few pqm bugs
<grantgm> good to hear that its still being actively developed. is it in a state where I should be pushing for our department to use it, or is it still really only used within bzr?
<tca> I originally reported https://bugs.launchpad.net/bzr/+bug/205564, and this bug seems to be fixed in latest bzr.dev. Should I just close the bug myself?
<ubottu> Launchpad bug 205564 in bzr "bzr log fails with KeyError: 'null:'" [Medium,Triaged]
<Peng> I'm pretty sure you can, so it wouldn't hurt to.
<Peng> If you're sure it's fixed.
<nslater> how would i check the latest revision of a remote repository?
<beuno> nslater, bzr revno LOCATION
<nslater> thanks beuno :)
<beuno> :)
<awilkins> Hmm, there appear to be some DNS issues
<Peng> oh?
<awilkins> I'm getting problems resolving my newshost, but it seems to resolve OK from a host in the states
<awilkins> http://just-ping.com/index.php?vh=news20.forteinc.com&s=ping!
<niran> the bzr-svn page says that merged revisions show up as ghosts in svn. what does that mean?
<jelmer> niran: They show up as ghosts in bzr
<jelmer> niran: In other words, right hand side revisions (in other words, revisions show indented by "bzr log") are not pushed into subversion themselve but a pointer to them is
<niran> oh... so the actual changesets shown NOT as ghosts in bzr are the same ones that will end up in svn?
<jelmer> niran: If you push a branch into Subversion and then run "bzr branch" on the Subversion URL somewhere else
<jelmer> it will only be able to copy the left hand side (not indented in "bzr log") revisions
<niran> jelmer: ok i think that makes sense
<niran> one more question
<niran> when pushing multiple changesets to svn, do they each get a separate commit, or do they all show up at once?
<jelmer> each left hand side revisions gets a separate commit
<niran> ok, thanks for your help
<lifeless> beuno: hi
<beuno> mornin' lifeless
<lifeless> beuno: you have an old index
<lifeless> beuno: that was before I added reporting of paths, just delete the index
<lifeless> beuno: also, completion, whaddya think :) :) :)
<beuno> lifeless, good, Still bugless then  :p
<beuno> completion?
<lifeless> check your gmail
<lifeless> sorry, suggestions
<lifeless> search completion/suggestions same thing
<jml> lifeless: are you off to the vibe today?
<beuno> lifeless, odd, I somehow missed that email completely  :/
<lifeless> jml: I think so
 * beuno checks gmail filters
<beuno> oh, VERY cool
<jml> lifeless: cool. I'll pack some books.
 * jml will head off in a few minutes.
<lifeless> beuno: so I guessed right that that is bling you'd find interesting :P
<beuno> lifeless, replied back. You rock  :)
<beuno> I still don't understand how that email got marked as read
<beuno> lifeless, can you send a test email my way?
<lifeless> done
<beuno> hrm, works fine. Odd.
<lifeless> bundle in a sec
<beuno> thanks  :)
<beuno> I've got a dinner, but I already know how to do the ajax bit for that, so it should be just a couple of hours work
<lifeless> sweet
<lifeless> after work tonight I'll do the refactoring and partial-read work required to make it faster
<beuno> LH will look *very* web 2.0 in a month's time
<mwhudson> :)
<beuno> lifeless, I get: beuno@beuno-laptop:~/bzr_devel/bzr-search$ bzr pull ~/Desktop/trunk-38.patch
<beuno> bzr: ERROR: Revision {('robertc@robertcollins.net-20080617122537-eyv8tt7s1dki5dyw',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x894f7ec>".
<lifeless> you probably don't have 37
<lifeless> oh, or my hacking send glitched cause there is no public branch
<beuno> beuno@beuno-laptop:~/bzr_devel/bzr-search$ bzr revno
<beuno> 37
<lifeless> abentley: how can I force bundle to include data for a revision
<lifeless> (bundle/send/whatever)
<beuno> lifeless, maybe just send me the whole branch?  should be small enough
<lifeless> beuno: I have :P
<lifeless> 401K including its own index :P
<beuno> lifeless, very very very cool  :)
<beuno> and, fast as hell compared to other apps to doing this
<abentley> lifeless: create a branch that lacks that revision and use it as the submit branch
#bzr 2008-06-18
<lifeless> abentley: do you think it would be unreasonable to have a flag to control this?
<abentley> lifeless: No.
<spiv> I know bialix already tried arguing for such a thing.
<spiv> It does feel like sometimes send is trying to insist it knows better than the user.
<abentley> spiv: everyone just complains about the way it is, but no one proposes a solution.
<abentley> spiv: It does.
<spiv> abentley: lifeless just proposed a flag just a second ago :P
<lifeless> abentley: ok, I'll put doing such a flag on my queue
<igc> morning
<abentley> spiv: What does the flag do?
<spiv> abentley: don't know, you just said "No" rather than asking ;)
<lifeless> abentley: there was a double negative - 'not unreasonable'
<abentley> spiv: two options are: 1. force it to use the revision spec 2. supply a second revision spec.
<lifeless> abentley: I would have defaulted to doing 1, do you think 2 is better?
<abentley> lifeless: Yes, if you're also cherrypicking.
<lifeless> abentley: as it happens I am; ok.
<abentley> lifeless: So presumably you want to force it in order to choose a revision older than the base of your revision spec.
<abentley> Is that right?
<abentley> spiv: And I do think that send's overcaution is warranted.  It's very hard for users to know when they've done it wrong.
<abentley> It's only when someone else has to get them to resend it that they find out.
<lifeless> abentley: so for me I wanted to send beuno my last commit
<lifeless> abentley: lp was offline
<abentley> lifeless: Do you have a local mirror of trunk?
<lifeless> as a user I imagined that if I did a cherry pick, it would include the data for the cherrypick (because I know it will grab *more*, I didn'tknow it would grab less)
<lifeless> abentley: I am trunk
<lifeless> (as in, yes, I have trunk, I am hacking on trunk, and I only have one local branch)
<abentley> So are you trying to send beuno everything he doesn't already have, or just specific changes?
<lifeless> just a single commit to trunk that he didn't pull before lp went to maintenance
<lifeless> the command I tried was 'send -r -2..-1', which had the right diff, but no data
<lifeless> erm, 'send -r -2..-1 . . ' for full disclosure :P
<abentley> Okay, so in this case, option 1 works.  You don't want him to apply a cherrypick, you want to send everything he doesn't have.
<lifeless> right, I'd be happy with a flag that said 'use the range to select what to copy even if it looks like its there'. But perhaps thats not enough for everyone...
<abentley> If you wanted him to apply a cherrypick of 4..5, but he only had 2, option 1 would break.
<lifeless> abentley: yah
<lifeless> abentley: I have an alternative idea though, what if 'send' never sent _less_ than the selected range?
<lifeless> abentley: and there was a flag to tell it to send less if needed
<lifeless> s/needed/possible/
<abentley> Seems like pointless irregularity to "never send less" than selected range.
<lifeless> I think it would have prevented the other folk with this issue experiencing problems, and it would have done what I naively expected it to do
<abentley> so the model is, -r selects what changes to apply, submit_branch determines what revisions are needed to do that.
<jam> I think forcing the minimum number of deltas to send would satisfy the majority of users that are bit by 'bzr send' not sending their revisions
<abentley> I don't think your proposal would have helped igc last week.
<jam> abentley: I did say "majority"
<jam> he would still need to use an appropriate target, but he could at least do
<jam> bzr send -rthread:
<jam> bzr send -rthread: ../bzr.dev
<jam> Which would select the right revisions to show in the diff
<jam> and the right revisions to include in the bundle
<abentley> jam: i.e. no different from now.
<jam> abentley: right, but everyone else who wants to do "bzr send -r -2..-1" would also benefit
<jam> which is what bialix wanted orignially
<jam> as he just wanted to send what he had worked on
<jam> and knew where things were
<jam> having to create a "temp" branch is sub-optimal
<abentley> jam: it shouldn't be temp.
<abentley> Branches are fantastically cheap, and you need to keep track of what other people don't have if you want to send stuff to them.
<abentley> a branch is a good way to do that.
<jam> abentley: they aren't very cheap untless you have --no-trees set
<lifeless> abentley: so thats the problem - there was no way in advance to predict that the common reference point - 'trunk' - would be unavailable to beuno
<jam> really, they aren't
<jam> especially when I'm just working on a simple bugfix for a plugin
<abentley> jam: I mean if you have --no-trees, of course.
<jam> the big thing about plugins is that I work on them "in-place" because I want to test what I'm doing
<jam> so I have to force another trunk branch
<jam> and put mine in place, etc
<abentley> jam: If it's casual hacking, you can just use the public branch as the submit branch.
<jam> abentley: sure, but it is a whole lot longer to type than just "-r -2"
<jam> I have to remember it, etc
<abentley> So I am quite convinced that option 1 isn't powerful enough, option 2 is too complicated, and option 3 makes send impossible to understand.
<jam> I don't see how it is impossible to understand, but unfortunately it is family time
<jam> hopefully we can discuss more later
<abentley> jam: okay.  The basic reason is that it makes the model more complicated, because sometimes it does X, sometimes it does Y, and so you never know what it's going to do.
 * beuno is off to a dinner
<lifeless> train time
<beuno> bbl
<abentley> jam: If people don't grasp send now, making what it does more complicated isn't going to help.
<jam> >= X is (IMO) *easier* to understand because it fits more what people expect
<jam> specifically if I give a range, it includes that range
<poolie> jam, are you still here?
<jam> poolie: off and on
<poolie> jam, i was going to ask about that xcross bug but jml just turned up and he's been working on it too
<jam> poolie: you got my emails, right?
<poolie> i did
 * mwhudson wishes for an after: revisionspec
<spiv> mwhudson: there could be lots of revisions that would match, though.
<mwhudson> spiv: it's clear enough for a mainline revision, isn't it?
<mwhudson> i mean, before: could match >1 revision too...
 * igc gets some breakfast
<mwhudson> (i presume it always takes the left hand parent, though 'help revisionspec' doesn't actually say this)
<spiv> mwhudson: That's true.  Possibly even for non-mainline revisions if you define an appropriate ordering (e.g. based on our current dotted revno scheme, i.e. topological based on when branches were merged to mainline)
<spiv> mwhudson: right, before: always takes the left hand parent AFAIK.
<mwhudson> spiv: basically, bzr log --short submit:.. is *almost* want i wanted to see
<spiv> mwhudson: sounds like there's a bug report/feature request or two to be made :)
<mwhudson> well
<spiv> (I mean, made somewhere more permanent than IRC)
<mwhudson> actually i think i want bzr missing --mine-only
<mwhudson> --short
 * mwhudson makes an alias
<abentley> jam: It can't make it easier to understand, since they also need to understand the normal behavior.
<poolie> spiv, where are you?
<spiv> poolie: on the 10:30 train
<spiv> eta about 11:10 I guess.
<poolie> ok
<jml> hitchhiker is pretty cool
<markh> jam: you around?
<poolie> lifeless: you said "The thing is, they are xml's that are being asked for" but is it guaranteed at this level that the fulltext inventories are xml?
<poolie> ok review for the last non-test files sent
<spiv> Have sent reviews of a few more test files, about to tackle test_knit.
<lifeless> poolie: the calling code expects xml
<lifeless> poolie: if its not it will blow up
<jam> markh something resembling around
<jam> weird, markh isn't present, but I don't see a disconnect for him
<mwhudson> * markh has quit (Read error: 104 (Connection reset by peer))
<mwhudson> 8 minutes ago
 * igc lunch
<spiv> jam: I just gave him a ping
<spiv> jam: he'll be on again in a sec
<jam> mwhudson: yeah, mine doesn't have that line
<jam> spiv: if you want, ping poolie and lifeless if they are there
<jam> they both wanted to talk with me
<jam> or, I guess, *poke* them for me :)
<markh> jam: you have a sec to share your recent experiences building the windows installer?
<jam> sure
<jam> once I got dependencies done
<markh> so, I saw a docutils error - did you see that?
<poolie> jam, hi
<jam> it was mostly just "make installer"
<markh> yeah, but that grinds to a halt at a couple of places for me :)
<jam> I'll try real quick
<jam> I haven't done it since 1.5
<markh> oh, roght
<markh> sorry - I thought you did the most recent binaries
<jam> markh: I didn't know someone *did* newer binaries
<jam> I have to do a few quick hacks to the makefile myself
<jam> namely, adding "-c mingw32" to the build lines
<jam> make installer PYTHON=/cygdrive/c/python25/...
<jam> since I use Make from cygwin
<jam> but win32 python
<jam> markh: this time, it got all the way to wanting to run "cog.py" for me
<jam> which means all of the .html files built fine
<markh> my problem with docutils is the same as Alex reports many months ago via https://lists.ubuntu.com/archives/bazaar/2007q4/035100.html - I get the same results with docutils 0.4, the "snapshot" on their site, and also the svn version
<markh> the issue appears to be the "." in the option name
<jam> markh: I seem to be using docutils.__version__ == 0.4
<markh> I started with 0.4, but now have 0.5
<jam> I do remember the --pack-0.92 being an issue
<markh> The problem doesn't appear on Linux either - but the fact Alex and I both saw it many months apart means there is *some* issue here
<markh> yeah, that is it
<jam> I thought we sorted it out somehow
<markh> maybe I need to "clean" my tree somehow?  Its certainly up-to-date though
<jam> markh: look at tools/rst2html.py
<jam> There is a workaround if "docutils.__version__ <= 0.4.1"
<markh> ah - ok, thanks - I'll dig a little more.
<jam> markh: it may be that the hack just needs to be updated for whatever version
<markh> I started with 0.4 though - I'll need to dig a little
<markh> so, apparently I already had 0.5 installed and trying to install 0.4 over the top left 0.5 in place.  It does look like the "." issue isn't fixed in docutils svn, so maybe that version check should just be removed completely?
<whitelynx> I've been looking through the bzrlib api docs for some way to get the username of the author of a given commit; can anyone point me in the right direction?
<whitelynx> i have a branch object to work with, and i just need the username of the author of the most recent revision
<mwhudson> the most recent revision is
<mwhudson> last_rev = branch.repository.get_revision(branch.last_revision())
<mwhudson> then last_rev.get_apparent_author()
<whitelynx> aah, i missed .repository
<whitelynx> cool
<whitelynx> thank you very much :-D
<mwhudson> np
<sabdfl> hi folks
<thumper> hi sabdfl
<mwhudson> hello sabdfl
<sabdfl> hi folks
<mwhudson> yay, i have loggerhead running without turbogears or cherrypy
<beuno> mwhudson, :) :) :)
<beuno> now, if you can do something about files changed, we can drop sqlite too!
<mwhudson> but using the loggerhead.conf gile
<mwhudson> which is the new bit
<beuno> mwhudson, I looked up to revno 186. Did you do more work after that?
<lifeless> beuno: wb
<lifeless> hi sabdfl
<mwhudson> beuno: i just pushed 187
<beuno> howdy lifeless. I'm pushing the last changes to my clean url branch, and bzr-super-search is up  :)
<lifeless> beuno: online demo?
<mwhudson> well, i'm ignoring some bits of the config file
<mwhudson> which i probably shouldn't ignore
<lifeless> mwhudson: you know about 'get_public_branch' ?
<Peng> "Is it possible the remote side is supports RPCs for a given version?"?
<mwhudson> lifeless: yes, what about it?
<lifeless> mwhudson: for the gnome bug on 'download command'
<mwhudson> lifeless: oh right, yes
<beuno> mwhudson, pushing my changes to clean urls. It's basically work on annotate.
<mwhudson> beuno: ok, i still haven't gotten around to looking at it properly :)
<beuno> "Rev 187: woohoo it works"   -> lol
<mwhudson> yeah, i'm not very good at super professional commit messages
<beuno> that's pretty descriptive to me  :p
<beuno> mwhudson, it may be a good idea for start-loggerhead.py to stop asking for Turbgears on that branch now
<lifeless> beuno: can you run up super-search on your adsl or something ?
<lifeless> beuno: I don't have LH running anywhere yet
<mwhudson> beuno: oh yeah :)
<beuno> lifeless, I absolutely can, and will
<beuno> mwhudson, one more thing. I'd *really* like to change python2.4 to python on the start/stop header. It works perfectly with python 2.5 (I constantly have to shelve it because I change that manually)
<beuno> is there some other reason not to change it that I'm missing?
<mwhudson> i really can't think of one
<beuno> :)
<beuno> I discovered -f -C on start-loggerhead, so I don't have to comment out the deamon out to test
<mwhudson> ah :)
<mwhudson> what does -C do?
<mwhudson> oh something dumb with pidfiles
<beuno> makes sure it's not already running
<beuno> yes
<beuno> I have a bug sort of related to that
<beuno> close and open it enough times, and, eventually, you'll have to kill -9 it
<mwhudson> i wonder what people use for serving their wsgi applications for real
<mwhudson> i'm not sure it's paste.httpserver
<lifeless> beuno: tell me when its up :)
<beuno> lifeless, putting it together now. I'll ping you the second it does something
 * Peng runs away.
<spiv> We have BUGFIXES and BUG FIXES sections in our NEWS file.
<spiv> In the same release in some cases.
<Peng> Of course. Everyone knows that "BUGFIXES" is for when the fix is more important than the bug and "BUG FIXES" is for when the bug is more important.
<Peng> Duh.
<Peng> :)
<spiv> Peng: Hmm, I thought maybe BUG FIXES was for the case when introducing a bug fixed something else ;)
<Peng> Hmm, that too.
<poolie> i think separate words is (are?) better
<mwhudson> mmm, wsgi makes it a bit harder than it could be to test things
<lifeless> poolie: 'are'
<mwhudson> oh well
<poolie> hm ok we already had a thread about forums
<lifeless> poolie: pull --overwrite from http://people.ubuntu.com/~robertc/baz2.0/versioned_files
<lifeless> beuno: some trouble ? (just keen to see it :P)
<beuno> lifeless, not really, it just takes a lot of time with template and all  :/
<beuno> I should have something working in a few minutes
<beuno> me and simpletal don't agree on how I can output HTML
<lifeless> heh
<Peng> poolie: I swear I'll do something actually useful one day, but until then, trivial typos are still nice to fix.
<beuno> lifeless, apart from that, everything is in place, so it's just a matter of working out the quirks now
<lifeless> beuno: cool. I thought from your earlier comment it was already done :)
<beuno> lifeless, just the javascript bit, I had to glue stuff together now
<beuno> templates put a lot of overhead to the process
<beuno> mwhudson's wsgi branch will change that  :)
<mwhudson_> next steps with that branch are making it less of a hack, i think
<mwhudson_> (and thinking about how to test it)
<beuno> yay!  sort-of-works
<beuno> lifeless, need to fix a small glitch, and I'll send you the URL  :)
<lifeless> Â©ol!
<epsy> hi
<epsy> i have a problem, bzr just crashed
<Peng> go on
<epsy> since user avatars aren't that useful to be versionned, i did a bzr rm --keep on the images/avatars dir
<epsy> now this is what i get:
<epsy> bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: images/avatars/upload
<epsy> parent of: (('images/avatars/upload', '5ef0e1b75641934ad6285db9860c3a40_97.jpg', '5ef0e1b75641934ad628-20080427193459-5bbck3mpjk6eryxr-135
<epsy> 9'), [('f', '0c0cad69edec800fc7b17e76719263785e7d07f2', 55692L, 0, 'AADZjEevoDtHr6A7AAAAGAI3NioAAIG2'), ('f', '0c0cad69edec800fc7b17e76719263785e7d07f2', 55692L, 0, 'xclan@fiji-20080427193835-i2lnc7oj8cj54cq9')])
<poolie> what command were you running?
<epsy> images/avatars/upload/5ef0e1b75641934ad6285db9860c3a40_97.jpg doesn't exist
<epsy> bzr status and bzr diff
<epsy> should i pastebin the traceback?
<poolie> epsy: can you file a bug for it please?
<epsy> ok, i'll do in the evening
<poolie> i suspect it has removed the directory but not the subdir or something
<poolie> thanks
<epsy> looks like
<lifeless> beuno: if you can leave the demo running once its working, I'll show it to Jc2k and bkor when they get up
<lifeless> beuno: I have to go catch a train now, back on line in ~1hr15
<beuno> lifeless, hold on 2'
<beuno> and I'll show you *something*
<lifeless> ok
<beuno> lifeless, http://200.127.6.219:8080/bazaar/bzr_garbage/changes
<lifeless> beuno: nice
<beuno> of course, it's just something thrown on the page. There should be a floating diff and all that
<lifeless> beuno: better in a drop down etc etc :)
<beuno> exactly  :)
<lifeless> beuno: also, it doesn't seem to handle two terms correctly (like if you type "fetch c" into the box)
<epsy> bbl
<lifeless> it should as for index.suggest([('fetch',), ('c',)])
<lifeless> but yeah - coolness
<beuno> lifeless, yes, I had to work around an issue where it transformd any string into a list of characters
<lifeless> and nifty fast given the link etc
<lifeless> ok train time
<lifeless> but you rock
<beuno> lifeless, I'll have something better when you come back  :)
<beuno> mwhudson_, ^
<mwhudson_> beuno: it doesn't seem to find anything
<mwhudson_> beuno: but i like the idea :)
<beuno> mwhudson_, really?  it doesn't find terms as you type?
<mwhudson_> beuno: no, when you press return
<beuno> it's the bzr-search branch
<beuno> so I'd suggest something like "test"
<mwhudson_> oh
<beuno> and, it tries every 200ms, so don't be un a hurry to type  :)
<mwhudson_> ok
<mwhudson_> but if you type rober
<mwhudson_> it suggests robert
<beuno> yes
<mwhudson_> but searching for robert doesn't give any hits
<beuno> well, that's because I broke search while doing this
<mwhudson> :)
<beuno> I was running against a train, so made a few exceptions while coding  :p
<spiv> Heh.
<mwhudson> #bzr: championing Train Driven Development
<beuno> hahaha
<beuno> I always stick with TDD  :)
 * beuno hides from vila 
<vila> beuno: better late than never ;-p
<mwhudson> interesting
<mwhudson> you have a/b versioned
<mwhudson> bzr mv a/b b
<mwhudson> bzr rm a
<mwhudson> oh, modify b
<mwhudson> then bzr rm a
<mwhudson> -> cannot remove modified file
<lifeless> back
<beuno> damn, too fast  :p
<beuno> I did fix search and whatnot
<lifeless> cool
<beuno> and pushed the branch
<beuno> trying to make the drop down more ajaxish
<Jc2k> this sounds shiny
<Jc2k> the evil plan worked, i guess
<lifeless> indeed it did muahahaha
<mwhudson> morning Jc2k
<Jc2k> morning :) or evening.. :)
<liw> I'm trying to apply a bundle I got via e-mail, and I get this: bzr: ERROR: Revision is not compatible with KnitRepository('file:///home/liw/p/python-coverage/upstream/.bzr/repository/')
<liw> what am I doing wrong?
<Peng> liw: You're using different types of repositories (one probably has rich roots)
<liw> so I need to ask the bundle submitter to switch to a different type of repository? that's inconvenient
<lifeless> liw: are you using bzr-svn ?
<Peng> liw: Run 'bzr info'. What format does it say you're using?
<liw> lifeless, nope, plain bzr
<lifeless> liw: bzr tries to preserve this, something strange has to have gone on to cause this
<liw> Standalone tree (format: dirstate)
<Peng> Yikes.
<Peng> That's ooold.
<lifeless> liw: I suspect they branched into a rich-root repository, and thats caused the bundle to have data your repository can't represent
<lifeless> liw: we want to change teh default and have everyone upgrade
<liw> so what should I do?
<liw> hmm, my local branch is made from the branch on my web server, if I "bzr upgrade" that one, and make a new branch locally, it has dirstate-tags
<liw> but still no luck merging the bundle
<mwhudson> you probably need --dirstate-rich-root or whatever it's called
<mwhudson> or --rich-root-pack
<mwhudson> these are repository upgrades, not branch upgrades, fwiw
<liw> what's the difference between --rich-root and --rich-root-pack?
<jml> liw: the first is rich root with knits
<jml> liw: the second is rich root with packs
<jml> I think.
<lifeless> liw: first, talk to yourr contributor and figure out what happened
<lifeless> liw: secondly, I'd apply the bundle with patch :P
<Peng> jml is correct.
<liw> jml, that is not entirely informative to me, being as I'm ignorant about bzr internals :)
<Peng> liw: Packs are the awesome new(er) repository format. They're fast and stuff.
<lifeless> liw: there are two dimensions
<liw> "bzr help formats" isn't particularly useful for choosing, either, imo
<lifeless> liw: disk representation
<lifeless> liw: and semantic structure
<lifeless> liw: 'rich root' is in the second and is not backwards compatible
<liw> lifeless, can we pretend for a  moment that I don't care about implementation details and just want to pick a format? :)
<Peng> liw: pack-0.92
<spiv> liw: you almost certainly want the default format (pack-0.92)
<lifeless> liw: *you should not change anything*
<lifeless> liw: I gave you isntructions above
<spiv> Your contributor seems to be using a non-default format though, and it would be good to find out why.
<spiv> Anyway, listen to lifeless :)
<Peng> Hmm, I guess signed messages on the list (or at least those with attachments) use PGP/MIME?
<liw> lifeless, yeah, I'm asking him, but in the mean while, I already ran "bzr upgrade" :)
<liw> lifeless, before you said anything, even
<ToyKeeper> lifeless: So, you're working on making bzr use a single storage format?
<Peng> ToyKeeper: Ideally, there would be one perfect format, and they're working toward that. The only reason there are multiple formats is to be able to make backwards-incompatible improvements, and because some are experimental.
<ToyKeeper> Well, finding the best way to organize the data is a good goal, and not at all simple.  :)
<lifeless> liw: 'bzr upgrade' on its own is fine and safe
<lifeless> Peng: my mails probably do
<lifeless> Peng: rfc 16?? IIRC
<Peng> lifeless: Yeah, I think so. You use Evolution, and the details are entirely different from Thunderbird/Enigmail's PGP/MIME, but it seems to be doing the same thing.
<Peng> Not only did I send a really trivial patch, signed with an untrusted gpg key, but I didn't use PGP/MIME, so the patch itself wasn't signed. :D
<beuno> aaaaaaaanyway, I'm off to bed
<beuno> lifeless, nicer way of showing suggestions will land soon-ish, but not today  :)
<beuno> pushed everything to LP  :)
<beuno> I'll leave LH running in case you want to play around more
<poolie> ok that's enough for me
<lifeless> poolie: night poolie
<lifeless> beuno: its looking promising all the same
<ToyKeeper> D'oh...  noticed a typo 5 seconds after submitting a bug.
<lifeless> :P
<lifeless> should I close it with 'bzr-aspell' is a good idea?
<ToyKeeper> Heh, not a spelling error...  the grammar was broken after re-arranging some phrases.
<ToyKeeper> Maybe I should just file another one...  "launchpad needs an 'oops' button".  :)
<mwhudson_> there is a bug for "i should be able to edit my comment for a while after posting it"
<ToyKeeper> Yeah, kinda figured that one would already exist.  And there is a function to edit the original bug description.  :)
 * igc dinner
<mtaylor> hey all
<mtaylor> if I've got a revid
<mwhudson> hello mtaylor
<mtaylor> hi mwhudson
<mtaylor> and I want to find the revno
<mtaylor> either of that revid
<mtaylor> OR
<mtaylor> of the left-most revision that contains that revid
<mtaylor> (since revision_id_to_revno won't work on revids that are sub-sets of a merge)
<mtaylor> is there a sensible way to do this that I'm missing?
<mwhudson> you want to find the revno of the mainline revision that merges your revid?
<mtaylor> yes
<mwhudson> and are we talking programmatically or just now and then in the shell?
<mtaylor> programattically
<mtaylor> this is for inside of a post-push email hook
<mwhudson> i don't think there's a very clean way of doing this
<mtaylor> so, just in case I'm missing something _else_...
<mwhudson> i guess you can keep taking the left hand parent until you get a revision that's in the revision_history of the branch
<mtaylor> how do I get the left hand parent?
<mtaylor> do I have to get the repository first?
<mtaylor> gah. how about get_parent
<mwhudson> branch.repository.get_revision(revid).parent_ids[0]
<mtaylor> oy
<mtaylor> ok
<mtaylor> mwhudson: is there a chance that given a revid I will keep trying that and get in to an endless  loop somehow?
<mwhudson> mtaylor: no
<mtaylor> ok. good
<mwhudson> and if you know that the revid is in the branch, you'll definitely get a mainline revision eventually too
<mwhudson> hang on
<mwhudson> i think i've been giving you bogus advice :(
<mwhudson> mtaylor: you want to know the revision that _merged_ the revid you've got, don't you?
<mtaylor> yes
<mwhudson> do you expect it to be a recent revision that merged it, or could it be arbitrary?
<mtaylor> I expect it to be recent (this is in post-push, and I'm doing this on old_revid
<mwhudson> (i've been telling you how to find the common ancestor of branch tip and your revid)
<mwhudson> mtaylor: then
<mwhudson> hm, i have code sort of for this even somewhere
<mtaylor> mwhudson: I essentiall want to get a revno I can pass to log.show_log()
<mtaylor> mwhudson: to get the diff of what was just pushed
<lifeless> mtaylor: you have a revid
<mtaylor> can I pass a revid to show_log()
<lifeless> mtaylor: erm, why are you using log to get a diff ?
<lifeless> 'revspec' handles user input to revnos and revids
<mtaylor> lifeless: what should I use instead?
<lifeless> passing revid:REVISIONID to a revspec will do what you need, but I'm confused why you wouldn't use diff :)
<mtaylor> lifeless: this is in a plugin?
<mwhudson> oh eh
<lifeless> mtaylor: nope, core. also have you looked at the email plugin and what it does?
<mwhudson> you have a much easier problem than you suggested i think :)
<lifeless> mtaylor: I'd really expect the sort of thing you want to be part of the email plugin TBH
<mtaylor> lifeless: yes... this is actually a fork of email plugin
<mwhudson> mtaylor: this is the code to do the hard thing: http://pastebin.ubuntu.com/21114/ :)
<mtaylor> mwhudson: sweet!
<mwhudson> mtaylor: listen to lifeless though
<mtaylor> ok
<mwhudson> mtaylor: but it sounds like bzr diff -r revid:old_revid is what you want
<lifeless> well, the post commit hook already handles all of this
<mtaylor> yes. that is exactly what I want
<lifeless> because a commit can move more than one revno (especially in bound branches)
<mtaylor> lifeless: yes. but the post commit hooks inputs are a little different than the info given to post-push
<mtaylor> because revnos don't change in post-commit
<lifeless> yes they do
 * mtaylor looks at code again...
<lifeless> (uncommon, but its possible to change revnos by doing a commit, if the right hand parent of the tree is the tip of the branch and the left hand parent is deeper in the branch)
<mtaylor> so, bzr-email does this: self.revno = self.branch.revision_id_to_revno(self._revision_id)
<mtaylor> ahh.. hang on
<mtaylor> lifeless: ok... I was looking in the wrong area. I think I see what you're talking about now
<mtaylor> lemme give this a try
<mtaylor> ok.
 * mtaylor has been stating the problem incorrectly
<mtaylor> I'm not crashing in the diff code when the revnos change, I'm crashing in the log code (thus why I was using show_log)
 * mtaylor smacks self in head
<lifeless> :)
<uws> jelmer, bkor, Jc2k: FYI, I've blogged about my Gnome Bazaar/SVN import experience here: http://uwstopia.nl/blog/2008/06/importing-bazaar-branches-into-gnome-svn
<Jc2k> cool :)
<lifeless> uws: if you'd like gnome to move to bazaar, you could note that in that post :)
<lifeless> uws: like 'but hopefully only temporarily, if we move to bazaar' :)
<uws> lifeless: good idea :)
<uws> lifeless: refresh, first paragraph
<uws> lifeless: another update, 3rd paragraph
<Jc2k> uws: i've been a bad boy and moved /BzrForGnomeDevelopers to /Bazaar. i dont know how to make it auto forward, so there is an extra click right now..
<lifeless> uws: hasn't updated for me :X
<uws> Jc2k: update
<uws> lifeless: ctrl-shift-r ?
<lifeless> http://uwstopia.nl/2008/06/gnome-specimen-now-in-gnome-svn is a 404 too
<Jc2k> awesome :)
<Jc2k> http://uwstopia.nl/blog/2008/06/gnome-specimen-now-in-gnome-svn works for me
<uws> lifeless: your missing the "/blog" part at the start of the url
 * uws updates link..
<uws> lifeless: now it works
<lifeless> that was the link I saw :P
<lifeless> ah, the network effect is live and well :)
<lifeless> still, nice
<Jc2k> uws: should the bzr push --remember svn+ssh://svn.gnome.org/svn/gnome-specimen/branches/import-from-bzr/ be pointing at trunk now?
<uws> I think I've done my share of bzr pimping for today :)
<uws> Jc2k: oops, sure
<uws> Jc2k: More suggestions, fixes, comments?
<Jc2k> uws: looks good :)
<lifeless> Jc2k: did you see http://200.127.6.219:8080/bazaar/bzr_garbage/changes ?
<lifeless> Jc2k: type in the search box there
<Jc2k> lifeless: no
<Jc2k> *looks*
<lifeless> (imagine that the hits are in a floating frame etc etc
<mwhudson> beuno: you have an interesting (i hope) mail
<mwhudson> but i really hope you're asleep
<uws> Is there a way to to tell bzr log to show all commits in the po/ directory?
<uws> bzr log po/    only shows the revision in which that directory was added
<mwhudson> mm, 22:00, time for dinner
<uws> and bzr log po/*.po  doesn't work either
<lifeless> I think there is a bug open
<lifeless> definitely want to do that efficiently
<uws> 1200, itme for lunch :)
<Jc2k> lifeless: it doesnt seem to do anything?
<lifeless> Jc2k: so if you type 'te' in the search box and don't press enter or anything
<lifeless> a completion list should appear at the top of the page
<Jc2k> lifeless: i get FF3 history based auto complete, and nothing else..
<lifeless> Jc2k: not as a popup
<lifeless> as black text - python tuples
<lifeless> # ('telling',)
<lifeless> # ('term',)
<lifeless> # ('term1',)
<lifeless> etc
<Jc2k> ah, firebug says there are some GET's outstanding
<Jc2k> they are taking their time ;)
<lifeless> hmm
<lifeless> it was near-instant for me before :)
<lifeless> beuno: are you still up ? :P
<Jc2k> i have timeouts showing in firebug now :(
<lifeless> so, I think his home machine is shut down now
<lifeless> the main page is timing out too
<Jc2k> ah
<lifeless> https://code.edge.launchpad.net/~beuno/loggerhead/bzr-search_integration
 * Jc2k imagines autocomplete goodness
<lifeless> :P
<beuno> argh, I can't sleep
<beuno> Jc2k, try again  :)
<beuno> mwhudson, just saw the email, I'll see what can be done about it. Thanks for the review
<mwhudson> beuno: oh dear
<beuno> I
<beuno> I'm going to skip sleeping tonight, that should make it easier tomorrow   :)
<Jc2k> veeerry cool beuno :)
<beuno> Jc2k, thanks. It
<beuno> argh
<beuno> it's all based off lifeless' fast-growing bzr-search
<beuno> it needs some UI love
<lifeless> Jc2k: ah you've seen it work ?
<Jc2k> lifeless: ys :)
<Jc2k> having that, "clean urls", a skinned loggerhead, and bzr-search indexes for GNOME - doable by GUADEC?
<beuno> Jc2k, when is guadec?
<Jc2k> july 7th to 12th
<beuno> Jc2k, yes, doable in trunk at the very least
<Jc2k> (there is a big DVCS talk going down..)
<beuno> (not sure when we're releasing 1.6)
<Jc2k> excellent, i fear not the trunk ;)
<beuno> Jc2k, are you going to be skinning it?
<Jc2k> trying, at least
<beuno> Jc2k, how much does it have to look like the current gnome.org?
<Jc2k> beuno: at the very least i want to stick the standard GNOME header on it: http://bzr-mirror.gnome.org/
 * beuno goes make coffee and pretends he just woke up
<Jc2k> there is some standard HTML for that, i dont see a problem there
<beuno> Jc2k, I can get that done for you
<Jc2k> cool :)
<beuno> there is a new theme coming up, but I don't know how close to that date we'll have it finished
<beuno> I'll make sure we can switch at the last moment if we happen to make it
<beuno> mwhudson, so... we're aiming at making bzr-search *the* search for LH, right?   Just so I know how much time I can shift into it
<mwhudson> beuno: sure
<beuno> yay!
<beuno> we should put together a roadmap of some sort at some point
<beuno> and/or keep filing bugs, I suppose
<beuno> lifeless, btw, "bzr search -s Robert C", *just* searches for "C"
<dato> maybe try -s 'Robert C' ?
<lifeless> beuno: not for me
<beuno> dato, right, makes sense. I'm being stupid, thanks  :)
<lifeless> actually 'Robert C' is different
<lifeless> it is a phrase
<beuno> beuno@beuno-laptop:~/bzr_devel/bzr.dev$ bzr search -s Robert C
<beuno> Suggestions: [('C',), ('CA',), ('CAUTION',), ('CHANGES',), ('CHECK_ALWAYS',),
<beuno> (and a very long etc)
<lifeless> on bzr search itself, doing 'bzr search -s Robert C' is missing  ('Coming',),
<lifeless> compared to bzr search -s C
<lifeless> do this:
<lifeless> :!bzr search -s C | grep Coming
<lifeless> :!bzr search -s Robert C | grep Coming
<beuno> right, what's it doing differently?
<Jc2k> so if i have branches with trees, can i make them treeless?
<Kinnison> yes
<mwhudson> bzr remove-tree
<Kinnison> bzr remove-tree [LOCATION]
<Jc2k> ahh, awesome
<Kinnison> there may also be a bzr reconfigure option but I don't know it
<Jc2k> i dont suppose there is a command to do that to all the branches under a repository?
<Kinnison> aah, erm
<Kinnison> you wanted a no-trees repo didn't you?
<mwhudson> for b in `bzr branches`; do ...; done
<mwhudson> ?
<Jc2k> eh, i did. and i dont fancy rerunning the conversion on 20gb of svn ;)
<mwhudson> though bzr branches is a bit funny, if the mailing list be live
<mwhudson> well, you can create new repos, treeless
 * Jc2k goes to poke
<mwhudson> and pull the branches into them
<Jc2k> i might just run the conversion again now i have a stable(ish) python-subversion
<Jc2k> my initial run was a mixture of pulling trunk a 1000 at a time, then running bzr svn-import afterwards to get branches
<Jc2k> so my trunk has tree, and the branches don't
 * Jc2k shrugs
<lifeless> beuno: first it searches for Robert
<lifeless> beuno: then it searches for terms begginning with C
<lifeless> beuno: and for any term that begins with C, removes it from the result set _unless_ it turns up in one of the documents that the search for Robert found
<lifeless> beuno: or in english, it only suggests things beginning with C that are relevant to things matching Robert
<beuno> lifeless, ah. Sounds advanced for such a inocent search
<beuno> but very cool to have
<lifeless> well I figured there was no point suggesting something, if they were to put it in and get no results back
<beuno> maybe that could be clearer on the UI, adding on top "All results for 'Robert' also containing 'C'"
<beuno> s/containing/begin with
<beuno> but of course, I'm getting picky
<lifeless> sure, see the commit saying 'crap ui' or something similar :P
<beuno> heh, yes. I may give that some lovin as soon as get it properly working in LH
<lifeless> I would say
<lifeless> "Suggestions for terms starting with 'C' and matching [('Robert',)]"
<lifeless> (in the absence of nice query print-outs
<lifeless> or something like that
<beuno> yes, that works better
<weigon_> how can I read back the property added by "bzr commit --fixes ... " ?
<weigon_> up to now I only saw it in bzr-gtk
<jelmer> launchpad will also recognize it
<jelmer> and the API exposes it, of course
<jelmer> I don't think there's anything in the command-line UI that exposes it atm
<weigon_> is it exposes as bzr <command> somehow ?
<weigon_> I would like to see it as part of bzr log --long
<james_w> I don't believe there is
<james_w> I think there was some work to expose it there, but I don't know where it got to
<awilkins> What do y'all bzr vets think of bug #240910 ?
<ubottu> Launchpad bug 240910 in bzr "ChrootServer cannot serve "root" of windows filesystem." [Undecided,New] https://launchpad.net/bugs/240910
<lifeless> it would be good to serve repositories on C and D simultaneously
<lifeless> though, given you expose the whole FS, is it a good idea ? :P
<awilkins> Not a good idea no, my beef is more with the sshd support being restricted to C:\
<lifeless> oh, clear bug, must fix
<awilkins> Cygwin sftp works ok, as long as you use the /cygdrive/ roots
<awilkins> So it's not a total showstopper, but obviously "smart" is intended to be the best game in town
<awilkins> I think LocalTransport supporting "None" as a base would possibly work, but I'm not knowledgeable enough to know how many disasters that would cause in the rest of the code :-)
<lifeless> mmm, file:// should be the root
<lifeless> for unix file:/// is /, forwindows file://C|/ is, IIRC the mangling folk do correctly
<Kinnison> Is there a way to usefully get (in shell) the list of associated branches for a given branch?
<lifeless> info
<awilkins> lifeless: Problem is that something in there resolves "/" to "file:///c:/" as the base of the LocalTransport for "/"
<lifeless> yes, bug :)
<lifeless> its probably related to CWD
<Kinnison> lifeless: sorry. Is there a way to get the information in a form which is useful for shell scripts?
<Kinnison> E.g. I'm imagining something like 'bzr get-related --parent [LOCATION]'
<awilkins> lifeless: I thought the root of the problem might be in urlutils._win32_local_path*
<awilkins> One emits the drive path for '/', the other chokes on a bare file:// uri
<lifeless> Kinnison: not so much, no. perhaps a trivial python helper ?
<lifeless> awilkins: I'm not sure, and its 10pm :)
<Kinnison> lifeless: Hmm, that's about as far as I had gotten. Aah well. I might go for refactoring bzrlib.info so that it can output all the info as a series of shell assignments or something similar
<Kinnison> lifeless: having bzr info --shellvars would be handy
<awilkins> lifeless: I shall hack my bzrlib about a bit longer then give up :-)
<awilkins> (for the afternoon, anyway)
<lifeless> Kinnison: sure, you know the drill :)
<Kinnison> lifeless: aye, but 'tis lunchtime now
 * Kinnison waves
<mtaylor> mwhudson: I wound up using that code you pasted for me. works like a champ
<mtaylor> mwhudson: not the world's _quickest_ mechanism... but it doesn't crash, which is a big improvement
<awilkins> lifeless : I think special cases for "file://" and '/' in urlutils fixes that bug
<awilkins> Just running the test suite.
<awilkins> 22/11041 (god this laptop  is wslow0
<mwhudson> beuno: if you get the chance, can you take a look at wsgi-ify?
<mwhudson> i think it's pretty much ready to merge once zpt.cleaner_urls gets in
 * mwhudson goes to bed
<lifeless> gnight all
<beuno> mwhudson, yeap, I've been following the commits, but I'll take a look at is as a whole
<lifeless> beuno: partial reads for suggestions now:
<lifeless> bzr.dev$ time bzr search -s f > /dev/null
<lifeless> real    0m0.723s
<lifeless> user    0m0.628s
<lifeless> sys     0m0.096s
<lifeless> vs
<lifeless> bzr.dev$ time bzr search -s f > /dev/null
<lifeless> real    0m7.392s
<lifeless> user    0m6.216s
<lifeless> sys     0m0.368s
<beuno> ah, going to be interesting to see that commit
<beuno> lifeless, does that improvement hold on smaller repos?
<beuno> it's very fast as-is, can't imagine now
<lifeless> beuno: its pushing now
<lifeless> k, revno 40 is up
<lifeless> seems to be slightly faster, yes
<lifeless> on bzr search itself
 * beuno reads through the diffs
<lifeless> 0.533 vs 0.510 seconds :P
<beuno> ah, copied over some stuff from bzr and played with that
<beuno> cool
<beuno> > 1 sec is very good on a repo the size of bzr
<beuno> even for web  :)
<lifeless> > 1 sec is easy to satisfy :P
<lifeless> < 1 sec is good :P
<LarstiQ> just throw in a time.sleep(1)!
<lifeless> hi LarstiQ
<LarstiQ> hey lifeless
<beuno> don't mention sleep please   :/
<jam> beuno: how about duermo
<lifeless> look after yourself man
<lifeless> don't burn out!
<lifeless> jam: beuno forgot to sleep
<jam> morning lifeless
<lifeless> hi jam
<jam> of course, you're one to talk :)
<jam> and, considering I was up until >1am last night, so am I
<lifeless> oh, I get crabby and shitty when I don't sleep enough
<lifeless> its all smoke n mirrors
<lifeless> beuno: your demo is down again :P
<james_w> hi jam
<beuno> lifeless, that's because I came to the office :)
<lifeless> beuno: ah
<jam> morning james_w
<lifeless> beuno: well, show jam, hopefully he will ooh and aah too :)
<jam> lifeless: Oh, I agree. Though normally it is the day *after* I don't sleep well
<jam> so if I fail to sleep on Tues night, I'm crabby on Thurs
<beuno> lifeless, http://intranet.pentacorp.net:8080/bazaar/bzr_garbage/changes
<jam> Wed I'm still running on adrenaline :)
<lifeless> yah
<beuno> howdy jam
<lifeless> jam: check the search widget in that url out
<jam> yeah, the partial match is pretty cool
<jam> and interactive
<jam> though having it show ('foo',) is a bit... odd :)
<lifeless> jam: 'make it work' :)
<jam> conceptually very cool beuno, nice work
<beuno> I have something prettier in store, it will just take a day or two
<jam> now you just need to clean it up, put it in a drop down, etc
<jam> but first, you need to sleep :)
<beuno> heh
<beuno> well, I'm going to ignore the fact I didn't sleep, so I can get back on a normal schedule
<beuno> so I'll probably make less sense as the hours go by
<lifeless> well
<lifeless> I'll go now to avoid the ugliness ;)
<lifeless> gnight everyone
<beuno> heh
<beuno> g'night lifeless
<jam> sleep tight lifeless
<adam_vollrath> Heylo, quick question.  What's the Bazaar Windows client equivalent to TortoiseSVN/CVS?  Or any other Windows client?
<vila> markh: ^
<Jc2k> adam_vollrath: i dont know anything about it, but i just found this: http://bazaar-vcs.org/TortoiseBzr
<vila> that's the one
<adam_vollrath> ah, I should've googled.  Thank you.
<pygi> adam_vollrath, I'd suggest using Olive, I think it works better, i.e. TortoiseBzr is still not finished
<Tsmith> so! I have made copious changes to my branch; how can i diff this to the trunk?
<james_w> Tsmith: "bzr diff -r ancestor:submit:" may get you what you want.
<james_w> also "bzr send -o- | less"
<Tsmith> what's submit?
<james_w> the "submit" branch
<james_w> it's what send defaults to.
<james_w> it falls back to the parent if one isn't defined
<Tsmith> -o- | less worked
<jam> james_w: you don't need "ancestor:submit:" submit: implies ancestor:
<james_w> ah, ok, so "diff -r submit:" will give you the same as the preview in the merge directive?
<jam> james_w: if it doesn't, let me know :)
<jam> you could also use "cd trunk; bzr merge --preview ../feature-branch"
<jam> that will also show conflicts, etc
<jam> which may be good/bad
<Tsmith> i get 2 diff things w/ diff -r submit: and -o- less
<james_w> can you see what the differences are?
<Tsmith> that's waht i'm trying to find out
<james_w> i.e. is one including trunk changes? Is one using an older base revision?
<Tsmith> bzr merge preview is terribly messed up
<Tsmith> it creatse a 19,895 line diff compared to the other 600 line one
<Tsmith> nevermind
<Tsmith> trunk was really out of date ;p
<yacc> Any way to get bzr stat to report the relative paths of files, when running bzr stat .? => currently the output of bzr stat needs manual cutting off the unneeded prefix when selective commiting files.
<james_w> yacc: I don't know of one, there's a bug open saying that paths should be relative somewhere
<gour> what is eta for 1.6?
<yacc> james_w, so my best guess is, when the pulse of my life slows down again to write a plugin that copies stat and monkey patches it to provide a relstat command, I guess.
<james_w> yacc: or write a patch to bzr that makes stat use relative paths?
<yacc> well, I have no idea if that's what everyone wants to have.
<yacc> :)
<yacc> james_w, anyway, till now I just managed to write one plugin that does not meddle with bzrlib, it does only monkey patch some of the standard python modules as needed ;)
<james_w> it should at least be an option I think, so it would be great to have a patch to core.
<james_w> https://bugs.edge.launchpad.net/bzr/+bug/30159
<ubottu> Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed]
<yacc> james_w,  ~jdobrien/bzr/bugfix (New) - Fix In Progress
<james_w> yacc: "In Progress" is actually a little generous for that branch it seems.
<yacc> james_w, yeah, but the last message applies to me too :(
<Jc2k> does git have any equivalent to git gc --prune --agressive ?
<Jc2k> (not sure if gc is the right command..)
<Jc2k> yeah, git-gc
<james_w> you mean does bzr?
<Jc2k> whoops, yeah
<Jc2k> jeez, is not even 10pm yet :)
<james_w> no, it doesn't unfortunately
<james_w> I think there was a plugin to do something similar, but it was plastered with big scary labels.
<Jc2k> i see
<Jc2k> at the moment, my bzr mirror of gnome takes 34gb and my git mirror takes 6gb..
<james_w> have you done "bzr pack"?
<Jc2k> no, i think thats what im looking for
<james_w> also "find . -name obsolete_packs -type d | xargs du -skh"
<james_w> it doesn't do as much as "git gc --prune --aggressive", it's like "git pack"
<james_w> however, the gc won't do much if anything on these mirrors.
<james_w> as it removes unreferenced objects, and you will only get them after rebases and the like, simply mirroring stuff shouldn't cause that.
<LeoNerd> Or uncommit
<Jc2k> i see
<LeoNerd> I quite often uncommit
<LeoNerd> I've been known to have four attempts at a commit, before the fifth one finally sticks :)
<Jc2k> the disturbing thing about Git in GNOME is that so many of the strong supporters use it in weird ways. i've not found a consistent story for making a git "mirror".
<Jc2k> there are at least 2 documented hacky scripts, neither of which seem to work
<Jc2k> where as bzr svn-import <PATH TO REPO> just works
<ToyKeeper> Heh, simplicity isn't really one of git's priorities.  :)
<Jc2k> its not really the simplicity, its the fact that i can't find a consistent story
<Jc2k> when i asked one group about their use of git-svn they didnt even realise it could do a full clone of branches and tags and all
<mwhudson> morning
<Jc2k> anyway, bath whilst bzr repacks things :)
<Jc2k> morning mwhudson
<psycoman> hoe can i make a diff with my local brach and the branch in launch pad ?
<psycoman> my branch was created from the launchpad branch
<Verterok> psycoman: try with: bzr diff -r branch:<your_lp_branch>
<Verterok> psycoman: if you want to only see the new revisions, you should use: 'bzr missing'
<psycoman> Verterok: like this ? bzr diff -rbzr diff -r lp:~yurimalheiros/textflow/0.3.x
<psycoman> bzr diff -r lp:~yurimalheiros/textflow/0.3.x
<Verterok> psycoman: bzr diff -r branch:lp:~yurimalheiros/textflow/0.3.x
<Jc2k> james_w: after just bzr pack, it now takes up 10gb more space :D
<mwhudson> that'll be all the obsolete_packs i guess
<james_w> Jc2k: yeah, check for obsolete_packs directories and purge them.
<Jc2k> kk
<bkor> Jc2k: bzr pack --i-mean-it
<Jc2k> fun :)
 * Jc2k is sad its not real :(
<Jc2k> james_w: its totally safe to clobber all obsolete_packs folders?
<james_w> Jc2k: they're there as a backup in case something went wrong with the pack.
<mwhudson> after the pack has finished, yes
<Jc2k> i see
<james_w> they'll be deleted at the next pack anyway.
<Jc2k> ah cool
<james_w> I think it's mostly insurance against disk syncs anyway.
<james_w> or rather things going bad while the data is still being written out.
<bkor> why not delete it right away instead of waiting for the next time?
<james_w> not sure, ask lifeless
<Jc2k> i dont think that helped much :(
<Jc2k> well, its about the same as before i started
<james_w> that's not good
<james_w> There was an allegation that bzr-svn creates large repositories, but I never saw any evidence to back it up.
<james_w> I'm sure lifeless will be interested in investigating this though.
<Jc2k> james_w/lifeless/jelmer: 33GB of rich-root-pack bazaar repos from 20GB of SVN (vs about 6gb of git FWIW)
<Jc2k> james_w/lifeless/jelmer: this is after a bzr pack and deleting obselete packs from each modules .bzr/repository folder
<james_w> git has the same data?
<james_w> i.e. all the same branches?
<mwhudson> bzr-svn creates long revision and fileids, which are stored uncompressed in the indices
<Jc2k> james_w: yes
<fullermd> I don't think pack does much [any] additional compression or such.
<fullermd> It just builds up larger pack files.
<Jc2k> these are the figures i have:
<Jc2k> x469yq@isshin:/srv$ du -s -m bzr/
<Jc2k> 33567   bzr/
<Jc2k> x469yq@isshin:/srv$ du -s -m svn/
<Jc2k> 25468   svn/
<Jc2k> x469yq@isshin:/srv$ du -s -m git/
<Jc2k> 6228    git/
<Jc2k> those folders should be roughly equal..
<Pieter> bzr blows up even larger than git?
<Pieter> eh
<Pieter> svn
<Jc2k> i'll try recreating one of the larger repositories in the morning to make sure its not a side effect of anything i've done
<awilkins> I found that it made large revisions when it was getting the branching scheme wrong
<awilkins> ie. for my 120MB tree, some revisions were an extra 120MB because it thought they were not a branch.
<Jc2k> interesting
<awilkins> The effect was particularly profound on this tree becuase the tree is large with respect to the size of the history
<awilkins> I'm not sure how easy it would be to spot if you were't watching for it (branching the trunk, then watching the repo as you do branches)
<Jc2k> hmm
<awilkins> In an SVN repo, you can tell the size of each revision because they are in seperate files
<Pieter> Jc2k: how many commits does that repo have?
#bzr 2008-06-19
<Jc2k> Pieter: there are ~520 repos with commits varying from 200 to 25,000
<lifeless> moin
<Jc2k> lo lifeless
<james_w> hi lifeless
<lifeless> Jc2k: you can do 'bzr pack && rm .bzr/repository/obsolete-packs/*'
<Jc2k> already done that
<awilkins> lifeless: Isn't it about 0600 there?
<lifeless> 0908
<awilkins> Ah, it's tomorrow
<awilkins> Last we spoke it was 2200 at you
<Jc2k> (before i rm'd the obsolete packs it was about 10gb bigger)
<lifeless> yes, it usually comes after yesterday :)
<awilkins> It's only just today here.... :-)
<lifeless> Jc2k: is that across all repositories?
<lifeless> Jc2k: are there working trees
<lifeless> Jc2k: try a break-down per project
<Jc2k> *overloads*
<lifeless> :)
<lifeless> back in a little bit grabbing breakfast
<Jc2k> lifeless: all my figures are for all 520ish repos as one
<Jc2k> lifeless: there were some working trees (mostly trunk), but i think i squished em
<lifeless> so, one mergarepo ?
<Jc2k> no
<awilkins> jam: Want to talk about my patch for #240910 ?
<Jc2k> 520 repos
<Jc2k> /srv/bzr/module1, /srv/bzr/module2
<lifeless> phew :)
<Jc2k> and i did du -s -m /src/bzr/ :p
<Jc2k> *srv, even
<lifeless> Jc2k: oh, you've deleted the obsolete packs dirs
<lifeless> Jc2k: you need to keep the directory around, only delete the contents
<Jc2k> oh
<Jc2k> >_<
<lifeless> james_w: ^
<lifeless> otherwise it will cry when it next tries to autopack
 * Jc2k rejigs his script to do lots of mkdir :)
<lifeless> so
<lifeless> I think I can say where the size is
<lifeless> you have very many tags
<lifeless> and each tag in the way its beinig brought across is a separate branch, which is to say:
<lifeless> thetagdir
<lifeless> .bzr
<lifeless> .bzr/format
<lifeless> .bzr/branch
<lifeless> .bzr/branch/format
<lifeless> .bzr/branch/lock
<lifeless> .bzr/branch/branch.conf
<lifeless> .bzr/branch/last-revision
<lifeless> so the first thing we could do is use --apparent
<lifeless> the second thing is to turn the tags into actual tags in trunk
<lifeless> jelmer: ^ this is planned, yes?
<mwhudson> beuno: hello
<lifeless> Jc2k: https://bugs.edge.launchpad.net/bzr-svn/+bug/81102
<ubottu> Launchpad bug 81102 in bzr-svn "Tag support" [Wishlist,Triaged]
<lifeless> Jc2k: I'll bet that starting with just a --apparent on your script makes things look better (because you are no longer measuring how inefficient ext3 is)
 * jml will see the sydney sprinters soon
<Jc2k> lifeless: where do i stick this magical --apparent? on du ?
<lifeless> Jc2k: yes
<Jc2k> kk
<lifeless> jml: I'm hacking intensly here, ring me if you need shit
<lifeless> Jc2k: it tells du to sum the visible size, not the blocks/extents allocated
<Jc2k> i see
<lifeless> if the apparent size is also ridiculously high we can look for bad deltas etc
<Pieter> Jc2k: how did you repack the git repos?
<lifeless> but if its not then I'm going to stick by my tags theory
<james_w> Jc2k: we could probably come up with a pretty simple script to convert the tags to bzr tags after the fact.
<Jc2k> Pieter: everything is here
<Jc2k> http://live.gnome.org/JohnCarr/Git
<Jc2k> james_w: it would have to cope with getting run repeatedly
<james_w> Jc2k: yup
<Pieter> Jc2k: you might want to repack the bigger repos with a higher --window. see http://vcscompare.blogspot.com/2008/06/git-repack-parameters.html
<lifeless> a couple of notes on size
<lifeless> we have a plan to change to a better delta format
<lifeless> we know from testing we can halve the effective size of the pack repository contents doing this
<lifeless> (this is all on the list, I can find pointers)
<lifeless> I think using a larger window is a bit like cheating, because most users won't repack themselves (or know to), and further the automatic packing git has recently added won't use this higher window - and the higher window has a cost
<lifeless> unless one is in a storage crisis, disk space is unlikely to be a determining factor on whether something is pleasant/effective to use
<lifeless> oh, finally - we're just about to land the work to allow not downloading all the history anyway, which makes repository size even more moot
 * Jc2k is looking forward to stacked branches
<Jc2k> lifeless: still 30gb
 * Jc2k heads for bed
<lifeless> Jc2k: ok
<lifeless> Jc2k: could you do a project-by-project -
<lifeless> du -s -m --apparent bzr/* ?
<lifeless> and mail me or something
<lifeless> bkor: or you, if Jc2k is gone :)
<Pieter> Jc2k: your gtk+ repo e.g. goes down from 250MB to 70MB if you repack more tightly
<Pieter> Jc2k: so you might be able to decrease that 6GB significantly
<devnotes> Hi, I'm having a problem creating a branch when running bazaar on Windows, can someone help?
<lifeless> sure
<devnotes> when I execute "bzr branch lp:do" I get the following error:
<devnotes> Permission denied (publickey).
<devnotes> bzr: ERROR: Connection closed: please check connectivity and permissions (and tr
<devnotes> y -Dhpss if further diagnosis is required)
<devnotes> Any thoughts?
<lifeless> I think you've done 'bzr launchpad-login'
<devnotes> Sorry, not following you.
<lifeless> but your username is wrong, or you don't have pagent running
<lifeless> ok
<lifeless> lp:do is a directory service url
<devnotes> ok
<lifeless> this does a lookup over the web for the real url
<devnotes> ok, so I am typing the wrong value then?
<lifeless> if you have told bzr what your launchpad username is, the real url is something like bzr+ssh://bazaar.launchpad.net/someuser/someproject/somebranch
<lifeless> if you have not told bzr what your launchpad username is, you get given anonymous access via http
<lifeless> can you run 'bzr launchpad-login' please
<devnotes> it replies with nickp-developernotes
<devnotes> sorry, that is 'nickp-developernotes' specifically.
<lifeless> ok
<lifeless> is that your launchpad account name?
<devnotes> well, my "name" on launchpad is "developernotes", but I believe I use an email address to actually login.
<lifeless> launchpad can be confusing
<lifeless> is https://edge.launchpad.net/~nickp-developernotes you ?
<devnotes> yep, that's me
<lifeless> ok
<lifeless> so, to access bzr+ssh you need to have ssh working
<lifeless> there are a number of possible problems
<devnotes> ok
<lifeless> one is that the ssh agent is not working
<devnotes> I provided my account on the webpage with my ssh key I have generated before.
<devnotes> ssh agent local on windows?
<lifeless> another (recently added one) is that your key is one of those generated by a buggy version of ssh, and has been blacklisted.
<lifeless> there are others
<lifeless> but lets check for the agent first
<devnotes> ok
 * spiv hops on a train
<lifeless> do you have pagent (the putty ssh agent) or some other agent that you use to unlock the ssh key?
 * mwhudson finds a bug in simpletal :/
<lifeless> or do you get asked a passphrase and type it in?
<devnotes> no, do I need to download putty?
<lifeless> no, I don'tthink we need it
<devnotes> asked a passphrase when I do what?
<devnotes> execute the branch command?
<lifeless> yes
<devnotes> no, it just replies with the error right away
<mwhudson> oh well, it's not too bad
<lifeless> devnotes: ok. I think you have a passphraseless key that is blacklisted. Uhm, how to check for this.
<lifeless> devnotes: stand by a second, I will see if I can confirm this for you
<devnotes> ok
<lifeless> ssh-vulnkey +sshkeys
<lifeless> Not blacklisted: 2048 26:59:18:ae:09:6b:fc:e6:47:98:ff:7d:8a:30:5d:cc nickp
<lifeless> ok
<lifeless> your key is fine
<devnotes> ok
<lifeless> so, I would guess bzr is not finding your key correctly
<lifeless> can you run bzr --version
<lifeless> there will be a log file location listed in the output
<lifeless> can you look inside that log file
<lifeless> hopefully there will be some clues
<lifeless> jam: you use windows right? any help?
<lifeless> markh: ^
<devnotes> what information do you want from the .bzr.log file, it's very long
<lifeless> well have a look down the bottom
<lifeless> see if it says anything about agents/keys/errors
<lifeless> or you could remove the file
<lifeless> and run the failing command again
<lifeless> then open it and it will have just that commands errors
<devnotes> 0.111  bzr arguments: [u'branch', u'lp:do']
<devnotes> 0.112  looking for plugins in C:/Users/Nick/AppData/Roaming/bazaar/2.0/plugins
<devnotes> 0.112  looking for plugins in C:/Program Files/Bazaar/plugins
<devnotes> 0.132  encoding stdout as sys.stdout encoding 'cp437'
<devnotes> 2.352  ssh implementation is OpenSSH
<devnotes> 3.594  Traceback (most recent call last):
<lifeless> please post that sort of thing http://pastebin.com/ in future - its faster and easier to read.
<devnotes> sorry, I'll do that now
<lifeless> no problem
<devnotes> http://pastebin.com/m3db7eeaa
<lifeless> devnotes: ok, one good thing here is we now know the ssh its using
<lifeless> devnotes: so we can debug a little deeper ourselves
<lifeless> devnotes: please do:
<lifeless> "ssh nickp-devnotes@bazaar.launchpad.net"
<poolie> hello lifeless
<lifeless> you should see something like:
<lifeless> hi poolie
<lifeless> No shells on this server.
<lifeless> Connection to bazaar.launchpad.net closed.
<devnotes> Permission denied (publickey).
<devnotes> do I need to execute this from cygwin?
<poolie> that conuts as success
<lifeless> devnotes: its fine as is
<lifeless> devnotes: now, we need to figure out if it is trying your ssh key and it doesn't match, or if its not finding your key
<lifeless> devnotes: please try
<lifeless> "ssh -v nickp-devnotes@bazaar.launchpad.net"
<lifeless> the output will be long
<lifeless> we're looking for lines like:
<devnotes> yep, what are you looking for?
<lifeless> debug1: Connection established.
<lifeless> debug1: identity file /home/robertc/.ssh/identity type 0
<lifeless> debug1: Offering public key
<lifeless> debug1: Server accepts key
<lifeless> - but you could just copy and paste everything to pastebin and I'll look at it for you
<devnotes> mines says "identity file /home/Nick/.ssh/identity type -1"
<abentley> lifeless: What is the behavior of BzrDir.sprout supposed to be when the source bzrdir doesn't have a branch?
<devnotes> http://pastebin.com/m770894d7
<lifeless> abentley: I chose rather arbitrarily to have it make a branch (because sprout is meant to make a new line of development).
<lifeless> abentley: it could reasonably be defined to error instead
<devnotes> huh?
<lifeless> devnotes: the lines with abentley: in front of them are a seperate conversation
<abentley> lifeless: understood.
<devnotes> gotcha ;-)
<lifeless> devnotes: I think the -1 indicates an error
<lifeless> devnotes: please try again, with -vv instead of -v, and post the output
<fullermd> I think type -1 indicates an RSA key...
<fullermd> debug1: identity file /home/fullermd/.ssh/identity type 0
<fullermd> debug1: identity file /home/fullermd/.ssh/id_rsa type -1
<fullermd> debug1: identity file /home/fullermd/.ssh/id_dsa type 2
<lifeless> fullermd:
<lifeless> debug1: identity file /home/robertc/.ssh/id_rsa type 1
 * fullermd ponders.
<fullermd> Ah, I don't have an id_rsa.  Weird.  I thought I did.
<lifeless> fullermd: :)
<lifeless> fullermd: thanks thats very helpful
<fullermd> So, yeah, looks like no user keys at all.
<lifeless> devnotes: can you look in your .ssh directory
<lifeless> devnotes: you should have a file called 'id_rsa', if you don't, then we have identified the problem and can look at how to fix
<fullermd> Well, either id_rsa or id_dsa should work.  But with a -1 on both (and on identity, which is the v1 key)...
<lifeless> fullermd: https://edge.launchpad.net/~nickp-developernotes/+sshkeys
<lifeless> fullermd: I wasn't guessing as to file name :)
<devnotes> http://pastebin.com/m606ae93a
<fullermd> lifeless: Ack!  You r hax0red him!
<devnotes> inside my .ssh folder I have 3 files.
<devnotes> id_rsa, id_rsa.pub, known_hosts
<lifeless> devnotes: ok
<lifeless> devnotes: for some reason ssh is not finding them
<lifeless> devnotes: is it possible you have two folders called .ssh ?
<devnotes> I'll do a search
<devnotes> yes, I can see two right now, one in "C:\cygwin\home", another in "C:\Users"
<lifeless> ok
<lifeless> as an experiment, please try copying the id_rsa and id_rsa.pub files to the other .ssh folder
<devnotes> the dir "C:\cygwin\home" only contains a known_hosts file
<lifeless> after copying them, try
<lifeless> "ssh nickp-devnotes@bazaar.launchpad.net"
<devnotes> crap, just found another folder called ssh, note there is no period in front of it.
<devnotes> two different directories....
<lifeless> well
<lifeless> to start with, the .ssh folder that has known_hosts only
<lifeless> that is the one to copy the two files I named into
<devnotes> files copied, now what?
<lifeless> "ssh nickp-devnotes@bazaar.launchpad.net"
<devnotes> It asked me for a passphrase this time, 3 times actually, I am trying to remember my password and then I got "No shells on this server.  Connection to bazaar.launchpad.net closed."
<lifeless> devnotes: excellent
<mwhudson> well, that means you connected successfully
<lifeless> devnotes: now run your original bzr command and it should work
<lifeless> devnotes: something in your setup has changed, but I don't know what. ssh, the secure transport we use, thinks your home directory has moved
<devnotes> thanks a million!
<lifeless> happy to help
<devnotes> so when I execute "bzr branch lp:do" it takes awhile and comes back with "branched 371 revision(s), where did those go?
<lifeless> "dir do"
<devnotes> got it....I was looking for another directory for some reason
<devnotes> do I need to cd into that dir to execute the push then?
<lifeless> yes
<poolie> yes we should print that
<poolie> the destination directory name
<devnotes> does the transfer normally take a while, it's been spinning with 0/4 for a while now
<poolie> it can take a while, it depends on how much history is there
<devnotes> gotcha
<jml> lifeless: I've got a subunit branch for you to review at lp:~jml/subunit/split-right
<lifeless> $ bzr break-lock
<lifeless> Killed
<lifeless> ouch
<lifeless> having set a ulimit -v I can't alter it!
<spiv> Heh.
<lifeless> I'm doing some scaling testing on bzr
<lifeless> as part of background idling tasks
<lifeless> and its fun:
<lifeless> h$ bzr pull http://bazaar-vcs.org/bzr/bzr.dev
<lifeless> Fatal Python error: PyString_InternInPlace: strings only please!
<lifeless> Aborted
<lifeless> exsqueeze me!
<mwhudson> oof
<abentley> spiv: I have a test to ensure that cloning a format produces the same format on the output.
<abentley> This test fails when the source repository is a RemoteRepository.
<abentley> Do you have an idea how I should fix the test?
<poolie> lifeless: wee!
<poolie> i doubt if you will reliably get a clean MemoryError
<spiv> abentley: there are already some tests like that in the suite
<poolie> lifeless: also, i suspect there is already a practical limit on heap allocation at not much more than 2g
 * spiv echoes the "wee!"
<poolie> well, on a 32bit machine, i guess yours is using 64bit userspace
<spiv> abentley: are you cloning to somewhere on the same transport?  Obviously you can't clone a RemoteBzrDir to a LocalTransport :)
<lifeless> poolie: you do actually
<lifeless>   File "bzrlib/progress.py", line 435, in clear
<lifeless>     self.to_file.write('\r%s\r' % (' ' * (self.width - 1)))
<lifeless> MemoryError
<lifeless> for instance
<lifeless> clearly the exact point that the error occurs will not always be where the leak is though :)
<poolie> mm
<abentley> spiv: Yes.  To ../transport
<poolie> i guess it may happen that the large allocation fails but there's enough to allocate stuff when doing the exception
<poolie> lifeless:  was that from running the test suite or actual use?
<lifeless> poolie: actual use
<lifeless> poolie: so the basic idea is to pretend to have a smaller machine
<lifeless> we'll see what users with smaller machines see
<lifeless> but not have to thrash on swap to find out
<abentley> spiv: It doesn't seem like this was meant to be the point of the test.
<lifeless> poolie: having found a use case that fails, normal analysis tools start to become relevant
<spiv> abentley: what does "same format" mean in this context?
<abentley> Same repository format.
<abentley> It's about making sure the on-disk format matches.
<spiv> abentley: so there's test_sprout_from_hpss_preserves_format in repository_implementations already, which seems like a related test.
<spiv> abentley: it uses bzrdir.BzrDir.open(self.get_vfs_only_url(...)).open_repository() to always get a non-Remote object when it wants to inspect the on-disk format.
<spiv> abentley: I think that's a reasonable way to do it.
<spiv> abentley: will that work for you?
<abentley> Sure, thanks.
<spiv> np
<abentley> spiv: Wait.
<poolie> i'm going to do a couple more mails then go back into finishing the versionedfiles merge
<spiv> Hmm?
<poolie> thanks for your answer lifeless
<abentley> get_vfs_only_url is only implemented on remote objects?
<lifeless> abentley: its a test suite helper method
<spiv> No, it's on TestCaseWithMemoryTransport
<lifeless> abentley: the test suite has three transports: readonly, branch/reopsitory (the default), and vfs-only
<lifeless> vfs-only is the backing transport for the Remote* objects used by the server side
<lifeless> so you can peek at what is going on
<abentley> Okay.
<abentley> Does get_vfs_only_url work when the bzrdir format is not RemoteBzrDirFormat?
<lifeless> it should always be set
<abentley> Got it.
<abentley> lifeless: Sprout doesn't create the branch until the fetch is complete.  Do you think that's an important behavior?
<abentley> It would be easier for me if I could just set stacking before fetching.
<lifeless> I think its important that we don't have a branch object other people could open and get the wrong repository/no repository error
<lifeless> how that is achieved I am not too concerned by
<lifeless> you can set stacking on a repository directly, by calling the add_fallback_repository method before the fetch is done
<abentley> lifeless: Yes, I see this, and doing this in the repository acquisition policy is the other option I'm contemplating.
<poolie> hm, mhammond is seeing much slower plain http pull than i am on linux, even for a similar repository
<poolie> maybe there is something about his repo
<jam> lifeless: I use windows, but I use pageant or cygwin's openssh
<jam> lifeless: I don't know how to configure paramiko to use keys without pageant
<lifeless> jam: you like like to idle in #gnash for a bit, or abentley, or both of you - project migrating to bzr
<Scoobert> noob with question
<abentley> lifeless: I got an email from you, but I couldn't really understand the bit about state.
<lifeless> abentley: I was referring to where the conversion data was
<lifeless> in case it was bad or needed tweaking or whatever - jam wrote the converter in question
<abentley> That was on rookery?
<lifeless> tungsten
<lifeless> I put the tarball of the output repository + branches on rookery
<lifeless> anyhow, I'm hand holding during my tz
<lifeless> but if one of you could lurk there your tomorrow it would be good, I think
<lifeless> Scoobert: shoot
<Scoobert> k
<lifeless> Scoobert: (generally, don't wait, just ask :))
<Scoobert> two developers add something to the end of the same module(happens alot on a virgin project)... = conflict for just about any VCS  ... why oh why
<abentley> Okay.
<lifeless> Scoobert: do you mean, you have a file like (say) foo.c
<lifeless> Scoobert: and dev one adds a function to the bottom
<lifeless> Scoobert: and dev two, in their own branch, adds a function to the bottom
<lifeless> Scoobert: and then when you merge, there is a big conflict?
<Scoobert> precicely, lifeless.
<Scoobert> any way to avoid?  (i love bzr btw)
<lifeless> Scoobert: so, its because we treat files as text, rather than some more abstract thing that means 'C source code'
<Scoobert> of course...and thank goodness it's true since we version more than mere code.
<Scoobert> but wish one could configure a merge algo to ignore conflicts at the EOF, or at least treat them as 'special' conflicts.
<lifeless> Scoobert: if we knew it was C code we could say 'dev 1 added funcX' and 'dev2 added funcY' so there is no conflict
<lifeless> as it is yeah, we see an insertion at EOF from two people and it conflicts
<lifeless> uhm, generally anywhere between functions this concept of two-insertions shouldn't conflict would be nice (if they had no identical lines, for instance)
<Scoobert> for instance I script out all the stored procs for my DB at the end of each day and VC them.  I'm glad bzr recognizes any and all differences in that case
<lifeless> perhaps file a bug. we do have pluggable merge methods so its possible for someone to experiment with this
<Scoobert> all right.  Thanks.
<lifeless> abentley: where can people get hitchhiker?
<lifeless> nvm found it
<abentley> lifeless: I've added some fun stuff since I announced it, e.g. non-interactive mode.
<lifeless> abentley: we have to reverse engineer the hosting facility on savannah
<abentley> lifeless: Oh, fun.
<lifeless> you can ls right ?
<abentley> lifeless: Sure.
<abentley> See help for a list.
<lifeless> thanks, it helped
<mwhudson> i should write a plugin that shows a bazaar branch in loggerhead
<mwhudson> any funky ideas for the names of the plugin or command ?
<lifeless> serve --http?
<mwhudson> that works i guess
<mwhudson> especially as we should make loggerhead actually serve up the .bzr files
<mwhudson> lifeless: do you have an example of adding an option to a command in a plugin that i can crib from?
<abentley> lifeless: I just fixed some bugs in hitchhiker's "info", "cat" and "get" commands as of revno 16.
<lifeless> abentley: cool, I think we're done for now though, no write access -> not much to do
<abentley> lifeless: This is the first public bzr: server I've seen, so it's kinda fun to play with.
<lifeless> ah :)
<mwhudson_> lifeless: do you have an example of adding an option to a command in a plugin that i can crib from?
<mwhudson_> ^ did that get a reply?
<lifeless> mwhudson_: oh yes; uhm, in this case I'd decorate the command I think (see the thread with jml re 'status' in loom)
<lifeless> mwhudson_: but I have written a plugin somewhere that actually introspects the command and adds an option
<lifeless> mwhudson: GET AN INTERNET
<mwhudson_> grrrrrrr
<lifeless> mwhudson_: oh yes; uhm, in this case I'd decorate the command I think (see the thread with jml re 'status' in loom)
<lifeless> mwhudson_: but I have written a plugin somewhere that actually introspects the command and adds an option
<lifeless> don't remember the name of it :P
<mwhudson_> heh
<mwhudson_> i'll look at loom
<jml> mwhudson_: it's worth reading the thread too.
<jml> mwhudson_: you should note your findings and submit them as a doc patch.
<lifeless> ok found it
<lifeless> old_format_type = builtins.get_format_type
<lifeless> builtins.get_format_type = get_format_type.decorate_get_format_type(
<lifeless>     old_format_type)
<lifeless> # XXX: This is ugly, fix bzrlib to make it cleaner. Right now changing the
<lifeless> # parser does not help because the old name is bound into the Options array for
<lifeless> # each command.
<lifeless> for command in commands._get_cmd_dict().values():
<lifeless>     if isinstance(command.takes_options, (set, list)):
<lifeless>         for option in command.takes_options:
<lifeless>             if not isinstance(option, bzrlib.option.Option):
<lifeless>                 continue
<lifeless>             if option.type == old_format_type:
<lifeless>                 option.type = builtins.get_format_type
<lifeless> yes, I know pastebin, sosueme
<mwhudson_> oh well, that's a bit more complicated than i need i think
<lifeless> that alters a option for many commands that use it
<lifeless> my suggestion of decorating was intentional
<lifeless> abentley: how does one tell a branch to preserve history /
<lifeless> abentley: (as in ,where is the doc to tell someone what to do)
<abentley> It's in bzr help configuration.
<abentley> append_revisions_only
<abentley> (If I understand the question)
<lifeless> so, its 'edit .bzr/branch/branch.conf and insert append_revisions_only=True' ?
<lifeless> (I want to tell rob savoye to do this on trunk)
<abentley> lifeless: yes.
<lifeless> thanks
<abentley> lifeless: also, you can set it when you create the branch.
<abentley> bzr init --append-revisions-only
<lifeless> abentley: conversions though, don't have new branches :)
<abentley> lifeless: It looks like BzrDir.clone is supposed to clone branch references verbatim.  This suggests it's not a good basis for 'bzr push', and probably explains a bug with pushing from lightweight checkouts.
<lifeless> abentley: well, its meant to preserve the state yes; its definitely related to the occasional bug with push; what should be happening is that the opened branch's bzrdir is used to clone() from
<lifeless> but for some reason sometimes people clone() from the tree's bzrdir - which is ok for cloning the checkout, but erroneous for push (which should only be working on the branch)
<abentley> lifeless: but if you clone from the branch's bzrdir, you won't get a tree.
<lifeless> thats true
<abentley> It seems like if we used sprout instead, then clone could life up to its name.
<lifeless> we could; though doesn't that confuse too - push is used to publish a branch, not to make a new line of development ?
<mwhudson_> lifeless: this is where i've got to: http://pastebin.ubuntu.com/21320/
<lifeless> mwhudson: looks like it will work
<lifeless> mwhudson: unlike your internet
<abentley> lifeless: Yeah, but any branch is potentially a new line of development.  cp -r was the original "bzr branch".
<abentley> There's a small amount of policy that branch should handle and push should not.  But they basically do the same thing.
<abentley> lifeless: I'm especially running into weirdness because bzrdir.open_branch().repository may or may not be the same as bzrdir.open_repository + fallbacks.
<abentley> And if I'm cloning the root of a shared repo with stacked branches, I think I'm completely SOL.
<lifeless> well, even without stacking, branch.repository is not guaranteed to == branch.bzrdir.open_repository
<abentley> lifeless: Sure.  It's the partial revisions I worry about.
<abentley> Fetching a revision when you don't have all the texts for its tree.  That kind of thing.
<lifeless> abentley: Can you expand on that? Do you mean a single repository that has a revision but not the matching text deltas ?
<abentley> Yes.  Because the text deltas are older than that revision, so they're in the stacked_on repository.
<lifeless> I think I'm misunderstanding; the text deltas are surely precisely the same ages as the revision
<yacc> Does hadoop start one and the same map tasks on multiple nodes concurrently?
<lifeless> ?
<yacc> oops, wrong channel ;(
<kumi2> heh
<kumi2> I was also going to ask something irrelevant, but you beat me to it
<yacc> kumi2, sorry.
<yacc> kumi2, I cheated, I only slept 2hours, so it's really unfairly easy for me to say something stupid :-P
<kumi2> :)
<Pieter> I hate it when that happens
<dholbach> good morning
<dholbach> can somebody tell me how in a bound branch with local commits I'd find out the timestamp of the last 'pushed commit'?
<lifeless> bzr missing ?
<dholbach> lifeless: do you know what in bzrlib I'd need to look for? I just don't know how to distinguish between a local commit and a 'pushed commit' - I'd prefer if the operation was light-weight :)
<lifeless> dholbach: there really isn't a difference, except one is not in the master branch
<lifeless> dholbach: distributed system, symmetrical behaviour etc
<lifeless> e.g. bzr log MASTERURL and bzr log LOCALURL and see the difference
<dholbach> HRM
<dholbach> to not hammer the main branch of 5-a-day-data (where lots of people commit the bugs they worked on to) we used commit (either forced or if the last commit was 60+ minutes ago) - now we pondered using local commits instead and 'pushed commits' every 60+ minutes instead
<lifeless> does just commit not work  ?
<dholbach> it does, it's just a problem if you use the 5-a-day client on two machines, where local commits might work better
<lifeless> why would they work better?
<dholbach> I guess you don't get conflicts that easily :)
<lifeless> Well, I'm looking for some statement of problem from you
<lifeless> so we can discuss
<dholbach> right now calling the tool just adds stuff to a text file, every 60+ minutes it does a commit
<lifeless> it sounds like 'we are seeing conflicts when we commit a lot from different machines' is your problem
<lifeless> is it one text file for everyone
<lifeless> or one per user
<lifeless> or one per bug
<lifeless> or ..?
<dholbach> one per user, in one branch
<lifeless> whats the 60 minute delay for?
<dholbach> we had a lot of problems with locks on bzrlp
<dholbach> we have nearly 120 committers and 5000 revisions in the last 5 months
<lifeless> so
<lifeless> the general thing to reduce concurrency is to add branches
<lifeless> rather than delaying commits
<dholbach> OK
<lifeless> why do you have one branch ?
<dholbach> I wanted to make it easy to make statistics from just getting one branch :)
<lifeless> so this is for stats
<lifeless> not for people to not tread on each other?
<dholbach> I agree we could change it to branch-per-person
<lifeless> so
<dholbach> http://daniel.holba.ch/5-a-day-stats/ is what I generate from the one branch
<lifeless> lp can list the branches for you
<lifeless> a small script can easily merge every branch that has new commits by using lp to determine that
<lifeless> and you then have one branch with all your people
<dholbach> I'll look into changing that
<lifeless> screen scrape https://code.edge.launchpad.net/5-a-day-data
<dholbach> especially with the Global Bug Jam coming up in early August, I'd like to have that situation fixed :)
<lifeless> oh, this would be interesting to toss bzr-search at
<lifeless> to answer 'who fixed X' :P
<dholbach> it's not necessarily about "Who fixed it?" but "Who made bug report X better?" :)
<dholbach> hi mvo
<lifeless> well
<lifeless> who touched X
<dholbach> right-o
<lifeless> have you seen bzr-search?
<mvo> hi dholbach
<dholbach> lifeless: no, not yet
<lifeless> abentley: API question for you; do you think having VF.get_sha1s return a dict would be better?
<lifeless> abentley: seems it would be more useful to me, for stacking
<lifeless> dholbach: read planet.
<abentley> lifeless: Yeah, that's more likely useful.  Or at least key/val pairs.
<lifeless> abentley: I'll change it to a dict I think, sha1s's are small
<lifeless> dholbach: http://advogato.org/person/robertc/diary/87.html
<dholbach> I'm playing with it right now :)
<dholbach> lifeless: NICE
<dholbach> still it says "Unable to load plugin 'search' from '/home/daniel/.bazaar/plugins'"
<lifeless> dholbach: does it?
<dholbach> yeah
<lifeless> dholbach: what bzr version do you have?
<dholbach> 1.3.1-1ubuntu0.1
<lifeless> garh
<lifeless> get 1.4
<lifeless> or 1.5
<dholbach> get it into hardy!
<lifeless> or 1.6b
<dholbach> at least it should be in hardy-backports
<dholbach> or something
<lifeless> we have a ppa
<lifeless> with builds for hardy
<dholbach> that's not the same :)
<lifeless> I know
<lifeless> anyhow, that just means it won't update the index on push/pull/commit
<lifeless> you can run 'bzr index' to incrementally update
<dholbach> yeah
<dholbach> good night lifeless
<lifeless> I was sayin gnight to poolie :)
<lifeless> I have much to do still
<dholbach> ah ok :)
<Jc2k> morning all
<matkor> Hi !
<matkor> is there any way to bzr cp file (to other location in same  branch ) ?
<Peng> No.
<lifeless> hi Jc2k
<lifeless> matkor: not yet, it is planned in some regard
<Jc2k> hi lifeless, just grabbing the du thing now
<lifeless> Jc2k: can you do du -s -m --apparent bzr/*
<lifeless> Jc2k: :)
<lifeless> Jc2k: I would like that, compared with git - then we can see if the pattern is consistent
<lifeless> Jc2k: or perhaps there are some outliers
<Jc2k> lifeless: jesus wept, gimp is 10gb
<lifeless> ahha!
<lifeless> and how big is the git gimp
<Jc2k> one sec
<lifeless> so this would be useful:
<lifeless> bzr size, git size, ratio
<lifeless> in a tabular form
<lifeless> the worst ratio is the first one we should look at
<Jc2k> bzr, http://pastebin.ca/1050900
 * Jc2k runs command to get git foo
<AfC> Jc2k: whoa
 * AfC admits that he was very concerned about the revelation that bzr-svn operates in a manner that creates (was it file properties?) that are visible to other users of an underlying Subversion repository. That doesn't seem to be the sort of thing that is likely to impress people.
<AfC> Jc2k: by the way, I thought you did a really nice job with http://gnome.unrouted.co.uk/
<Peng> What does bzr-svn do?
<AfC> Peng: read the thread around http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/41686/focus=42933 . Dear Dr Winder is a tad persistent for my tastes, but he and Ben seem to be pointing out a behaviour that could lead to bad PR for Bazaar.
<AfC> (though I cannot think, off hand, what bzr-svn could do differently given its long declared mission of storing full Bazaar branch information in a foreign repository)
<Peng> Oh.
<Pieter> Jc2k: did you get my notes on git's repack?
<lifeless> Pieter: why do you have to supply an option?
<Pieter> the default has a low setting. it can be ok for smallish repo's, but you get a lot better results witha higher --window
<lifeless> so why isn't the default higher?
<Pieter> because it takes longer
<lifeless> (what is the impact on people of telling them to do this
<lifeless> (so that it can be evaluated more deeply than just 'it can be foreced to do XXX'
<Pieter> the default was mostly just a guessed value, as nobody had done any benchmarks before
<Pieter> but you typically only need to do it once for a repository, after that people shouldn't repack --aggressive anymore
<lifeless> bzr tries to manage this so most users never need to run pack at all
<Pieter> git autopacks every xx commits too
<lifeless> though folk seem to be working around a couple of perf bugs by running pack :(
<Pieter> you just need to do it the first time because git-svn doesn't produce good packs
<lifeless> yes, I know - they brought that in after bzr released a packs repository, AFAIK
<Pieter> There had been some patches, but there was a lot of resistance for auto-repack from older git users
<Pieter> because it can take some time to do, they wanted to do it themselves
<lifeless> what was the objection ?
<lifeless> ah, raced with you :)
<lifeless> so with bzr some folk have said it should be manual
<lifeless> but to date, once I point out its amortising latency noone has objected further :)
<Pieter> :D
<lifeless> one of the big differences ibetween bzr and git that I can see is the size of the remote api
<lifeless> git is extremely minimal, but we allow all branch operations - create/delete/commit/push/pull/uncommit/diff/cat/etc over the wire from the standard client
<Peng> hg is minimal too: http://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol
<lifeless> yup
<lifeless> this makes doing adhoc queries harder without a web UI running
<lifeless> as well as making various scripts etc more complex
<Peng> ISTM though that hg has had an effective smart protocol for ages, while bzr is still working on clunking together something complicated and inefficient.
<Peng> Which is rude to say, but it's the impression I've been getting.
<Peng> And, the reason is that you (and that's a collective "you") weren't focusing on the smart protocol for a long time, and are trying to create something feature-rich and robust.
<Peng> But still; hg's decision seems to have worked out decently for them.
<Peng> Yeah...I don't know why I just said all that.
<gour> moon phase?
<lifeless> appearances matter :P
<lifeless> so bzr works very well with no smart server, hg requires one to scale decently
<lifeless> hg's wire protocol only scales if you keep the heads() list small
<lifeless> and yes, we're now writing a full smart server and the tension is getting the smallest possible set of methods
<Peng> gour: Yeah. That works.
<lifeless> because more than are needed is bloath
<lifeless> but not enough is slow
<gour> Peng: ;)
<lifeless> if we required a streaming protocol, it would be a lot easier
<lifeless> (git does this AFAICT)
<lifeless> but we wanted to tunnel cleanly over http
<Peng> If you created a minimal API, would that ruin dumb server performance?
<lifeless> no, abstract interfaces for the win
<lifeless> (and we have a minimal interface, just too minimal, and done a bit naively - first cut) - we're improving that release by release
<liw> mmm. bzr performance. I should do some more torture.
<Jc2k> AfC: its bzr-mirror.gnome.org now :) you should join #gnome-bzr
<gour> any chance for gnome to embrace bzr?
<Jc2k> gour: all i have to say is, bzr-mirror.gnome.org works, git-mirror.gnome.org... resolves to 127.0.0.1.. :P
<gour> :-D
<gour> what about projects like postgresql, wxwidgets...? any of them talk about migration?
<Jc2k> AfC: btw, im not concerned about the use of properties at all. i think its awesome. obviously revision properties would be better...
<Jc2k> AfC: but if you look at gnome-specimen in loggerhead, you see how it preserved some data that svn would ahve thrown away
<Jc2k> AfC: spot the commit that was done in SVN: http://bzr-mirror.gnome.org:9876/gnome-specimen/trunk/changes
<lifeless> liw: running that 22GB repository is interesting
<lifeless> liw: I think we need to disable one of the internal caches, or make it LRU or something
<Jc2k> lifeless: i did my ratio the wrong way around but i actually found a bunch of repos where Git sucks ass
<Jc2k> lifeless: 1mb of gnome-cookbook BZR to 37MB of Git gnome-cookbook
<liw> lifeless, I have about three months' worth of daily snapshots of Debian/Ubuntu mirrors, I was thinking that it would be fun to build a repo with all those source packages...
<Jc2k> lifeless: on the other hand, my git mirror of f-spot is 11mb and my bzr mirror is 482mb..
<lifeless> Jc2k: please do
<lifeless> meh, liw please do
<lifeless> Jc2k: ok
<Jc2k> i wonder
<lifeless> Jc2k: lets get some more figures behind this
<Jc2k> f-spot i could have cocked up
<lifeless> Jc2k: the revision count for each import
<Jc2k> *checks*
<liw> lifeless, "meh"?
<lifeless> Jc2k: (perhaps bzr-svn is getting more history)
<lifeless> liw: meh at nmistyping names :)
<liw> lifeless, ah
<lifeless> Jc2k: and get the tag count for each project
<Jc2k> yup, f-spot i cocked up
<Jc2k> some of the ones i did manually at first had working trees
<Jc2k> lifeless: you have google docs? i'll throw this on a google docs spreadsheet?
<Jc2k> lifeless: don't suppose you know the foo to get total revisions in a git repo and a bzr repo?
<Peng> Does "bzr pack" fix un-optimal things, like if fulltexts appear more frequently than they should for some reason (like bzr-fastimport)?
<james_w> Jc2k: bzr info -v lists the revision counts I believe
<Peng> Like, does it re-encode/reprocess things, or just shuffle data around?
<james_w> Jc2k: for a single branch "git rev-list | wc -l" will do it I think
<Jc2k> gah, too brain dead to splice the output of bzr info -v
<Jc2k> and i have many branches for the git mirrors in some cases
<lifeless> Peng: bzr pack does not do that [yet]
<lifeless> Jc2k: I can get gdocs
<lifeless> Jc2k: for bzr, I was suggesting 'bzr revno'
<Pieter> james_w: that revision count sometimes doesn't correspond to the number of commits "git log" gives btw
<james_w> why not?
<Jc2k> Pieter: i got your notes, but right now i'm more interesting in getting my mirrors to work than packing them tbh ;)
<Pieter> james_w: I don't know, I just noticed it
<kiko> hey
<kiko> this bzrlib thing
<kiko> who wrote it?
<lifeless> kiko: some randoms
<kiko> lifeless, I have to say, it's just blown me away as to how cool it is. and I don't ever say that!
<lifeless> kiko: excellent :)
<kiko> lifeless, I think these randoms know that they are doing
<kiko> lifeless, what's the easiest way to print the last log message committed to a working tree?
<mwhudson_> tree.branch.repository.get_revision(tree.branch.last_revision()).message i think
 * mwhudson_ zzzs
<lifeless> tree.last_revision()
<lifeless> but yes
<kiko> mwhudson_, ah, thanks.
<gour> kiko: invoke "bzr log -r last:1" :-)
<kiko> gour, I am a bzrlib maven. I don't mess with no commandline!!
<cyberix> Is bazaar going to have a sprint at europython this year?
<lifeless> cyberix: I don't think so, because the bzr folk that would be likely to go are going to GUADEC, and the dates are the same
<lifeless> (bzr core folk I mean). obvisouly anyone is welcome to organise seomthing :
<lifeless> :)
<cyberix> The ones at europython are going to be my first sprints ever, I'm not even sure what they are
<cyberix> I've been told that it is about people coding rapidly together
<lifeless> yah
<cyberix> I use bzr so it might be more interresting to me than some arbiray web framework
<jelmer> cyberix, afaik larstiq was going to europython this year
<lifeless> night all
<lifeless> Verterok: is beuno feeling better?
<lifeless> Jc2k: I'll try to catch up with you tomorrow morning
<Jc2k> lifeless: kk
<Jc2k> night
<jaypipes> statik: http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<statik> jaypipes: hurrah! i'm trying to post something about it now too
<jaypipes> statik: this coming within the hour from Giuseppe: http://datacharmer.blogspot.com/2008/06/from-bazaar-to-sandbox-in-5-moves.html
<beuno> lifeless, howdy  :)
<beuno> slept 12 hours, everything is looking better now
<jam> beuno: /cheer
<beuno> hey jam!
<beuno> jam, are we going to have a "This week in Bazaar", well, this week?
<jam> beuno: we should, statik agreed to it
<jam> we'll probably be mostly talking about the above announcement
<beuno> oh, it's official?  col!
<beuno> *cool
<jam> beuno: yeah, about 3-6 months of the last year has been working on that
<jam> nice to have it mostly public now
<beuno> yeah, it got delayed too, didn't it?
<beuno> (blog seems down to me)
<jam> well, official announcements always seem to
<jam> beuno: both blogs open for me
<gour> jay! new bigger customer for bzr
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta2 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<beuno> odd, doesn't open here
<jaypipes> gour: indeed, indeed. :)
<gour> what about postgresql? still cvs?
<jam> gour: last I checked
<jam> which was ~6 months ago
<gour> they're nice potential customer...i was thinking about wxwidgets lately as well
<beuno> jam, I suppose congratulations are in order, your work payed off (and I suppose statik's too)
<jam> thanks
<jam> yeah, statik was really the power broker here
<jam> I just did the conversion
<jam> and we've been supporting them as they hit hiccups
 * gour congrats to all
<jam> Its actually quite good to have a group like them, as it starts pushing at our seams
<gour> jam: what do you think about postgresql and wxwidgets?
<jam> gour: I like both of them :) I have no idea what their community is like, or how open they are to suggestions about VCS
<jam> I was on postgres a long time ago
<jam> (the mailing list)
<gour> sqlite?
<statik> i've heard some mild inquiries about postgres, we sure would be happy to help them convert if there is someone in the postgres dev community that wants to work with us
<jam> gour: the big problem is that I'm a developer/user, and not really a politician. Statik is the guy to go to, if you want someone to do what you want :)
<statik> sqlite would be interesting too, but I think most dev there is done by one person
<gour> sqlite is CVS
<james_w> hi jam
<james_w> hi statik
<james_w> congratulations
<jam> hi james_w
<jaypipes> jam: we like pushing on the seams. ;)
<statik> thanks! all i did was talk, jam did the real work :)
<gour> statik: get gnome & xfce for now  ;)
<statik> yes, several people are going to GUADEC to help, and that gnome-bzr mirror is pretty nice
<jam> statik: politics out-weigh technology every time.
<Jc2k> gnome isn't going to be easy, a lot of the core people are already distracted by Git
<gour> same with gtk
<gour> btw, i use haskell and moved to bzr from darcs...haskell community still sticks to darcs although e.g. ghc has problems with it
<jam> gour: did you try darcs "2"?
<jam> I at least thought I heard it had changed some fundamental bits to work better
<jam> I do wish we could have their cherrypicking support
<jam> just haven't figured out how to represent it well in a snapshot model
<gour> jam: see top of http://bugs.darcs.net/ it happened in the week when i was seriously evaluating bzr ;)
<jam> "No I don't think so, it is a non-local problem"
<jam> ouch
<jam> gour: I forgot that the comments are in reverse order... a bit hard to read actually
<jam> I guess if you are following the issue tracker, the thing you want to read is at the top
<Jc2k> gour, statik, jam: on Git vs Bzr in GNOME, best read is:
<Jc2k> http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00064.html
<abentley> statik, jam: contrats.
<Jc2k> http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00062.html
<Jc2k> http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00169.html
<gour> jam: i had similar (read: serious issues in darcs-1 as well) - that's why i'm here now ;)
<jam> anyone know how to tell pidgin that you really want your tab back where it was (in the other window)?
<jam> I guess the best I found was to add another tab, so the tab bar shows...
<jam> then you can drag it
<jam> gour: glad to have you :)
<semslie> thanks for the links Jc2k. I've been looking out for something like that.
<gour> however, availability of gui tools, good win32 support etc. are some add-ons (useful to my peer devs) why bzr is chosen
<Jc2k> semslie: the whole thread amused me.
<Jc2k> semslie: behdad misunderstands bzr-svn very badly and says it cant do stuff it can a lot, for example
<Jc2k> semslie: behdad also threatens to take his ball in at one point, too
<semslie> I'm looking forward to reading it. kilner and I have been using bazaar against a subversion repository via bzr-svn for a month or two now so I'd like to compare notes with what I've experienced.
<semslie> Jc2k: my experience has been good on the whole, with one or two edge cases that confused me but were understandable given the nature of using a dvcs against a centralised one.
<Verterok> lifeless: hi, sorry for the delay (just 1h :P )
<Jc2k> semslie: i'm a big fan of bzr-svn, hence http://bzr-mirror.gnome.org :)
<beuno> mornin' Verterok
<Verterok> beuno: g'mornin'
<vila> hi all
<vila> yeah for a new project using bzr :)
<semslie> Jc2k: me too, but I also feel that the whole experience could be even better. bazaar impressed me so much that I'll take crashes against svn with a pinch of salt and work out how to get around them, but it would be nice to see that experience become smoother.
<beuno> hey vila
<vila> hi beuno, currently working on bzr-upload :)
<beuno> vila, oh, very cool
<beuno> that needs to be made more public ASAP  ;)
<beuno> jelmer even has a deb ready for that as soon as we give him the green light
<vila> beuno: wow, I need to find some more free time then :)
<beuno> vila, I haven't lost any data with it, ever. That seems a good enough
<beuno> symlinks thingie could be patched, and some other tweaks
<beuno> but most people can use it as-is I think
<james_w> Jc2k: thanks for the links. I thought one of your posts was the best that I read.
<Jc2k> james_w: :) which one?
<vila> beuno: I have a half-working version for a more robust full upload (half-working cause it triggers a bug in bzrlib, or said otherwise, I overused some function), but that gave the hints for a full working one. Once done, I'll address chmod bits
<james_w> does this work with the tools? Does that? Are we going to have a centralised with offline access model? or a gatekeeper?... <- that one
<Jc2k> ah :)
<james_w> good things to be asking, but it didn't seem to have any effect.
<Jc2k> james_w: for the whole thread behad just seemed to crying "i want git" and not really responding too well to anything that wasnt "i agree"
<Jc2k> i fear that the DVCS discussion at GUADEC will be similar
<james_w> yup
<Pieter> It'll be decided the GNOME-way
<james_w> it seems like there is a fair chance that it ends up with svn sticking around and then everyone using that as a backend, with some modules going off and doing there own thing if the leaders desire.
<Pieter> which is "let's wait a few dozen more years"
<Jc2k> Pieter: i wish GNOME had a BDFL. right now its a free for all at the individual modules level, with seemingly no real goals for the project as a whole.
<beuno> vila, great, I'll be spying on your LP branch
<Pilky> statik, jam: congrats on the MySQL announcement
<Jc2k> plus stuff like, how many canvas libraries do we need?
<statik> thanks!
<vila> beuno: ok
<statik> Pilky: I saw someone was converting BazaarX to work with Git, the cross-pollination is pretty neat :)
<Pilky> yeah, I'm meant to be talking with him today to see how we're going to manage all of this
<vila> the more people collaborate, the less they waste energy bashing each other tool :)
<Pilky> because the idea is that they'll share the majority of the same code
<Pieter> as long as they don't call it GitX :)
<Pilky> and the UIs should be almost identical, except for where git and bzr differ
<Pilky> heh, it's called Gitty
<Pieter> good
<Pieter> cause GitX is mine
<Pilky> heh
<Pilky> of course the bar has been set now with Versions so having more people working on the same code is going to help quite a lot
 * vila thinks jam can detect every mispelled 4 letters word beginning with h :-)
<Pieter> looks like gitty doesn't do anything yet
<Pilky> Of course it complicates things quite a bit with regards to hosting the projects
<Pilky> Pieter: yeah, Colin (the guy who's working on it) couldn't commit to github through his company's firewall yesterday
<Pilky> it would be nice to try and closely brand BazaarX and Gitty together in the long run
<Pilky> especially as they're going to be virtually the same app
<Jc2k> Pilky: stick it in SVN, and use git-svn and bzr-svn :)
<Pilky> Jc2k: I've considered that, also comes down to how the project will be structured
<Pieter> I wouldn't work on a git/bazaar gui project that uses svn
<Jc2k> im sure there are plenty of git people who wouldnt use a git GUI that was hosted in bzr.
<Pilky> I'd prefer not to, but it's going to be complicated either way
<Pieter> my git-bzr works perfectly fine for my needs
<Pieter> i can just do git bzr pull / git bzr push
<Pieter> http://frim.frim.nl/GitX6.mov btw
<Pilky> in theory all that would need to happen is references to BZRCore would need to be replaced with GITCore
<pasky> Pieter: doesn't git log by default hide merges?
<Pieter> no
<Pilky> unfortunately there's a few areas where I work around bzr for speed
<Pilky> Pieter: looks nice
<Pilky> looks like it only does browsing at the moment
<Pieter> yes
<Pilky> I guess Gitty and GitX will appeal to different groups atm, depending on what they want from a GUI
<Pieter> Vienna:m pieter$ time bzr branch lp:mysql-server/5.0
<Pieter> bzr: ERROR: Target directory "5.0" already exists.
<Pieter> real	0m19.882s
<Pieter> nice how it takes 20 seconds to give that error
<Pilky> I haven't got branch history planned for BazaarX until 0.5
<Pieter> I first want to add multiple branch support / multi repo support.. then look at a gui for committing and perhaps blaming
<pasky> Pieter: oh, right I was confused
<Pilky> yeah, we're going from the committing side of things first
<Pieter> and I want to do some fancy things like a rebase -i frontend
<Pilky> hmm
<Pilky> we've got some interesting stuff planned, for example I want to try and us FSEvents to automatically do bzr mv
<Pilky> so you can rename a file in an editor, or the finder and BazaarX will detect that and do the bzr mv for you
<Pieter> ah
<Pieter> luckily git doesn't need that
<Pilky> but I believe git doesn't have quite as comprehensive as system for doing moves and renames, correct?
<LeoNerd> But then doesn't git get very upset if you rename and modify a file at the same time?
<Pieter> (I thought FSEvents only works on the directory level? so you don't get any info on which file was changed)
<Pieter> the renaming stuff works ok in most situations
<Pilky> nope, I believe it works on the file level as well
<jelmer> Pilky, That seems like something that would be useful to bazaar in general
<jelmer> Pilky: I.e. as a separate plugin, independent of a particular GUI
<Pieter> Mercurial has it already
<Pieter> you can just take that
<Pilky> remember, it's used for notifying time machine and spotlight for informing them when to update
<Pilky> jelmer: we may run it as a background process
<Pieter> Pilky: time machine doesn't use kernel info, and spotlight doesn't use fsevents
<Pilky> ?
<Pilky> FSEvents were created for spotlight
<Pieter> no, they are separate
<Pilky> they were added in Tiger, but made public in Leopard
<james_w> Jc2k: from the wiki you may want to remove the claim that bzr has never had a regression.
<Pieter> fsevents is a userlevel interface that is less powerful, spotlight has its own kernel access
<Pilky> Pieter: if they don't use FSEvents then what do they use, seems stupid to have 3 separate file system notification systems
<Pieter> Pilky: yeah, they probably did it because you can't get file notifications with fsevents
<Pilky> hmm, so it's all the same system, just with different levels of access
<asabil> has there been any suggestion about changing the bzr branch/pull/push output ?
<asabil> because the way it is now, it gives the illusion that bzr is very slow
<Pieter> Pilky: you can use the kernel interface, but you need root for that
<Pilky> yeah, not ideal
<Pieter> you could just put it in with the applescript exploit
<LarstiQ> cyberix: I'll be at EP, if you want to meet up.
<dato> LarstiQ: not sure if you're making DebConf, but I'm not making it myself
<dato> LarstiQ: and hi!, of course :)
<Mez> w00t - best ever function ever
<Mez> bzr shelve works on svn branches
<Pilky> Pieter: by the looks of things, using kQueue is going to be the best way to do it
<LarstiQ> dato: I'm not, alas. Extremadura though, that I should be able to make :)
<LarstiQ> Mez: cool :)
<dato> LarstiQ: nice. I should *so* bury in shame if I don't make Extremadura myself ;)
<LarstiQ> dato: if that happens, I'll come look you up :P
<dato> *g*
<Mez> LarstiQ, cept it thinks everything done by svn:keywords is a change
<jelmer> Hi dato, LarstIQ, Mez
<jelmer> Mez: that's a known bug unfortunately - bzr needs to support keywords first
<Mez> jelmer, yeah... and it wont let you only shelve from a single file/dir
<jelmer> Mez: Hmm, I thought that worked
<jelmer> Mez: Do you get an error or something?
 * LarstiQ dines
<Mez> jelmer yeah
<Mez>   File "/home/mez/.bazaar/plugins/svn/branch.py", line 106, in unprefix
<Mez>     assert relpath.startswith(self.get_branch_path())
<Mez> AssertionError
<vila> beuno: more robust full upload done, look, test, report, enjoy :)
 * beuno pulls
<jelmer> Mez: Ah, thanks
<vila> beuno: It should now be possible to upload even if the remote dir is "dirty". bzr-upload will just clear its way. Of course that may be destructive, but that's the point :)
<Mez> jelmer, hope it helps
<jelmer> Mez: Any chance you can file a bug?
<beuno> vila, as in, delete all files unrelated to the tree?
<Mez> jelmer, am in the middle of a massive merge..
<vila> beuno: no, not *that* destructive :) Only the files or dirs that are in the way
<beuno> vila, can you enlighten me on what "in the way means"?
<vila> the cases I had in mind was files renamed into dirs and vice-versa. These cases would have triggered weird errors
<vila> "in the way" == "files or dirs that needs to be deleted because we want to upload dirs or files at the same location"
<vila> -2s/renamed/changed/
<beuno> vila, ah, seems reasonable
<beuno> very cool
<vila> symlinks will have to be handled in the same way if/when we want to support them
<beuno> I may attempt to fix that, although I've been secretly waiting for jelmer to run into that bug enough time for him to attempt to first  :p
<jelmer> I did look into adding support for that
<jelmer> but gave up when I couldn't find a function to create them in the Transport interface
<vila> beuno: *Now* I can't imagine a scenario anymore where a full upload will not allow restoring a clean state remotely
<beuno> vila, so you're happy-ish for more people to start using it?
<vila> yup
<beuno> yay!
<beuno> I'll writeup a blog post/email later on
<james_w> go team!
<jelmer> vila/beuno: Time to file that ITP?
<beuno> jelmer, go!
<vila> the lack of chmod bits may still bit some people, but that's far less important than getting a remote dir totally screwed up
<beuno> vila, I have a few branches with work done on bzr-upload, but they are either unfinished, or don't have tests yet, so I'd rather stop pushing more untested code then get that in. Hopefully I'll be able to make some time for it soon
<vila> which could happen, for example, if two people try to upload at the same time, two branches that have diverged and contain some kind changes
<beuno> vila, that's what patches are for  :)
<pasky> Has anyone ever made any detailed comparison of patience diff and the classic Meyers diff? Like taking a corpus of commits and comparing the two diff outputs and judging the difference for sensibility?
<vila> beuno: on that subject, I was already wondering if it's time to have more branches for the plugin so that we can experiment more freely and then merge the official branch when ready
<pasky> or is there just anecdotal evidence available?
<vila> beuno: so create your branches and I'll review them
<vila> jelmer: excuse my ignorance, but was is an ITP ? :)
<beuno> vila, ok, will clean some of them up. I just want to be able to provide code changes with tests as well
<james_w> pasky: jam is most likely to know of anything like that, he's done a lot of tweaking.
<beuno> vila, Intent To Package in Debian. It's basically telling everyone that you're going to be packaging that software
<vila> beuno: good. On the dry-run option, I've looked at the existing tests and I may able to refactor them so that you can reuse most of them
<vila> s/may able/may be able/
<beuno> vila, ah, that would be cool. I couldn't find a way to do that without duplicating the tests that it affected and pass on the dry-run option
<vila> beuno: the idea is to separate the setup/exercise/verify/teardown parts. setup and teardown are already down, exercise and verify should be separated so that you can reuse the exercise part, do your own upload (with --dry-run option) and do your own verify
<vila> s/already down/already done/
<vila> and yes, I'd like to be able to amend my commits like I fix my typos in IRC :)
<gour> like darcs' amend-record?
<fullermd> `bzr sed`  ;)
<beuno> haha
<beuno> vila, that sounds perfect. Like always, you rock
 * gour thinks statik rocks too bringing demanding customers to bzr
<statik> thanks :)
<pasky> james_w: thanks for the hint ;)
<pasky> i'll ask when i see him around
<awilkins> jam: Ping?
<bkor> has someone seen http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html ? the table is hard to read, it is about bzr using 2.8 times more storage than git
<jelmer> I think that's from Pieter in this channel
<Pieter> yeah
<jelmer> statik: Congrats! Really awesome to see MySQL aboard
<cyberix> LarstiQ: sure, why not
<engie> ï»¿Hi. Has anyone come across systems for avoiding stale comments by associating them with a section of the file & a revision, then getting the VCS to flag them up on commit if there are any changes in that section?
<bkor> Pieter: did you get feedback from bzr devs why it is so big?
<jelmer> I think we need to remove the comments indicating we're smallest from that wiki page
<jelmer> or at least more clearly indicate they're not very representative
<Jc2k> NO
<jelmer> Jc2k, ?
<Jc2k> i have git, svn and bzr for all GNOME. for some modules bzr gets caned badly, but i've also got some where bzr canes git.
<Jc2k> the no was a protest at my laggy wifi connection on this train :p
<Jc2k> i will post figures when i have verified all things are fair
<jelmer> ah, ok
<jelmer> Actually looks like there already is a comment up there
<jelmer> Jc2k, it would be interesting to see in what situations one of the two is better
<gour> ...and why
<gour> :-)
<Jc2k> i seem to remember gnome-games making git-svn suffer
<jelmer> beuno: Are you a DD?
<beuno> jelmer, no. Do you need a sponsor?
<jelmer> beuno, yep
<beuno> I can get you one  :)
 * beuno goes fetch a DD
<beuno> hrm, out for lunch
<jelmer> no hurries
<jelmer> bzr builddeb http://bzr.debian.org/pkg-bazaar/bzr-builddeb/unstable/
<jelmer> will build the package
<beuno> alright, I'll drag her in here as soon as she's back
<jelmer> thanks
<beuno> cool, thanks jelmer :)
<jelmer> I'll be away tonight, will be back in ~5 hrs
<beuno> jelmer, np, that will give her some time to review
<Pieter> Jc2k: but, you didn't repack those repositories at all
<Pieter> or, without any --window flag
<Pieter> bkor: I think general consensus was that bzr can still do a lot in generating better packs
<Ng> is it just me or did the progress bar on branching code go away?
<beuno> mwhudson__, while working on the new theme I found a few more issues with my clean url branch. So I'll delay that a bit more until I solve those too
<awilkins> jam: Ping?
<pygi> hey strangy, what's  up?:)
<strangy> just bzr cloned my subversion repo
<strangy> :)
<strangy> from assembly
<strangy> assembla
<strangy> pygi: and you?
<pygi> strangy, working on some articles =)
<Jc2k> Pieter: i did git --bare gc --prune --aggressive
<engie> Hi. Is there a recommended way to abort a commit from a pre_commit hook in a plugin?
<mwhudson> beuno: what issues?
<Jc2k> Pieter: am i expected to know how gc works sufficiently to correctly balance alien arguments like --window and --depth to suit each one of the 520 modules?
<beuno> mwhudson, with revision comparison
<beuno> in /revision
<beuno> it uses revid to compare
<beuno> and we're using revnos now
<mwhudson> beuno: did you try _my_ zpt.cleaner_urls branch?
<mwhudson> i think i fixed that
<beuno> mwhudson, ah, I merged that into my branch, but it didn't travel all the way into my new theme one because it encountered 16 conflicts, which made me revert  :)
<beuno> cool then
<mwhudson> heh
<beuno> I'll merge those in and fix the remaining issue with next/prev
<Jc2k> Pieter: and your still missing the point that we can learn from the differences between an out of the box git mirror and an out of the box bzr mirror and fine cases where both projects can be optimized
<Jc2k> Pieter: i presume the reason that git doesnt pack more agressively by default is for speed?
<mwhudson> beuno: paper over the issue, i think you mean :)
<Jc2k> Pieter: also, how often am i meant to set the git gc cronjob to run?
<beuno> mwhudson, paper over?
<mwhudson> beuno: sorry, just as i said in my mail, navigation is kind of messed up in loggerhead anyway
<mwhudson> i'm not expecting you to fix that :)
<beuno> ah, heh
<beuno> right, I wasn't familiar with the expression
<mwhudson> oh, sorry
<beuno> so, yes, patch it up the best way possible until we do something sensible with that
<beuno> btw, this may seem like an odd question
<beuno> you wouldn't happen to know a revision in the bzr tree that has multiple merge points (merged from in LH), would you?
<mwhudson> >2 parents?
<mwhudson> there are a couple, i think, i went looking for them a while back
<Lo-lan-do> G'day all
<beuno> I'd be happy with 2. I want to test something, but I went back ~20 pages and couldn't find any
<Lo-lan-do> Is there a mostly stable web interface for bzr?
<Lo-lan-do> I hear about loggerhead, but I don't see much activity on the webpage, and it's not in Debian...
<Lo-lan-do> (Or Ubuntu, I guess)
<beuno> Lo-lan-do, me and mwhudson have been working on it like crazy the past month or so
<Lo-lan-do> Yay :-)
<beuno> Lo-lan-do, https://edge.launchpad.net/loggerhead
<beuno> get trunk, it's the latest and greatest
<mwhudson> beuno: all mainline commits have 2 parents :)
<beuno> mwhudson, not according to LH: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes
 * mwhudson gets confused by graph iter_ancestry
<mwhudson> beuno: no, really: each mainline commit has two parents: the previous mainline commit and the revision being merged
<Lo-lan-do> beuno: Is there an online demo somewhere?
<beuno> Lo-lan-do, not of the current trunk, but, well, Launchpad runs it
<mwhudson> Lo-lan-do: http://bzr-mirror.gnome.org:9876/mango/trunk/
<beuno> ah
<beuno> it seems we do  :)
<beuno> mwhudson, is that running your wsgi branch?
<mwhudson> beuno: yes
<Lo-lan-do> mwhudson: Tha,ks
<beuno> mwhudson, very cool. I should merge that into one of the branches I'm working on so I can start punching wholes in it
<Pieter> Jc2k: you're expected to know that if you're converting a 6GB repo, yes
<beuno> mwhudson, but we don't show both parents in LH, do we?
<Pieter> Jc2k: after that, you should never have to run gc --agressive again
<beuno> mwhudson, right, well, LH doesn't show it
<mwhudson> well, the left hand parent is shown in an implicit way i guess
<Pieter> Jc2k: and git gc will be performed automatically, you don't need to do that yourself
<db-keen> I've made several unrelated changes, how can I hold back, and not commit modified versions of certain files?
<engie> db-keen: Have you tried the bzr shelve command?
<beuno> mwhudson, ok. But we have a loop for "merged in" and "merged from", so I was wondering in what cases that actually loops
<mwhudson> db-keen: yes, bzr ci path will commit only changes under path/
<mwhudson> beuno: oh right
<mwhudson> hang on, i can give you a list of revids
<Pieter> Jc2k: you can just take a window of 100 for everything if you want
<db-keen> engine: that looks like what I want, thanks!
<Jc2k> Pieter: but git packed automatically as it imported, so why is it so important to pack it again?
<mwhudson> beuno: http://pastebin.ubuntu.com/21464/
<Pieter> Jc2k: because the packs that git-svn produces are suboptimal
<mwhudson> (14 parents??)
<Jc2k> Pieter: is that considered a bug that will be fixed?
<Pieter> no
<beuno> mwhudson, that's it, thanks  :)
<Pieter> if it would repack every time in between, it would cost a lot of time
<Pieter> so it's better to just do it once at the end
<mwhudson> beuno: http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/robertc@robertcollins.net-20060503100143-94b0e2f638dbbb8d seems a good example
<mwhudson> (but you have to use merge --force to get this to happen i think so it's going to be rare)
<beuno> mwhudson, Please try again -  Sorry, there was a problem connecting to the Launchpad server.
<mwhudson> odd
<beuno> (nicer errors)
<mwhudson> it worked for me
<beuno> there, refresh 3 or 4 times and it got it
<mwhudson> :/
<Jc2k> Pieter: as im mirroring, over time would the backs because sub optimal again?
<Jc2k> *packs
<beuno> mwhudson, when are you deploying zpt on LP?
<Jc2k> (thanks for answering me btw, the git mirror has been a pain so far)
<mwhudson> beuno: should be next wednesday
<Jc2k> (and no one in GNOME seems to know the right way to do things)
<beuno> mwhudson, gather some before-statistics, so we can compare  :)
<mwhudson> heh, probably a good idea
<beuno> ok, cool. Multiple parents doesn't break the new theme
<Pieter> Jc2k: once the pack has been optimized, subsequent normal git-gc's will behave properly
<Pieter> Jc2k: you just need to do this once
<Jc2k> cool
<Lo-lan-do> Hm.  Seems like loggerhead isn't as straightforward as I had expected.
<Lo-lan-do> I guess I'll wait for someone to package it (hi jelmer :-)
<blueyed> Hi. I have a bzr branch, which mirrors a CVS repo (using tailor). I've committed a previous rev. from a derived branch to the CVS branch and when the change came back, it caused a conflict with a newly added file ("conflict adding file ..."). That shouldn't happen, or is this expected?
<Jc2k> Lo-lan-do: hehe, it was really easy for me ;)
<jam> statik: this-week time
<statik> i'll call you now
<Lo-lan-do> Jc2k: I'm getting errors about a "peak" module, even though I have the python-decoratortools package installed
<beuno> Lo-lan-do, you branched trunk?
<beuno> you need python-sqlite, python-simpletal
<beuno> and turbogears
<beuno> python-turbogears to be precise
<Lo-lan-do> Yup, I have all of these.
<Lo-lan-do> Branched from http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/
<beuno> Lo-lan-do, can you paste the full traceback?
<Lo-lan-do> http://pastebin.com/d603a4b67
<beuno> Lo-lan-do, try installin python-pkg-resources
<Lo-lan-do> Already there
<mwhudson> Lo-lan-do: you could try lp:~mwhudson/loggerhead/wsgi-ify
<Jc2k> Lo-lan-do: i am using wsgi-ify, which is why i said it was really easy :)
 * Lo-lan-do installs python-pastewebkit
<mwhudson> python-paste should suffice
<mwhudson> (at least that's the package name in hardy)
<Jc2k> mwhudson: python-pastedeploy is needed too
<mwhudson> Jc2k: is it?
<Jc2k> on etch, yes
<mwhudson> hmm
<Lo-lan-do> python-paste isn't enough, apparently (on sid)
<mwhudson> what fails without it?
<Jc2k> mwhudson: i can remove it and get you a traceback if you like?
<Lo-lan-do> ImportError: No module named paste
<beuno> Lo-lan-do, right, python-paste is needed  :)
<Lo-lan-do> Now I get http://pastebin.com/df82c6d0
<Lo-lan-do> beuno: That was with python-paste, but without python-pastewebkit
<mwhudson> that's strange
<mwhudson> Lo-lan-do: maybe try putting
<mwhudson> import logging.handlers
<mwhudson> at the top of start-loggerhead.py ?
<mwhudson> Lo-lan-do: but also try using the new serve-branches.py script
<Lo-lan-do> Adding the import works
<beuno> mwhudson, I saw you started work for a bzr plugin  :)
<mwhudson> beuno: yeah, it's pretty brainless
<mwhudson> Lo-lan-do: ah, ok
 * mwhudson adds that to his branch
<mwhudson> Lo-lan-do: but you may want to use serve-branches.py anyway :)
<beuno> mwhudson, thoughts on *just* showing side by side diffs in the new theme?  Currently we process and write out the diffs twice. Once for side by side, and once for unified.  Would doing that get me killed?
<Lo-lan-do> Hm.  For some reason, Iceweasel displays the XML as is.
<mwhudson> beuno: not by me
<mwhudson> Lo-lan-do: oh hang on
<mwhudson> i think i forgot to push a fix
<beuno> mwhudson, we can re-add that option later on, with my ajax branch, since we will request only what the user wants
<mwhudson> beuno: though i would if picking the unified view would make more sense
<mwhudson> the side-by-side view tends to extreme wideness
<mwhudson> Lo-lan-do: please pull again, you want revision 204
<beuno> well, I'm a vimdiff man, so I prefer side by side, no matter the width. I can leave both, just thought we could make the transition with just one, and then re-add it later on with ajax-goodness
<Lo-lan-do> mwhudson: Better, thanks.
<mwhudson> beuno: i don't have a strong opinion
<Lo-lan-do> Although I suppose I'm still going to whine: could you only regenerate cached data if no revisions have been added?
<mwhudson> beuno: only displaying one does make a lot of sense i think
<mwhudson> Lo-lan-do: pardon?
<Lo-lan-do> Otherwise it can take quite some time between startup and operational status
<mwhudson> Lo-lan-do: oh i see
<mwhudson> Lo-lan-do: no
<mwhudson> basically
<mwhudson> loggerhead needs to merge sort the revision graph when it starts up
<mwhudson> i suppose it could cache this somewhere...
<Lo-lan-do> That's going to be a problem if I want to integrate it into a GForge plugin...
<mwhudson> why would you be restarting it frequently?
<Lo-lan-do> Even if it only took one second per branch, there can be hundreds or thousands of branches...
<Lo-lan-do> To take new project and branches into account?
<mwhudson> you don't need to restart to do that
<Lo-lan-do> Unless there's a way to run loggerhead as a CGI, but then startup time is even more important.
<mwhudson> well, you do if you use a config file, but that's a bad idea :)
<mwhudson> Lo-lan-do: are you auto generating a loggerhead.conf at the moment?
<Lo-lan-do> At the moment I'm getting my first instalce of loggerhead to run so I can play with it, that's all :-)
<mwhudson> ok
<mwhudson> well, if you use the serve-branches.py version, it will pick up new branches as they are added just fine
<Lo-lan-do> But I'm all in favour of a daemon that needs no restarts, if one can add/remove branches to it.
<mwhudson> but it's bound to the file system
<Lo-lan-do> fam or something?
<mwhudson> if the information about what branches you have is somewhere else, you'll need to write some (simple) code
<mwhudson> Lo-lan-do: hah, no, nothing that fancy
<mwhudson> it's lazy, it doesn't create the branch views until the first view of a branch
<mwhudson> (which does mean the first view of a branch can be slow)
<Lo-lan-do> Okay, so no list of existing branches?
<mwhudson> i think bzr needs to change a fair bit before we can get away from that, sadly
<mwhudson> Lo-lan-do: right
<mwhudson> Lo-lan-do: it's what's running on http://bzr-mirror.gnome.org:9876/
<Lo-lan-do> Okay.  I suppose I'll generate links with "bzr branches" in the background.
<mwhudson> that is just serve-branches.py running from the directory that contains all the repositories
<Lo-lan-do> Oh, hey, an f-spot branch.  I guess I can abandon mine :-)
 * mwhudson goes to to breakfast and stuff
<abentley> beuno: Showing only side-by-side diffs will get you killed by me.
<abentley> Having to always switch it is annoying enough.
<beuno> abentley, even if I bring it back in the next release?
<beuno> it's stupid how it's done now, and wastes ton of resources
<abentley> beuno: So wouldn't it make more sense to stop it wasting resources?
<beuno> abentley, yes. I have a branch for that, but it's too big of a change to land it this release
<abentley> You'll waste more resources with ajax.
<beuno> and why is that?
<abentley> Because the expensive part is performing the sequence matching, and that only needs to be done once.
<abentley> But if you ajaxify it, you
<abentley> will throw away the sequence.
<beuno> abentley, well, today, we generate each diff twice per file changed per page. With ajax, we'll only generate it once, and when you actually want to see the diff to that file
<beuno> so, I think we'll get a big win overall, even by doing sequence matching twice
<abentley> The expensive part of generating a diff is the sequence matching.
<mwhudson> abentley: no, it's rendering all that html :)
<abentley> And avoiding retrieving the texts twice doesn't hurt either.
<beuno> right, bzr is not an issue at all here
<mwhudson> the actual getting the diff out of bzr is not the problem today in loggerhead
 * mwhudson really goes to have breakfast now
<abentley> mwhudson: Diff generation is O(n^2).  Is generating HTML?
<beuno> 3sec to generate a 30k line diff, 30sec to make it HTML
<Lo-lan-do> mwhudson: What if a branch disappears?  Will serve-branches.py remove it from its cache and the list?
<beuno> abentley, ^
<abentley> beuno: ^
<beuno> heh, I don't follow  :)
<beuno> you're talking about the cost of generating in bzr, right?
<abentley> HTML generation ought to scale linearly.  File diffing scales with the square of the number of lines.
<abentley> So in the worst case, File diffing will always be slower.
<beuno> I understand that theoretically, but, in practice, in out big-case scenario (36k line diff), bzr takes 3 seconds to generate it, and it takes us over 30 seconds to make that HTML
<abentley> beuno: This is with simpletal?
<beuno> abentley, yes
<abentley> How is the HTML being generated?
<beuno> it's 1.40m with KID
<beuno> abentley, mapping the diff object generated by LH with the template
<abentley> It sounds like taking a more direct approach would be appropriate.
<beuno> I'm working on the new theme now, where I'm trying to improve that
<beuno> abentley, direct as in not using a template?
<abentley> beuno: Using a template only for the icing, using list.append(string) for generating the HTML.
<mwhudson> Lo-lan-do: the listing is always done with os.listdir(), so yes
<mwhudson> Lo-lan-do: it will stay in the cache (currently, at least, this much would be fixable)
<Lo-lan-do> Hmm.  That sounds quite interesting.
<engie> Hi. What's the best way to tell which of two revision numbers (as strings) is the latest?
<beuno> yes, that's something I'd like to try eventually, or use a non-xml based templating engine for those bits. But, well, we have bigger problems at the moment, so we're trying to get those out of the eay first
<Lo-lan-do> Surely the cache expires after some time, right? :-)
<mwhudson> engie: you can't
<mwhudson> Lo-lan-do: nope!
<mwhudson> Lo-lan-do: this is probably not ideal
<mwhudson> engie: in general
<abentley> engie: You can only do that when the revnos are in the same branch and have no dots.
<engie> mwhudson, abentley: OK, thanks
<abentley> Then, the larger number is more recent.
<komputes> hey guys, I have a project I'm working on, but every time i pull all the files that were executable loose the executable bit.
<komputes> which means every time i pull it I have to chmod u+x those files. does anyone know why this is happening, how to circumvent this without ignoring the file all together.
<mwhudson> komputes: well, that shouldn't be happening
<komputes> mwhudson: I doubt that one of the other project members are playing a trick on me
<mwhudson> but bzr does track the execute bit
<jam> james_w: Elliot mentioned that you had a screencast, is that something I can link publicly for "this week" ?
<komputes> mwhudson: does the fact that ownership of the file changes from user to user have anything to do with the error i'm having?
<statik> jam: http://www.theregister.co.uk/2008/06/19/mysql_dumps_bitkeeper/
<komputes> statik: very nice ;)
<Lo-lan-do> mwhudson: Is all the caching in serve-branches.py done in memory?
<mwhudson> Lo-lan-do: not all of it, but a fair chunk yeah
<mwhudson> memory usage has been a bit of a problem with loggerhead, but so far the blame's more been on the rendering than this caching
<Lo-lan-do> Hmm.  There's definitely going to be problems with that on a forge.
<mwhudson> well it's a problem on launchpad too, so we're actively working on it :)
<Lo-lan-do> Glad to hear it :-)
<Lo-lan-do> Also, the RSS/atom link gives me Internal Server Error.
<Lo-lan-do> But apart from that, I'm quite impressed, and I'm eager to see it stabilised and deployable :-)
<awilkins> Verterok: Aha, you are here
<awilkins> How's that xmlrpc stuff going? Want an enthusiatic dogfooder?
<mwhudson> Lo-lan-do: the atom feed i fixed just now
<Lo-lan-do> mwhudson: http://pastebin.com/d1e6721d0 for the error
<mwhudson> Lo-lan-do: yeah, that one ;)
<mwhudson> pull again
<Lo-lan-do> No revisions to pull.
<mwhudson> darnit
<mwhudson> i hadn't pushed it, pushing now...
<Verterok>  awilkins: Hi :)
<Verterok> awilkins: it's going quite good, I just implemented error reporting in xml :D
<Lo-lan-do> Yay, it works :-)
<awilkins> Verterok: My users are running into the lethargic performance of the plugin ; if it's stable enough, I'll take an order of 6 to go ....
<awilkins> Verterok: Well, I'll try it out on their data, and if it blows up, I'll try to fix it.
<Verterok> awilkins: I'm using it in a daily basis (dogfooding, as you said)
<awilkins> Verterok: Sounds good - is the performance up? Is the XMLRPC a socket-based server?
<Lo-lan-do> mwhudson: Also, a link to go "up" one directory would be welcome.
<awilkins> Verterok: More to the point, are there public branches :-)
<mwhudson> Lo-lan-do: hm, good idea
<mwhudson> Lo-lan-do: file a bug? :)
<Verterok> awilkins: regarding performance, the bzr-java-client testsuite runs in aprox 45 sec. against the CLI ~4min :D
<Verterok> the current server is a extension of the python SimpleXMLRPCServer
<Verterok> awilkins: yes, there are public branches...
<awilkins> Verterok: I bet the differential on Windows is even greater ; it doesn't like to start processes.
<awilkins> Verterok: Are they on lp?
<Verterok> awilkins: I didn't test it on windows yet, so your help is more than welcome :)
<Verterok> awilkins: should be on lp...let me check
<Verterok> awilkins: oops, I keep pushing to my server, I'll push the xmlrpc branch to lp in a sec.
<Verterok> awilkins: I must go for 30min, I'll push as soon I finish this
<awilkins> Roger roger
 * Verterok heads to a boring meeting
<Lo-lan-do> mwhudson: http://pastebin.com/d21742d3
<mwhudson> Lo-lan-do: i'm not sure something so simple will work in all cases
<mwhudson> Lo-lan-do: maybe it should, though!
<Lo-lan-do> Seems to work here, although only when in a branch.  I can't go up to /gforge/ if I'm in /gforge/patched/ for instance (the branch is at /gforge/patched/foo/)
<Lo-lan-do> http://pastebin.com/d769c9742 fixes that :-)
<Lo-lan-do> (Proof of concept, needs tuning, and so on)
<aldolat> hi there! :)
<Lo-lan-do> mwhudson: http://pastebin.com/d2e6819e4 and I'll stop bugging you about it :-)
<aldolat> can I delete a project of mine in LP?
<strangy> aldolat: no .. you must make a ticket for that
<strangy> and that annoys me
<aldolat> this is not good... an admin of a project should have the possibility to do that
<aldolat> imho :)
<strangy> i agree but in this case it does not have that permission
<aldolat> clear & simple :D
<aldolat> thx. bye! ;)
<engie> Is there a command that tells me what the revision number would become if I committed right now?
<beuno> engie, I suppose bzr revno + 1
<beuno> (not a command really)
<engie> OK, thanks
<james_w> hi jam. I'd prefer not to link it publicly from it's current location. Could we defer it for a week?
<Verterok> awilkins: still around?
<engie> ï»¿Is there a recommended way to abort a commit from a pre_commit hook in a plugin?
<engie> At the moment I throw an uncaught exception and it's pretty messy
<engie> This is to do some code sanity checking before committing
<lifeless> morning everyone
<vila> strangy: and how about *renaming* a project ? For hysterical raisins the webdav plugin is called bzr.webdav, I'd prefer bzr-webdav..
<vila> hi lifeless
<Verterok> mornin' lifeless
<mwhudson> engie: i think raising an exception is the way
<mwhudson> if you raise a subclass of BzrCommandError (i think it's that one) the message wll be displayed nicely
<engie> mwhudson: OK, I'll grep for that and have a go
<strangy> vila: i don't know ... i created a test project on launchpad just to test it .. and then i could not delete it, instead i had to make a ticket
<strangy> vila: that is all i know ...
<vila> strangy: ok, thks
<awilkins> Verterok: Yes, just lurking intermittently
<Verterok> awilkins: ok, I just pushed to lp both branches xmloutput+xmlrpc and java-client+xmlrpc
<Verterok> awilkins: https://code.launchpad.net/~guillo.gonzo/bzr-xmloutput/xmlrpc
<Verterok> and https://code.launchpad.net/~guillo.gonzo/bzr-eclipse/java-client-xmlrpc
<Verterok> awilkins: I'm going to create the bzr-java-client project, so we can work on this as the "bzr-java team" :)
<statik> james_w: have you considered or tried uploading your screencast to archive.org?
<statik> i've never tried with video
<james_w> hi statik, no, but I saw a recommendation that it could be good idea.
<awilkins> Verterok: Go bzr-java team :-)
<james_w> I also considered ShowMeDo.
 * awilkins goes out to pcik capes
<james_w> statik: had any luck creating any?
<Verterok> awilkins: go team! :D
<statik> awilkins: are you working on netbeans or eclipse?
<awilkins> statik: Eclipse (3.2)
<statik> awesome
<awilkins> Blarrgh, ate too many jelly beans and have a serious sugar headache
<lifeless> abentley: I'd love a get_mpdiffs that included deletes
<abentley> lifeless: You mean actually including the deleted text?
<lifeless> yes
<lifeless> like NewText
<lifeless> but GoneText
<lifeless> for a couple of use cases; the immediate one is to index it
<abentley> Well, I think it could be arranged.  The text builder would ignore it, of course.
<lifeless> but annotate has this limitation of being hard to identify deleted lines with it
<Verterok> statik: there some folks working on IDEA, and I think a Netbeans related mail reached the list a few weeks ago
<abentley> lifeless: For a multi-parent diff, mpdiff is kinda arbitrary about which parent it assigns lines to.
<lifeless> abentley: re loggerhead speed; we have a C differ, and bzr's core has been hammered on for speed - template engines may have had less detailed work done on them
<lifeless> abentley: for my index needs thats fine, I don't care about ParentText, only New + Gone
<lifeless> (and New is all I can get today, I was just speculating about moving to using mpdiffs and this seemed a useful dicussion to have
<abentley> I think it would be fine, as long as it was optional.
<lifeless> beuno: is there new bling to peek at?
<mwhudson> beuno: ping
<beuno> lifeless, I've got the javascript for it done, need to integrate it into LH, which will be in a few hours when I finish cursing with the new theme
<beuno> mwhudson, pong
<lifeless> beuno: awesome!
<mwhudson> beuno: ok, still working on theme stuff then, that's what i was going to ask :)
<mwhudson> beuno: i think i may try finishing off zpt.cleaner_urls then
<mwhudson> beuno: as i really really really want to merge it and wsgi-ify today
<beuno> mwhudson, yes. I'm working on the diff view, which is quite complicated to get right
<mwhudson> beuno: i can believe that, and it's not something i can help with
<beuno> mwhudson, oh, cool. If you could, that would be great. If not, I'll do that after this
<mwhudson> beuno: whereas i think i can fix up the urls just fine
<mwhudson> if with a bit of cursing
<beuno> mwhudson, perfect. I've got 2 gfx guys sitting here hearing me curse, and proposing new ways to structure the HTML every 20 minutes  :)
<mwhudson> :)
<beuno> I have a few ideas on how to improve the diff generation code (LH's, not bzr's), but it will need a few days work, so I'm deferring that for later on
<mwhudson> beuno: if it helps at all, i seriously recommend stealing stuff wholesale from trac's diff view
<mwhudson> beuno: if that means we lose side-by-side for now, *shrug*
<mwhudson> (imo)
<jam> james_w: that's fine, he just commented on it in this_week, and I thought I could link it, but we can link it later
<beuno> mwhudson, yes, the trac is great for unified diff, but I think more people will scream at us if we loose side-by-side than with unified. Of course, eventually we'll have both
<beuno> mwhudson, emailed you what the current diff looks like
<mwhudson> beuno: the "<< previous" looks funny
<mwhudson> beuno: but it looks fine
<beuno> mwhudson, yes, I'm not going to show a previous if there is none, so I removed the CSS bit, which made it ugly looking  :)
<mwhudson> ok :)
<beuno> I was trying to dump the diff text directly without having to go line by line, to speed it up, but it's going to be impossible without changing large amounts of code
<beuno> so I'm back to doing it with the line-by-line approach
<Verterok> awilkins: I forgot to mention, the xmlrpc java-client dependencies are available at: http://guille.beuno.com.ar/maven-repo/
<mwhudson> fair enough for now
<mwhudson> i agree that it would be really good to change this though
<beuno> mwhudson, FWIW I'm getting a lot of those LP timeouts on LH
 * mwhudson takes a peek at the machine
<beuno> I'm hammering http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/bialix@ukr.net-20070922162037-d1ym5gbli9utowto mostly, if it helps
<beuno> (hammering == accessing every ~5 minutes)
<mwhudson> that sounds like a load even loggerhead should be able to cope with :)
<mwhudson> the machine seems a bit busy but nothing bonkers
<mwhudson> it runs too many services, that's the big problem
<beuno> I haven't been able to see that page in a while now
<mwhudson> hmm!
<lifeless> vostok still?
<mwhudson> yeah, for just a little longer
<lifeless> I don't think its too many services
<awilkins> Verterok: Ta
<lifeless> I think its inefficient services that will expand to use the resources available
<lifeless> and then crash anyway
<mwhudson> lifeless: well, ok
<james_w> hey! http://article.gmane.org/gmane.comp.version-control.subversion.devel/101669
<lifeless> pedants-R-us at your beck and call
<mwhudson> but it's not just loggerhead though :)
<mwhudson> the puller hits it pretty hard too
<lifeless> I love this:
<lifeless> SILENTLY upgrade your working copy, which means that previous
<lifeless>     versions of Subversion will no longer be able to read it.
<lifeless> see, this is why I think what we do is _better_
<awilkins> It's not the first time
<lifeless> abentley: your bzrdir change, is just a conf file?
<lifeless> awilkins: oh, I know :)
<awilkins> It's a shame, because it restricts you to using older CLI clients until your GUI clients catch up
<abentley> lifeless: Yes.
<lifeless> abentley: then I think its ok to add it without bumping the format, but subsequent changes are likely to need a bump
<abentley> lifeless: agreed.
 * beuno makes a voodoo doll shaped like IE7 and starts poking it with needles
<lifeless> abentley: is the new file cloned?
<abentley> lifeless: no.
 * mwhudson wanders off to a different computer for a call
<mwhudson> beuno: loggerhead got restarted, the link should work now
<beuno> mwhudson, it does, thank you
<jam> beuno: I just got it to work as well
<jam> that doesn't seem like a particularly huge diff
<lifeless> 7 methods to go
<engie> I'm working on my first bzr plugin - https://launchpad.net/bzr-stale-comments . The idea is to put RevNo: X into docstrings and other comments which shows the revision number that the comment and associated code block is valid for. The plugin detects these and fails the commit if the code has been updated but not the comment. It is only just working, with no real semblance of testing,
<lifeless> engie: cool
<lifeless> engie: sounds interesting
<beuno> jam, I don't think it's the diff, it may be the multiple parents, but I'm just guessing
<awilkins> Verterok: I'm getting "unable to load plugin"
<Verterok> awilkins: using bzr-eclipse/trunk?
<awilkins> Verterok: Just in the bzr client
<awilkins> Verterok: Installed xmloutput.xmlrpc as "xml" in the bzr plugins folder and it says "Unable to load plugin xml" at the start of every call
<awilkins> bzr Unable to load plugin u'xmloutput' from u'C:/Users/Adrian/AppData/Roaming/bazaar/2.0/plugins'
<Verterok> awilkins: do you have bzr.exe or a full python install?
<mwhudson_> awilkins: bzr -Derror rocks
<mwhudson_> should get you a more useful traceback
<Verterok> mwhudson_:  thanks ;)
<awilkins> Verterok: Full python install, I even just built the 1.6b2 to see if it was that
<awilkins> "No module named errors"
<Verterok> awilkins: maybe a typo in my rush to push the lastest changes...
<Verterok> awilkins: let me double-check this
<Verterok> awilkins: heh, I renamed a module form errors to xml_erros and left a errors.pyc behind
<Verterok> that's the reason it "works for me" (tm)
<Verterok> :P
<mwhudson_> ouch
<awilkins> Fixed
<igc> morning
<Verterok> awilkins: great, (it was in service.py) here too...pushing the fix to lp
<Verterok> mornin' igc
<lifeless> igc: http://www.theregister.co.uk/2008/06/19/mysql_dumps_bitkeeper/
<igc> hi Verterok
#bzr 2008-06-20
<igc> thanks lifeless. So the big 1.5 finally lands.
<Verterok> awilkins: all tetsts passed :) (pushing to lp now)
<Verterok> awilkins: I'll be back online in ~ 1h (heading home)
<Verterok> seeya
 * Verterok runs to catch the train
<igc> reviewing abentley's StackingPolicy patch today
<abentley> igc: thanks.
<kumi2> lifeless: wow, mysql using bzr
<lifeless> kumi2: nice huh :)
<kumi2> yeah that's so awesome.
<jelmer> james_w: Now that bzr-loom is packaged, do you think it makes sense to have bzr-builddeb suggest it?
 * jelmer also wonders if it makes sense to make the bzr package suggest every possible plugin
<jelmer> you'd assume that reverse "Enhances:" would be suggested by aptitude, but that doesn't appear to be the case yet
<lifeless> bug filin' time
<poolie> hi
<beuno> howdy poolie
<jelmer> 'morning lifeless, poolie, beuno
<beuno> evening jelmer
<lifeless> hi jelmer
<beuno> lifeless, http://intranet.pentacorp.net:8080/bazaar/bzr_garbage/changes
<lifeless> beuno: getting there!
<beuno> :)
<mwhudson> beuno: can you suppress ff's history suggestions
<mwhudson> ?
<beuno> food, then polish
<lifeless> beuno: suggestions - put it to the right, or else suppress ff
<lifeless> also, could you show it as words and phrases not tuples:)
<beuno> mwhudson, that's one of the things I have to find out. I probably can with some voodoo magic
<beuno> lifeless, I'm going to do better then that
<lifeless> and perhaps they can be clickable, to make that the search ?
<beuno> yes :)
<beuno> that's what I meant by better
<beuno> and it should go away when you delete all text
<beuno> and a big list of etc
<beuno> but, I'm off to get food
<beuno> mwhudson, I uploaded the fix to the clean url branch
<beuno> your changed didn't seem to quite get there
<mwhudson> beuno: i noticed :)
<beuno> not it behaves the same as it does on LP
<beuno> s/not/now
<mwhudson> beuno: so when i said i was firefighting
<mwhudson> that was triggered by me not accessing launchpad's loggerhead to compare my branch to launchpad :)
<beuno> hahaha
<mwhudson> thanks for doing it :)
<beuno> I'm so glad I don't have access to some places...   :)
<beuno> ok, off for a bit
<mwhudson> i'm hoping to get that taken away soon :)
<mwhudson> beuno: see ya later
<beuno> mwhudson, let me know what else I can do to help with the wsgi merge
<beuno> if that's going in sooner then later, then I'll start merging that in with me branches and see what breaks  :)
<beuno> I'd like to fix setup.py and everything that surounds installing LH
<beuno> aside from making lifeless happier with more search bling, of course  :p
<mwhudson> beuno: well, i think i'll be merging zpt.cleaner_urls soon
<mwhudson> beuno: and then probably the wsgi-ify stuff
 * mwhudson merges zpt.cleaner_urls to trunk
<mwhudson> uff, wsgi-ify is 2400 lines of diff
<mwhudson> out of only 8k lines total :)
<mwhudson> hmm
<mwhudson> should bzr branch $url a/b create a shared repo at 'a' if it doesn't exist?
<mwhudson> it would be a bit magic, but it would be handy
<lifeless> mwhudson: eep, sscary
<lifeless> mwhudson: maybe with a flag
<lifeless> mwhudson: but what if a/.. is a repo
<mwhudson> lifeless: yeah, maybe it's too magic
<mwhudson> in general i do worry a bit that getting a good environment for a new project with bzr  (shared repo, appropriate appendpath-y paths in locations.conf) takes a bit too much typing
<Peng> jelmer: I ask this daily, but is bzr-svn's 0.4 branch considered stable at the moment?
<TodoInTX> Hello; I just created a project on launchpad and am trying to check-in my files to it.  I created a branch but when I try to push I get...
<TodoInTX> bzr: ERROR: Not a branch: "/home/matt/mysql/scripts/".
<TodoInTX> did I miss a step somewhere?
<spiv> How did you create the branch?
<TodoInTX> On lauchpad.net  Code -> Register a Branch -> Fill out form...
<TodoInTX> added my public key...
<TodoInTX> then I got this page... Update this branch: bzr push lp:<url>
<spiv> TodoInTX: registering a branch on Launchpad doesn't create a branch.  See "bzr init --help"
<spiv> TodoInTX: you probably want to do something like "bzr init /home/matt/mysql/scripts", then "bzr add" in that directory to add files to that new branch, then "bzr commit" to commit the files, then "bzr push lp:<foo>" to push the result to Launchpad.
<TodoInTX> ok... missed lots of steps :-)
<spiv> thumper: ^ looks like the "Register a Branch" and choosing "Hosted" still leads newbies astray
<thumper> :-|
<TodoInTX> spiv:  grr... I did "bzr init help" and it made a directory 'help', I assume it's not safe to just delete that... I need to kill it from the repository some how?
<spiv> TodoInTX: it is safe to delete that
 * TodoInTX removes the .bzr directory anyway for good measure. 
<TodoInTX> nothing usefull in there yet anyhow
<spiv> TodoInTX: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html  is probably a good thing to read if you haven't already
<TodoInTX> will do.
<TodoInTX> spiv, thumper: either of you Canonical employees?
<spiv> TodoInTX: both :)
<TodoInTX> ah, know egrubbs in San Antonio ?
<spiv> Yeah :)
<spiv> I saw him at PyCon in Chicago a while ago.
 * spiv -> lunch
<TodoInTX> :-D he's in my MySQL users' group I created.
<TodoInTX> though pushing his PgSQL agenda ;-P
<TodoInTX> we used to work together a Rackspace for several years.
<jml> lifeless: would it make sense for loom to have an analogue of 'bzr log' for 'record'?
<lifeless> jml: yes
<jml> lifeless: good. I will file a bug to this effect.
<lifeless> thumper: you could just delete the web ui to create hosted branches :)
<lifeless> jml: most of TODO is valid bugs
<jml> lifeless: I didn't even think to check TODO
<jml> lifeless: in that case, I am going to take TODO and turn it into bug reports.
<lifeless> sure; just think about each one ;)
<jml> naturally
<thumper> lifeless: no
<TodoInTX> ï»¿spiv: sorry to be a pest... trying to push using lp: url location from site gives "http does not support mkdir()".  Trying using bzr+ssh: format from the tutorial gives "Parent directory...does not exist."  Tried with --create-prefix and it pushes but I don't see the files associated to me on the site.
<beuno> mwhudson, yay! Did you have to fix anything else?
<TodoInTX> thumper:  ^ ideas?
<thumper> TodoInTX: you need to do `bzr launchpad-login <your lp id>`
 * beuno curses LH in LP
<mwhudson> beuno: on the phone, brb
<thumper> TodoInTX: which version of bzr?
<TodoInTX> thumper:  1.3.1
<TodoInTX> It says "Created new branch" but I don't see it.
<thumper> TodoInTX: it takes a few minutes to flow through the LP ether
<TodoInTX> hrm... so I could have a couple up there now :-/
<TodoInTX> thumper: ah... login was the trick.   now original lp: location works :-)
<beuno> statik, ping
<Peng> If a patch for a random bug is in bzr.dev, can I mark it as fix released?
<beuno> Peng, I believe it's fix committed until it's in a release
<Peng> Okay. Does anyone mind if I change the status, though?
<Peng> (Bug 215059, fwiw; it was fixed in r3506.)
<ubottu> Launchpad bug 215059 in bzr "Cannot push if login is an e-mail address" [Unknown,Confirmed] https://launchpad.net/bugs/215059
<beuno> Peng, on the contrary  :)
<lifeless> Peng: please, bug gardening is a good thing
<Peng> lifeless: fix committed?
<lifeless> Peng: if its not in 1.5, fix committed is appropriate
<Peng> done
<lifeless> please also tag it for 1.6, so people can tell what release it is going into
<Peng> Oh.
<lifeless> or is it a milestone; yes a milestone
<lifeless> http://bazaar-vcs.org/BugGuidelines?highlight=(bug)
<lifeless>     *
<lifeless>       Fix released - the fix is merged into the bzr.dev branch. (It may not be strictly "released" as a tarball yet but this definition seems best.) Please put the milestone for the upcoming release into the bug change message and the bug target milestone.
<lifeless> thats our official usage; I was confused
<Peng> Wait, how do you change the milestone? "Nominate for release"?
<beuno> I'm not sure *why* we do it that way, since common usage for it is committed == trunk, released == in a release
<Peng> It's nice not to have to go mass-changing bugs when making a release.
<mwhudson> beuno: just merged wsgi-ify :)
<lifeless> beuno: because lp shows 'fix committed' bugs by default
<Peng> "Nominate for release"?
<lifeless> beuno: but when determining what to work on you want 'not fixed bugs'
<lifeless> Peng: uhm I don't know :(
<lifeless> Peng: it seems to have changed somewhat
<beuno> mwhudson, oh, VERY cool
<beuno> congrats  :)
<Peng> I nominated it for 1.6, but I don't know if that's correct.
<Peng> Can someone give me an example of a fixed bug tied to a milestone?
<Peng> Hmm
 * Peng shrugs.
<lifeless> thanks Peng
<mwhudson> how can i revert a symlink?
<mwhudson> i'm getting 'not in the same branch as' errors
<poolie> the obvious thing doesn't work, mwh?
<lifeless> there is a bug open
<lifeless> we resolve it
<poolie> mwhudson: suggest you rm then revert it
<poolie> plain rm
<lifeless> rm link && bzr revert link will work around
<mwhudson> poolie: ah right, thanks
<poolie> lifeless: if you want to talk now would be good for me
<lifeless> poolie: I'd rather talk Monday if thats cool with you; I have substantive news to report
<poolie> that's totally ok
<poolie> thanks
<lifeless> s/have /have no /
<poolie> oh heh
<poolie> i thought you wanted to just build anticipation :)
<poolie> spiv: could you please send that brief update mail on hpss status, before 4:30?
<Peng> poolie: What's the right way to say a bug was fixed in a particular release? "Nominate for release"?
<beuno> mwhudson, #158584 is fixed with the wsgi branch, right?
<mwhudson> ubottu: ...
<mwhudson> bug 158584
<ubottu> Launchpad bug 158584 in loggerhead "can't browse to revisions whose revid contains %2F in loggerhead/codebrowse" [Undecided,In progress] https://launchpad.net/bugs/158584
<mwhudson> beuno: yes
<mwhudson> beuno: in two ways :)
<mwhudson> (1, we generate revnos, 2, revid links work now)
<beuno> ah, that's right  :)
<beuno> no "super fixed
<beuno> on LP
<beuno> so fix committed  :p
<igc> poolie: I need to head off in an hour or so. I'm reviewing abentley's stacking policy patch today and expect to get an email out about that before I go
<Peng> What are loggerhead's trunk's current dependencies, then? Paste, ...?
<beuno> simpletal
<Peng> Paste and simpletal; that's it?
<beuno> Peng, I'll find out in a sec, after marking bugs as fixed, I'm going to get setup.py into shape
<beuno> oh, python-sqlite
<Peng> Also, is it in a usable condition? I might run it just for fun.
<beuno> until we fix bug #156609 at least
<ubottu> Launchpad bug 156609 in loggerhead "sqlite bindings should not be required unless you use caches" [Undecided,Confirmed] https://launchpad.net/bugs/156609
<beuno> Peng, yes, very usable  :)
<Peng> Except for setup.py? Can it just be run from source?
<beuno> Peng, yeah, ./start-loggerhead.py and you're off  (after editing loggerhead.conf)
<mwhudson> Peng: the setup.py is probably broken
<mwhudson> beuno: serve-branches.py is much easier now
<beuno> I've seen you mention it, I'll look into it now. Does it have any drawbacks?
<beuno> oh, and also, do you mind if I remove the homepage/ dir from trunk?
<mwhudson> it stores the sql in a tmpdir, rather than a deterministic location
<mwhudson> beuno: no, that's a good idea
<mwhudson> beuno: are you in loggerhead-team now?
<beuno> mwhudson, nope
<beuno> the thing that bugs me the most is not being able to set priorities to bugs  :/
<jml> lifeless: https://code.edge.launchpad.net/~jml/subunit/split-right/+merge/413
<lifeless> jml: EWORKDAY
<jml> no need to shout
<lifeless> jml: symbolic constant, not a shout
<Peng> Y'know, port 9876 is registered.
<Peng> I don't know what the heck for, but still. :P
<lifeless> isn't that bzr:// ?
<mwhudson> oops
<mwhudson> it's what serve-branches.py uses
<mwhudson> mind you, 8080 is registered too :)
<lifeless> no, 4155 is bzr
<Peng> 4155 was officially registered for bzr too. :)
<Peng> mwhudson: Shouldn't serve-branches.py be executable?
<mwhudson> Peng: probably
<Peng> That was a hint to someone with push rights. ;)
<poolie> hello igc
<igc> hi poolie
 * mwhudson is fairly hint-proof
<Peng> Hey look, it works.
<Peng> How do you get serve-branches.py to use a different IP or port?
<mwhudson> you edit it
<mwhudson> which, yeah, isn't so wonderful
<Peng> How do you kill it?
<Peng> Woah, 45 MB of RAM. Nice..
<mwhudson> Peng: C-c
<mwhudson> it doesn't background
<beuno> mwhudson, trunk seems much faster to em
<Peng> So special signals to make it do magical things?
<beuno> s/em/me
<mwhudson> Peng: C-c to exit isn't special is it?
<mwhudson> it's how bzr serve works too
<Peng> Err, No*
<Peng> I meant "No".
<mwhudson> Peng: i'm sorry it's been a long week and i'm tired
<mwhudson> Peng: what was that "no" attached to?  and is there something you'd rather serve-branches did differently?
<Peng> I meant "No special signals ...".
<Peng> Some things do stuff like reload config or restart or shut down gracefully when they get SIGINT or SIGHUP or whatever.
<mwhudson> ah
<mwhudson> nop
<mwhudson> e
<beuno> mwhudson, really, wsgi thing is really nice. Really  :)
<mwhudson> it has no config to reload :)
<Peng> So far Loggerhead looks pretty nice, and it was trivial to set up. :)
<mwhudson> progress hooray
<Peng> What about proxying to it from a web server, so it can be available from http://example.com/loggerhead/ or something instead of http://example.com:9876/?
<mwhudson> that's possible, but requires coding atm
<Peng> How much coding?
<mwhudson> you want to wrap the app object in a paste.deploy.config.PrefixMiddleware object
<mwhudson> Peng: very little
<Peng> Oh.
<mwhudson> from paste.deploy.config import PrefixMiddleware
<mwhudson> app = PrefixMiddleware(app, prefix='loggerhead')
<mwhudson> i think
<Peng> I think it'd need a leading slash.
<mwhudson> uh, yes, probably
<igc> time for me to go today - see you all next week
<lifeless> bye igc take care
<igc> thanks lifeless
<beuno> mwhudson, sent you a small patch to remove some remaining tg stuff
<lifeless> beuno: http://www.google.com/webhp?complete=1&hl=en disables the ff bar
<beuno> lifeless, cool, thanks. Once I finish adapting the branch to trunk, I'll finishis polishing that further
<beuno> mwhudson, scratch that, found a few more, re sending in a bit
<beuno> mwhudson, re-sent
<mwhudson_> beuno: ah, the correct thing to do with branchview.py is to delete the file :)
<beuno> mwhudson_, ah, it's superseded with apps/*, right?
<mwhudson_> beuno: yes
<mwhudson_> i am completely done for this week though
<Peng> I think my VPS died. :\
<Peng> It's slightly on-topic: I was working on setting up Loggerhead at the time! :D
<beuno> mwhudson_, oh, absolutely.  This looks really good. The more I use it, the more I love it  :)
<Peng> Oh, good, just routing issues.
<beuno> ok, search now works with wsgi magic and doesn't autocomplete. On to making them links
<lifeless> wicked
<beuno> google keeps scanning my local LH branch]
<beuno> seems it grabbed it from the logs
<lifeless> :P
<beuno> I know because it hits the 36k diff file often
<chandlerc> google never did anything of the sort!!!!!
<beuno> and my CPU goes through the roof
<chandlerc> ;]
<chandlerc> beuno: you can stop it from scanning directories....
<beuno> chandlerc, well, yes, but I don't want to add a robot.txt to *every* LH branch I have
<chandlerc> hmm
<chandlerc> you sure you would have to?
<beuno> pretty sure, yes
<chandlerc> what's your layout, if you don't mind? honestly, thats a bit nuts...
<chandlerc> and i can file a bug with the responsible team. ;]
<beuno> chandlerc, well, LH uses it's own http server, and if you file a bug for it, I'll be the one fixing it, so maybe we can avoid that  :p
<mwhudson> branchesfromfilesystemroot should have a robots.txt
<chandlerc> bwahahahahaha
<chandlerc> excellent
<lifeless> chandlerc: you work at google?
<chandlerc> indeed
<chandlerc> (recently)
<chandlerc> hold on...
<mwhudson> (the one i just wrote for launchpad does)
<chandlerc> pff, i'll join from work i guess.
<lifeless> so in theory, google may well want to index LH sites
<chandlerc> hmm
<lifeless> but it would be more efficient for it to learn bzr and read the history itself (like bzr-search does)
<chandlerc> somehow... that doesn't seem the most likely outcome
<chandlerc> good to know there are other bzr-lovin googlers
<lifeless> (because loggerhead pages themselves are just rendered denser info)
<lifeless> chandlerc: you found some bzr-love site within google ? :)
<chandlerc> no, just noting that other bzr folks work at google
<chandlerc> refreshing
<lifeless> cool
<lifeless> I know jaq like bzr, and hes at google for a bit now
<chandlerc> hehe
<chandlerc> i'm a big fan of bzr, with one exception -- i want perforce's integrate. ;]
<Peng> Thanks for the help, guys. Setting up loggerhead was a snap. :)
<Peng> Except for when I broke my web server configuration for a few seconds.
<lifeless> Peng: must have come a _long_ way then :)
<Peng> lifeless: I'm using the trunk. It was literally just "sudo apt-get install python-paste python-simpletal" and "./serve-branches.py".
<Peng> (Well, then I installed paste deploy and hacked serve-branches.py a bit so I could use a reverse proxy, but still simple.)
<beuno> lifeless, http://intranet.pentacorp.net:8080/bazaar/bzr.garbage/changes
<beuno> mwhudson, ^    (no more work, I promise)
<lifeless> beuno: freaking cool
<Peng> Hmm, using serve-branches.py, loggerhead is leaving behind its temporary directories, some of them with the sqlite files.
<beuno> lifeless, it's even reproducible on other people's computers too  :)
<beuno> (as in, no more hardcoded paths)
<Peng> If a loggerhead instance gets crawled by a web crawler, how bad will its ram usage get?
<beuno> Peng, google has been quite nice up to now. Doesn't crawl aggresively
<lifeless> beuno: cool. two-words are behaving badly though :)
<lifeless> beuno: if I type:
<lifeless> test Robert
<lifeless> into the search box, what do you pass to bzr-search.suggest() ?
<Peng> beuno: But what if it gets hit by something less friendly and benign?
<lifeless> and http://intranet.pentacorp.net:8080/bazaar/bzr.garbage/changes?q=test+Collins makes it crash I think
<beuno> lifeless, not anymore  :)
<beuno> doesn't return results
<lifeless> so
<lifeless> test Robert
<lifeless> should result in [('test',), ('Robert',)]
<beuno> I think it has to do with a workaround I had to add, because it was splitting up strings into letters
<lifeless> as the search termlist
<lifeless> "test Robert"
<lifeless> should result in [('test', 'Robert')]
<beuno> lifeless, http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080620055014-8wnr5qpzt6h2x7mz?file_id=search.py-20080614235103-lpt63f7b2drplju8-1
<beuno> I have to do: query_list = [query_list]
<beuno> or it will split up "test" into [('t', 'e', 's', 't')]
<beuno> so the side-effect of me doing that is probably forcing all searched into one term
<lifeless> so, what is repr(query_list) before you alter it ?
<beuno> Peng, with the current LH trunk, I think it's fine with crawlers
<Peng> Yeah, I just loaded a couple reasonable large diffs, and ram usage barely changed.
<Peng> 32 bytes each time.
<beuno> lifeless, hrm, seems to work now
<beuno> 'robert'
<beuno> [('robert',)]
<beuno> (before and after)
<beuno> didn't before though
<lifeless> ok
<lifeless> now send
<lifeless> robert collins
<lifeless> as the search
<beuno> NoMatch: No matches were found for the search ['robert collins'].
<beuno> let me remove that first line now
<lifeless> I guess thats robert+collins in the url
<beuno> lifeless, with out that first line:
<beuno> 'robert collins'
<beuno> [('r',), ('o',), ('b',), ('e',), ('r',), ('t',), (' ',), ('c',), ('o',), ('l',), ('l',), ('i',), ('n',), ('s',)]
<beuno> before and after aplying: query = [(query_item,) for query_item in query_list]
<lifeless> beuno: ok, and now http://intranet.pentacorp.net:8080/bazaar/bzr.garbage/changes?q="robert+collins"
<lifeless> whats the repr for that before you alter it
<beuno> lifeless:
<beuno> '"robert collins"'
<beuno> [('"',), ('r',), ('o',), ('b',), ('e',), ('r',), ('t',), (' ',), ('c',), ('o',), ('l',), ('l',), ('i',), ('n',), ('s',), ('"',)
<lifeless> beuno: ok
<beuno> that's with my hack commented out
<lifeless> beuno: so, we don't have phrase indices yet
<beuno> is it suppose to work that way?
<lifeless> so we can ignore the " scenario, I just wanted to see how it would come across
<lifeless> what you're being given is a string
<lifeless> we need to break that into terms
<beuno> so, split by spaces?
<lifeless> assuming users only give us valid characters (not a bad start)
<lifeless> terms = query_list.split(' ')
<lifeless> terms = [(term,) for term in terms]
<beuno> alright!
<beuno> [('"',), ('r',), ('o',), ('b',), ('e',), ('r',), ('t',), (' ',), ('c',), ('o',), ('l',), ('l',), ('i',), ('n',), ('s',), ('"',)'robert collins'
<beuno> er
<beuno> no
<lifeless> sorry, query = in that
<beuno> 'robert collins'
<beuno> [('robert',), ('collins',)]
<lifeless> yah
<beuno> yes, I guesses the variables part :)
<beuno> now, I should probably do something better than raise an uncought exception when no results are found  :)
<lifeless> now, for friendliness
<lifeless> we should show in the completion the terms before the one being completed
<beuno> yay!  http://localhost:8080/bazaar/bzr.garbage/changes?q=partial+index
<lifeless> that is, return [query[:-1] + term] for term in terms
<jamesh> so, if you check the world wide web into a bzr branch, you should have a google killer
<lifeless> jamesh: LOL
<lifeless> jamesh: might be a tad slower
<beuno> (s/localhost/intranet.pentacorp.net)
<lifeless> :)
<beuno> lifeless, I don't understand what you mean by "the terms before the one being completed"
<lifeless> so 'robert collins' -> ('robert',), ('collins',)
<lifeless> suggestion completes options for collins
<lifeless> but the drop down box would read nicer I think if it showed
<lifeless> robert collins1
<lifeless> robert collins2
<lifeless> etc
<lifeless> rather than
<lifeless> collins1
<lifeless> collins2
<lifeless> as it will today
<Peng> How useful are LH's caches on a bzr.dev-sized branch with the trunk now?
<beuno> Peng, the caches are only used for files-changed
<Peng> It takes 3 or 4 seconds to generate the cache, so I hope that penalty wouldn't be incurred in every request if I didn't use them...
<lifeless> beuno: if I made diff(inv1, inv2) 5 times faster, would that be enough to remove them ?
<beuno> it's a pretty big win, although it doesn't have much to do with branch size as much as with how many merges each parent has
<beuno> lifeless, yes. I believe the difference today is about that much, maybe less
<beuno> Peng, you mean the cache on startup?
<Peng> beuno: First time the branch or repo is hit after it starts.
<beuno> that's a one time thing for the revision graph. It gets cached in memory
<beuno> only on startup
<beuno> it's assumed that you won't be restarting LP too many times (unless you have to work on it)
<beuno> s/LP/LH
<beuno> 66.249.72.129 - - [20/Jun/2008:03:16:00 -0200] "GET /bazaar/bzr_garbage/revision/31 HTTP/1.1" 404 - "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
<beuno> I keep changing branches and googlebot tries to resume where it left off  :p
<jml> beuno: does it ever leave the cache?
<lifeless> beuno: another nice thing would be if I could arrow-down into the pop up box rather than using the mouse
<beuno> jml, just for files changed, in an ugly sqlite DB
<beuno> lifeless, yes, simulate autocompletion. I'd have to do substantial changes to the javascript for that
<beuno> making the search results more interesting is higher on the list  :)
<beuno> and, well, making LH index stuff automagically
<beuno>  /SearchUI: 0.029181003570556641 secs
<beuno> lifeless, very nice performance  :)
<jml> lifeless: loom TODO refers to "warp" a lot. Is that an old name for 'thread'?
<lifeless> jml: I was intending to do a bulk rename to warp and weft
<lifeless> but I suspect that folk will have trouble
 * jml certainly will
<spiv> poolie: I've sent an update
<jml> lifeless: my knowledge of textiles comes entirely from B-grade fantasy novels and a presentation on the history of Toyota :)
<lifeless> http://en.wikipedia.org/wiki/Warp_(weaving)
<jml> lifeless: why not call them patches?
<lifeless> jml: several things
<lifeless> jml: the bottom thread represent upstream; its 'a patch against null' if you like, but huge
<lifeless> jml: terminology overload, a 'commit' is also a patch
<chandlerc> i go away, and everyone starts talking
<poolie> thanks spiv
<beuno> poolie, have you seen the combination of lifeless's magic and some ajax?  http://intranet.pentacorp.net:8080/bazaar/bzr.garbage/changes
<beuno> (try searching)
<poolie> i saw a version a few days ago
<lifeless> poolie: try it now then :P
<poolie> wow!
<spiv> beuno: that's becoming slick very fast!
<chandlerc> wow...
<beuno> spiv, heh, thanks  :)
<chandlerc> beuno, lifeless: rock
<chandlerc> =D
<beuno> it will look even better on the new theme
<chandlerc> need this on googlecode
<lifeless> switch to bzr
<chandlerc> i use bzr
<lifeless> (I mean googlecode should switch :))
<chandlerc> googlecode's svn is just my remote "branch"
<lifeless> chandlerc: you can easily run this yourself on your own bzr branch
<chandlerc> i actually will probably do so
<lifeless> :)
<chandlerc> googlecode's source browsing is actually impressively similar
 * beuno goes off for 20 minutes
<chandlerc> before they made the latest improvement, it wasn't nearly as good
<beuno> (that means the LH branch will go away with me)
<lifeless> beuno: push!
<beuno> lifeless, already did  :)
<lifeless> beuno: is it wsgified ?
<beuno> lifeless, yeap
<beuno> it's super-fast with wsgi
<lifeless> beuno: is super-search running the trunk deployment stuff?
<beuno> lifeless, yeap, merged with the latest bits from trunk
 * lifeless might look at updating squid-cache.org's instance
<beuno> lifeless, well, trunk is a *big* improvement over what there is now
<beuno> I will probably iron out the remaining search bits in the next few days to add auto-indexing and such
<beuno> having it be in production somewhere would be neat :)
<gour> what's is 'super-search' ?
<beuno> gour, http://200.127.6.219:8080/bazaar/bzr.garbage/changes
<beuno> try searching  :)
<lifeless> I'm going to call it a day work wise
<gour> beuno: ta
<gour> hmm this http://200.127.6.219:8080/bazaar/bzr.garbage/revision/20?q=performance looks interesting
<lifeless> gour: its an improved search for loggerhead utilising bzr-search
<gour> lifeless: will loggerhear become more install-friendly in the future?
<lifeless> gour: it has already AIUI
<gour> hmm
<gour> maybe i should say: dep-friendly
<Peng> gour: python-paste, python-simpletal, python-sqlite
<beuno> yeap, and I hope to drop python-sqlite in the near future
<Peng> I also installed python-pastedeploy for one stupid little middleware. :\
<Peng> LH is still somewhat RAM-heavy.
<Peng> But it's a breeze to get running.
<james_w> beuno, lifeless: great work, I like it.
<beuno> james_w, thanks  :)
<Peng> What was it that breathed new life into Loggerhead?
<lifeless> mwhudson and more recently beuno have been working on it for a while
<lifeless> sometimes it takes a while to ramp up
<lifeless> I'd like to take a little credit, I think the web2y stuff has been enabled by bzr-search
<poolie> ok that's it for me
<beuno> yes, the code for the indexing/searching and the actual guidance to get it working, hence the aknowledgment in the copyright  :)
<Peng> Why do query_list.split(' ') instead of just query_list.split()?
<beuno> I think split() tries to do more things, but it should work just the same
<beuno> off to bed
<beuno> g'night/morning/good weekend (as applies) to everyone  :)
<gour> g'night
<Peng> beuno: Exactly, just split() does try to do more things, e.g. ignoring extra whitespace and also splitting on newlines and tabs and stuff. That seems like more useful behaviour for a search box to me.
<Peng> This place is quickly getting boring.
<Peng> Are you about to go to sleep too, gour?
<Peng> I might.
<Peng> beuno: Good night. :)
 * Lo-lan-do stays there to keep the channel alive (with whining, but still)
<gour> Peng: no, 10am here
<Lo-lan-do> Wah-wah-wah, I want loggerhead packaged in Debian!
<Lo-lan-do> Wah-wah-wah, I want faster startup times for bzr!
 * Lo-lan-do dodges incoming bricks
<Peng> Haha.
<james_w> jelmer: nice work: http://laserjock.wordpress.com/2008/06/19/how-do-i/
<james_w> http://arjen-lentz.livejournal.com/120586.html
<jelmer> Peng: yep
<jelmer> Peng: you can check for yourself by running "make check"
<Peng> jelmer: BTW, I think I had to install 20 dependencies before it would compile. :D
<jelmer> just "libsvn-dev" should do it
<Peng> jelmer: Yeah, but it added up to 20. And I needed python-docutils.
<matkor> What is yours action plan in scenario: I want do small fix on remote branch, so I bzr checkout, later I realise changes are biger so I bzr unbind, serveral times bzr commit .. now I want to merge to remote branch
<matkor> checkout remote branch again and merge to it locally ?
<Lo-lan-do> That, or merge remote branch into local.
<matkor> or bzr bind, bzr update and commit as one big commit ?
<matkor> Lo-lan-do: and later push to remote ?
<Lo-lan-do> Yep.  It amounts to the same thing, mostly, except the LHS an RHS may be reversed.
<matkor> Lo-lan-do: LHS, RHS ?
<Lo-lan-do> Left-hand side, right-hand side.
<Lo-lan-do> Basically, you merge A into B or B into A.  Result is similar, but the graph isn't displayed exactly the same.
<matkor> Lo-lan-do: I would perfer to keep main line (leftmost in olive/log) of changes as made on remote branch ...
<Lo-lan-do> Then bind, update and commit.
<Lo-lan-do> Your local changes will be one commit, but their history will still be recorded remotely.
<matkor> Lo-lan-do: Oh, they will be still visible as many commits in remote branch history ?
<Lo-lan-do> Yes.  The local subgraph will be integrated into the remote branch.
<matkor> Excellent, thanks a lot for help, Lo-lan-do !
<Peng> jelmer: http://people.samba.org/bzr/jelmer/bzr-svn/.bzr/ 's repository has been renamed to repository.backup. Are you doing something or did it break?
<jelmer> Peng: whoops, should be fixed now
<jelmer> I was trying to upgrade it from pack-0.92-subtree to rich-root-pack
<Peng> Why does it have subtrees anyway?
<jelmer> historical reasons
<jelmer> it predates the existance of the rich-root-pack format
<Peng> Why'd you want rich roots?
<jelmer> it's a nonexperimental format
<jam> guilhembi:
<jam> found ancestors: set(['sp1r-jani@a88-113-38-195.elisa-laajakaista.fi-20080328101427-50685', 'sp1r-to
<jam> mas@poseidon.ndb.mysql.com-20080327140832-38613'])
<guilhembi> the final .frm
<jam> bzr cat -r revid:sp1r-jani@a88-113-38-195.elisa-laajakaista.fi-20080328101427-50685 sql/sql_table.cc
<jam> bzr cat -r revid:sp1r-tomas@poseidon.ndb.mysql.com-20080327140832-38613   sql/sql_table.cc
<Verterok> mornin' beuno
<beuno> goooood morning Verterok
<beuno> you're up earlier than expected!  At work yet?
<Verterok> really?, not yet....and I'm not going there until monday ;)
<Verterok> I can say the same for you, at work?
<beuno> hahaha
<beuno> no, just woke up, not even fully dressed yet  :)
<Verterok> hehe
<Verterok> beuno: thanks for the mail, I'll take a look at the mysql/whatever migration during this afternoon
<guilhembi> Path conflict: mysql-test/t/rpl_sync_binlog_basic_32.test / mysql-test/t/sync_binlog_basic_32.test
<guilhembi> jam: ^
<beuno> Verterok, ah, no problem. Handing off stuff is always fun
<beuno> abentley, Verterok is taking over the sqlite > mysql for BB  :)
 * beuno runs
<guilhembi> jam:
<guilhembi> https://code.launchpad.net/~mordred/mysql-server/5.1-telco-6.2-merge
<guilhembi> 6.0: ndb is bzr branch sftp://bazaar.launchpad.net/~cmiller/+junk/ndbtest
<abentley> beuno: Cool
<guilhembi> jam: https://bugs.launchpad.net/bzr/+bug/238895
<ubottu> Launchpad bug 238895 in bzr "'bzr merge --weave/--lca' does not conflict on permutated lines" [Medium,Triaged]
<guilhembi> jam: sql/ha_ndbcluster.cc
<vila> beuno: ping
<vila> beuno: isn't bzr-upload --dry-run the same thing as bzr status -rupload: (given we define a revision-spec for upload) ?
<beuno> vila, pong
<beuno> htm
<vila> htm ?
<beuno> "hrm" with a type  :)
<beuno> argh "typo"
<vila> :)
<beuno> well, yes, now that I think about it
<vila> beuno: reusing status will  have the added benefit of displaying unknown files, helping people (like me) who tend to forget to bzr add...
<beuno> ok, I'm sold
<beuno> I can delete most of the code I did, and just re-use status -r to automagically display that
<vila> beuno: sorry about that, I just thought about it today :-/
<vila> on the bright side, deleting code is good :)
<beuno> vila, nothing to be sorry about, you just saved me from writing tests for it!  :p
<vila> lol
<beuno> cool, now that leaves some time for me to look into adding some progress bars
<beuno> vila, how hard would it be to show the transfer rate?
<beuno> I know you mentioned it before
<beuno> and the more it feels like an ftp client, the easier for website devs to feel comfortable with it
<vila> beuno: I have no idea :) I never hack the progress bars :)
<beuno> vila, I can do the progress bars. I was wondering about transfer rates with transports
<vila> I think we need to wait for bzrlib to implement that at the transport level, poolie talked about doing it (not himself, but it's something that will come one day or the other)
<vila> in the mean time, we may try to implement some two passes trick to count how many bytes we need to transfer, how many roundtrips we will have, etc, but that will be hackish IMHO
<beuno> ok, so not very straightforward
<beuno> we can start with hackish and move on to something better when it's available  :)
<vila> beuno: no. But the 'upload' revision spec still need to be implemented if you really don't know what to do :)
 * vila goes back to x bit implementation drawing board :)
<beuno> ah, cool  :)
 * beuno packs up to move it to the office
<vila> beuno: just for the record, are you using ftp and sftp or only one of them on average ?
<beuno> vila, sftp 95% of the time
<vila> ok, so I may have a working sftp version first (the bzrlib ftp transport doesn't support mode at all, I'll have to create a custom ftp transport for that)
<beuno> great!  I'll finish my draft for to announce it to the world and run it by you if you're still around  :)
<beuno> now, AFK for ~20 minutes, office chair is more comfortable
<LaserJock> james_w: ping?
<james_w> hi LaserJock
<LaserJock> james_w: thanks for the comment on my post. I figured you'd show up ;-)
<james_w> heh, I'm never far away :-)
<guilhembi> jam: I updated the support incident 2413.
<guilhembi> bye
<jam> thx
<jam> have a good weekend
<LaserJock> james_w: question though, in Debichem we just have debian/ directories in SVN. Does bzr-builddeb look in some place for the .orig.tar.gz files?
<james_w> LaserJock: first, the archive, then it will use a watch file if you have one.
<james_w> I could extend it to look under a certain path (remote) as well.
<LaserJock> james_w: hmm, I have them locally (right now I'm doing a new upstream release so they aren't in the archive)
<LaserJock> though I have a watch file so that'd work too
<james_w> unfortunately there are a couple of bugs with the apt and watch file methods as apt and uscan are a little bit crazy
<LaserJock> k
<james_w> ah, if you have them locally then put them in "../tarballs"
<james_w> assuming you have the debian/ checked out on disk
<james_w> you can override this temporarily with "--orig-dir=.../wherever"
<LaserJock> hmm
<poolie> hello james_w, thanks for all your bug work and mail recently!
<poolie> it's so cool
<james_w> hi poolie
<LaserJock> so one thing I'm not crazy about is that it leaves directories (../tarballs ../buildarea) around
<james_w> poolie: you're up early/late aren't you?
<poolie> late, yes
<poolie> on phone
<james_w> LaserJock: yeah, I kind of regret that now, it follows svn-buildpackage here.
<LaserJock> ah
<gour> '--rich-root-pack' it the recommended format in bzr-1.6?
<james_w> I'd perhaps like to transition away at some point, but I haven't thought through the plan.
<LaserJock> I haven't used svn-buildpackage yet
<james_w> gour: --pack-0.92 I think
<LaserJock> james_w: ok, well can you give me a couple good reasons to use bzr-builddeb over just exporting the debian/ into an unpacked .orig.tar.gz ?
<james_w> LaserJock: not having to do that manually?
<james_w> being able to test before commit?
<LaserJock> but svn export is only a single command
<james_w> tar xzf is another though.
<LaserJock> or bzr export
<LaserJock> but you only do that once
<james_w> yeah, it will work fine until you delete or rename a file.
<LaserJock> right, then you just rm your debian/ and rexport
<james_w> yup
<LaserJock> re-export
<LaserJock> so I'm not really seeing savings
<james_w> that's fine. If it don't appeal to you then you don't have to use it
<gour> james_w: ta
<LaserJock> james_w: well, I'm not trying to be a pain, I'm just trying to figure out what exactly it's for
<james_w> LaserJock: you're not being a pain.
<james_w> you're right though, there's no great advantage to it if you are happy to do the steps manually.
<jaypipes> statik: FYI: http://www.jpipes.com/index.php?/archives/240-Removing-Barriers-to-the-Community-MySQL-Moves-to-Bazaar.html
<statik> jaypipes: thanks!
<jaypipes> of course. :)
<jam> jaypipes: I'm a bit surprised on your Hundred Flowers link, considering there is some controversy that it was intentioned to "identify critics and silence them".  But I guess the original thought is very nice
<jaypipes> jam: heh, indeed.
<jam> jaypipes: and certainly thanks for the post, I certainly look forward to what mysql can do with a distributed open dev community
<jaypipes> jam: what about featuring the mysql project once things have been stabilized for a bit? might be a good chance to promote bzr and LP...
<jam> jaypipes: I'm not sure what you mean by "featuring". As it making it a feature project on LP?
<nevans> congrats to the bzr team on the publicity that mysql will bring.  :)
<jaypipes> jam: yes, that's what I meant.  I'm not pressuring or anything, I just think it would be cool! :)
<jaypipes> jam: certainly, there has been a ton of blog buzz on PlanetMySQL about bzr and Launchpad and 100% of the feedback has been positive, which is awesome.
<jam> jaypipes: I agree, I don't have much say in LP featured projects, but I'll put my vote in somewhere :)
<vila> jam: ping, a few questions about chmod bits in bzrlib ?
<jam> vila: pong, chmod away
<vila> sumaary of my current understanding: transport handle mostly files and dir under .bzr and use 0777/0666 by default, plus we handle +x as a versioned property
<jam> abentley: I have a question about Tree.iter_references, there seems to be a discrepancy between what WT4.iter_references() returns and what the code in Tree.iter_references would return
<jam> vila: I would be surprised if anything under .bzr/ wasn't handled by Transport
<jam> maybe stuff in .bzr/checkout
<abentley> jam: It's been quite a while, but I'll try answering.
<jam> so I take that back a bi
<jam> abentley: Basically, WT4.iter_references() returns abspath, and Tree.iter_references returns relpath
<jam> the tests don't notice
<jam> because only WT4 actually implements "supports_references"
<jam> I would *rather* return relpath
<jam> as it works better for non disk-based paths
<jam> s/paths/trees
<vila> jam: >-/ I agree with that of course, I think I don't understand your answer
<jam> vila: you didn't ask a question yet :)
<jam> vila: Things under .bzr/ should generally only be accessed through a Transport, and we version +/- x as a property.
<vila> my question is more about the working tree, except for the u+x bit, we ignore the rest
<abentley> jam: RevisionTree should also implement references.
<jam> abentley: It doesn't implement the function "def supports_references()" which means it doesn't get tested yet
<abentley> I think relpath is the only sane choice.
<jam> abentley: ok, I'll change the test and get Tree working
<vila> i.e. we won't even detect 0667 as an executable ?
<jam> vila: I'll have to figure out on 667, but IIRC, if we see that a file should be executable
<jam> we do a stat(), and then mask based on if the file is writable
<jam> so if you have 600, then  we set it to 700
<jam> if you have 660 => 770, 666 => 777 etc
<jam> I'll check on 0667 in a sec
<vila> jam: don't check
<vila> I'm just trying to understand the bug picture
<vila> the other point now: so far, we have only encounter problems regarding the sticky bits with openssh sftp, right ? All other mode bits are correctly handled by sftp ?
<jam> vila: Our check is:         return bool(S_IEXEC & mode)
<jam> And S_IEXEC == 0100
<vila> yup
<jam> so no, we only check if 0700 is executable
<vila> so I was right, we do the minimun, fair enough
<jam> vila: right the mask is something like 0777 so the 02777 the "2" gets stripped
<vila> ok, fine, thanks a lot, that answer my questions
<jam> vila: *if* we didn't chmod, then they would retain the sticky bit because the fs sets it automatically
<jam> so there has been some push to ask users to use a wrapper script to get their umask right
<jam> and then not try to chmod the files ourselves
<jam> though with packs, most of that is moot, as long as the files are readable
<vila> hmmm
<jam> because we only create them 1 time
<jam> so you need write permission to the directory
<jam> but we don't create it automatically
<jam> except at init time
<jam> At least on Linux servers, you can delete a file that you don't have +w to, as long as you have +w on the directory
<vila> ok. The point is, I try to use the transport for the bzr-upload plugin where I somehow manage a remote working tree (as in write-only mode :)
<jam> so for a pack repo, you should only need to do "find .bzr -type d -print0 | xargs -0 chmod 770" (you can sneak in a 2 if you want)
<jam> vila: sure
<jam> And you are trying to get the bits right on the remote files?
<vila> so the idea is to get the chmod bits from the local working tree and blindly apply them remotely
<vila> well, as right as possible :->
<jam> vila: I would tend to only set them if you think they would be interesting
<jam> though maybe avoiding the ssh issue would be a problem
<jam> because then *some* files would get sticky
<jam> and others wouldn't
<vila> the targeted audience being web devs, I don't think there is a lot of sticky bits around...
<jam> vila: *I* would make sticky bits on my webspace if multiple people are updating it
<jam> but I'm not an average web dev :)
<vila> the web server is the one that update them no ?
<vila> so even group bits may be irrelevant ?
<Pieter> ghaa, bzr diff is so slow
<jam> Pieter: under what circumstances?
<vila> Pieter: wrong channel :)
<jam> And what --version ?
<Pieter> bzr diff -c 0.5.5 on bzr.dev, 1.5
<jam> Pieter: How long for you? I'm doing an lsprof here, but I have some ideas as to what is happening, and it will probably get better in the next release or 2
<Pieter> about 4 seconds
<jam> Pieter: so the #1 issue is that the branch we are holding onto isn't in a transaction lock
<jam> the #2 issue is that dotted revnos are slower than they should be
<jam> though I do have some work on that
<jam> but it won't land for a little while because I'm dealing with other stuff right now :)
<jam> #3 is that our indexes are a bit slower to lookup than they have to, which lifeless has at least proposed a patch for
<jam> I haven't had a chance to look at it yet
<jam> abentley: Ahh, it seems that RevisionTree tests are being tested using WT3 as the base tree, which *doesn't* support references, so the RevisionTree implementation doesn't get tested
<abentley> They would have been written when WT3 did support references.
<jam> sure
<jam> thats one of the problems with tests that skip silently :)
<jam> abentley: reactivated now
<jam> and now passing the test again
<abentley> jam: great.
<jam> abentley: Though DirStateRevisionTree is failing the get_reference_revision test
<jam> abentley: And I believe it is because of the _dirstate_tree_from_workingtree automatically committing
<jam> not positive, but likely
<Pieter> if I have a Tree, how can I tell if a given directory in that tree has files in it?
<jam> Pieter: are you saying you have a WorkingTree, or you don't know?
<jam> (like it could be a RevisionTree, etc)
<Pieter> I have a RevisionTree
<jam> tree.iter_entries_by_dir(specific_file_ids=[tree.path2id('directory/path')])
<jam> list(tree.iter_entries_by_dir(specific_file_ids=[tree.path2id('directory/path')]))
<jam> if you want the list
<jam> rather than an iterator
<Pieter> no, just a boolean if it has files :)
<jam> try:
<jam>   tree.iter_entries_by_dir(specific_file_ids=[tree.path2id('directory/path')]).next()
<jam> except StopIteration:
<jam>   have_files = False
<jam> else:
<jam>   have_files = True
<jam> Pieter: though I think that might always return 1 entry for the directory itself
<jam> you probably also need to check that "tree.path2id('path')" doesn't return None indicating there is nothing at that path
<jam> but that should get you going in the right direction at least
<Pieter> ah yes, that will work
<Pieter> thanks :)
<Pieter> bzr-fast-export tries to export directory renames when there are no files in that directory
<Pieter> and that causes git-fast-import to crash, as it doesn't track empty dirs :)
<jam> interesting, though in Bazaar you certainly can rename a directory with no contents
<jam> My understanding is that there was a weird race if you move the 1 file in a directory
<jam> Ah wait, it was something about moving a directory *and* renaming a file inside of that directory
<jam> because if you renamed the whole directory, you didn't have the right path to rename the file
<jam> something like that
<Pieter> yeah, I fixed that already
<jam> weird, intermittent connection loss
<Pieter> can't I split a hunk with bzr shelve?
<LeoNerd> Not easily
<LeoNerd> I usually revert then vimdiff between file and file.~1~
<jam> Pieter: you can split between hunks, I didn't think you could split a specific hunk
<LeoNerd> You can pull lines about arbitrarily then
<Pieter> bah
<Pieter> hmm, the iter_entries_by_dir thing just returns an empty listiterator if you supply a pathid instead of a list of pathids
 * beuno hugs mwhudson_ and continues working
<james_w> abentley: sorry, I might have jumped the gun on that bzrtools bug report. I'm not sure why he is getting the traceback, but it looks as though this is intended behaviour.
<Pieter> jam: I think the iter_entries_by_dir will always return just one result
<Pieter> jam: it won't walk the contents of the dir
<abentley> james_w: I thought PatchFailed was now behaving like a user error.
<abentley> Pieter: By specifiying the file ids you want, you are restricting its output to just those file ids.
<abentley> Pieter: You might want something more like walkdirs.
<Pieter> abentley: yeah, that's what I figured
<jam> Pieter: if you supply a pathid it iterates the string
<jam> which doesn't match anything
 * Verterok cross his fingers and fires the BB migration script
<jam> abentley: I forgot that iter_entries was not recursive
<jam> Pieter: there is Tree.walkdirs(path=XX)
<jam> Which takes a single path string
<Pieter> jam: yeah, doing that now
<jam> abentley: so I found the problem with get_reference_revision... specifically we are doing a commit in the outer WT to get the appropriate DirStateRevisionTree, but that is "recurse=True", so it does a commit in the subtree as well...
<beuno> Jc2k, are you running (or going to be) running trunk for LH?  So I can poke at the theme bits on the weekend.  Also, if there's anything else you need before Guadec, let me know and/or file a bug en LP for it  :)
<jam> abentley: for RevisionTree you explicitly pass "recursive=None", so I think I just need to do that for DirStateRevisionTree
<abentley> Oh, that sounds plausible.
<jam> I just wasn't sure if that would break anything else, but it doesn't seem to
<james_w> abentley: yes, code examination showed that it does. Is this an old bug?
<abentley> Yes.
<james_w> ok, thanks, I'll look for when it was fixed and update the bug
<Pieter> ah, got my shelve problem solved
<Pieter> http://ss.frim.nl/==808
<Pieter> whoo
<tolstoy> Folks: is there any info anywhere on BZR return codes?
<tolstoy> When I do a "bzr diff" on a remote repo, it works, but I get a return code of 1, which isn't so nice for scripts.
<tolstoy> bzr diff on a repo with no changes, and I get an rc of 0.
<eMxyzptlk[away]> Hey guys, I'm always getting No handlers could be found for logger "bzr", looking on google I found some bugs filled on LP which is related to ssh or whatever, but I'm always getting this even if am not inside a repo like running bzr in /tmp or /dev or ~ will give this msg
<eMxyzptlk[away]> any ideas ?
<Pieter> tolstoy: that's pretty standard.. isn't that just diff's return codes?
<tolstoy> Pieter: I have no idea. I'll check that out.
<Verterok> tolstoy: in the case of diff, try: bzr help diff
<Verterok> at the end of the help you can find the meaning of the exit codes
<tolstoy> Verterok: Damn! I looked at that help text many times, and never paid attention to the big fat Exit Values. Sheesh. Thanks!
<Pieter> tolstoy: I think 0 is no differences, 1 is differences, 2 is error
<Verterok> y'r welcome :)
<tolstoy> Pieter: Ah, now I get it. Odd, but cool. Now: to hack that in to an ant script.
<Pieter> hah, bzr.dev is only 20MB in git
<tolstoy> The only problem I'm having now is "tagging" a remote branch.
<tolstoy> Can't seem to even tag a local branch, then "commit" it. Says there's nothing to commit.
<fullermd> You don't commit tags.
<tolstoy> But they can be "pushed" to remote branches?
<tolstoy> Er, I'll back up.
<fullermd> Yes, they get sent on push.  They're just not commit'd; when you make a tag, it's saved.
<tolstoy> If I do a build (say), and I want to tag it, but have made no other changes, how do I push that tag remotely to our "source-of-truth".
<Verterok> tolstoy: making a branch maybe?
<tolstoy> Heh heh. Babysteps. If I can get people to use bzr in place of cvs, the next task is to rethink all this in the first place. ;)
<fullermd> Well, you tag revisions.  So you tag whatever revision you built.
<fullermd> (the latest, I presume)
<Verterok> abentley: around?
<abentley> Verterok: Hi.
<Verterok> Hi
<Verterok> I moved all BB tables into mysql except for mergerequest :)
<Verterok> I'm having problems with the patch_text column
<Verterok> I defined it as a Blob in MySql but for some reason SqlAlchemy is trying to decode the contents so I get UnicodeEncodeError with it :(
<Verterok> abentley: I was thinking in change the type of the column to text. could be any problem with this change that affects the bundles?
<beuno> as in, "can binaries be treated as text"
<abentley> The contents are not in any particular encoding.
<Verterok> thx beuno  :)
<abentley> I think I have some that are utf-16..
<Verterok> hmm...I see, that could be a problem with column encoding
<beuno> Verterok, I think you can dump any encoding into a blob column
<beuno> not sure how to handle the migration
<Verterok> beuno: indeed
<Verterok> beuno: that's the problem :), SqlAlchemy try to decode the blob contents
<Verterok> I'll fallback to plain-old sql :P
<Verterok> abentley: thanks
<eMxyzptlk[away]> No one get 'No handlers could be found for logger "bzr"' ??
<eMxyzptlk[away]> I get it on Gentoo and on Ubuntu :O
<tolstoy> fullermd: Yes, I tag on he branch I just pulled from a remote repo, but I need to make sure the tag is ALSO on the remote repo.
<tolstoy> There doesn't seem to be a way to push a tag over there.
<tolstoy> The branch I have at hand is only "pulled" to do the compile.
<tolstoy> Hm.
<tolstoy> Maybe ssh user@host (cd /path/to/repo ; bzr tag name)
<tolstoy> is the way to go.
<fullermd> push pushes tags (even though it doesn't say so)
<tolstoy> Yeah?
<tolstoy> I'll test....
<fullermd> (at least, I'm pretty sure it did last time I tested it, which was a while ago)
<tolstoy> BTW, anyone know of a nice diff2html (or is that patch2html)?
<tolstoy> Yes, bzr push does indeed push tags, even though it says, "No revisions to push."
<james_w> eMxyzptlk[away]: check the permission on your ~/.bzr.log
<eMxyzptlk[away]> james_w, Thank you that worked, apparently it was root:root
<eMxyzptlk[away]> james_w, thx again, u saved me from going blind when I use ZSH auto-completion lol
<lifeless> hi guys
<beuno> gooooooooooooood morning lifeless
<lifeless> looks like I'll be doing a talk in 7 days at slug about bzr-search
<beuno> jelmer, I need to test something, and I know you play around with symlinks a lot. Is there any branch in LP you know has symlinks?
<beuno> lifeless, neat. And that is only... what, 2 weeks after you started?
<lifeless> yah
<lifeless> mind you, its thanks to you there is substantial bling to demo
<lifeless> it would be cool to show an IDE as well :)
<beuno> well, it's recursive in that sense. You did most of the heavy lifting
<lifeless> :)
<beuno> ah, that seems like a hint towards Verterok
<beuno> which just happens to have the day off work today...  :p
 * beuno ducks
 * Verterok blinks
<Verterok> hi lifeless
<lifeless> Pieter: in case you aren't aware, our storage layer is pluggable, and we have plans to dramatically increase the compression of it
<lifeless> Pieter: other things have just been more important
<lifeless> hi Verterok :)
<Verterok> 7 days, to have a working (eclispe way) demo of bzr-eclipse+bzr-search?
<lifeless> Verterok: 6 - I'm a day ahead :)
<beuno> common, you can do it in 2!
<Verterok> oh, right... ok, in 6 then :D
<beuno> lifeless, any idea of git or hg have anything similar to this?
<lifeless> beuno: not yet :) - there are external source indexing tools (like bonsai) already; but AFAIK this is unique in integration and slickness (well except for google code search, but thats kinda different :P)
<Verterok> lifeless: I could try to get a working version of it for monday
<Verterok> (your monday)
<lifeless> Verterok: if you feel like it it would be awesome. I can do a 45 minute talk on just your screen shot the other day + loggerhead and bzr-search
<Verterok> lifeless: I was thinking in a version that actually do something with the results :)
<lifeless> Verterok: see that would be so cool
<Verterok> like mapping the files to eclipse "resources" and show them in a tree-like view or something
<lifeless> jelmer: have you played with beuno's demo of loggerhead?
 * beuno fires it up again
<beuno> and, of course, googlebot was just waiting for me to do that...
<lifeless> :P
<igc> hi guys
<beuno> morning igc
<igc> hi beuno!
<beuno> igc, I've seen the MySQL people talking about a video on a talk you gave. Any idea if that's available yet>
<beuno> ?
<igc> beuno: I don't know sorry. I know the talk was videoed but no-one has sent me a link to it if it's been made public
<beuno> igc, I'll keep an eye put for it then
<beuno> have you seen the latest bling with lifeless's bzr-search?
<igc> beuno: I've seen a version from a day or two ago.
<igc> It didn't have the nice new colour bling Joey was asking for feedback on though
<beuno> igc, look now: http://intranet.pentacorp.net:8080/bazaar/bzr.garbage/changes
<beuno> (try searching)
<beuno> ah, yes, new theme.  That's pretty advanced, I'm hoping to wrap that up next week
<igc> beuno: sweet. The last version I saw was showing tuples in the search box so this is now much nicer :-)
<beuno> yes, less geeky, but nicer  :)
<igc> *but* searching for lifeless doesn't match anything. That surprised me the other day (and still does)
<igc> maybe I should search for Collins instead
<beuno> well, he doesn't seem to use his nickname in commits
<igc> yes, Collins is far more satisfying (in terms of a result)
#bzr 2008-06-21
<lifeless> igc: lifeless is just my irc handle
<jam> beuno: I feel bad that everytime I follow your link it calls bzr garbage
<beuno> jam, hahah, so do I  :)
<jam> beuno: right now I'm getting a timeout trying to connect
<jam> is it down?
<beuno> I tend to name stuff that will need deleting _garbage
<beuno> I'm home
<beuno> lemme get you the IP
<beuno> http://200.127.6.219:8080/bazaar/bzr/changes
<beuno> (remove the "garbage" bit, may also throw off googlebot)
<jam> :)
<jam> beuno: when I type "robert" it selects robert for a second, then a huge list of entries, and then goes back to robert
<jam> any idea why it "flickers" ?
<jam> beuno: also, it doesn't seem to match "collins" as it doesn't seem to be indexing the committer name
<jam> oh, and switching windows and switching back causes it to flicker again
<beuno> hrm, it shouldn't
<beuno> FF3?
<jam> yep
<beuno> ah, yes. I know what's happening
<beuno> I don't stop calls to the server when you type faster than 200ms per ketstroke
<beuno> *keystroke
<jam> I also tried "Refactoring" as I see that in a commit message right away
<jam> and it doesn't find the rev
<beuno> so you get delayed calls thrown at you
<beuno> it's in my ToDo
<jam> actually, I haven't gotten a successful hit from any of the recent commit messages
<jam> Though it will put it in the helper list
<beuno> interesting, I may of broken something
<jam> 'logic' worked
<jam> 'crude' did not
<jam> maybe you just need to regenerate it?
 * beuno tries
<beuno> well, running "bzr search Refactoring" from terminal works
<jam> is it case sensitive?
<beuno> shouldn't be, no
<beuno> ok, so I'm doing something wrong in my logic, bzr-search does sent me those results
<lifeless> whats up?
<beuno> LH is failing at some point, and I don't quite understand why...
<lifeless> jam: the index is case sensitive for now - Foo vs foo in c++ is important
<jam> lifeless: sure, but it was still failing
<jam> I tried both forms
<jam> anyway, I'm done for the night
<lifeless> jam: yah, just letting you know the guts
<beuno> yes, I'm getting back a list with sets instead of a list with strings
<lifeless> beuno: from search ?
<beuno> it seems RevisionHit gives me a set, and FileTextHit a string, so I'm not showing RevisionHits
<lifeless> beuno: point me at your code
 * beuno waits for LH to load in LP
<beuno> lifeless, http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080620063154-mztu3hdo7t70l781?file_id=search.py-20080614235103-lpt63f7b2drplju8-1
<beuno> line 52
<beuno> I wonder how I managed to miss this up to now...
<beuno> ah
<beuno> needed a [0]
<beuno> thanks for pointing it out jam   :)
<beuno> pushing the fix now..
 * Peng stares at bzr-svn.
<lifeless> bzr-svn stares back
<Peng> :P
<Peng> It's complaining about my svn Python bindings.
<lifeless> beuno: well I was complaining about funky results ;P
<lifeless> man
<lifeless> linkedin is such a fanboyclubthing
<beuno> lifeless, heh, right. Well, jam found the search term I could debug  :P
 * beuno has avoided linkedin up to now
<beuno> anyway, search results seem coherent with the CLI
<jam> lifeless: you are the one who asked *me* to join... and now you say it is just fanboy. I feel... dirty
<lifeless> jam: :)
<lifeless> jam: You're not a acquaintance rather than trusted colleague/friend
<lifeless> jam: its folk I've met twice wanting to 'link up' than I was complaining about
<lifeless> beuno: cool
<jam> It is just that you are so amazing everyone wants to be your friend
<lifeless> And I thought I had ego problems
<lifeless> :)
<Peng> If I can import svn.delta, why can't bzr-svn?
<Peng> Oh.
<Peng> Word of advice: don't go scattering things called "svn" around your PYTHONPATH.
<lifeless> :P
<lifeless> absolute imports ftw
<Peng> That wouldn't help. bzr-svn tries to import svn.delta, but found my thing instead.
<lifeless> k
<Peng> Oh well. The only damage done is a little wasted CPU and disk I/O.
<Peng> Sorry for the interruption. :)
<lifeless> lol np
 * Verterok wonders why utf-8 isn't used by everyone... 
<lifeless> Verterok: oh, I wish
<Verterok> lifeless: I have bundleBugggy running on mysql, but I have some problems with blob encodings :P
<beuno> Verterok, really?  didn't have to change any queries for it?
<beuno> altright. I won't take that personal
<beuno> (and type properly either)
<Verterok> sorry...pushed the wrong button :P
<Verterok> beuno: I think the problem is in the migration code, not in BB itself or it queries
<beuno> ah, thought you already had it running
<beuno> abentley did mention that encodings where really wierd and mixed up
<Verterok> yes, if I don't import the mergerequests from sqlite, it work like a charm :P
<beuno> can't you convert it as you migrate?
<Verterok> indeed, they are
<Verterok> beuno: I don't know in what encoding is each blob...so I basically try:...catch: until it works :)
<beuno> ah, sounds fun
<Verterok> try: except
 * Verterok is writtin too much java code
 * beuno is glad he passed that on
 * Verterok too :)
<Verterok> beuno: something is wrong with the inserts in mysql, i get some warnings about data truncated... :(
<beuno> Verterok, that's odd. Truncated for blobs?
<Verterok> yep..
<Verterok> and came directly from MySQLdb module
<xif> hello
<xif> congrats for MySQL switching to Bazaar.
<Verterok> beuno: here is the traceback http://rafb.net/p/T5fBZX72.html
<lifeless> xif: hi, thanks
<xif> is there any way to implement a form of locking with bzr?
<beuno> Verterok, very odd. On the other hand, we may be able to get help from mysql now  :p
<xif> or generally, any way to make sure no more than one developer is working on a particular file?
<Verterok> beuno: that would be great, but first I want to be sure I'm not doing something wrong ;)
<beuno> Verterok, I don't see where it's been truncated there, just an encoding error
<Verterok> oh, I wasn't clear... I get the truncate warnings when I'm running the migration script
<Verterok> beuno: sqlite2mysql.py:95: Warning: Data truncated for column 'text' at row 1
<beuno> Verterok, it may be worth a try changing that column's name
<beuno> I suspect it may be a reserved name
<beuno> so it could confuse mysql
<lifeless> xif: no, because you can have two independent branches
<lifeless> xif: imagine that there is only one file in your tree; two branches being independent implies concurrent editing of that file
<Verterok> beuno: yes, but that is the 2dn warning, the firstone is: sqlite2mysql.py:95: Warning: Data truncated for column 'patch_text' at row 1
<beuno> Verterok, ah, that throws my theory off the table   :/
<beuno> Verterok, probably a mysql configuration
<beuno> max_something
<xif> lifeless: hm, too bad. we're trying to manage some binaries here. merging never works for that, of course. so we simply must find a way to prevent - or at least alert - when someone tries to edit a file that somebody else is working on.
<beuno> (not helpful, I know, finishing the bzr-upload [ANN])
<Verterok> beuno: ok, i'll check
<Verterok> beuno: thanks
<xif> I'm not sure this can't be done (at least in a "cover 90% of the need" way) by a bazaar plugin....
<lifeless> xif: if you had a single branch, a plugin could conceptually write a file describing advisory locks
<lifeless> xif: I suggest bringing it up on the list; may strike someone's interest.
<xif> lifeless: yeah, that's what I was thinking too. a master branch for the binaries.
<xif> thanks!
<beuno> xif, maybe by having a similar file to .bzrignore
<beuno> version that
<beuno> make sure everyone pulls
<beuno> and write a plugin on top of that
<beuno> looks in that file, does magic
<xif> beuno: yeah, sort of what I was thinking...
<beuno> that way you could have a lock with regexes!
<beuno> "no one else touch my jpgs"
<beuno> or something more professional
<beuno> pre_commit hook that checks if that has been changed...
<beuno> seems fairly possible, if someone puts some work into it
 * xif nods
 * beuno is off to the movies
<xif> enjoy!
<lifeless> have fun beuno
<jshaffer> is there a way to copy a file and have bzr recognize it as a copy? is there a copy command?
<rockstar> bzr cp
<jshaffer> Bazaar (bzr) 1.5
<jshaffer> bzr: ERROR: unknown command "cp"
<rockstar> Nevermind, thought I used that today but I didn't...
<lifeless> jshaffer: not yet; its been discussed
<jshaffer> ok. thanks
<teratorn> anyone know how to make bzr-svn work on remote SVN repositories that require authentication? I get an error: bzr: ERROR: Invalid http response for https://svn2.hosted-projects.com/Phoenix/PCP/branches/fxcm-3/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<bob2> you should be able to provide a username in the url and then get prompted for a password
<teratorn> ah, I found the problem: https://answers.launchpad.net/bzr-svn/+question/24177
<lifeless> anyone looked at clearsilver ?
<felipec> in bzr each branch has only one head, right?
<lifeless> yes, we define branch as being a head
<lifeless> you can have many heads in a repository, and many branches in a repository, repositories give you storage sharing across branches
<felipec> lifeless: I see, but a branch is a head?
<lifeless> well, its an entry to the graph, it doesn't acctually have to be a head
<felipec> lifeless: ah, perhaps we have different definitions of "head"
<felipec> lifeless: by head I mean a node with no childs
<lifeless> yes, thats what head means
<lifeless> so, we have two separate objects involved
<lifeless> we have Branch, which has a 'tip', that points into the revision graph
<lifeless> the revision graph is stored in a Repository. An instance of Repository is one part of the distributed database
<lifeless> there is no requirement that the tip of a branch be a head in the distributed database (because that would be logically inconsistent with people being able to branch and commit without affecting the source branch)
<lifeless> but
<lifeless> we only include revisions reachable from the tip when we do log and other operations
<lifeless> so being a head in a graph sense really doesn't matter - it only matters for systems like git and hg that conflate branch storage with history storage
<lifeless> (For instance, I have a repository with 13000 heads; I can make a branch from it to a new project in 0.2 seconds or so)
<felipec> lifeless: ah, true, being a head doesn't matter
<felipec> lifeless: in that example you would only have one head in the new branch, right?
<lifeless> if I branched into an empty repository yes; the tip of the branch and what it references gets copied, which would leave the tip as the head (when you consider only the data in that repository)
<felipec> lifeless: but why you say git and hg conflate branch storage with history storage?
<lifeless> well, its possibly more true for hg than git
<lifeless> in hg when you have 2 heads in its history storage, it shows up as have two branches
<lifeless> in git you have a list of 'heads' and 'refs'
<lifeless> AFAICT they won't scale to very large numbers of branches
<lifeless> (though it is very cheap to enumerate the branches because its in a single file)
<lifeless> felipec: anyhow, why were you asking whether we have more than one head per branch?
<felipec> lifeless: in git a branch is just a pointer to a commit (a ref)
<felipec> lifeless: I'm writing a document explaining why mtn sucks, and although I'm a git fan I want to show how things are dong in other decent DSCMs
<felipec> s/dong/done/
<lifeless> felipec: monotones management of divergence is a little awkard
<felipec> lifeless: I think having multiple heads in a branch is chaos
<lifeless> so for bzr heads in teh repository is entirely unrelated to whats in a branch
<lifeless> a branch has a tip, which is a ref to a commit; same as git
<lifeless> branches also have tags, which themselves are ref's to commits
<felipec> lifeless: tags are part of the branch or the repo?
<lifeless> felipec: each branch has its own tags; the point into the repo
<lifeless> s/the /they /
<felipec> so, two branches can have a 1.0 tag, for example
<lifeless> right
<lifeless> a concrete use case would be a single repository storing project A and project B which is a fork of A
<lifeless> they may both have done 1.0 releases that are different code bases.
<felipec> yeah, I get it
<felipec> lifeless: by the way, do you know about any reference to the internal design of bzr?
<lifeless> but storage is shared between their history, and any merges as well
<lifeless> felipec: doc/developer/, the wiki has a Classes/ sub area
<lifeless> and there is all the docs in the code itself - docstrings
<felipec> lifeless: I couldn't find much on doc/developer
<lifeless> http://doc.bazaar-vcs.org/bzr.dev/developers/index.html
<felipec> lifeless: http://doc.bazaar-vcs.org/bzr.dev/developers/repository.html
<felipec> lifeless: http://doc.bazaar-vcs.org/bzr.dev/developers/container-format.html
<felipec> that's the most similar I can find to branch representation, but not really useful
<AfC> felipec: obviously this is more work, but if you were to read the archive of this list over the last 18 months or so you'd find a fair amount of anecdotal information you could use towards your research.
<lifeless> pydoc bzrlib.branch/Branch
<lifeless> erm, bzrlib.branch.Branch, thats the Branch object
<AfC> s/this/the Bazaar project's/
<lifeless> felipec: that talks about the serialization of the packs in the repository
<lifeless> felipec: I guess it depends on what you mean by design
<lifeless> felipec: we are _very_ modular
<lifeless> felipec: as we learn better ways of doing things we implement them
<lifeless> felipec: so to us design really talks about responsibilities and layers, not about disk formats per se
<lifeless> felipec: (in part because svn can be considered an implementation detail of bzr due to how deep bzr-svn hooks in)
<felipec> lifeless: I thought so, so there's no way I can for example create a test application independent of bzrlib to find all the branches in a repo?
<felipec> without looking at the code of bzrlib
<lifeless> uh,
<lifeless> 'bzr branches'
<lifeless> but no, no more so than you can for git or hg
<lifeless> (I've looked at doing it independent of git's tools, and had to go to the code to get details)
<lifeless> it doesn't seem particularly useful to me to try to pin disk details down so that other folk can implement when the code is free; anyone that wants to know can read the /actual/ spec (not a poor proxy); also they can just use the code directly in the first place.
<lifeless> things like bzrlib.dirstate do offer EBNF descriptions of the file format
<lifeless> but this isn't intended for external reimplementation (though I know that DVCS for emacs actually used that to write a parser for the dirstate)
<felipec> lifeless: I've tried to understand the repository format by looking at bzrlib but I couldn't, I guess I will have to try harder
<AfC> I suppose different repository implementations have different formats.
<AfC> {shrug}
<lifeless> felipec: pydoc bzrlib.repofmt.pack_repo
<lifeless> felipec: that should get you somewhere
<lifeless> felipec: with our current default repository format (the best performing one to date :))
<AfC> felipec: to all appearances the Bazaar hackers have worked very hard to give  bzrlib a decent public face capable of manipulating arbitrary Bazaar branches, working trees, repositories etc. If you do speak Python then you'll probably do well to use bzrlib directly to ask the questions you have of a given branch.
<lifeless> I'm off, bbiab
<cdleary> does anybody know if pushing to a remote location triggers a post_pull hook at the remote location?
<lifeless> cdleary: if you are using a recent enough bzr, and bzr+ssh, it should I think; it will certainly trigger your local bzr's post_push hook locally with the remote location as the target parameter
<cdleary> lifeless: yeah, I was trying to avoid a push-and-update style hook, because I feel like the whole "ssh in after and clean up" thing is a little too hackish when there's a bzr instance running on the other end of the transport
<lifeless> I hear it works quite well
<lifeless> or you can look at bzr-upload I think it is; if you are deploying via bzr
<cdleary> ah that's a cool plugin, but I was thinking more about modifying bzr-email to send email after pushing to a "central" branch
<lifeless> well, my understanding is that that is available
<lifeless> but you need to be using bzr+ssh so that there is a bzr process on the other end
<cdleary> oh, it's already available? do you know if there's a recommended way to go about doing it, or do I switch bzr-email from a post_commit to post_pull hook like I thought?
<Jc2k> beuno: ping
<lifeless> cdleary: you'll need to read the list archives and recent release notes I think
<lifeless> cdleary: it would be a post-push, not post-pull
<lifeless> cdleary: you are pushing after all
<lifeless> Jc2k: his midnight I think
<lifeless> Jc2k: argentinian
<cdleary> lifeless: thanks for the tips :) didn't know that post-push got triggered at both ends, and I'll go check out the lists
<lifeless> cdleary: I'm hazy on details, I know andrew bennets was working on this, and email was one of the primary use cases
<lifeless> sorry I can't be more useful :P
<Jc2k> lifeless: yeah i thought he'd be asleep
<cdleary> well if I get a solution working that's not a total hack I'll be sure to propose a merge on launchpad ;)
<cdleary> but if it's already done then I'm golden
<cdleary> lifeless: (oh, and thanks for bzr-email :)
<lifeless> cdleary: my pleasure
<matid> Hi there!
<matid> Just wondering, what is the preferred way to set up Bazaar on the server to share a single push repo in a team of 5+ developers?
<matid> I mean I could do with bzr+ssh, but how about permissions for different projects, etc.?
<db-keen> http://pastey.net/89808
<db-keen> The part that isn't working is straight out of the guide
<Peng> I'm not sure, but I think install_named_hook may be pretty new. Maybe your bzr is too old.
<Peng> Also, ew, complicated os.system().
<Peng> Also, isn't it executing Ruby code that only executes something else and does a trivial check on the output? Python can handle that...
<db-keen> yeah, I'm sure with a little effort I could easily convert it to python, but I don't really know python
<AfC> matid: what do you mean by "single push"?
<matid> I should say a common push repository.
<matid> So that all devs can push to it.
<AfC> matid: Well if you've only got ~5 people I'm not terribly sure what you need permission barriers for, but regardless, standard unix permissions apply. If they own the repository (ie, the .bzr/repository) directory at . or .. then they can push to it.
<AfC> etc
<AfC> If you want them to be able to push to each others', then I'd suggest they all be in a "bzr" group or something and make the directories appropriately sticky and/or umasked.
<matid> OK, I think I found what I was looking for...
<matid> I had the directory chmoded 02770 but it wasn't enough to make the permissions work as I wanted them to work.
<matid> I had to add a shell script to change umask before running bzr.
<jelmer> teratorn, see the bzr-svn FAQ
<matid> jelmer: Hi. You're the maintainer of bzr-svn, right?
<jelmer> matid, yep
<matid> jelmer: A quick question: which version of bzr is best suited for bzr-svn as of now?
<jelmer> matid: Depends on the version of bzr-svn you're using
<antoranz> Hi guys! when is bzr 1.6 coming out?
<jelmer> matid: There's a list on the wiki
<matid> jelmer: I currently use bzr 1.3.1 with bzr-svn 0.4.9
<matid> jelmer: I wanted to upgrade bzr and I was wondering if it's going to break bzr-svn or not.
<jelmer> matid: Yes, you'd have to upgrade bzr-svn as well
<antoranz> jelmer: how about my question? :-D
<matid> jelmer: Does bzr-svn work with 1.6 or it's 1.5 only?
<jelmer> antoranz, Sorry, I don't know what the release plans for 1.6 are
<antoranz> k
<jelmer> matid: 1.6 isn't out yet
<antoranz> I saw 1.6 beta 2 was released almost 2 weeks ago. how did it go?
<matid> jelmer: I should go with 1.5 and newest bzr-svn then, right/
<matid> ?
<antoranz> matid: I guess so.
<jelmer> matid: Yes, 0.4.10
<antoranz> what repository for gutsy and hardy) do I have to enable to get the beta?
<antoranz> or it has to be done by hand?
<jelmer> I think you can only get it from the source tarball
<matid> jelmer: What version of svn should I get to have bzr-svn working?
<matid> jelmer: I upgraded bzr and bzr-svn and now I get this error: http://pastie.org/219489
<matid> jelmer: That's after I try bzr pull on an svn branch I used to use with bzr 1.3.1 and bzr-svn 0.4.9
<jelmer> matid: That's an issue with 0.4.10 and Subversion 1.5
<jelmer> I think there's an open bug about it
<matid> jelmer: What should I do then?
<jelmer> matid: Use Subversion 1.4, comment out that particular assert in Subversion 1.5 or stay with bzr-svn 0.4.9 for now
<antoranz> OK... I added the repositories for betas and release candidates
<matid> Commenting this assert out and recompiling subversion should do the trick, right?
<jelmer> matid, yep
<antoranz> but now bzr is kept from updating
<matid> jelmer: Thanks! That fixed the issue.
<jelmer> antoranz, how do you mean?
<jelmer> beuno, ping
<antoranz> http://www.pastebin.ca/1052494
<jelmer> you probably have some plugin installed that can't be upgraded
<jelmer> but relies on the version of bzr you have currently installed
<antoranz> let me see
<antoranz> the problem is the version of python-central
<antoranz> bzr: Depends: python-central (>= 0.6.5) but 0.5.15ubuntu2 is to be installed
<antoranz> any ideas?
<Jc2k> lo all
<Jc2k> i have a launchpad question, just grabbing a link..
<Jc2k> so...
<Jc2k> jelmer created https://code.edge.launchpad.net/~gnome-bzr-mirror
<Jc2k> which is awesome
<Jc2k> does launchpad use shared repositories?
<Jc2k> i.e. by the simple fact that bzr-mirror.gnome.org is getting mirrored by launchpad, do personal branches become really cheap?
 * Jc2k goes to test
<fullermd> No.
<Jc2k> ah
 * fullermd dashes hopes in only 2 letters!
<Jc2k> that would have been wicked levels of cool
<clemente> Hi, I'm still unable to run bzr from the bzr branch, since when I do ./bzr, it still uses the bzrlib from /usr/lib, that means the old one which was installed on the system
<clemente> I have this problem each time I want to run a Python program without installing it...
<Verterok> clemente: you need to modify your PYTHONPATH envvar
<clemente> Verterok: however that doesn't work. I tried:  PYTHONPATH=/w/bzr.dev/  /w/bzr.dev/bzr fast-import  ......
<clemente> And I still get in âpluginsâ:  bzrtools             /usr/lib/python2.5/site-packages/bzrlib/plugins/bzrtools
<Verterok> clemente: couldd you paste the output of YTHONPATH=/w/bzr.dev/  /w/bzr.dev/bzr version
<clemente> Bazaar (bzr) 1.6b3
<clemente> The problem is not with the bzr executable but with bzrlib
<Verterok> clemente: it's clearly a pythonpath issue, for some reason python is looking first in /usr/lib
<Verterok> clemente: something is overriding your pythonpath :(
<clemente> Ok, thanks, I will search the cause
<Verterok> clemente: sorry I can give you more help with this issue
<tro> is there any way to convert a rich-root-pack repo into a pack-0.98
<tro> ?
<Jc2k> create a brand new repo as pack-0.98 and pull from the old one to the new one?
<jelmer> tro: No, that's not possible
<jelmer> (I think you mean pack-0.92, btw)
<tro> right. 0.92
<tro> looks like this branch i'm working with was imported using bzr-svn
<tro> i guess it uses rich-root-pack by default?
<jelmer> tro: Yep
<jelmer> tro: rich-root-pack will hopefully become the defualt format in bzr 1.6
<tro> hmm ... so how will people upgrade from pack-0.92?
<jelmer> "bzr upgrade --rich-root-pack" will upgrade a branch
<tro> does the same go for shared repos? i'm setting one up right now
<jelmer> tro: yep
<jelmer> tro: You can also create a rrp one using "bzr init-repo --rich-root-pack" (saves you an upgrade)
<tro> jelmer: so if i run that command on a shared-repo, will all the branches it hosts be converted as well?
<jelmer> tro: yes
<tro> neat
<tro> thanks
<eMxyzptlk> Hey guys, is there an alternative to "darcs amend-record" ??
<eMxyzptlk> If you don't know what it means well it will record new changes under the old revision..
<eMxyzptlk> Add to it not replace it
<lifeless> eMxyzptlk: no there is not, because in a distributed database a revision id needs to have a single unique value
<eMxyzptlk> lifeless, ah ok
<lifeless> eMxyzptlk: however, you can for the mst recent commit do 'bzr uncommit; bzr commit' to pop off the last commit and then make a new one
<eMxyzptlk> lifeless, thanks anyway :)
<eMxyzptlk> lifeless, yea that's what I am actually doing right now
<eMxyzptlk> lifeless, but it would be nice to create something that does this ( maybe a plugin ), it saves me time copying/pasting the log of the commit
 * Verterok dances
<Verterok> BB now runs on mysql :D
<lifeless> Verterok: cool
<lifeless> beuno: hi
<Verterok> hi, lifeless
<Verterok> I finally won the encodings battle :P
<beuno> hey lifeless
<beuno> Verterok, oh, yay!  does that mean BB working with MySQL?
<Verterok> beuno: yep :D
<beuno> oh, very cool
<beuno> is it reproducable?  the migration I mean
<Verterok> http://steppenwolf.selfip.net:8089
<Verterok> beuno: it should, I'm writting the README ATM
<beuno> Verterok, push to LP, mail the list!  ;)
<Verterok> beuno: there is only one unresolved issue, that odd warning about "data truncated" in a blob :P
<Verterok> I'll push to LP as soon I finish the docs..
<beuno> Verterok, ah. Have you mean able to track down if it actually removes data or not?
<Verterok> not yet, I focued on fighting against encoding errors :)
<Verterok> beuno: next iteration is to track down the warning
<beuno> Verterok, congrats!
<Verterok> thx beuno
<fullermd> Well, blob/text only store 65k...   bundles can get bigger than that fairly commonly.
<Jc2k> lo beuno
<fullermd> You can get 16 meg in a mediumblob, which is probably enough.  But might as well just go to the 4 gig in longblob.
<lifeless> jelmer: around?
<jelmer> lifeless, jup
<Verterok> fullermd: thanks for the tip
<lifeless> beuno: have you show jelmer loggerhead-super-search?
 * Verterok cheking what kind of blob is using
<beuno> lifeless, I don't think so...
<beuno> jelmer, http://200.127.6.219:8080/bazaar/bzr/changes
<lifeless> beuno: got time to run up your demo ?
<beuno> lifeless, I left it up. Googlebot keeps trying revids  :p
<beuno> hey Jc2k
 * Verterok waves fullermd (0 warnings)
<Jc2k> :)
<Verterok> fullermd: thanks!! it worked like a charm
<lifeless> jelmer: go to that url, and type into the search box
 * fullermd has his uses   8-}
<beuno> Jc2k, did you get my ping yesterday?
<Jc2k> beuno: yes. im using the wsgi-ify branch, and our priorities are clean urls and any of bkors bug reports that are possible. and i want it to look GNOMEy. :p
<Jc2k> i cant think much more than that right now
 * Jc2k is ready to pass out
<jelmer> wow, works nicely :-)
<lifeless> Jc2k: I believe wsgify is in trunk now
<beuno> Jc2k, clean urls and wsgi and other fixes have been merged intro trunk
<lifeless> jelmer: thats 'how complete' bzr-search is :)
<Jc2k> ace
<beuno> Jc2k, if you pull from there, you should have all of it.
<beuno> I'll start playing to get it looking gnomish
<jelmer> lifeless: Does it work without loggerhead as well?
<lifeless> jelmer: grab the plugin and give it a whirl :)
<lifeless> jelmer: clearly, you have not done so :)
<lifeless> jelmer: it can index about 6MB/minute at the moment
<lifeless> (it did a 509MB code base - launchpad - in 80 minutes)
<Jc2k> beuno: cleaner urls, i should have said even cleaner urls ;)
<Jc2k> beuno: http://bzr-mirror.gnome.org:9876/conduit/trunk/annotate/1445?file_id=276%401811c9d2-c306-0410-a128-ae57aa55c946%3Atrunk%3AChangeLog
<beuno> Jc2k, ah, file paths instead of fileids. Gotcha. That can get tricky, but I'll see what I can do  :)
<Jc2k> it would be nice to be able to have discovarable links like /conduit/trunk/ChangeLog :)
<lifeless> Jc2k: I think you mean predictable
<lifeless> Jc2k: or guessable
<lifeless> Jc2k: (I agree, having such links is important)
<beuno> yes it would. Just have to figure out a good way for weird characters not to come back and bite us. Maybe I can add it as an experimental feature off by default
<lifeless> beuno: weird characters?
<beuno> lifeless, in filenames
<beuno> passing them through URLs
<beuno> apart from that, it should be easy
<lifeless> beuno: so, output urls as utf8
<lifeless> beuno: decode as utf8, failure to decode is a 404
<beuno> lifeless, yes. I'm just not sure if that would be good enough to go on by default. I'll get it done, and see what mwhudson thinks, he's looked into that before
<beuno> it may have been a cherrypy limitation, which we already got rid of
<lifeless> its a std66 recommendation FWIW
<lifeless> internally paths are unicode to bzrlib
<lifeless> so url = urlescape(path.encode('utf8'))
<lifeless> and the reverse is urlunescape.decode('utf8')
<lifeless> if framework foo is doing some or all of that for you, thats fine
<beuno> sounds simple enough. Jc2k may get everything he wants then  :)
<lifeless> the only failure mode is clients who guess at a url and are using a different encoding (e.g. utf16, or non-latin* or cpWHACKO)
<lifeless> if they guess though, thats where I suggest 404;
<lifeless> _most_ unix clients will be using utf8
<lifeless> and I think many browsers transcode to utf8 when you type in a url, because its such a common case
<lifeless> (though if they do that they do make it hard to actually go to a url hosted by e.g. a russian windows user)
<Jc2k> \o/
<lifeless> (which btw is one thing that really bites about standard 66) - 'undefined' is firmly entrenched as far as 'what charset was this url encoded as'
<beuno> I suppose that if it gets complicated, we can allow generating fileids instead. It's just a matter of what we leave on by default, as both can work always, we just present on or the other to the user in links
<lifeless> well, users can always browse to a url
<lifeless> start at the root and client down, even the biggest code base should be only a few clicks to get to a path; then they can copy the bit of the url they want
<lifeless> copy and paste is good at preserving stuff :)
<beuno> True. I'll poke mwhudson on monday in case he already has a good reason why it isn't as straightforward
#bzr 2008-06-22
<beuno> lifeless, you know what would be cool?  Making bzr-stats have similar indexes to bzr-search. So to make it easy to get stats, and be able to get something line "how many lines X commiter has added"
<beuno> (in a cheap way, not processing everything each time)
<lifeless> beuno: yah
<edcrypt_> hi people - are there any script to fetch svn:externals with bzr-svn?
<edcrypt_> pinax.hotcluboffrance.com uses a lot of external apps, I think I'll write a quick script to fetch each one with bzr...
<Verterok> beuno: pushed, mail sent
<Verterok> I'm off, at least for a few hours (birthday party), seeya later
<beuno> Verterok, cool, have fun
<Verterok> beuno: thanks
<engie> Hi. I've pushed, with sftp, a branch to a web server and I can browse to it at http://www.studentrobotics.org/~stephen/jsdndide/local/ - what do I use to branch from this over http from another machine? I've tried every variant on branch with that URL I can think of!
<jam> engie: You seem to have a shared repository in use on that machine, which is not exposed via http
<jam> I'm guessing you have one in your home dir
<jam> and Apache is only serving things under public_html
<jam> So you need to "bzr init-repo public_html/" or possibly "public_html/jsdndide" before you do another "bzr push"
<engie> OK. Is this because the local branch is under an init-repo directory on my local machine?
<jam> engie: no, there is a repo on the remote machine
<jam> otherwise we would have created one with the branch
<jam> sorry, with the "push"
<jam> engie: It is a good thing to have a shared repo on the other machine, it just needs to be somewhere that people can access it through http
<engie> Ohh, looks like I accidentally pushed a .bzr up there when I was trying things out yesterday
<engie> That machine doesn't have bzr on it
<jam> engie: you don't need one, you can do "bzr init-repo sftp://host/~/public_html"
<engie> Is there any benefit to doing that? Does it share history between multiple branches?
<engie> Ahh brilliant, that's working, thanks
<lifeless> jelmer: so what do you think
<lifeless> RAOF: go to http://200.127.6.219:8080/bazaar/bzr/changes
<lifeless> RAOF: and type in the search box
<RAOF> lifeless: Is there really only one change there matching 'lambda'?
<lifeless> looks like
<RAOF> So, the find-as-you-type thing is good.  And it's nice and fast.
<RAOF> The formatting seems a little off?
<lifeless> yes
<lifeless> being worked on
<RAOF> Hm, it also doesn't much like "refactor" as a search term.
<lifeless> hey, spare time, hacked up, new search engine etc
<RAOF> It flips between anything matching 're' and 'refactor' :)
<lifeless> beuno: http://200.127.6.219:8080/bazaar/bzr/revision/33?q=lambda doesn't search-complete?
<lifeless> RAOF: uhm, not sure what you mean about flipping
<RAOF> lifeless: Oh, I thought you were after comments/queries/criticisms.  If you'd like unadulterated praise, I can provide that, too :)
<lifeless> RAOF: I'm not after either actually :)
<lifeless> RAOF: you can throw peanuts at SLUG on friday if you like
<lifeless> RAOF: this is just a follow up to the xesam comment in u-m
<RAOF> Right.
<RAOF> Aaah, I think I see the problem:  Typing r..e..f..a..c..t..o..r gives "refactoring" as the sole hit.
<lifeless> which comment I can't even remember now
<lifeless> just that it made me think I should show you this
<RAOF> Right.  Contrary to Amaranth, I think search can be useful.  And I can immediately see how this could be nice and useful :)
<lifeless> yah, this is a tiny code base its searching - the bzr-search plugin itself
<lifeless> searching bzr's code base will give more suggstions:
<lifeless> :!bzr search -s refactor
<lifeless> Suggestions: [('refactor',), ('refactored',), ('refactoring',), ('refactorings',), ('refactors',)]
<RAOF> But typing 'refactor' really quickly will briefly bring up 'refactoring', and then bring up all matches for 'r'
<lifeless> RAOF: oh interesting. Thats because its a lot cheaper to search a smaller dataset I suspect
<lifeless> RAOF: so its getting out of order results
<lifeless> beuno: you should include in the response to a lookup, the string that was asked for
<lifeless> beuno: then the client can ignore responses that are not the same as the current search is showing (or perhaps just ones that were done off a shorter prefix)
<lifeless> s/smaller dataset/smaller number of terms/
<lifeless> RAOF: there is a full command line client to bzr-search, if you prefer that
<lifeless> garh, fugliest site ever: http://python2.near-by.info/index.php?option=com_content&view=article&id=144&Itemid=111
<lifeless> I was trying to find pure python b+/b-tree implementations
<lifeless> but that one sure seems locked away
<beuno> lifeless, the javascript isn't included in the revision page. It's a bug  :)
<lifeless> beuno: :P
<beuno> and, it does wierd things because it looks for every character, no matter how fast you type
<beuno> another know bug
<beuno> I have to make the javascript stop propagating if you type before it sends out the request
<beuno> right now it queues them, which was simpler at the time
<lifeless> beuno: not at all
<lifeless> beuno: my suggestion will make it appear better
<lifeless> say it asked for - in order - 'r', 're', 'ref', 'refa'
<lifeless> but the answers come back in the order 'ref', 'refa', 're', 'r'
<lifeless> thats why it looks wierd
<lifeless> but more specific searches complete faster, so this is actually expected
<beuno> yeah, probably because
<lifeless> now, imagine that in each answer you include the search at the top of it
<beuno> 'r' took longer to process
<lifeless> so the answer for r will have 'I am a search for 'r'
<lifeless> and so on
<lifeless> then the client can do this:
<lifeless> if the current contents of the widget does not start with the response, ignore it
<lifeless> if the contents do start with the response, and no drop down is shown, store the thing the response is for in a variable and show the drop down
<beuno> yes, that's one way to do it. But that would hammer the servers pretty bad on a large scale
<lifeless> if a drop down is already shown, and the response is for a shorter query than the drop down is, discard the response
<lifeless> beuno: this is not a replacement for asking less often; its needed anyway (because under high load this can happen anyway)
<beuno> lifeless, right, that makes sense
<lifeless> (oh, and if the user deletes terms, obviously reset this variable or something
<beuno> so it should be a combination of both
<lifeless> yes
<beuno> ok, so *more* javascript to write  :)
<lifeless> :)
<beuno> but it's great that we're debugging this so much, it may get in shape to go into trunk sooner
<beuno> I'd like to add a few optional plugins to LH
<beuno> this being one of the strongest recommended ones
<beuno> also, I have plans to get the integrated into bzr-gtk, if no one does it first
<beuno> it's even better as a desktop application  ;)
<lifeless> perhaps jelmer will now hes seen it work :)
<lifeless> beuno: perhaps these glitches (like revision page missing the javascript should be bugs ?
<beuno> lifeless, I'd have to create a project for that. Do you think it's worth having a seperate project for it?
<lifeless> nah just on loggerhead
<beuno> oh, sure, that sounds like a good idea
<beuno> I'll file the revisions one (and annotate, and the rest) if you file the search order  :)
<lifeless> k
<lifeless> done
<beuno> me too
<jml>   File "/home/jml/.bazaar/plugins/svn/core.py", line 25, in <module>
<jml>     from bzrlib.plugins.svn.client import get_config
<jml> ImportError: No module named client
<jml> I got that when I tried to branch a svn branch with bzr
<lifeless> is there a client.py file ?
<jml> there's a client.c file. Apparently I need to build bzr-svn.
<lifeless> jelmer: ^
 * jml installs a bunch of stuff
<jml> ok. that version of bzr-svn is not going to help me much.
<lifeless> now
<lifeless> Peng: around?
<lifeless> jml: ping
<jml> lifeless: pong
<lifeless> loggerhead is down
<lifeless> do you know if we moved it off vostok yet ?
<jml> lifeless: no I don't.
<lifeless> dang
<lifeless> do you know the new machine name it would have moved too ?
<beuno> lifeless, AFAIK, the new version of LH will be deployed on wendsday, so maybe that's when they're moving it?
<lifeless> beuno: these things are unrelated
<lifeless> beuno: deployments are routine; moving to a new machine is reconfiguration, testing etc
<lifeless> mwhudson was talking about doing it driday
<jml> lifeless: no, I don't.
<lifeless> anyhow, It's 5am in London, I'll wait till 7am and ring james
<lifeless> jml: have you played with kjbuckets ever?
<lifeless> http://gadfly.sourceforge.net/kjbuckets.html
<jml> lifeless: years ago
<lifeless> thats more than I; impressions?
<lifeless> http://bazaar-vcs.org/RobertCollins#head-b2dc9ae46f1860c46f79682db455c3512152d148
<jml> lifeless: memories more like it. in the end I did my own graph classes.
<jml> lifeless: I recall the API as being a little cumbersome.
<lifeless> k, thats sufficient to tip me away
<lifeless> needing to compile would be a burden anyhow
<lifeless> scary: http://www.pythonweb.org/engine/
<Peng> lifeless: pong
<lifeless> Peng: do you have that magic to get the new LH running at a subfolder?
<Peng> lifeless: Subfolder?
<lifeless> yeah, so it can fit in an existing site
<lifeless> mwhudson showed you how last week
<Peng> lifeless: Oh.
<Peng> lifeless: Here's my serve-branches.py: http://paste.pocoo.org/show/75647/
<lifeless> Peng: thanks!
<Peng> lifeless: (Then I just used lighty's mod_proxy/mod_proxy_core.)
<lifeless> Peng: yeah, I have squid for that :P
<Peng> :)
<lifeless> loggerhead is back
<beuno> lifeless, are you deploying the new LH in squid-cache.org?
<lifeless> beuno: not just yet, I'm going to deploy a demo copy at my house
<beuno> lifeless, re: bug #242046
<ubottu> Launchpad bug 242046 in bzr "ppa feisty bzr and bzrtools not installable" [Undecided,New] https://launchpad.net/bugs/242046
<beuno> is bzr uninstalable too?
<beuno> I used PPAs copy feature, and have had to re-upload without it akready for gutsy
<lifeless> beuno: bzr and bzrtools - both
 * beuno grumbles
<beuno> I'll re-upload now
<beuno> so the copy tool is not really useful...
<beuno> (or I'm using it wrong, which is more probable)
<beuno> hrm, that's odd. I *did* re-upload bzr for feisty
<beuno> not bzrtools though
<lifeless> well
<lifeless> the problem is the dependency on python-central
<beuno> buildlog seems to think the right version was used: http://launchpadlibrarian.net/14569048/buildlog_ubuntu-feisty-i386.bzr_1.5.0-1~bazaar1~feisty1_FULLYBUILT.txt.gz
<lifeless> ok
<lifeless> may just be bzrtools;)
<lifeless> let me uninstall that and upgrade bzr
<beuno> I'm fixing bzrtools now
<lifeless> ok bzr is fine
<beuno> cool, I'll upload bzrtools in a minute
<beuno> sorry about that
<lifeless> np
 * beuno uploads and waits for the build deamons to wake up
<Peng> Bug 241938?!
<ubottu> Launchpad bug 241938 in bzr "MemoryError on "bzr ci" for 1396 Megabytes file" [Undecided,New] https://launchpad.net/bugs/241938
<lifeless> Peng: yah, we should be able to handle such files
<lifeless> theres nothing in the disk format preventing handling them
<Peng> How much work would it take not to read entire files into RAM?
<lifeless> Peng: for simple storage and tree building, not a huge amount, though doing it without affecting performance for normal files is important
<lifeless> Peng: for delta storage, diffs, merge its much tricker
<lifeless> delta storage depends on diffs
<lifeless> merge could just write .BASE, .OTHER, .THIS and give up
<lifeless> but three-way merge etc is nice to offer, and that depends on diff
<lifeless> in a high entropy file the line count is about 1/256 the file length, a 1.4G file is 5.6million lines long
<lifeless> if we hash the file to (say) sha1, its still 100MB per instance of the file (20*5.6million)
<lifeless> which is pretty high
<lifeless> and easily exploited to cause DOS by having many more \n's.
<beuno> lifeless, re-uploaded bzrtools, should be fixed, but can you double check?
<lifeless> beuno: its good now
<beuno> :)
<jelmer> lifeless: hmm, I'll give that a try some time
<jelmer> lifeless: the loggerhead frontend certainly is very fast!
<jelmer> jml: you need to run make these days (or ./setup.py build_ext --inplace)
<lifeless> jelmer: revno 42 should work nicely for you
<Peng> jelmer: Is bzr-svn supposed to have any old-style classes?
<jelmer> Peng: nope
<Peng> It has 11. :P
<jelmer> is there anything in particular bad about old style classes?
<jelmer> or is it just a stylistic thing?
<Peng> For me, it's stylistic.
<lifeless> jelmer: is there a small svn repo around you run live tests against ?
<lifeless> jelmer: in particular one that bzr-svn supports :P
<jelmer> I generally use svn://svn.samba.org/smb-build/trunk
<jelmer> lifeless: if you've got any repositories in particular that don't work, please file a bug..
<lifeless> jelmer: do you support repository.weave_store.get_weave ?
<jelmer> lifeless: nope, don't support any weave implementation at all
<jelmer> not as provider, that is
<lifeless> jelmer: are you working on it? (will be needed for stacking)
<Peng> jelmer: fwiw, I have a branch up at http://bzr.mattnordhoff.com/bzr/bzr-svn/trivial/new-style-classes that fixes all of the old-style classes I could find.
<jelmer> lifeless: I'm planning to work on it, haven't started yet
<lifeless> jelmer: and can you point me at the bits of bzr-svn that would give access to the svn backing data?
<jelmer> lifeless: Trying to finish my own python bindings atm
<jelmer> lifeless: what do you mean with backing data specifically?
<jelmer> lifeless: *svn python bindings
<jelmer> Peng: thanks, I'll have a look at merging that
<Peng> :)
<lifeless> jelmer: I'd like to make bzr-search index svn repos
<lifeless> jelmer: all it needs is a non-colocated branch object supporting the repository graph and versionedfile apis
<jelmer> Peng: merged, thanks
<jelmer> lifeless: Getting the versionedfile APIs to work is a fair amount of work
<jelmer> lifeless: the graph code is all there
<lifeless> eww
<lifeless> bzr: ERROR: libsvn._core.SubversionException: ("Can't find a temporary directory", 20014)
<lifeless> jelmer: ^ hints?
<lifeless> jelmer: I did '/home/robertc/bin/bzr', 'checkout', '--lightweight', 'svn://svn.samba.org/smb-build/trunk', 'sbm-build-test'
<lifeless> 4.G free on /
<lifeless> 198 files in /tmp/
<jelmer> hmm, no - what version of bzr-svn is this?
<lifeless> svn --version
<jelmer> you may want to try with the latest release just to be sure
<lifeless> svn, version 1.4.6 (r28521)
<lifeless>    compiled Mar 11 2008, 08:53:49
<lifeless> I'm running hardy
<lifeless> happens just running svn co
<jelmer> also happens running svn co you mean?
<lifeless> svn: Can't find a temporary directory
<lifeless> I mean
<lifeless> $ svn co svn://svn.samba.org/smb-build/trunk
<lifeless> svn: Can't find a temporary directory
<jelmer> time for strace :-)
<lifeless> garh
<lifeless> I was hoping you had seen fuckage before :)
<jelmer> I vaguely recall something like this
<jelmer> but don't remember the specifics :-(
<Peng> Set TMP or whatever, just to check?
<lifeless> server side fuckage
<lifeless> http://rafb.net/p/sOwYPM49.html
<lifeless> the first line, I think, is the key
<lifeless> read(3, "( success ( ) ) ( success ( 36:e8204dac-47fa-0310-9482-a4e8a03ab89e 29:svn://svn.samba.org/smb-build"..., 4096) = 105
<lifeless> sorry, line 5
<lifeless> read(3, "( success ( ( ) 0: ) ) ( failure ( ( 20014 32:Can\'t find a temporary directory 77:/home/tretkowski/s"..., 4096) = 170
<lifeless> success (failure!)
<jelmer> hardcoehmm, chroot broken perhaps :-(
<jelmer> hardcoded paths?
<lifeless> well, I'm not tretkowski :P
<lifeless> bzr-svn work with gcode yet ?
<jelmer> yeah, always has afaik
<lifeless> k
<lifeless> I'll hunt for a small project there ;P
<jelmer> you just need the svn+ hack to work around the fact that bzr aborts as soon as it gets a permission denied
<Peng> Oh.
<Peng> Hmm.
<Peng> With the 0.4 branch, trying to branch http://ack.googlecode.com/svn/trunk/ (with or without "svn+") exits after a second with a return code of 11.
<asabil> lifeless: last time I checked bzr-svn was unable to checkout some code from gcode : http://code.google.com/p/waf/
<jelmer> asabil: even with the svn+ hack?
<asabil> jelmer: hack ? I was using either http:// or svn+ssh://
<jelmer> asabil: I don't remember seeing a bug report about that :-)
<jelmer> asabil: I meant svn+http://
<asabil> I don't think I tried svn+http
<lifeless> jelmer: what needs to happen to fix the bug?
<jelmer> lifeless: bzr needs to be somewhat more persistent when probing for repository formats
<jelmer> rather than aborting the minute it gets something that's not NotBranchError
<lifeless> jelmer: why? what raises the permission denied ?
<jelmer> lifeless: trying to open .bzr/branch/format raises a 403
<lifeless> rather than a 404?
<jelmer> yes, afair that was the problem
<lifeless> hmmm
<lifeless> so
<lifeless> I don't think the driver loop should catch more things
<lifeless> the probe functions should catch whatever other things that neither indicate an error nor a found branch
<jelmer> I don't think the Bzr branch format catching 403 is very nice though
<jelmer> if something's got to do it, rather have it be the driver loop
<lifeless> well
<lifeless> how can the driver loop tell that 403 means 404?
<lifeless> have we filed a bug with googlecode that it gives 403 when a 404 is appropriate?
<lifeless> (I agree that the Bzr branch format catching 403 is not nice). But I also think that the driver catching 403 is  not nice
<lifeless> because, if you had nested branches, typeA and typeB
<jelmer> ah, and the other reason the svn+ stuff exists is to work around the ssl certificate stuff
<lifeless> and there is a permission problem on typeB, typeA can be detected incorrectly
<lifeless> what will address the ssl certiicate stuff?
<jelmer> there's an ancient bug report open about bzr dealing with self signed certificates
<lifeless> k, I have a lightweight checkout
<lifeless> so I can fiddle
<lifeless> no promises, but if I get something shaping up I'll give you a branch
<lifeless> now for dinner and games though :)
<jelmer> cool
<jelmer> have a nice weekend
 * jelmer goes and removes the last dependencies on the official svn python bindings
<Jc2k> oooh
<gour> congrats jelmer
<gour> they finally did 1.5.0, but still....
<Peng> Would your bindings be usable by other projects?
<jelmer> Peng: in theory, yes
<jelmer> however, they're not very well documented and the set I converted is limited to what bzr-svn needs
<gour> that's good enough
<jelmer> if there are other projects interested in using these bindings as well, I'd happily provide them as a separate package
<jelmer> I'd rather wait for such projects to ask first though, rather than putting all of the work in now to find out nobody cares
<lifeless> jelmer: you still support 1.4 w/patches?
<lifeless> jelmer: (hardy only has that ...)
<lifeless> jelmer: how do I get a repository id out of a bzr-svn branch object?
<jelmer> lifeless: yeah, patches aren't even necessary anymore
<jelmer> lifeless: branch.repository.uuid
<lifeless> jelmer: and the relative path to the branch?
<lifeless> jelmer: I'm going to use uuid/branch-path-here/ as a lookaside index path
<jelmer> lifeless: branch.get_branch_path()
<lifeless> hi AfC
<AfC> lifeless: Good evening
<AfC> Is there a command [line client command] which lists all the revision properties / metadata of a given revision?
<lifeless> I don't think there is today
<lifeless> some of the data can be pretty big and is not human consumable
<AfC> Huh
<lifeless> gcommit stores per-file commit messages as revision properties
<AfC> (oh yeah? What consumes it?)
<lifeless> I think gannotate or something
<lifeless> jam will know
<AfC> (not important)
<lifeless> AfC: speaking of locale, ulrich drepper rejected the latin patch for libc
<lifeless> AfC: so Ubuntu is carrying it locally :)
<lifeless> jelmer: ok, I've got to the point where   File "/home/robertc/.bazaar/plugins/svn/repository.py", line 332, in get_inventory_weave
<lifeless>     raise NotImplementedError(self.get_inventory_weave)
<lifeless> is triggered
<lifeless> jelmer: its kinda slow to get that far :(
<AfC> lifeless: Ulrich has always been a hard case.
<lifeless> AfC: oh yes :)
<lifeless> he applied his trademark tact and diplomacy
<AfC> Maybe if you were to become a Benedictine monk or something. That might add credibility (you know, since you have none).
<lifeless> :)
<lifeless> wasn't my credentials, its was the locals
<lifeless> 'just another made up locale' wa the prhase I think
<AfC> Yeah, I can see that. Latin is a lot like Klingon, after all.
<lifeless> :P
<lifeless> ok, its working now for commits
<lifeless> jelmer:
<lifeless> jelmer: revno 43, if you'd like to tell me what I'm doing wrong that makes it so slow, that would be cool.
<lifeless> jelmer: ping
<lifeless> jelmer: where do you want bugs filed, ctrl-C was having trouble stopping 'bzr search test' on http://waf.googlecode.com/svn/trunk
 * Jc2k is tempted to forcefully upgrade parents to ubuntu
<Jc2k> lifeless: will bzr-search work against bzr-mirror.gnome.org :)
<lifeless> Jc2k: yes, bzr-mirror is native bzr
<lifeless> Jc2k: I recommend fresh indices with revno 42
<Jc2k> cool i might give that a spin later
<lifeless> if you do, you could also try the loggerhead branch that supports it :)
<Jc2k> presumably thats now all shiny and wsgi-ify-arific
<Jc2k> in which case, take me to ur url :)
<lifeless> yes
<lifeless> https://code.edge.launchpad.net/loggerhead
<lifeless> second from top
<Jc2k> this ok for bzr-search: cd ~/.bazaar/plugins && bzr branch lp:bzr-search search && cd search && bzr revert -r40
<Jc2k> ?
<lifeless> no need to revert
<Jc2k> 40 was wrong anyway, i meant 42
<lifeless> 43 is fine too
<lifeless> but < 42 will use a different index logic that gives poorer results on searches
<Jc2k> i see
<Jc2k> rar, the search branch of loggerhead hard depends on a bzr-search that is globally installed
<lifeless> well
<lifeless> file a bug
<lifeless> and show me the error
<mwhudson> surely you can fiddle BZR_PLUGINS_PATH ?
<Peng> Or run LH as a user with it in his ~/.bazaar/plugins?
<lifeless> Jc2k: what user does loggerhead run as
<Jc2k> lifeless: at the moment, as me, but in a second im going to move it to x469yq
<lifeless> pastebin thee rrror
<lifeless> Jc2k: it should not depend on a global install of bzr-search
<lifeless> Jc2k: if you can pastebin the error I can advise
<lifeless> Jc2k: for different accounts, just put bzr-search in the ~/.bazaar/plugins/search dir in the relevant account
<Jc2k> lifeless: sorry, laptop just ran out of power
<Jc2k> lifeless: thats where it is
<Jc2k> this is going to be painful.. *tries to remember copy and paste in putty*
<Jc2k> lifeless: line 20 of loggerhead/search.py
<Jc2k> from bzrlib.plugins.search import errors
<Jc2k> No module named search
<lifeless> ok, do this
<lifeless> python -c 'import bzrlib.plugins.search'
<Jc2k> same error
<lifeless> ok
<lifeless> for me:
<Jc2k> ah
<Jc2k> got it
<lifeless> :P
<Peng> Does Loggerhead use any global bzr settings for anything, like your username or something?
<lifeless> Peng: well, it doesn't do commits
<Peng> Yeah, but..
<lifeless> Peng: but yes, it does load the global settings
<Peng> Do any of them affect it?
<lifeless> dunno
<Peng> My only ones are email, editor and LP user.
<lifeless> I can't imagine any of those affecting it
<Peng> Anyway, I'm moving it to its own user, and wondering if I should copy bazaar.conf over.
<lifeless> Jc2k: what was wrong?
 * Jc2k blushes
<Jc2k> fix was
<lifeless> Jc2k: also, currently indices are per-branch, not per-repository (because search shouldn't return commits from a different branch), so you probably only want to index trunk; a full text index is a pretty large fraction of the history in the first place
<Jc2k> cd ~/.bazaar && mv search plugins/
<lifeless> Jc2k: :P
 * Jc2k blushes some more
<Jc2k> ok. i'll index conduit/trunk first. what is the command foo?
<lifeless> bzr index conduit/trunk
<lifeless> or
<lifeless> cd conduit/trunk && bzr index
<Jc2k> and i can run that every time i update the mirror?
<lifeless> nah
<lifeless> it will keep itself up to date once indexed
<Jc2k> sweet!
<lifeless> (or at least its meant to; we can check that it is by running your script and searching for something in the most recent commit)
 * Jc2k desperately wants to learn more about bzr internals some time so he can hack on things :)
<Jc2k> k, the conduit index was quite quick
<Jc2k> awesome
 * Jc2k searches for fixme :)
<lifeless> its currently case insensitive only
<lifeless> sorry
<lifeless> sensitive
<Jc2k> what are your thoughts on showing GNOME this?
<Jc2k> i want to keep up the "look at this shiny shiny" blogging
<lifeless> well
<lifeless> you're supporting the mirror :P
<Jc2k> hmm
<lifeless> I would say
<lifeless> give beuno a few days to polish loggerheads UI for it
<lifeless> its web2.0y
<lifeless> but a little crude
<Jc2k> kk
<lifeless> talk to him when he gets up though
<lifeless> and get it running so you can tell him what bits suck and what don't :)
<Jc2k> :D
<Jc2k> the only think i noticed is that it finds a revision, but i have no clue what file the match is in
<Jc2k> thing, even
<ToyKeeper> hrrm...  looks like bzr_access does 'bzr' but not 'access' yet.
<lifeless> ToyKeeper: I recall a patch or two for that recentl
<ToyKeeper> I took a quick look, and it appears the reason it doesn't do per-repo permissions is because the repo path isn't specified in SSH_ORIGINAL_COMMAND.
<ToyKeeper> Every "bzr push bzr+ssh://host/path/to/repo" results in "bzr serve --inet --directory=/ --allow-writes" on the remote side.  I'm not sure how to get the /path/to/repo part.
<ToyKeeper> At least, it's not in os.environ anywhere.  Maybe there's a better place to look.  :)
<lifeless> ToyKeeper: does bzr_access hook into the smart server methods, or just wrap things ?
<ToyKeeper> As far as I can tell, it just wraps things...  look up the ssh user, then replace the --directory= and --allow-writes parameters, and exec bzr.
<lifeless> ah
<ToyKeeper> Granted, that's sufficient for my personal use...  but it's not very useful for more than one user.  :)
<clemente> Hi. I have this: âetecâ is a link to /etc, and is listed to be added to the repository. I want not to add it, so I try: âbzr remove --keep etecâ. And the result: âbzr: ERROR: Not a branch: "/etc/".â
<clemente> So I can't remove it
<lifeless> clemente: I think there is a bug open
<lifeless> clemente: you need to:
<lifeless> rm <link>; bzr remove <link>
<lifeless> ln -s <whatever>
<Peng> (or mv <link> <link>.bak or something..)
<clemente> lifeless: thanks, that works
<clemente> It's bug 236149, by the way
<ubottu> Launchpad bug 236149 in bzr ""Error: Not a branch" when trying to revert a symlink" [Low,Triaged] https://launchpad.net/bugs/236149
<Pieter> Vienna:5.0 pieter$ time bzr pull lp:mysql-server/6.0
<Pieter> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<Pieter> real	25m3.689s
<Pieter> why does that have to take 23 minutes?
<Jc2k> what happens if you do it again?
<mwhudson> which bzr version?
<mwhudson> there was a bug here
<Pieter> 1.5
<Peng> Were the performance issues pulling from packs to knits fixed?
<Pieter> Jc2k: then it's 'just' 23 seconds
<lifeless> Pieter: it has pulled the data in
<lifeless> Pieter: repeat the operation; bet you it will be much faster
<Pieter> yeah, 60x as fast is ok
<lifeless> Peng: well, knits to packs has to annotate
<lifeless> Pieter: hmm, 30 seconds still. likely an index problem:
<lifeless> http://bazaar-vcs.org/RobertCollins#head-b2dc9ae46f1860c46f79682db455c3512152d148
<lifeless> Peng: I believe it should be 'ok' to pull to knits, not stellar, but ok
<Jc2k> Pieter: can you answer a gitweb question?
<Pieter> Jc2k: perhaps, try me :)
<Jc2k> *grabs a url*
<Jc2k> ok question 1, how can i make the first page faster. its scanning 520 modules and is insanely slow.
<Jc2k> question 2, have a look at http://git-mirror.gnome.org/?p=glib;a=summary
<Pieter> what version of gitweb do you have? (out of which git version?)
<Pieter> there have been patches for the slow listing, I think they were integrated into 1.5.5 or 1.5.6
<Jc2k> its a bare mirror, i have down git --bare svn fetch, how to i update "master" to svn/trunk?
<Jc2k> *done
<Pieter> git update-ref svn/trunk master
<Pieter> eh
<Pieter> reverse those
<Jc2k> is that a once per update thing, or a once per repository thing?
<Pieter> once per update
<Pieter> if you want to do it for always, try git symbolic-ref master svn/trunk
<Pieter> or rather, git symbolic-ref refs/heads/master refs/remotes/svn/trunk, or wherever it is
<Jc2k> will that cause any problems for people cloning from git-mirror.gnome.org ?
<Pieter> no
<Jc2k> ace
<Jc2k> thank you for answering my questions Pieter, as always :)
<Jc2k> what as the git-gc command you wanted me to run?
<Pieter> git repack -adf --window=100 or so should do
<Jc2k> i'll run that and the symbolic-ref thing when theres some free time on the server then
<Jc2k> im guessing that'll be about 4 hours
<Pieter> make sure you have the refs right :) i'm not sure wher git-svn stores its refs
<Jc2k> will do!
<Pieter> Jc2k: http://kerneltrap.org/mailarchive/git/2008/3/13/1160884 << about projcet list caching
<Jc2k> Pieter: does one of those say "this is in HEAD and will be in git 1.x"?
<Jc2k> :)
<Pieter> Jc2k: no. There's a gitweb caching GSoC going on though that will be in 1.6.0
<Jc2k> ah
<Peng> This is weird... when one of my branches was branched over http, the smart server was barely used at all.
<Peng> Absolutely none of the more bandwidth-intensive requests used it. There are a couple dozen hits to the indexes and packs.
<awilkins> Peng: Do people find HTTP more convenient?
<Peng> awilkins: ?
<awilkins> Peng: Are you saying that making it availeble over HTTP makes people use the smart server less, or that serving over HTTP doesn't USE the smart server?
<lifeless> Peng: it falls back to VFS operations for many things today; spiv has been working on making it do so less; possibly there are bugs there, or the client was one tat doesn't have his work incorporated
<Peng> One person branched this branch over http. It auto-detected bzr+http being available, but barely used it.
<Peng> There were 35 hpss requests and 49 for packs or indices.
<lifeless> wow, very chatty
<Peng> Hmm, does the smart server log?
<lifeless> yes
<lifeless> .bzr.log
<Peng> Huh.
<Peng> Well, it's running as my web servers user, and it doesn't have a home dir. Oh well.
<Peng> server's*
<jelmer> lifeless: filed as bugs against bzr-svn in lp
 * jelmer reads his backlog
<spiv> jelmer: I've seen flurry of commits on bzr-svn recently.  How's the cext going?
<jelmer> spiv: it's there and working :-)
<spiv> jelmer: sweet
<spiv> jelmer: if I want to try out the shiny new stuff, which branch should I sue?
<spiv> Er, "use" :)
<Jc2k> eh, we know your motives now spiv :P
<jelmer> the 0.4 one
<jelmer> lifeless: woot on getting bzr-search working against svn!
<spiv> jelmer: hmm, I get a segfault if I try to pull in my python trunk conversion (in svn_auth_set_parameter), and traceback if I try to pull in my Twisted trunk checkout (KeyError for u'trunk' in _get_old_id).
<spiv> I mustn't be lucky tonight :)
<jelmer> please try pulling again
<jelmer> I'm pushing my latest changes now
<jelmer> hmm, one sec
 * spiv -> zzz
<jelmer> spiv: g'night
<jelmer> awilkins: ping
<Jc2k> lifeless: my server is about to explode :P k thx bai
<Jc2k> its sucked up 95% of memory :)
<Jc2k> it seems to have calmed down now
<jelmer> Jc2k: what were you running?
<Jc2k> jelmer: bzr index
<Jc2k> on gcompris
<MvG> Is there any verbose documentation about the different repository formats? I'm especially curious about the difference between rich-root and rich-root-pack.
<Peng> MvG: rich-root is dirstate-tags (well, the repo hasn't changed since knit) only with rich roots, and rich-root-pack is pack-0.92 only with rich roots.
<MvG> What are rich roots?
<jelmer> MvG: in rich root formats, the root directory has a file id
<MvG> Ah.
<jelmer> MvG: older formats don't store a file id for the root directory
<MvG> What's the kind of operation that uses this feature?
<MvG> Anything to do with having nested branches?
<MvG> What's the status of nested branches, by the way?
<jelmer> yeah, nested branches need root ids
<jelmer> bzr-svn also relies on root ids because it avoids a lot of special casing and corner cases
<jelmer> MvG: LarstiQ was working on it last I heard
<jelmer> LarstiQ: ping
<LarstiQ> has no one else done anything with it?
<jelmer> not afaik
<LarstiQ> ok
<vxnick> Hi All - got a bit of a problem if anyone can help?
<fredreichbier> just ask, vxnick ;)
<vxnick> Thanks - basically, I'm tracking an upstream by way of "svn export" (as I can't get bzr-svn working for one reason or another)
<vxnick> I'm tracking this in "upstream/project", (which I "bzr init"-ed) - I then "bzr add" and "bzr commit" these files
<vxnick> The problem I'm having is merging the contents of that project into an empty trunk (which is a checkout)
<vxnick> It tells me the working copy is out of date, although a "bzr update" doesn't do anything as there's nothing in the repository
<vxnick> I also managed to get a nice traceback somehow :(
<vxnick> Now, merging the contents into trunk works fine (bzr status shows N+ for each file), but I can't commit these as it says there are no changes to commit
<vxnick> When I bzr update, it shows "-D" next to each file, and I get "bzr: ERROR: Reserved revision-id {null:}" (presumably because I'm on revision 0)
<vxnick> bzr status then shows whitespace next to each filename
<vxnick> and bzr commit deletes the files, but throws a traceback and this error: bzr: ERROR: exceptions.AssertionError: 2 != 1
<vxnick> any ideas, fredreichbier?
<Peng> Wow.
<Peng> Using "svn export" for a mirror is pretty awful.
<Peng> You should really try to get bzr-svn -- or any other converter -- working.
<vxnick> Yeah, I gave it a couple of goes but with no luck
<Peng> What issues were you having?
<vxnick> bah, I can't remember now
<vxnick> it was a couple of weeks ago I last tried
<vxnick> I was working on the basis that "svn export" doesn't export any history with it, just a clean tree
<vxnick> in effect working the same as if I were to add the files myself
<clemente> vxnick: that's what I was thinking... Can you reproduce the problem if you add the files yourself? Maybe the problem has nothing to do with Subversion
<vxnick> bear with me and i'll give it a go now...
<clemente> I myself am getting a crash with âbzr statusâ and I'm trying to figure out the cause
<clemente>   File "/Werkstatt/bzr.dev/bzrlib/tsort.py", line 415, in __init__
<clemente>     parents = self._graph.pop(branch_tip)
<clemente> KeyError: 'pop(): dictionary is empty'
<vxnick> clemente: same issue when adding the files myself
<Peng> Uh-ohs.
<Peng> clemente: Up-to-date bzr.dev?
<vxnick> just to clarify - should I be "bzr init" the directory when I add the files, along with bzr add and bzr commit, then merge into trunk?
<clemente> Peng: almost; one moment...
<clemente> Peng: yes
<Peng> clemente: If you can find a way to reproduce this, file a bug.
<Peng> (Well, search for existing bugs first...)
<clemente> What's the efficient way of finding out more about an error? Inserting âpdb.set_trace()â? Turning on some debug mode...? Running tests?
<Peng> clemente: You can run it so it'll automatically drop into pdb, but I forget how.
<vila> BZR_PDB=1 ?
<clemente> vila: yes
<clemente> vxnick: I suppose that init+add+commit should work... (Do they work without problems for you?) The big problems could be with the merge
<clemente> vxnick: if you get errors, maybe you can debug them. BZR_PDB=1 :-)
<vxnick> clemente: those work fine for me usually, so I think you're right in that it's the merge.
<vxnick> I presume you can merge something into an empty directory, or do you need to have the same (older) files there beforehand?
<vxnick> I could pull the files in, but then the parent dir for the trunk would be the upstream, which doesn't make much sense to me
<vxnick> the main problem, to clarify, seems to be that "bzr commit" doesn't commit the merge to the repository - bzr status shows the new files, and I can see them in the physical directory of the trunk too
<vxnick> "commit" just reckons there's no changes, thus nothing to commit
<clemente> I thought âcommitâ sends the changes to your branch, whereas âpushâ sends them to the remote repository. I would try âpushâ and âmergeâ instead of âcommitâ
<vxnick> I've got a remote repository setup with a checkout on my local machine
<vxnick> commit can work locally and/or remotely I believe
<vxnick> if you are using a checkout
<vxnick> I believe push/pull work for a branch
<vxnick> but I'm quite new to bazaar, so might be wrong :)
<clemente> vxnick: yes, right. I'm also new and in fact I still haven't succeeded in doing a âmergeâ...
<vxnick> I've managed to merge branches locally, but this is the first time I've tried merging into a checkout
<vxnick> I have prevously "bzr init"-ed a directory and then branched it, then merged from the branch back into the "trunk"
<vxnick> if you branch something, you have to "pull" the changes from the original dir into the new branch - I think that merges as well automatically
<vxnick> if you want to merge the differences from the new branch to the old, you use merge
<vxnick> if that makes sense
<clemente> vxnick: I don't know. I would try looking at where the error message comes from in the code, in case you get an error
<vxnick> yeah I might try that, but I'm not familiar with Python
<vxnick> and I have to do some weird stuff to get the trace from it
<vxnick> other than that, it's just the generic bzr error messages such as "working copy out of date" and so on
<clemente> Then look if the syntax you're using is the correct one
<clemente> You may also find a way to reproduce it to see if some other person sees the problem
<vxnick> yeah fair enough
<clemente> Don't worry... I have just gotten your error :-)
<clemente> bzr: ERROR: Reserved revision-id {null:}
<clemente> After doing a merge of a patch I created with âsendâ
<Leonidas> What is the command to modify the working tree to look like some older revision?
<Leonidas> I've tried both checkout and update, but none of them lets me specify the desired revision
<vxnick> bzr revert?
<vxnick> or uncomitt
<vxnick> uncommit*
<vxnick> see what "bzr help revert" or "bzr help uncommit" show - that should help :)
<Leonidas> vxnick: bzr revert seems to be what I needed. Right. uncommit whould be too much, I don't want to loose the tip/HEAD
<vxnick> ah right
<Leonidas> btw, that is the name of the most recent revision? hg calls it tip, git HEAD and bzr? -1?
<LarstiQ> Leonidas: -1 is a shorthand for that, yes
<vxnick> HEAD I think
<LarstiQ> vxnick: not in a tool addressable way
<LarstiQ> Leonidas: but if you want to talk terminology in discussions, tip or head would be understood
<Leonidas> LarstiQ: ok, thanks.
<clemente> vxnick: I got also âD-â on update
<vxnick> is that with a checkout?
<clemente> Problem is: rev_id=null  here:
<clemente>   /Werkstatt/bzr.dev/bzrlib/mutabletree.py(52)tree_write_locked()
<clemente> -> return unbound(self, *args, **kwargs)
<clemente> > /Werkstatt/bzr.dev/bzrlib/workingtree_4.py(1103)set_parent_trees()
<clemente> -> _mod_revision.check_not_reserved_id(rev_id)
<clemente> But I don't understand more
<clemente> vxnick: it was with init+merge+update
<clemente> where the merge came from a patch file (created with âbzr sendâ)
<clemente> It happens also with latest bzr
<vxnick> have you tried just a normal merge?
<clemente> You mean, from a repository instead of from a file?  (No)
<vxnick> try making a dir "bzr init dir" then branching it to "dir2" - add a couple of files with some random text in "dir" and then cd to dir2 and "bzr pull". Make some changes in "dir2", cd to "dir" and "bzr merge ../dir2"
<clemente> vxnick: I suppose you had to do âcommitâ at least once after the âinitâ
<clemente> otherwise you stay at revision 0
<vxnick> yeah, sorry
<vxnick> and bzr add before the commit
<clemente> (and this may be the problem for rev_id to be null...)
<clemente> vxnick: ok, it stays there without errors under âpending mergesâ
<clemente> (I did a âcommitâ also on dir2)
<vxnick> do a commit and it should work
<clemente> Ok, so no problems in update/commit/status
<clemente> My first successful merge, thanks for the help :-)
<clemente> Now I try with a patch file instead of with a repo
<clemente> Ok, I only get the error message if the merge occurs before revision 1
<clemente> This fails on âupdateâ:  mkdir bzr00004; cd bzr00004; bzr init; bzr merge /n/resprueba/mezcla ; bzr update
<clemente> But this works:  mkdir bzr00005; cd bzr00005; bzr init; echo a>b; bzr add b; bzr commit -m "be"; bzr merge /n/resprueba/mezcla ; bzr update
<clemente> So the problem is doing the âmergeâ before you have done a âcommitâ on your new repository
<clemente> I suppose it's a bug
<asabil> clemente: how do you want to merge in an empty repo ?
<asabil> They have no parent in common
<clemente> Is it not allowed?  âmerge with emptyâ == âbranchâ?
<asabil> clemente: try to pull
<clemente> Yes, âpullâ works
<clemente> I think then that instead of failing, bzr should show an error message which says that (you can't merge in an empty repository)
<Peng> s/repository/branch/
<clemente> But I thought that after âinitâ you got really an empty repository, that is, a first parent (a root parent)
<Peng> s/repository/branch/
<clemente> Thanks. Does ârepositoryâ mean âcollection of branchesâ?
<Peng> No.
<Peng> A repository is a big bag of revision data.
<clemente> A branch too
<Peng> No.
<clemente> Or a branch is the place, and the repository the content?
<Peng> On disk, a branch is simply the ID of the most recent revision in that branch. That's used to figure everything else out from the revisions in the repository.
<clemente> I submitted bug 242175, about improving the error message
<ubottu> Launchpad bug 242175 in bzr "Better error message when merging into empty branch" [Undecided,New] https://launchpad.net/bugs/242175
<clemente> Peng: where can I find precise definitions of those concepts? (applied to Bazaar)
<Peng> I dunno; user guide?
<clemente> (Peng: yes, it was)
<clemente> What's that about a âsmart serverâ? Does it work? According to [1] it's still under design phase. [1]: http://bazaar-vcs.org/Specs/SmartServer
<Peng> clemente: Yes the smart server works.
<clemente> Ok, I'll try it
<Peng> clemente: It still doesn't have optimal performance, but they're working on it, and it's perfectly usable today.
<Peng> clemente: FWIW, I always use the smart server.
<Peng> clemente: If you're using a knit repo (upgrade!), it's a huge performance improvement. Packs are fast enough that it's not really, but it probably would be if you're moving a lot of data, and anyway, it's cooler and getting better all the time.
<clemente> Can you also use on a machine where you can't modify apache.conf?
<Peng> clemente: bzr+http? Um, can you modify .htaccess?
<clemente> Yes
<Peng> clemente: You can use it then
<Peng> clemente: You can install bzr?
<clemente> Yes
<clemente> Is that in the manual?
<Peng> Is what?
<clemente> The explanations for setting up the smart server with .htaccess
<clemente> I only find that for ssh, inetd, or a dedicated server
 * Peng shrugs.
<Peng> When I set it up, I used the documentation.
<clemente> I will read more documentation then
<Peng> Hmmm.
<Peng> You're right.
<Peng> That section doesn't mention it.
<Peng> The source tree has doc/en/user-guide/http_smart_server.txt
<Peng> Not sure where to find it in the html
<Peng> clemente: Oh, it's at the bottom, in an appendix. http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi
<Peng> clemente: (You don't need to use FastCGI.)
<clemente> Ok, thanks for all help, I will continue learning bzr; bye
<bkor> jelmer: "It generates inefficient code - it generates proxy classes that " <-- ends abruptly
<awilkins> jelmer: pong
<jelmer> bkor: whoops, thanks
<jelmer> awilkins: The C extensions branch is there!
<jelmer> and passing all tests on Linux
<Peng> Hmm. I was able to push bzr-svn into a rich-root-pack repo, but not upgrade the subtree repo to it.
<jelmer> Peng: Hmm, that sounds like a bug
<Peng> jelmer: (I meant bzr-svn's repo itself, not an svn repo managed by bzr-svn.)
<Peng> I was also left with a "repository.backup".
<Peng> Probably the same thing that happened to you a couple days ago.
<Peng> Bzr flatly refused to do it since, of course, rich-root-pack doesn't support subtrees.
<jelmer> Ideally, bzr would only refuse to upgrade from subtree to rich-root-pack if there was actually a revision in that repository that used subtrees
<Peng> Yep.
<Peng> And it already has the proper machinery, since push can do it.
<jelmer> Push probably breaks if you try to push a revision with a subtree into rich-root-pack
<Peng> That's what I mean. Push probably handles it exactly how upgrade should.
<edcrypt> some of this info seems outdated: http://live.gnome.org/DistributedSCM
<jelmer> Peng: I mean that it breaks badly :-)
<Peng> Oh.
<bkor> edcrypt: please update
<edcrypt> bkor: will try to research some references...
<mwhudson_> morning
<Jc2k> evening mwhudson_ :)
<mwhudson_> Jc2k: did you see that you can run loggerhead trunk now? :)
<Jc2k> mwhudson_: did you try search on my copy of loggerhead ;)
<Jc2k> you should be able to give it a spin on gtk+ now :)
<mwhudson_> neat :)
<Jc2k> so yeah, im running a different branch now :)
<mwhudson_> heh, ok
<Jc2k> its very had not to blog about the loggerhead foo :)
<Jc2k> mwhudson_: i can link loggerhead into apache more now?
<Jc2k> rather than having it running in a screen session :P
<Peng> Heh, I have it running in screen too.
<Jc2k> i guess i just need mod_wsgi
<mwhudson_> Jc2k: i guess so, yes
<mwhudson_> Jc2k: feel free to blog
<mwhudson_> i don't really know if there are any real actual advantages to mod_wsgi
<Jc2k> mwhudson_: waiting a few days for some bueno polish :)
<mwhudson_> oh, ok :)
<mwhudson_> beuno: i see you noticed your ~loggerhead-team membership :)
<lifeless> moin
<thumper> morning
<mkanat> mwhudson_: Trying loggerhead trunk, getting a traceback with start-loggerhead.py: http://pastebin.mozilla.org/465681
<mwhudson_> mkanat: you use auto_folder ?
<mkanat> mwhudson_: I do.
<mwhudson_> i bet i never even checked that
<mwhudson_> mkanat: have you seen the new serve-branches.py script?
<mkanat> mwhudson_: I have, but I don't want to serve everything in the path. Is that avoidable?
<mwhudson_> not without programming i guess
 * mwhudson hmms
<mwhudson> actually it's url_prefix that's broken i think
<mkanat> Oh, hmm.
<mkanat> Yeah, I need that unless I can just tell it "strip off the /var/www/html/everythingsolved.com/bzr/ from every path for the URL".
<lifeless> jelmer: any comment on the speed issue it has?
<mwhudson> truth be told, i've never understood the purpose of many of the things you can put in loggerhead.conf :)
<mkanat> mwhudson: Heh. :-)
<mwhudson> mkanat: i just pushed r166 of trunk, try that?
<lifeless> Jc2k: which branch chewed all your ram while indexing?
<mwhudson> morning lifeless
<mkanat> mwhudson: Yes, that seems to be running! :-)
<mwhudson> mkanat: woo!
<Jc2k> lifeless: i'm not entirely sure if it was bzr index or not, but things got a little rough on the box for trunk of... gcompris, gimp-help, gimp and guadec-web
<mwhudson> mkanat: i hope this one doesn't chew all your ram...
<Jc2k> i aborted them..
<mkanat> Well, the first plus I can see is that my log isn't full of 404s. :-)
<lifeless> Jc2k: oh it likely was :)
<lifeless> Jc2k: can you edit index.py
<Jc2k> gimp.. i dont know, i was just worried it would break so i abored it anyway
<lifeless> look for group_size = 2500
<Jc2k> lifeless: i can, but i'd prefer not to whilst it was still running
<Jc2k> its indexing nautilus
<lifeless> drop that down and repeat until it stays happy
<lifeless> I'd like to figure out some way to auto tune
<jelmer> lifeless: 'morning
<jelmer> lifeless: speed issue?
<lifeless> Jc2k: uhm, its fine to do as its running :P
<mkanat> mwhudson: I'm getting a few tracebacks in my debug.log, though not sure what the problem is (I just have spiders that are crawling the site, apparently). Want to see the traceback?
<lifeless> jelmer: in the backlog; it was very slow at indexing just the commits via bzr-svn
<mwhudson> mkanat: yeah, let's have a look
<mkanat> mwhudson: http://pastebin.mozilla.org/465683
<lifeless> Jc2k: the .py -> .pyc will be recompiled the next time python loads it
<mwhudson> mkanat: so i think that happens when someone browses to blah/blah/inventory?file_id=file_id_of_non_directory
<mwhudson> mkanat: it's possible we're generating a bogus link somewhere
<mkanat> mwhudson: Ah. And that link shows up in the UI? (This is the Googlebot doing this, apparently.)
<mwhudson> mkanat: it seems unlikely that googlebot just made such a url up, indeed :)
<mkanat> mwhudson: And WOW, this version is WAY better on the resources!
<mkanat> I can't even pick it out in top's list.
<mwhudson> mkanat: :)
<lifeless> jelmer: the easiest way to show you is for you to try it yourself :P
<mwhudson> mkanat: i can't see anywhere where a bogus link like that would be generated
<mkanat> mwhudson: I'll watch my apache log for referrers.
<mwhudson> mkanat: it's possible that we fixed this bug without noticing at some point and googlebot is remembering it
<mkanat> mwhudson: Yeah, that is possible.
<mwhudson> mkanat: one idea
<mkanat> Ah, I couldn't pick it out in top because it wasn't there--I had Ctrl-C'ed and I forgot that I was running ./start-loggerhead.py -f. :-)
<mwhudson> mkanat: do you have an 'updir' link in the root of the branch (in the files view)?
<mkanat> mwhudson: I'll look.
<mwhudson> that's something i could imagine going wrong
<mwhudson> (though it doesn't in my tests)
<mwhudson> mkanat: this branch should still be a lot better than the old version on resources
<mwhudson> mkanat: please let us know how it does over time
<mkanat> mwhudson: Yeah, it is so far.
<mkanat> mwhudson: Yeah, I will.
<mkanat> mwhudson: Oh, problem.
<awilkins> jelmer: So the 0.4 branch now has the cext branch merged in it?
<mkanat> mwhudson: The URLs look like http://localhost:8080//bzr.everythingsolved.com//vci/stable/revision/88
<jelmer> lifeless: I'm confused - bzr-search appears to rely on weaves which bzr-svn doesn't have
<mkanat> mwhudson: Which is the path to the local server, not the right URL.
<mwhudson> mkanat: oh bugrit
<mwhudson> mkanat: i thought i'd fixed that
<jelmer> awilkins: yep
<lifeless> jelmer: it only indexes commit messages on SvnBranch objects today
<mwhudson> ugh, indeed, totally not
<jelmer> lifeless: ah, ok
<lifeless> jelmer: yesterday I did the various bits of machinery needed to teach it where to store an index for a svn branch, and disabled the stuff it couldn't use
<awilkins> jelmer: Will distutils build them?
<jelmer> awilkins: yes
<lifeless> jelmer: if you change commits_only = True, to False on line 161 of index.py you can see it fail to access weaves :)
<mwhudson> mkanat: fixing...
<mkanat> mwhudson: Okay. :-)
<mwhudson> mkanat: can you try r167 from https://code.edge.launchpad.net/~mwhudson/loggerhead/config-vhost ?
<mkanat> mwhudson: I can just pull from that into my current?
<mwhudson> yes
<mkanat> mwhudson: Wow, bzr does not like that URL.
<mwhudson> mm
<mwhudson> it should redirect to the branch
<mwhudson> lp:~mwhudson/loggerhead/config-vhost should work better
<mkanat> mwhudson: http://pastebin.mozilla.org/465687
<Jc2k>  Sorry, you don't have permission to access this page.
<Jc2k> You are logged in as John Carr.
<mwhudson> oh
<thumper> ???
<mwhudson> mkanat: try again
<mkanat> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~mwhudson/loggerhead/config-vhost/".
<thumper> ah
<thumper> mkanat: there will be a pause
<thumper> mkanat: while the http system realises that it is no longer private
<mkanat> Okay.
<thumper> mkanat: give it a minute or so
<mkanat> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<mwhudson> what command line are you running??
<mkanat> mwhudson: bzr pull https://code.edge.launchpad.net/~mwhudson/loggerhead/config-vhost
<mwhudson> (do you have a checkout? in which case 'bzr unbind')
<mkanat> Oh, right, I should unbind.
<mkanat> mwhudson: Thanks. :-)
<mkanat> mwhudson: I had it bound manually so that I could just type "bzr up" when I wanted to.
<mwhudson> uh
<mwhudson> 'bzr pull' should work
<mwhudson> mkanat: oh, this branch will require paste.deploy, btw
<mkanat> mwhudson: Okay, that version dies: http://pastebin.mozilla.org/465688
<mwhudson> PrefixMiddleware(app, translate_forwarded_server=True, prefix=webpath)
<mwhudson> i.e. add the 'app' argument
<mwhudson> (sorry)
<mkanat> Okay.
<Jc2k> lifeless: i halved it, whatever that will lead to..
<mkanat> mwhudson: Now my frontpage URLs are slightly wrong: http://bzr.everythingsolved.comvci/stable
<mkanat> mwhudson: And if I fix that in the URL bar, the internal URLs look like: http://bzr.everythingsolved.comhttp%3a//bzr.everythingsolved.com/vci/stable/revision/88
<mwhudson> so basically, that didn't work at all
<mwhudson> mkanat: what's the server.webpath in your loggerhead.conf ?
<mkanat> server.webpath = 'http://bzr.everythingsolved.com/'
<mkanat> I just added that slash.
<mkanat> So it was server.webpath = 'http://bzr.everythingsolved.com'
<mwhudson> mkanat: so if you remove that
<mwhudson> and the "translate_forwarded_server=True"  in start-loggerhead.py
<mwhudson> then it should Just Work
<LarstiQ> (TM)
<mkanat> mwhudson: It originally didn't have the /.
<mkanat> mwhudson: Adding the slash makes no difference, it seems.
<mwhudson> mkanat: but that worked with the old loggerhead, right?
<mkanat> mwhudson: Yeah, slashless worked with the old loggerhead.
<mwhudson> so two things (1) do what i said above, that should get you working (2) i have some work to do to get perfect compatibility with old loggerhead.conf files
<mkanat> mwhudson: Oh, remove server.webpath entirely?
<mwhudson> mkanat: yes
<mkanat> Okay, here we go! Let's try. :-)
<mkanat> Okay, with both of them gone, the front page works.
<mkanat> mwhudson: But the internal URLs look like: http://localhost:8080/vci/stable/revision/88
<mwhudson> mkanat: you are running behind apache using mod_proxy ?
<mkanat> mwhudson: Yeah, I think so.
<mwhudson> oddness
<mkanat> mwhudson: Here's my Apache conf: http://pastebin.mozilla.org/465704
<mwhudson> mkanat: that's not mod_proxy, that's mod_rewrite :)
<mkanat> mwhudson: Well, [P] is using mod_proxy, no?
<mwhudson> hm, maybe
<mwhudson> anyway, what paste.deploy is doing is relying on HTTP_X_FORWARDED_SERVER
 * mkanat read the Apache docs just now and it says that [P] does indeed use mod_proxy.
<mwhudson> yeah, me too
<mkanat> mwhudson: Anywhere I could put some debug code to spit out that env var?
<mwhudson> def (environ, start_response, orig=app):
<mwhudson>  print environ
<mwhudson>  return orig(environ, start_response)
<mkanat> mwhudson: In what file?
<mwhudson> in start-loggerhead.py, just before the serve call
<mkanat> Okay.
<mkanat> mwhudson: In the try block?
<mwhudson> mkanat: yeah, should work
<mwhudson> (doesn't matter much, basically)
<mkanat> def (environ, start_response, orig=app):
<mkanat>         ^
<mkanat> SyntaxError: invalid synta
<mwhudson> erm
<mwhudson> do you know python well?
<mkanat> I know it, but I don't know these frameworks well enough.
<mkanat> And I don't know it well enough to know what an empty def call does.
<mwhudson> i typed three lines for that function
<mwhudson> mkanat: http://pastebin.ubuntu.com/22225/
<mwhudson> mkanat: phone now, brb
<mkanat> mwhudson: Okay.
<mkanat> (Ahh, it was nameless originally.)
<mwhudson> mkanat: oops :)
<mkanat> 'HTTP_X_FORWARDED_SERVER': 'bzr.everythingsolved.com'
<mwhudson> mkanat: sorry about this, thanks for being patient
<mkanat> mwhudson: Hey, no problem.
<mwhudson> mkanat: and then still funky urls?
<mkanat> mwhudson: Yep.
<mwhudson> grr
<mkanat> Not *as* funky as they used to be.
<mkanat> I mean, at least these could theoretically be right, if I was somehow on the server itself. :-)
<mkanat> You can see it here if you want: http://bzr.everythingsolved.com/vci/stable/changes
<mkanat> HTTP_X_FORWARDED_HOST is also bzr.everythingsolved.com.
<mwhudson> mkanat: i wonder what version of paste deploy you have?
<mkanat> rpm -q python-paste
<mkanat> python-paste-1.6-1.el5
<mkanat> rpm -q python-paste-deploy
<mkanat> python-paste-deploy-1.3.1-1.el5
<mwhudson> mm, pretty close to the same as me
<mkanat> Hmm, welcome to "our product has no changelog".
<mkanat> Ahh, yes it does.
<mkanat> It was just cleverly hidden.
<mkanat> mwhudson: What version of paste-deploy do you have?
<mwhudson> 1.3.1-2 (ubuntu hardy here)
<mkanat> Yeah.
<mkanat> Okay, so yeah, the same.
<mkanat> mwhudson: And paste 1.6?
<mwhudson> 1.6-2
<Peng> What's this about url_prefix being broken?
<mwhudson> Peng: if you're not using loggerhead.conf. it shouldn't affect you
<Peng> Indeed I am not.
<Peng> I'm using serve-branches.py with the Paste Deploy prefix thingy. :)
<Peng> (If that's what url_prefix does..)
<mwhudson> Peng: it's not
<Peng> Heh, okay.
<Peng> I'll shut up then. :)
<mwhudson> mkanat: try this patch: http://pastebin.ubuntu.com/22228/
<mwhudson> i think i was getting too complicated :)
<poolie_> good morning
#bzr 2009-06-15
 * Peng_ sneaks /away
<jelmer> visik7: I've looked into having the Bazaar smart server run over jabber
<jelmer> visik7: Unfortunately it's only possible to offer services to particular people using XMPP, it's not possible to announce that you're running a Bazaar smart server
<jelmer> lifeless: btw, related to your [RFC] history editing vs history presentation post, did you see the recent blog post from Linus about workflows in Linux ?
<lifeless> no, url me up please
<james_w> http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html
<jelmer> lifeless: and in particular this rant that he links: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
<lifeless> thanks
<jelmer> "Don't change history" may not be very novel in the Bazaar world, but as a git user I found that rant quite useful.
<jelmer> I'm getting more and more convinced that what people really seem to want is well-working looms for in-progress patches
<mwhudson> the main difference for me from the rant is that merging trunk at 'random' points is ok because trunk is always clean
<fta> jelmer, hi
<jml> jelmer: I'm people, and I certainly want that :)
<RenatoSilva> I'm looking for a project hosting. I'm considering cvs, svn, hg, bzr and git hostings. I know Google Code, Gitorious and Github for now. Any other suggestions?
<poolie> RenatoSilva: launchpad.net
<AfC> RenatoSilva: you don't really need much to host a DVCS branch, certainly not a bzr one. Just a web server and a ssh account, and you can easily host your work.
<RenatoSilva> poolie: last time I've checked launckpad I'd have to do complicated stuff to set up my repo, and with some limitations (like I can't put exe files there)...
<Peng_> RenatoSilva: .....What?
<RenatoSilva> Yeah, I don't remeber well
<RenatoSilva> Maybe I was confused
<RenatoSilva> But how is the set up process today?
<RenatoSilva> What repos, limitations?
<RenatoSilva> I'm afraid only bazaar is supported
<lifeless> RenatoSilva: setup your project; then bzr push lp:~USERNAME/PROJECT/BRANCHNAME
<RenatoSilva> does it have issue tracker, wiki, and other secondary infra-structure?
<lifeless> yes no yes
<lifeless> jelmer: thanks for that link
<RenatoSilva> lifeless: I'll take a look again, thanks
<RenatoSilva> Do you guys think LaunchPad is better than BitBucket?
<lifeless> yes
<RenatoSilva> why
<garyvdm> RenatoSilva: You probably will get a very biased answer to that question here.
<garyvdm> RenatoSilva: I like it. I have never used BitBucket - so I can't compare.
<lifeless> well, for starters lp supports bzr. More broadly it has mailing lists, translations and integration with build farms
<lifeless> Also, I work @ Canonical so my answer is likely biased :).
<lifeless> random data point - bitbucket has 4000 projects on it apparently, lp has 12000
<RenatoSilva> I just don't know why would I want to choose one of bzr, hg, and git rather than other
<RAOF> I _don't_ work at Canonical, and I'd also recommend launchpad.  It's nicely integrated, it's development is reasonably consistent, and the bzr integration is very useful.
<jml> poolie: btw, I'll be sending a few different release related emails out today.
<lifeless> RenatoSilva: so choose one; it doesn't matter which. If you find it doesn't work well and the community isn't helpful for you, swiwtch.
<lifeless> poolie: In about 10 minutes I'll be going nose-down on check with the world turned off.
 * SamB sends jelmer a bzr-svn patch
<RenatoSilva> lifeless: maybe hg, because Moin uses hg, and my projects are moin plugins
<RenatoSilva> but I'd like to use cvs because I'm already using it at work
<lifeless> poolie: so if you have stuff you want to chat about, earlier >> later :)
<lifeless> RenatoSilva: unless you're merging with moin it won't matter that moin is in hg and your plugins aren't.
<RenatoSilva> is it possible to work with vcs's over http?
<lifeless> RenatoSilva: using CVS is worse than using any of bzr/hg/git: CVS has many performance issues, few correctness guarantees, is problematic for sysadmins.
<RenatoSilva> my work deny access to other ports
<lifeless> RenatoSilva: to varying degrees, yes. Bzr supports read and write over http. However, *launchpad* hasn't deployed the write module for http.
<igc1> morning all
<RenatoSilva> lifeless: yeah, I mean commit over http. It would be really nice don't you think
<lifeless> RenatoSilva: mwhudson here can tell you about that vis-a-vis launchpad ;)
<lifeless> AFAIK its not in the pipeline at the moment.
<garyvdm> RenatoSilva: you can push to launchpad over ssh - that is quite a common port - If I was you I would check if that is open.
<mwhudson> yeah, would be nice
<mwhudson> no time though
<lifeless> mwhudson: btw why were you asking about doing reconcile on launchpad?
<mwhudson> lifeless: i thought if it was an overnight job, i could have done it last night
<lifeless> mwhudson: yes but why are you doing it?
<mwhudson> lifeless: it didn't seem like a bad thing to do
<lifeless> ah
<lifeless> its not, just very expensive
<RenatoSilva> lifeless: since you work at canonical (which country btw?), I'd suggest you wiki for projects documentation
<mwhudson> right
<lifeless> mwhudson: I'm working on check [a precursor to reconcile] at the moment.
<RenatoSilva> garyvdm: I will check if ssh is allowed, tahnks
<mwhudson> lifeless: yeah, i know
<lifeless> RenatoSilva: yes, the developers of launchpad would like to do something along wiki lines
<lifeless> RenatoSilva: time & design are still up in the air, last that I heard.
<lifeless> ok, nose grinding time. If anyone needs me, SMS please.
<RenatoSilva> lifeless: if you're going to use moin, you may want to wait for the 2.0 release
<mwhudson> RenatoSilva: it's pretty unlikely that lifeless is going to be doing the wiki work
<RenatoSilva> mwhudson: it's just a suggestion to the wiki guys, he could tell them
<RenatoSilva> where is canonical? London?
<garyvdm> RenatoSilva: Canonical is registered in the Isle of man, It's head office is in London, but it is a virtual company with most of it employees are from all over the world.
<garyvdm> Alot of the bzr developers are from Australia
<garyvdm> RenatoSilva: p.s. I don't work for Canonical.
<poolie> (back)
<poolie> lifeless: i don't think i want to talk to you urgently
<poolie> jml, hi, how did you go with the release? want to talk?
 * RenatoSilva had an energy crash
<jml> poolie: would love to talk. maybe give me 15-30mins to finish up what I'm doing now?
<poolie> ok
<poolie> igc, how are you doing today?
<igc> hi poolie - ok thanks
<igc> poolie: slept most the weekend so that helps
<RenatoSilva> oh, BitBucket is paid, agh.
<poolie> garyvdm, igc, i'm using explorer
<poolie> it's really nice!
<garyvdm> poolie: Great!
<poolie> i wish there was a way to get it to open a browser on the branch's launchpad page
<igc> poolie: thanks
<poolie> or, generically, it's web page, like lp-open
<poolie> or is there?
<igc> poolie: it got zero love over the weekend - too tired sorry
<jml> it's really easy to do :)
<igc> poolie: we could add that pretty easily
<garyvdm> igc: I don't think qbzr would need to be extended. You can just run bzr lp-open
<igc> garyvdm: right
<poolie> igc oh it wasn't a complaint
<poolie> spiv: hi, good morning
<poolie> spiv, i was wondering on the weekend, where did aaron get up to with the subtree design docs?
<poolie> do you know?
<garyvdm> igc, poolie: What I'm planning to do qmain is to have lots of lp related functionality, but have it implemented in a separate plugin.
<garyvdm> *to do for qmain
<RenatoSilva> BitBucket's HTTP push/pull is commit / checkout over HTTP?
<RenatoSilva> checkout / commit
<igc> garyvdm: sounds good
<igc> garyvdm: and don't forget that explorer let's plugins add their own panels simply by registering them
<garyvdm> RenatoSilva: with a dvcs, you generally commit to your local repository, and then push that to your central branch
<spiv> poolie: I'm not sure; there was a small amount of chatter on the list I think (on a tangentially related thread about "merge --pull")
<RenatoSilva> garyvdm: ok, but over http?
<RenatoSilva> garyvdm: in bitbucket I mean
<garyvdm> I don't know
<spiv> poolie: I haven't heard much, although I think we committed the version of the doc we had at the end of UDS (in the devnotes branch)
<garyvdm> I don't know if they let you push over http
<garyvdm> I'm sure they let you pull over http though.
<garyvdm> RenatoSilva: I think you need the bzr-webdav plugin to push to http with bzr
<spiv> poolie: IIRC we had reached decisions that were acceptable to both of us for all the questions in the "unanswered questions" section, and Aaron was intending on going through all the use cases at the end of the doc and writing the commands to demonstrate how they'd work.
<spiv> (and thus verify that the use case was actually satisfied)
<RenatoSilva> garyvdm: launchpad could include such feature
<poolie> jml, as RM, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/7429
<poolie> ok that'd be good
<jml> poolie: what happened to the '|' line prefix?
<garyvdm> RenatoSilva: In theory - yes. I don't think it would be high on their priority.
<poolie> i removed it so you can more easily copy the text
<jml> poolie: it wasn't necessary for formatting then?
<poolie> i think it changes it from the equivalent of <blockquote> to <pre>
<garyvdm> RenatoSilva: as mwhudson said re http push > "yeah, would be nice, no time though"
<jml> poolie: ok. looks good to me.
<mwhudson> garyvdm: you don't need webdav, there's bzr+http
<RenatoSilva> garyvdm: yeah, :(
<RenatoSilva> garyvdm: however would that be hard? It's just about installing the plugin and setting up the http server right?
<spiv> RenatoSilva: and figuring out how to handle authentication
<garyvdm> mwhudson: Ah - yes.
<RenatoSilva> ok, anyway, it's a suggestion
<mwhudson> and performance implications
<lifeless> poolie: are you on the pone at the moment?
<lifeless> garyvdm: webdav is not what lp would use
<lifeless> garyvdm: lp would use bzr+http - the smart server.
<garyvdm> yes
<lifeless> RenatoSilva: launchpad has scaling to consider; its not the same problem for a hosting site that it would be for a single user wanting commit-over-http.
<RenatoSilva> lifeless: ok
<RenatoSilva> as I said: suggestion
<lifeless> sure. As already discussed its desired but not done yet.
<RenatoSilva> ok
<RenatoSilva> lifeless: BitBucket has this feature
<mwhudson> RenatoSilva: like everyone, we have a much longer list of things we'd like to do than we have time to do
<mwhudson> RenatoSilva: the things you've been mentioning are already on our list :)
<RenatoSilva> ok thank you
<jml> poolie: want to talk?
<igc> bbiab
<RenatoSilva> Since bzr is a dvcs, but at work I can only use bzr over http, which is not supported by launchpap, I could do the following: have two repos, one at work, and another at launchpad. When changing my code at work, I commit locally, then I take the repo home, and then I push it to launchpad. Is this ok?
<thumper> RenatoSilva: you could always push home if you install bzr-webdav for http pushes from work with a post push hook to push to LP :)
<RenatoSilva> thumper: but is my procedure ok too?
 * thumper dumps and runs
<RenatoSilva> am I realizing it well?
<thumper> RenatoSilva: sure
<RenatoSilva> ah ok
<RenatoSilva> thumper: to carry the repo home by email or pendrive is more easy procedure than pushing twice, isn't it?
<thumper> is it?
<RenatoSilva> thumper: I imagine it's just about copying the files
<garyvdm> RenatoSilva: What thumper was saying is that you can set up you home server so that when you push to it, it automatically pushes to launch pad
<RenatoSilva> thumper: keep my PC online is a non-go
<RenatoSilva> garyvdm: ^
<RenatoSilva> garyvdm: oh...
<RenatoSilva> garyvdm: I see
<thumper> RenatoSilva: ok, in which case a pen-drive repo is a good idea
<RenatoSilva> garyvdm: seems nice
<garyvdm> thumper: - I think you would need to use a on tip change hook to do that.
<RenatoSilva> Does a push push the history, or does it work like a "commit" of the local HEAD?
<thumper> garyvdm: sure, but it'd work
<SamB> RenatoSilva: it pushes history, yes
<thumper> RenatoSilva: push pushes all the revisions that the remote repo doesn't know about
<RenatoSilva> SamB: oh, nice then
<RenatoSilva> Now I can forget BitBucket
<SamB> but if you had any uncommitted changes, it would not push them
<RenatoSilva> SamB: ok, we just have to commit locally before pushing...
<SamB> which is generally a good thing, unless you lose the working directory ;-)
<RenatoSilva> Is bzr easy to learn? If I read a quick guide (where?) in 20 minutes, would I be able to set up a project in launchpad and do the basics (including the above procedure)?
<garyvdm> RenatoSilva: Oh yes
 * garyvdm finds url to quickstart guide
<garyvdm> bzr in 5 min: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<thumper> what format string should I use for a new bbc format with the 1.16rc for `bzr init-repo --no-trees --2.0?`
<RenatoSilva> garyvdm: thank you, I just found it at the same time. I hope it's enougth
<Peng_> thumper: --2a maybe?
<Peng_> thumper: What do you mean?
<RenatoSilva> is http://bazaar-vcs.org/BzrEclipse usable?
<RenatoSilva> stable?
<thumper> Peng: I mean that I used to say --development-rich-root
<thumper> Peng: but now we have an alpha format
<thumper> Peng: I was wondering what the short name is for the init-repo commadn
<garyvdm> RenatoSilva: I believe so. (I don't use Eclipse)
<garyvdm> RenatoSilva: you may also want to look at http://bazaar-vcs.org/QBzrEclipse
<RenatoSilva> garyvdm: ok thanks
<RenatoSilva> ok, I'm leaving. Thank you guys for the help. Bye.
<jml> poolie: I guess you missed my earlier ping.
<poolie> hi
<poolie> was on the phone
<poolie> talk in 15m?
<poolie> or maybe just now?
<igc> abentley: please bounce bb when you get a chance
 * igc lunch
<garyvdm> igc: Please can you subscribe to the qbzr mailing list with you @internode.on.net addresses so that we we have to manually approve messages sent with that address?
<garyvdm> *your
<garyvdm> + a don
<garyvdm> + a don't in there somewhere...
<fullermd> Speaking of qbzr...
<fullermd> I had qlog croaking yesterday...
<garyvdm> fullermd: On the latest of lp:qbzr?
<poolie> jml, when you file bugs, please mark them confirmed and set some reasonable priority
 * fullermd checks to see if it's repeatable.
<poolie> someone else can always override you if they disagree
<garyvdm> fullermd: maybe bug 386618
<ubottu> Launchpad bug 386618 in qbzr "[regression] qlog FILE is broken for files from qbzr src (trunk revno.770)" [Critical,Fix committed] https://launchpad.net/bugs/386618
<poolie> like bug 387117
<ubottu> Launchpad bug 387117 in bzr "ListOption doesn't respect param_name" [Undecided,New] https://launchpad.net/bugs/387117
<jml> poolie: ahh ok.
<fullermd> Hm.  Well, it doesn't do it now...
<jml> poolie: bzr doesn't use the New status as a drive-to-zero style inbox then?
<fullermd> Yeah, going back to r774 gives what I remember.  So I guess it's fixed  :)
<garyvdm> :-)
<igc> garyvdm: done
<garyvdm> thanks
<poolie> jml, in practice no
<poolie> i have mixed feelings about whether we should
<poolie> however, whatever we're doing with it, there's no point having another roundtrip when a developer files a bug to classify it
<poolie> any of us including you can make an assessment of a bug we're filing
<jml> :D
<bialix> hi, I want to use http://en.wikipedia.org/wiki/Bazaar_(software) to improve Russian wikipedia page. Can somebody confirm this page is enough up-to-date?
<bialix> garyvdm: hi
<garyvdm> Hi bialix
<bialix> I'm thinking about your revision selector
<bialix> your approach is interesting, I'm just want to ask why we don't want to use existing qlog for this?
<garyvdm> Yes - that is a option.
<bialix> e.g. when user need to select revision then we open separate qlog-like window and allow to select revision or range of revisions there?
<garyvdm> igc also had some ideas regarding this.
<bialix> we can remove some elements, e.g. search
 * bialix looks
<bialix> do you have bug number by hands?
<garyvdm> I'm not sure If loged a bug - let me see
<bialix> poolie: around?
<bialix> garyvdm: it's indeed files
<bialix> filed
<bialix> Bug #328598
<ubottu> Launchpad bug 328598 in qbzr "Create a revisions selector widget. Use in commands like push/pull." [Medium,In progress] https://launchpad.net/bugs/328598
<bialix> well, using igc suggestion it's really make sense to create separate window to select
<bialix> while I'm not sure about date
<garyvdm> So whether we display a dialog or a custom widget in a combo box does not mater too much
<bialix> why somebody need date when there is full log?
<garyvdm> The latter is easer.
<bialix> um, no the difference is huge
<bialix> qlog-like dialog allow you to browse revisions, see their details and get the diff
<bialix> everything like in qlog
<bialix> IIUC combobox only allow you to see summary for revisions
<garyvdm> He want's the date option so we cater for people who have branches that take a very long time to load like mysql/ooo
<garyvdm> bialix: yes - a dialog gives a more space to work with.
<bialix> ah, this makes sense for Date then
<garyvdm> I'm thinking in my mind: tabs at the top to select Revno (log) | Date | Tag | Other (branch:, submit: etc)
<pygi> garyvdm: tabs are evil :-/
<bialix> such construct is better suited for separate dialog IMO
<bialix> pygi: not in this case
<garyvdm> LineEdit at the bottom to the left of the ok button - which shows you what you have selected/can edit manualy.
<garyvdm> Hi pygi
<garyvdm> bialix: do you have any gdb skills
<bialix> LineEdit is OK
<bialix> a bit
<igc> hi bialix, pygi, garyvdm
<bialix> hi igc
<bialix> glad to see you
<bialix> I hope you're better
<igc> bialix: I am thanks
<bialix> igc, you send some mails from you internode account
<bialix> this address is not subscribed to qbzr ml
<igc> bialix: it should be now
<bialix> I've tried to subscribe you directly but can't
<bialix> ok
<garyvdm> bialix: ha ha - I asked igc to subscribe that acocunt just now :-)
<igc> thanks to garyvdm pointing that out earlier :-)
<bialix> garyvdm: :-D
<bialix> igc, can you confirm http://en.wikipedia.org/wiki/Bazaar_(software) this page is good enough to use for translation to Russian?
<bialix> we desperately need to improve Russian wiki page
<bialix> it's hard to write something original in wikipedia, so I've decided to just translate English one
<garyvdm> bialix: I'm getting a segfault with some code I have written. I can't figure out how to get gdb to give me a stack trace.
<bialix> segfault or traceback?
<garyvdm> bialix: I can spot 1 error - I think bzr-git is more advanced than it claims.
<bialix> hmmm
<garyvdm> I'm getting a segfault - and I want to get a trackback for that segfault
<bialix> I'm not sure I understand correctly
<bialix> usually when you get segfault the python died, is not?
<garyvdm> Yes \
<bialix> so you can't get traceback
<garyvdm> Apparently you can with gdb - but I can't figure out how.
<bialix> oh
<bialix> sorry
<bialix> I've misread first time
<bialix> gdb, not pdb
<bialix> no, sorry
<garyvdm> Ok - never mind - I should probably go and read the manuals....
<bialix> my linux skills is rather small
<igc> bialix: that page looks ok to me
<bialix> so I'll translate it, thanks igc
<garyvdm> The code that is segfaulting: lp:~garyvdm/qbzr/trees - run qbrowse - expand a folder.
 * bialix looks
<bialix> igc, do you have experience in building deb packages for PPA?
<igc> bialix: no sorry
<lifeless> igc: ping reminder on command hooks
<bialix> garyvdm: segfault on windows too
<bialix> you did something bad with PyQt I guess
<igc> lifeless: sure. next on my list after looking at an eol bug report
<bialix> usually to segfault python one have to deal with C-extansions
<bialix> maybe incorrect usage of malloc/free
<bialix> maybe you try to read data that was deleted from memory
<bialix> or outside bounds of array
<bialix> garyvdm: thanks for fixing regressions, I'm unblocked now
<bialix> we need to think hard about unittesting
<garyvdm> bialix: sorry about those.
<bialix> I've used another branch to commit, in the end we have DVCS!
<garyvdm> Yes re unit tests
<garyvdm> There is just so many to be written - It is quite daunting.
<bialix> yes, a bit
<bialix> how to eat the elephant?
<garyvdm> I spent about 3 days writing tests for loggraphprovider, and I only covered the first 2 methods :-(
<bialix> this is disapponting, I know
<garyvdm> Ok - so I very new a writing tests.
<bialix> ask vila for help
<garyvdm> vila helped me alot at uds!
<bialix> vila likes tests
 * bialix summons vila!
<bialix> nope, does not work
<bialix> ok, Gary I have to go to work, see you later
<garyvdm> Ok - bye
<igc> lifeless: I'll get on to that Command.hooks re-review now
<RenatoSilva> in CVS each dir is a module. In Bazaar, each dir is a branch?
<luks> no, branch is a directory
<RenatoSilva> then yes, don't?
<RenatoSilva> are sub dirs of the branch branches themselves?
<luks> I meant to point out that it's the other way around :)
<RenatoSilva> sub dirs of a CVS module are modules themselves.
<luks> so no, not every directory is a branch
<luks> but every branch is a directory
<lifeless> bzr is nothing like CVS :)
<RenatoSilva> what's a module / project in CVS repos? It's just a dir in the repo tree. Is this the same with Bazaar or other tools?
<RenatoSilva> luks: ok I've got it
<luks> there isn't anything like that
<luks> in bzr you generally work with the filesystem
<luks> so if you want to group branches, you can use a directory
<RenatoSilva> it seems that branches are like the CVS repos themselves, not their modules
<luks> you can't really compare cvs and bzr
<RenatoSilva> ok
<vila> hi all
<poolie> hi vila
<vila> hi poolie !
<lifeless> igc: I replied
<lifeless> igc: one more from you should do it
<igc> hi vila!
<lifeless> igc: ping
<lifeless> igc: See above
<igc> lifeless: looking now
<lifeless> danke
<lifeless> EODing
<lifeless> poolie: check is refactored to ~ where I want it; tuning somewhat now - reconcile's core needs fixing too, and the performance is odd - tracking down details now.
<poolie> night lifeless
<RenatoSilva> where is the output files for bzr init?
<RenatoSilva> where are
<RenatoSilva> oh bzr is smart, .bzr is /ah under windows
<RenatoSilva> is there any problem if I remove the hidden gflag?
<RenatoSilva> flag
<vila> RenatoSilva: I don't think that will be a problem, but if you encounter one: 1) Restore it, 2) File a bug
<Spabby> good morning bzr experts
<vila> Spabby: hi
<poolie> vila, i'm writing up a patch for the bug process stuff
<vila> poolie: cool
<Spabby> can anyone help me install the automirror plugin please? I have followed the instructions for installing plugins on the bzr website and also in the readme but I cannot get it working!
<vila> Spabby: can you elaborate ? Note that I don't know the plugin, but we'll see
<Spabby> yes
<Spabby> one second sorry
<Spabby> firstly it says to install to ~/.bazaar/plugins and the directory didn't exist
<Spabby> so I created the directory
<Spabby> and copied the automirror directory there
<Spabby> I then added the post_commit_mirror parameter to the branch.conf file
<Spabby> but when I commit nothing happens
<vila> Spabby: do you have bzr installed on the remote server ?
<Spabby> yep
<Spabby> if I commit to the remote server it works fine
<Spabby> and if I do a bzr update on the remote server that also works great
<vila> Spabby: more importantly (as far as I understand the plugin intent), do you have a remote branch there ?
<Spabby> yes
<vila> did you look at your .bzr.log file ?
<Spabby> ah
<Spabby> no
<Spabby> is that in the .bzr dir?
<vila> 'bzr version' will tell you where it is
<Spabby> ah
<Spabby> I suspect the plugin is in the wrong place ;)
<Spabby> no it looks right
<Spabby> should it list plugins installed after "looking for plugins" line?
<RenatoSilva> what's this output in $bzr launchpÃ¡d-login?
<RenatoSilva> [-                   ] https >      0KB     0KB/s |
<lifeless> jml: argh; could you please make sure the RM notes make it clear to preserve NEWS headings?
<vila> Spabby: 'bzr plugins -v' should answer that
 * igc dinner
<lifeless> jml: otherwise everyone landing stuff collides for the first period after; and hilarity *doesn't* ensue.
<vila> RenatoSilva: it's an artifact of the progress reporting, I think there is already a related bug on launchpad.net for it, but may be not for the launchpad-login command
<Spabby> super duper the plugin is installed
<Spabby> right so it must be the config that is borked
<RenatoSilva> vila: I only receive this output, and push is not working
<RenatoSilva> I don't know if I'm authenticated or not
<vila> RenatoSilva: Are you behind a firewall ?
<RenatoSilva> I'm at home
<RenatoSilva> hum let me see
<vila> RenatoSilva: some homes come with firewalls :)
<RenatoSilva> on the windows :)
<Spabby> this is frustrating the hell out of me, it should be so simple!
<RenatoSilva> vila: what is the exact process to allow
<RenatoSilva> bzr.exe? pageant.exe? putty.exe?
<vila> RenatoSilva: Ha :-/  Relevant bug is #186920 I think
<vila> ubottu: bug #186920 ?
<Spabby> can I update a remote branch using bzr?
<ubottu> Launchpad bug 186920 in python "bzr launchpad does not handle proxy when used for name resolution " [Unknown,Confirmed] https://launchpad.net/bugs/186920
<Spabby> please?
<vila> Spabby: As long as you're not using lp, yes
<vila> :-/
<Spabby> i mean I can ssh in and do an bzr update
<Spabby> but can I do it locally or do I have to do that
<RenatoSilva> vila: what is the process to allow? pageant? bzr? putty?
<vila> Eerk, sorry guys, Spabby: forget my last message
<vila> RenatoSilva: sorry, I meant proxy, not firewall
<Spabby> ok I have written a bash script that will commit changes and update remote host, it will do!
<RenatoSilva> No proxy. I deactivated firewall and it didn't worked
<spiv> Spabby: you might like to try the push-and-update plugin
<Spabby> spiv, I'll be honest I don't understand the difference between "push" and "commit"
<spiv> Spabby: or perhaps the bzr-upload plugin
<spiv> Spabby: https://launchpad.net/bzr-push-and-update and https://launchpad.net/bzr-upload
<vila> RenatoSilva: what does your .bzr.log file say ?
<LarstiQ> Spabby: commit creates a new revision, push publishes it
<spiv> Spabby: commit adds a new revision to a branch with the contents of your working copy on disk.  push updates one branch from another branch.
<RenatoSilva> vila: where?
<Spabby> ok so I definitely want to be using commit
<vila> RenatoSilva: 'bzr version' will tell you
<Spabby> as I want to be working locally until a module is complete then committing it to the central repo
<RenatoSilva> vila: is this log cleanned from time to time btw?
<vila> RenatoSilva: yes
<vila> RenatoSilva: renamed to .bzr.log.old to be precise, and .bzr.log.old is deleted if present at that time
<RenatoSilva> for lp login: failed to import pycurl: No module named pycurl
<RenatoSilva> failed to instantiate transport <bzrlib.registry._LazyObjectGetter object at 1034800, module='bzrlib.transport.http._pycurl' attribute='PyCurlTransport'> for 'https://launchpad.net/': DependencyNotPresent(Unable to import library "pycurl": No module named pycurl)
<vila> RenatoSilva: shouldn't be a problem, what bzr version are you using ?
<RenatoSilva> 1.15-2
<vila> RenatoSilva: that's strange anyway, I thought the windows installer included pycurl
<vila> RenatoSilva: how did you install ?
<RenatoSilva> for push: http://pastie.org/512276
<RenatoSilva> vila: hum, 1.15-2 is a self-extracting zip
<LarstiQ> RenatoSilva: is this still about 'command-line: line 0: Bad configuration option: ClearAllForwardings
<LarstiQ> ?
<RenatoSilva> y
<LarstiQ> RenatoSilva: then fix your openssh config :P
<LarstiQ> although bzr might be passing that option in
<LarstiQ> RenatoSilva: according to the log you pasted, openssh is used, not putty/pageant
<RenatoSilva> how do I see the ssh client?
<RenatoSilva> set
<spiv> Yes, bzr will pass that option in if it is spawning openssh.
<RenatoSilva> it seems that I need some python dependecies, pucurl etc
<RenatoSilva> pyculr
<RenatoSilva> pucurl
<spiv> pycurl is an optional dependency.
<RenatoSilva> pycurl!
<LarstiQ> RenatoSilva: no, you can ignore pycurl
<Spabby> not bzr related at all but can you remember the name of the scripting software that allows you to basically record your command line as a macro?
<Spabby> mental block
<RenatoSilva> paramiko and pycrypto too?
<Spabby> its ok I remember, it's expect
<LarstiQ> RenatoSilva: those two are pretty essential for ssh
<RenatoSilva> maybe I should try the installer 1.15-1 instead of my 1.15-2
<spiv> IIRC paramiko is only necessary for SFTP (as the actual SSH bits can be done with openssh/putty/whatever).
<spiv> And IIRC pycrypto is only necessary for paramiko.
<spiv> I'm curious about which version of OpenSSH you have that doesn't recognise the ClearAllForwardings option, though.
<RenatoSilva> how do I set the SSH client?
<lifeless> spiv: it may be an ssh.com version or some such
<spiv> lifeless: right
<LarstiQ> RenatoSilva: BZR_SSH=plink
<spiv> lifeless: (although we try to detect that too, IIRC)
<LarstiQ> RenatoSilva: environment variable
<RenatoSilva> LarstiQ: shouldn't it be the full path?
<spiv> RenatoSilva: set the BZR_SSH environment variable to one of paramiko, openssh, ssh, plink.
<LarstiQ> RenatoSilva: no, just the type (paramiko, openssh, ssh, plink)
<spiv> RenatoSilva: I'm curious, what does "ssh -V" report?
<RenatoSilva> LarstiQ: bzr: ERROR: [Error 2] O sistema nÃo pode encontrar o arquivo especificado (file not found)
<spiv> RenatoSilva: I guess plink.exe isn't on your %PATH% then.
<RenatoSilva> spiv: I only have ssh because of MSYS: OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
<LarstiQ> 2.9!?
<RenatoSilva> spiv: that's why I said: I need the full path!
<spiv> Ah, that is a pretty damn old OpenSSH
<spiv> RenatoSilva: why is setting %PATH% harder than setting %BZR_SSH%?
<LarstiQ> spiv: why is bzr_ssh not in `bzr help configuration`?
<spiv> (I mean, it would be nice if it were possible to specify a full path, but that feature doesn't exist yet.  Patches welcome!)
<spiv> LarstiQ: a bug, I guess.
<LarstiQ> spiv: yes :P
<RenatoSilva> spiv: I set the apth
<spiv> LarstiQ: also, for no good reason (probably just historical) it doesn't get looked up by the regular config machinery, i.e. you can't set it in bazaar.conf
 * LarstiQ nods
<RenatoSilva> The server's host key is not cached in the registry. You have no guarantee that the server is the computer you think it is. The server's rsa2 key fingerprint is: ssh-rsa 1024 ******.
<RenatoSilva> Connection abandoned. bzr: ERROR: Connection closed: please check connectivity and permissions
<spiv> LarstiQ: it's just environment or autodetect or default. (in that order)
<LarstiQ> RenatoSilva: do you have access to server logs? Are you using the correct user? Is the key you supplied allowed to login? etc
<spiv> RenatoSilva: so perhaps all that's needed is for you to manually do "ssh bazaar.launchpad.net" and accept the host key so it gets saved in the registry.
<RenatoSilva> I opened a session with PuTTY
<RenatoSilva> bzr: ERROR: Target directory lp:~renatosilva/+junk/solenoid-moin-theme already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
<RenatoSilva> it's better error now :)
<RenatoSilva> ooohhhh \o/ it's working
<spiv> RenatoSilva: cool
<RenatoSilva> spiv: I had to store the server keys
<RenatoSilva> my first branch \o/
<RenatoSilva> https://code.launchpad.net/~renatosilva/+junk/solenoid-moin-theme
<RenatoSilva> thank you guys, you are _so_ helpful
<RenatoSilva> btw: http://moinmo.in/ThemeMarket/Solenoid
<RenatoSilva> http://bazaar.launchpad.net/~renatosilva/%2Bjunk/solenoid-moin-theme/annotate/head%3A/htdocs/css/msie/style_ie8.css
<RenatoSilva> why does it show the 1st line only?
<lifeless> thats very odd
<lifeless> could you please file a bug at https://bugs.launchpad.net/loggerhead ?
<RenatoSilva> lifeless: it seems that for some reason the file has Mac-style  line breaks
<spiv> RenatoSilva: mention that in the bug report :)
<RenatoSilva> spiv: this is a dump of the file "/* Width was too short */\rdiv.wrapper
<spiv> RenatoSilva: I can see the file content already... a bug report is what's needed at this point.
<RenatoSilva> spiv: https://bugs.launchpad.net/loggerhead/+bug/387225
<ubottu> Launchpad bug 387225 in loggerhead "File content not entirely displayed" [Undecided,New]
<RenatoSilva> I will commit the windows-line-break version
<RenatoSilva> how do I link to the bug?: the complete URL?
<lifeless> spiv: http://bazaar.launchpad.net/%7Erenatosilva/%2Bjunk/solenoid-moin-theme/revision/1 does the file list look like it has something odd at the top to you?
<lifeless> RenatoSilva: link to it where
<RenatoSilva> in the commit comment
<RenatoSilva> This change is because of this bug: xxx
<lifeless> however you like :). you can also say '--fixes lp:<number>' in the command line when you commit
<RenatoSilva> in eclipse you can put just 'bug 123', when shown in bugzilla a link is created to that bug
<ubottu> Launchpad bug 123 in rosetta "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123
<RenatoSilva> lifeless: the commit doesn't fix, but is caused by the bug :)
<james_w>  
<lifeless> RenatoSilva: oh right. In Ubuntu the convention is
<lifeless> LP: #<Number>
<RenatoSilva> who told ubottu to write that?
<spiv> lifeless: yes
<RenatoSilva> bug 12345
<ubottu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
<RenatoSilva> oh
<james_w> RenatoSilva: if you say "bug <number>" in a bug comment then it is linked correctly, perhaps loggerhead could do that too
<james_w> in fact, I think it's done for the comments that LP shows on the branch page, it's just because loggerhead is a bit separate that it doesn't currently
<RenatoSilva> is a bug id unique among the projects?
<james_w> in launchpad, yes
<spiv> lifeless: there's an empty <li class="files"></li> that's causing it, I think.
<lifeless> the root perhaps
<lifeless> anyhow bug sent
<spiv> Yeah.
<lifeless> LarstiQ: so, know where jelmer is?
<spiv> lifeless: in fact almost certainly the root, judging from how it renders other directories.
<RenatoSilva> james_w: so I can just type exactly "Thsi commit is because of bug 387225."
<ubottu> Launchpad bug 387225 in loggerhead "File content not entirely displayed" [Undecided,New] https://launchpad.net/bugs/387225
<spiv> lifeless: "/" shows along with other files as something you can click & expand to see changes.
<james_w> RenatoSilva: yeah, it won't do anything yet, but it probably should :-)
<spiv> Anyway, that's enough internet for the evening...
<james_w> RenatoSilva: you may also want to use the "--fixes lp:" thing, as that tells LP to link the branch and the bug
<RenatoSilva> actually, "Launchapd bug"
<RenatoSilva> james_w: the branch is not a fix
<james_w> ok, then don't :-)
<lifeless> spiv: bug 387227 if you want to comment
<ubottu> Launchpad bug 387227 in loggerhead "odd rendering of files list" [Undecided,New] https://launchpad.net/bugs/387227
<RenatoSilva> hwo to store a default merge location?
<RenatoSilva> RenatoSilva:  --remeber.
<RenatoSilva> Is this stored under my prefs or under the branch?
<RenatoSilva> tiased: the branch
 * RenatoSilva read the 5-min tutorial in a few hours o.O
<RenatoSilva> thank you guys, I'm leaving, bye.
<lifeless> ciao
<LarstiQ> lifeless: no, last time I saw him was previous saturday in Amsterdam. I have noticed him being on irc less lately.
<gioele> hello.
<gioele> Is it me or the PPA has not been updated for bzr 1.15.1?
<gioele> I see 1.14.1 and 1.15 only
<LarstiQ> you are right. The beta ppa has 1.16-rc1
<fullermd> How odd.  the MD5 for the 1.16rc1 tarball is a dead link...
<fullermd> And bzrtools too.
<bialix> igc: ping
<bialix> igc: is this branch still needed? https://code.launchpad.net/~ian-clatworthy/qbzr/explorer-prototype
<igc> bialix: no
<bialix> mark it as abandoned please
<igc> bialix: I can delete it if you like
<igc> bialix: ok
<bialix> thx
<bialix> btw, qversion in the trunk
<bialix> luks: I see you have uploaded packages for qbzr 0.11, thank you. We need packages for 0.12 too, because it's version compatible with bzr 1.16
<TheJosh> Hi I am having some problems with some scripting with bazaar
<TheJosh> I am making a PHP script which merges in changes from one branch to another
<TheJosh> but exec, shell_exec and friends don't return any script output - even though when I execute these commands in my shell they actually return output
<TheJosh> How can I get the output out of these commands?
<lifeless> it may be that the output you're looking for is on stderr
<fullermd> As is customary, the PHP manual tells you everything but what you care about, but AFAIK all those commands give you stdout, but not stderr.
<lifeless> most chatter is on stderr
<fullermd> And in some cases, bzr might give you different output if it's not run on a terminal, I'm not sure.
<TheJosh1337> so why does bzr output to stderr? Isn't stderr for, like errors?
<TheJosh1337> and can you trick bzr into thinking it is a terminal? set TERM env or something?
<lifeless> stderr is for output that isn't the main output
<fullermd> Try using proc_open().
<TheJosh1337> When I run the command with 2>&1
<TheJosh1337> I get the output, but I get other junk too
<TheJosh1337> No handlers could be found for logger "bzr"
<TheJosh1337> [27093] 2009-06-15 21:38:58.811 INFO: Nothing to do.
<TheJosh1337> Nothing to do.
<fullermd> (of course, like most PHP executing functions, that still calls a shell for the execution.  Sigh.  A continuing irritatnt...)
<lifeless> thats very odd output
<TheJosh1337> what is this 'logger "bzr" stuff'. I don't want that
<TheJosh1337> I guess I can regex it out but that's a bit crappy
<lifeless> we use python's logging facilities to do output
<lifeless> something is causing bzr's setup routines not to run
<lifeless> or it may be related to trminal detection (but even then we should setup a logger)
<lifeless> you can fool bzr yes, it honours TERM etc
<TheJosh1337> so If I set TERM=bash, that might fix it?
 * fullermd doesn't see that in his termcap...
<TheJosh1337> hmm
<TheJosh1337> TERM=xterm
<TheJosh1337> that will fool it
<fullermd> Something like vt100 is usually the LCD, but yah, that'll work fine.
<fullermd> Probably doesn't matter too much unless you get exotic.
<TheJosh1337> setenv('TERM=vt100') doesn't fix it. I'll have to try with proc_open which allows setting env vars
<AfC> I just upgraded a bzr.dev in format "pack-0.92" at revno 3638 to "1.14" and 76.7 MB later pulled to revno 4441. And it completed. How about that.
<fullermd> I'd guess the std{err,out} issues are more likely to be your issue than terminal detection, though.  I'd try with just that first.
<TheJosh1337> I changed my code to use proc_open and now it doesn't return anything at all
<TheJosh1337> can I set the logger somehow, so it doesn't throw the stupid messages?
<lifeless> TheJosh1337: file a bug about the messages please. Also what version of bzr are you using?
<TheJosh1337> 2.6.21
<TheJosh1337> my bad
<TheJosh1337> 1.6.1
<TheJosh1337> that's quite an old version isn't it.
<fullermd> Fairly, yah.
<TheJosh1337> I am running Ubuntu Intrepid
<TheJosh1337> I guess its time to upgrade to Jaunty
<TheJosh1337> well im off then - Have an upgrade to do
<TheJosh1337> cya
<GPHemsley> How do I change the push branch listed in `bzr info`?
<lifeless> bzr push --remember <URL>
<GPHemsley> thanks
<gioele> lifeless: is there another way to set the push branch location?
<AfC> gioele: $ vi .bzr/branch/branch.conf
<lifeless> gioele: bzr help configuration
<gioele> lifeless: ah, great. I'm adding that to the Location wiki page
<gioele> difference between the public and the submit branch? Both seem to be used by the 'bzr send' command
<fullermd> Y'know, it may be time to stop having a separate section in there for branch6...
<vila> jelmer: ping, unless we chat, I'm afraid we will stay out of phase :-) I'm sure we're close to agreeing though :)
<jelmer> vila: hi!
<jelmer> vila: Did you see my last reply?
<cyberixae> Does bazaar always retrieve full history of a branch, when I branch from it?
<jelmer> cyberixae: if you don't specify --stacked, yes
<SamB> jelmer: well, if he creates a new branch in the same repository, there is no need for it to do any fetching, is there ?
<cyberixae> "The new branch will depend on the availability of the source branch for all operations."
<cyberixae> "all operations"?
<SamB> jelmer: got my patch, btw?
<cyberixae> What is the point of having one then?
<jelmer> SamB: yep, it's already in the 0.6 branch
<jelmer> SamB: thanks
<SamB> no problem
<SamB> it was an easy fix
<cyberixae> Look, our project has some big files in the main branch and I was considering to move them out of the way into another branch and deleting them from the main branch.
<cyberixae> But this is useless, if the history is downloaded everytime anyway
<cyberixae> Is this correct?
<SamB> well, not quite useless
<SamB> at least you wouldn't have to have them in the working directory then!
<SamB> but yeah, they'd still get downloaded
<cyberixae> the speed of download and amount of disk space were the concerns here.
<SamB> well, not having it in the working directory would obviously save some disk space
<SamB> but not really any download
<cyberixae> why?
<cyberixae> the version history is compressed?
<SamB> well, probably
<cyberixae> But the files are compressed already anyway
<SamB> but what I mean is that instead of having the copy in the history *and* the one in the directory, you'd just have the one in the history
<cyberixae> we have some jpegs, mp3s and oggs in there
<SamB> ah.
<SamB> if this were #git, I might be suggesting "git filter-branch"
<SamB> ... does anyone know of something like that for bzr?
<bialix> oh great masters of [bzrlib] unittesting! can you say me how to test NotBranchError?
<bialix> SamB: you mean fast-import-filter
<jelmer> bialix: test what about it?
<jelmer> bialix: btw, any news on your bzr-git windows porting effort?
<bialix> jelmer: I'm writing helper method for qbzr to open working tree and show errors NotBranchError/NoWorkingTree errors in GUI
<bialix> IIRC there is fake tree created at temp dir root
<bialix> so how can I force NotBranchError in my unit test?
<RenatoSilva> can a branch contain anotehr branches?
<jelmer> bialix: there shouldn't be a fake tree created at the temp dir root
<bialix> jelmer: re bzr-git: it means your bzr<->git roundtripping means for me that I should wait until each my patch lands before I can start to work on next one
<jelmer> bialix: the bzr testsuite relies on that not being the case
<jelmer> bialix: I think you mean *lack* of roundtripping, with roundtripping there wouldn't be a problem :-)
<bialix> I mean rebasing
<jelmer> bialix: You can send me multiple patches in one go though, as long as you don't have any unpublished work based on the stuff you've sent me
<igc> bialix: bug 387241 is fixed now
<ubottu> Launchpad bug 387241 in bzr-explorer "bzr explore fails to open branch with out-of-date working tree" [High,Fix released] https://launchpad.net/bugs/387241
<RenatoSilva> can I tag a previous revision?
<igc> bialix: but qgetupdates doesn't work
<bialix> jelmer: you've rejected my test script, it was a little blocker for me. and then I digressed on other things
<igc> bialix: there's a radio button to refresh the working tree, it runs, it completes but the OutOfDateTree exception doesn't go away
<bialix> igc: hm?
<bialix> gile a bug?
<bialix> igc: I'm about to finish simpler qupdate dialog
<jelmer> igc: qile a bug ? ;-)
<bialix> :-P
<bialix> s/gile/file/
<igc> bialix: shall do. why qupdate when qgetupdates already exists?
<bialix> qgetupdates is too much for this IMO
<bialix> it's a swiss knife
<bialix> what does not work actually?
<igc> qgetupdates seems to update the *branch* but not the working tree
<bialix> jelmer: how you mock GTK widgets for testing?
<bialix> igc: there is radio button with 2 variants
<bialix> second variant should update wt
<jelmer> bialix: I think we basically create them but don't call show
<igc> bialix: maybe qgetupdate just needs more options put into an extension panel
<jelmer> bialix: but jam should be the expert on that, he did the testing stuff
<bialix> igc: qgetupdates and qgetnew designed by Mark Hammond
<igc> bialix: anyhow, I'll file a bug
 * SamB wants "bzr clog"
<bialix> clog for what?
<bialix> jelmer: did you see my email about saved commit data?
<SamB> bialix: color log
<bialix> ah
 * bialix reads about unittesting in Qt but found QtTest approach a bit limited
<bialix> igc: q about English
<bialix> igc: you're using Adds, Modifies in bzr explorer view
<bialix> why not Added, Modified?
<bialix> just curious
<bialix> I want to understand difference
<igc> bialix: it should be Added, Modified - I'll tweak
<fullermd> No need to get tense about it   8-}
<RenatoSilva> I'm new to bzr. I tagged a specific revision, but when I commit or push, it stands that there's nothing to change. Why?
<fullermd> Well, you don't commit tags, so that's half the answer.
<fullermd> The other half is that push doesn't say when it pushes tags.  I think it just does anyway, but it may not if there aren't revisions to push too; can't remember.
<RenatoSilva> fullermd: that's why I also tried to push
<RenatoSilva> fullermd: it's kind of bug isn't it? for example...
<RenatoSilva> fullermd: I pushed 2 revisions, but 'forget' to tag rev 1 as 'RC_2009.6.14'
<RenatoSilva> fullermd: then I pulled the branch, tagged revision 1, and then I want the local and remote branch (in launchpad) to contain the new tag
<RenatoSilva> fullermd: maybe forcing the commit? how about it?
<bialix> igc: btw, I'm working with bzr explorer all day today. It's very nice shaping
<fullermd> There's no commit.  Tags are on a different timeline.
<fullermd> push probably _should_ push the tag anyway, even if there are no new revisions.  It may; I don't remember.
<fullermd> Did you check?
<igc> bialix: nice to hear
<bialix> I need qswitch very soon otherwise I can't work with my plugins
<bialix> I'm using lightweight checkouts for plugins
 * igc does his fix commit and push using explorer --gtk
<RenatoSilva> fullermd: how do I browse tags?
<igc> s/fix/first/
<fullermd> RenatoSilva: `bzr tags [$LOCATION]`
<RenatoSilva> fullermd: oh, bzr log
<igc> must be time for some sleep :-)
<fullermd> igc: Well, hopefully it was a fix too   ;)
<igc> fullermd: I guess it was :-)
<bialix> igc: look at new qupdate from bzr+ssh://bazaar.launchpad.net/~qbzr-dev/qbzr/qupdate/
<RenatoSilva> fullermd: I pulled it onto a new dir, and the tags is there...thanks
<RenatoSilva> I just can't see it trhough launchpad
<bialix> bzr tags -d lp:your-lp-url-here
<fullermd> LP may have the tags cached, I dunno.  But if they show up in a new pull, they're there, so it'll work out.
<RenatoSilva> bialix: as I've pulled and it had the tag, such command should work
<RenatoSilva> bialix: and works
<RenatoSilva> bialix: I can't see it through the web interface tough
<fullermd> That may be a LP bug.  Might try getting somebody there to check.
<RenatoSilva> a loggerhead bug maybe
<RenatoSilva> fullermd: https://bugs.launchpad.net/loggerhead/+bug/246739
<ubottu> Launchpad bug 246739 in loggerhead "tags are not available" [Wishlist,Triaged]
<igc> bialix: I'll took a look tomorrow sorry
<igc> night all
<bialix> ok, night
<balor> I have a patch in the middle of my tree that I'd like to revert.  Is there any way to just throw away that patch?  Or even better, just mark the patch as thrown away?
 * RenatoSilva found weird that he could push the tag without launchpad-login
<bialix> balor: shelve?
<balor> bialix: That seems to shelve all changes since the revision in the middle of the tree.  I just want to remove one revision from the revision history.
<bialix> oh, you can't
<balor> bialix: thanks
<bialix> you need to reqrite entire history
<bialix> reqrite
<bialix> rewrite
<bialix> rats
<balor> :)
<bialix> you can look at rebase plugin
<balor> So branch at -r n-1 and then replay -r n+1
<bialix> but old and new history will be incompatible after replay
<bialix> yes, something like that
<RenatoSilva> can I change commit comments?
<bialix> after commit?
<RenatoSilva> yes
<bialix> you can't
<bialix> history is immutab;e
<bialix> immutable
<bialix> you only can uncommit and then commit again with new message
<RenatoSilva> yes, thant's ok
<RenatoSilva> bialix: uncommit -r 10 for a range of 1..20 will uncommit all the 11..20 commits right?
<bialix> look at `bzr uncommit -h`
<RenatoSilva> it doesn't mention that
<bialix>   If --revision is specified, uncommit revisions to leave the branch at the
<bialix>   specified revision.  For example, "bzr uncommit -r 15" will leave the
<bialix>   branch at revision 15.
<RenatoSilva> my mistake sorry
<RenatoSilva> then it's like I tould you
<bialix> vila: ping
<vila> bialix: pong
<bialix> is there any way I can trigger NotBranchError in the tests?
<vila> raise NotBranchErro ? I think I don't understand the question, that's too obvious >-/
<bialix> ok, lets pastebin first
<bialix> http://pastebin.com/m1f001ece
<bialix> this test fails because error is not raised
<vila> right
<bialix> here is open_tree http://pastebin.com/m695017ea
<bialix> why?
<vila> because there is a workingtree ?
<bialix> in temp root?
<bialix> what should I do then?
<vila> bialix: try checking what WorkingTree.open_containing(directory)[0] is returning
<bialix> 1sec
<vila> bialix: in temp root ? that's strange, but put a breakpoint before open_containing and look there
<vila> or better put the breakpoint in your test and do 'pp self.test_dir' and look there
<bialix> it returns <WorkingTree4 of C:/tmp/testbzr-g8nxvt.tmp>
<bialix> as I remember bzrlib creates fake working tree at the temp dir root
<bialix> to prevent leaking tests outside testing jail
<vila> nope, fake repo, not fake wt AFAIR
<bialix> but in fact it's WT here
<LarstiQ> cyberixae: for a stacked branch, it does not download the full history when you branch it.
<bialix> should I intialize empty bzrdir then?
<LarstiQ> cyberixae: if you perform an operation that needs it, like, say, log, it will at that point contact the stacked-upon branch to retrieve it.
<LarstiQ> cyberixae: if that branch is no longer reachable, you can't log the revisions you didn't have in the first place
<vila> but open_containing search upwards by design, why don't you use open() instead ?
<vila> bialix: ^
<bialix> why I should?
<bialix> I'm using open_tree as substitution for WorkingTree.open_containig
<vila> bialix: well, open_tree docstring says: "Open working tree at specified directory." not 'specified directory or above'
<vila> bialix: ha ok
<bialix> ok, i'll change docstring
<vila> bialix: wow, you're right, I was wrong, bzr creates a working tree not a repo
<bialix> new docstring:http://pastebin.com/m289b92c0
<vila> bialix: cool
<bialix> vila: self.make_bzrdir does not help
<bialix> I'm getting NoWorkingTree with it
<bialix> so... it's imporssible?
<vila> what happens if you use /I/do/not/exist as a path ? still NoWorkingTree ?
<bialix> um
<bialix> let me check
<bialix> yep, it works
<bialix> thank you!
<vila> bialix: you're welcome
<bialix> I'm inventing simple mocks to testing qbzr
<bialix> I'm curious how you test bzr-gtk
<vila> bialix: way to go !
<vila> bialix: from memory: classes than can raise dialogs define a self.dialog_class that tests override with nockups
<vila> mockups even
<bialix> aha
<bialix> so I'm using something similar then
<vila> bialix: yup ;)
<bialix> oki
<bialix> woot!
<jam> morning vila
<vila> jam: hi ! Looking at your better heads right now
<vila> I mean reviewing
<jam> sounds good
<fullermd> Better head?  Is there something wrong with the one he has now?
<vila> fullermd: tsk tsk headS, we need more like him, so we multi-head him
<fullermd> Is that really advisable?  I'm of two minds about that...
<vila> two is bad, use three to avoid ties
<Tak> pff, good enough for zaphod...
<vila> jam: lp is driving me mad, there is a '_counters = [0,0,0,0,0,0,0]' in your code that doesn't appear in the mail for your merge proposal, grr
<vila> jam: I review it from your branch >-/
<jam> vila: well, I updated my branch a lot since the submission
<vila> Ha ! That explains a lot :) Well, so I review the good bits, right ?
<jam> so the original idea of whether we want it or not
<jam> is certainly present
<jam> the latest version has some bug fixes
<jam> and more optimizations
<vila> jam: for both implementations ?
<jam> vila: the test suite passes for both implementations... so yeah
<jam> I didn't do as many optimizations  for the python code
<jam> but it at least has the correctness fixes
<jam> There wasn't a lot of algorithm diff between python & pyrex
<jam> mostly just Dict/List tuning
<jam> oh, and heaps are quite a bit faster if you can use peek + heapreplace() rather than pop + push
<jam> since it doesn't resize the list
<jam> (possibly causing reallocs, etc.){
<vila> jam: review sent, I've got revno 4411 here
<jam> vila: yep, 4411 is my latest
<ronny> oh damn, missed jelmer again
<vila> jam: EOD for me then
<jam> vila: have a good night
<The_User|afk> Hi! After a bzr update some of my branches don't work anymore. I get errors when I try branch, log, checkout and some other command. I get "KeyErrors" and an Exception-Backtrace
<The_User> sorry, it works after a downgrade to 1.8
<dash> hmm
<dash> there is a guy in my office who is using git
<dash> our code is all in svn
<dash> i am wondering how i should pitch bzr to him
<dash> he doesn't seem like a git zealot, just a guy who heard there was a better thing than svn
<LeoNerd> I use bzr at work against a svn repo, largely so I have "bzr shelve"
<mneptok> dash: "SVN is a great system. Just like Eminem is a popular musical artist. You know, if we're in 2002."
<dash> mneptok: the issue is git, not svn :)
<mneptok> dash: sorry, i read "never heard"
<mneptok> there's nothing *worng* with git. you just have to accept is was built with a certain audience in mind. if you're willing to adjust your thinking to be that audience, it will work for you.
<mneptok> personally, i want my tools to match my workflow and mindset, not vice versa. bzr does that.
<Tak> well, bzr has a high command/interface correlation with svn
<Tak> e.g. svn revert blah => bzr revert blah || git checkout -- blah
<fullermd> Actually, I think one of the options to git reset is more like revert...
<dash> yeah, that was the main thing I came up with
<fullermd> (and another is like uncommit, and another is like pull...)
<dash> 1) 'svn foo' can be replaced with 'bzr foo' in nearly all cases 2) bzr gets by without history editing a lot better
<Tak> crossplatform usage?
<Tak> reduced inter-language fragility?
<Tak> do the dev tools you're using support either git or bzr?
<LeoNerd> I don't think any of my dev tools support svn, cvs, rcs or sccs either... yet still I manage :P
<Tak> I bet they do ;-)
<Tak> but either way, if they support bzr, that would be additional ammunition
<Laney> How do I break a lock if the break-lock command I'm told to paste throws an "Unsupported protocol" error?
<mneptok> dash: bzr also has professional paid support. git does not. you may never need it, but it's nice to know the net is there.
<fullermd> I'm sure you could find somebody good with git who'd be happy to take your money...
<james_w> Laney: against launchpad>
<Laney> james_w: right
<james_w> Laney: you ignore what it tells you to do and use a different URL instead
<james_w> bzr break-lock lp:~user/project/branch
<Laney> apparently I locked it 864 hours ago
<Laney> (u-d-t)
<Laney> ok that worked, thanks
<jelmer> hi Tak
<Tak> jelmer: hello
<Peng_> Pfft, can't diff while pulling. Darn dirstate lock.
<dash> mneptok: hm! an interseting point
<dash> anyway
<dash> the dev environment is eclipse on OSX
<dash> how's eclipse support these days
 * fullermd boggles.
 * Peng_ scrabbles.
<Peng_> Or something!
<fullermd> So I just updated my bzr.dev, which was 4 revs behind (those made today)
<fullermd> Combined, the commit mails for them, which include the diffs, come to about 150k.
<fullermd> The pack file pull created was 7 megs.
<Peng_> fullermd: Yeah, something has been wrong for a while now.
<Peng_> fullermd: Nowadays I pull from lp:bzr since it behaves normally and then http://bazaar-vcs.org/bzr/bzr.dev/ in case there's anything newer.
<Peng_> I wonder if it has to do with changes to make sure stacking or CHKs have all the necessary data which somehow screwed things up for other formats too.
 * Peng_ shrugs.
<Peng_> Someone should probably care about this, but that someone ain't me.
<Peng_> For me the annoying part is that it always transfers 5 MB (or 8 MB this time). I don't notice the disk space.
<fullermd> Hm, yeah.  branch'ing it off and pulling from lp:bzr gives a 400k pack.  That makes a lot more sense.
<Peng_> It's nice to know I'm not just crazy. :)
 * fullermd scribbles up an email.
<garyvdm> Currently when I try view a file in loggerhead on launchpad, I get "internal server error"
 * Peng_ starts running bzr pull with various -D options.
<garyvdm> e.g. http://bazaar.launchpad.net/~garyvdm/qbzr/trees/annotate/head%3A/lib/browse.py
<Peng_> garyvdm: There's some stacking-related bug.
<Peng_> garyvdm: At least that's the popular theory, IIRC.
<garyvdm> Peng_: is there a work around?
<Peng_> garyvdm: Don't think so.
<garyvdm> Is there maybe a cat page, I don't need annotate.
<garyvdm> Oh - there is a small little icon on the right hand side.
<Peng_> If you have some bandwidth, you can run "bzr cat" and annotate on remote branches.
<Peng_> Hehe, running bzr pull from a GigE connection is fun. :D
<garyvdm> Peng_: I'm posting a question to stack overflow, and I want to put a link to the code.
<Peng_> garyvdm: Ah.
<Peng_> fullermd: FWIW, I here's a log of pulls (just revision 4443) with various -D options (though I didn't combine them): http://cheezum.mattnordhoff.com/tmp/.bzr.log
<Peng_> Err, s/I //
<fullermd> May be a useful followup to my mail.
<Peng_> Where'd you send your mail? The list?
<fullermd> Yah.
 * Peng_ pokes at his mail client.
<solarion> any idea why bzr would eat up all my RAM and then go get itself OOM killed?
<SamB> solarion: because it was doing too much allocation?
<SamB> er, no idea!
<solarion> "Build phase:Adding file con"
<SamB> what were you doing ?
<solarion> bzr co --lightweight <repo with 4G of PDF files>
<Peng_> solarion: Would the file "con" happen to be larger than your RAM?
<solarion> it is effing annoying
<solarion> there it goes again
<ronny> jelmer: hi, aware of any rules when extending what object types dulwich gets? (i'd like to add some own stuff for my personal hacks)
<jelmer> ronny: basically just register in dulwich.objects
<ronny> jelmer: aware if git has any rules for those extensions
<jelmer> ronny: in dulwich.objects.type_map and dulwich.objects.num_type_map
<ronny> last time i asked that in #git they acted like i was xenu
<jelmer> ronny: I don't know what the C git implementation will do with objects of types it doesn't know about
<jelmer> ronny: dulwich will raise a KeyError I think if it encounters objects of types it doesn't know about
<jelmer> thumper, mwhudson: How hard would it be to do imports to a non-default repository format on launchpad?
<jelmer> thumper, mwhudson: (on a case-by-case basis)
<mwhudson> jelmer: we don't really have anywhere to store the information that there's a different format wanted for this import
<mwhudson> jelmer: it could be done, but would be work
<jelmer> mwhudson: ok
<jelmer> mwhudson: (some bzr-git imports will work into the 2a format, since it doesn't squash xml-invalid characters)
<mwhudson> jelmer: why do you ask?
<mwhudson> ah
<mwhudson> well, hopefully there will be a new default format fairly soon :)
<mwhudson> we can make all git imports 2a more easily
<SamB> do new SVN imports use bzr-svn yet?
<Peng_> jam: <3 for lp:~jameinel/bzr/1.15-pack-source
<jam> Peng_: did you test if it works for you?
<Peng_> jam: No. If you think it's safe enough, I'd be happy to, though.
<jam> Peng_: should be safe, the tests still pass :)
<Peng_> jam: OK, but if it is somehow broken, will it lead to tracebacks or horrible corruption?
<Peng_> The former is ok. The latter, not so much.
<jam> Peng_: if it was horribly broken, I suppose you could get some missing objects
<jam> like it wouldn't fetch a referenced text key
<jam> etc
<jam> you could always fill those in later if it was really bad
<jam> or you could just do  a test in a copy of your repo
<jam> and tell me if the download was correct :)
<jam> and not worry about using it 'live' as much
<jam> oh, and you can 'cp -rl' if space is a concern
<jam> (we don't append to pack repos, so they are fairly safe to hardlink)
<Peng_> Pulled 1933 KB. That's definitely an improvement over 8+ MB!
<Peng_> jam: I've already run "cp -ai" on the repo like 8 times today. 1 more isn't gonna hurt!
<Peng_> jam: Oh. I didn't check that it didn't horribly corrupt the repo, though.
<Peng_> jam: Want me to?
<jam> Peng_: as long as you can "bzr log -vp" the newly pulled revisions
<jam> I'm pretty confident
<Peng_> Argh, I already deleted it. :P
<jam> since that would have to extract all the data that we should have referenced
<jam> Peng_: well as you said, only 1MB :)
<Peng_> jam: Yeah, but now I have to copy the repo again
<Peng_> jam: "bzr log -vp -r -1" worked.
<Peng_> Will "bzr pack" completely eliminate the duplicate data?
<Peng_> Or whatever?
<jam> Peng_: yes
<jam> 'bzr pack' will remove the duplicates
<abentley> lifeless: in bzr.dev 4441, aliases now override main command names.  Concretely, "bzr help shelve" now uses the bzrtools version.
<pygi> jam: it seems that it also backs up previous packs
<pygi> I've seen cases where bzr pack doubles repo size...
<jam> pygi: rm .bzr/repository/obsolete_packs/*
<pygi> jam: I know :p
<jam> and yes, it is 2x the size until that gets cleaned out
<pygi> others don't tho :)
<jam> but I'm pretty sure Peng_ knows that, too :)
<pygi> jam: can't we get bzr pack clean? :P
<pygi> at least in 2.x, where we supposedly focus more on the UI :)
<Peng_> jam: Good to know. I'm probably too lazy to run around "bzr pack"ing everything, though... :P
<lifeless> abentley: I will file a bug immediately and look at it shortly.
<lifeless> abentley: to be clear; bzrtools has old-shelve which has an alias shelve?
<Peng_> jam: FYI, I ran "bzr check" too, and it was ok. (Bunch of inconsistent parents, but that's always the case.)
<Peng_> lifeless: "shelve1", not "old-shelve", but yes.
<lifeless> jam: morning
<lifeless> jam: still around?
<Peng_> I could swear I had reconciled that repo... where did the inconsistent parents come from? new revisions?
<james_w> morning lifeless
<james_w> morning poolie
<lifeless> Peng_: did it get upgraded to rich roots rececntly?
<Peng_> lifeless: Nope, still 1.9.
<Peng_> It's totally possible that I didn't ever reconcile it. I have a lot of repos lying around.
<poolie> hello all
<jml> poolie: hi.
<garyvdm> Hi poolie, jml
<jml> garyvdm: hi
#bzr 2009-06-16
<igc> morning all
<igc> hi garyvdm, jml
<garyvdm> Hi igc
<jml> igc: g'day
<thumper> nightly ppa is broken for bzrtools again
<thumper> bzr claims 1.17dev
<thumper> but package says 1.15ish
<thumper> and bzrtools from the ppa doesn't like 1.17 yet
<jml> thumper: yeah, I was going to ping you about that.
<thumper> jml: why ping me?  I don't do anything with the ppa
<jml> thumper: just in reference to our earlier conversation, is all.
<jml> istr it's either statik or james_w who maintains the ppa.
<thumper> I think it is james_w given the uploader :)
<james_w> aye
<thumper> james_w: is bzr.dev packaged as 1.16 or 1.17... ?
<james_w> bzr.dev is packaged as 1.15+ currently
<james_w> which is an oversight
<james_w> man, those tooltips on the branch listings are pretty irritating
<lifeless> jml: so, when do you want to get together for EP stuff?
<lifeless> jml: any afternoon this week would be good for me
<jml> lifeless: tomorrow is best for me.
<jml> lifeless: what time is good?
<jml> lifeless: also, wrt preserving NEWS headings -- I'm not 100% clear on what you mean.
<jml> lifeless: when I get clear, I'll be happy to patch the releasing guide.
<lifeless> jml: there are a number of headings like INTERNAL
<lifeless> they should exist, with no entries, under IN DEVELOPMENT
<jml> ahh ok
<lifeless> jml: tomorrow is fine
<lifeless> say after lunch? 1ish?
<jml> so when adding the IN DEVELOPMENT section back in, when merging the release branch back, the RM should also add in the empty headings?
<lifeless> yes
<jml> cool.
<lifeless> otherwise devs add the randomly
<lifeless> and we get order changes and conflicts and spurious new section names
<jml> that's easy enough.
<lifeless> yup :)
<jml> lifeless: 1ish is good.
<igc> bbl
<bialix> garyvdm: hi
<garyvdm> Hi bialix
<garyvdm> You are up early/late
<bialix> I have a question about Diff button in qlog when there is ext diff configured
<garyvdm> ok
<bialix> late
<garyvdm> Same :-)
<bialix> in Windows I see small button with triangle on it
<bialix> how you created it?
<garyvdm> Call button.setMenu
<garyvdm> see lib/diff.py line 118
<bialix> that's all?
<garyvdm> Yes
<bialix> yeah, I found this code
<bialix> and it's the same on Linux?
<garyvdm> Yes :-)
<bialix> nice
<bialix> I'm tinking about improving our Browse... button for selecting branch or merge directive
<garyvdm> allthough - it is not a narrow button when using the gtk style :-(
<bialix> I want to use the same approach
<bialix> how bad it in gtk?
<garyvdm> screenshot comming...
 * bialix waiting
<bialix> btw, what you think about adding simple support for gathering list of available branches on code page of project at lp?
<bialix> I've played with urllib2 and I think we can grab lp:urls from code page
<garyvdm> it use to look like this: http://garyvdm.googlepages.com/qlog.png
<garyvdm> now it looks like : ....
<garyvdm> busy uploading.
<poolie> garyvdm: you might like to look at python-launchpadlib too
<poolie> it's kind of poorly documented
<bialix> there is no pastebin for images, is it?
<poolie> but it lets you poke through basically the whole data model of launcphad
<poolie> hello btw
<bialix> hi poolie
<dash> bialix: imgur.com maybe
<garyvdm> bialix: my internet is just bad...
<bialix> crop just button from image
<garyvdm> dash: i'll try that
<bialix> to make image small
<poolie> lifeless, spiv, all, i'm going to close my mail client soon...
<garyvdm> http://imgur.com/HBbWZ
<garyvdm> imgur is cool dash
<poolie> so i'm looking for (a) moral support (b) pointers to anything you think i really must reply to
<garyvdm> bialix: basically the button is too wide.
<bialix> yep
<bialix> maybe explicit width settings will help?
<garyvdm> Yes - just have not really looked at it.
<bialix> poolie: launchpadlib has too much dependencies
<poolie> simplejson, wadllib, httplib2?
<bialix> +lazr.ui + oath
<lifeless> poolie: +1 :)
<bialix> + don't know what elase
<poolie> jml, could you run "bzr info http://bazaar.launchpad.net/~mbp/bzr/doc/"
<garyvdm> bialix: I've been think about qmain a bit, bit have been coding the tree widget refactoring mostly. I've made some good progress tonight.
<lifeless> poolie: uhm, nothing offhand that is critical
<poolie> i get a weird message about redirection
<bialix> garyvdm: I'm using Ian's bzr explorer, it' nice
<poolie> me too
<spiv> poolie: same, nothing I can think of needing your attention now.
<bialix> garyvdm: will be nice to have there your tree widget though
<bialix> garyvdm: why it has segfaulted?
<garyvdm> In parent() i was returning a valid index for the root - it should be an invalid index.
<spiv> poolie: perhaps try --no-plugins?  ISTR a bug report about weird redirections that turned out to be due to bzr-svn
<bialix> ah, ok
<bialix> garyvdm: I hope you will place folders at top, as in qbrowse
<bialix> garyvdm: this is most often used sort order for explorer-like tools
<garyvdm> Yes - and later be-able to control that by being able to click on the headings
<bialix> as you wish
<bialix> we need to show unknown/ignored there too, do we?
<garyvdm> Low priority at the moment.
<garyvdm> Yes
<garyvdm> If you are browsing a working tree.
<bialix> and maybe have ability to filter items by status all/versioned/modified/unknown/ignored
<garyvdm> yes - one widget to do all of that
<garyvdm> I've got my work cut out :-)
<bialix> cool
<garyvdm> QSortFilterProxyModel will be my friend for that.
<bialix> ah
<bialix> nice
<garyvdm> With special performances cases for workingtree unknown/ignored I assume.
<bialix> garyvdm: I've made attempt to look into QtTest lib (for testing Qt GUI).
<bialix> it's rather limited
<garyvdm> I don't think we need a silver bullet for test.
<bialix> re test: may be it makes sense to think how to separate GUI and logic/model
<bialix> so we can test logic/model easily
<bialix> QtTest is not even a bullet, IMO
<garyvdm> Yes thats way I started on tests for LogGraphProvider.
<jml> poolie: http://paste.ubuntu.com/196702/
<bialix> IIRC, there was desire to move it into bzrlib core?
<garyvdm> Yes
<garyvdm> It would be nice for bzr-gtk to reuse LogGraphProvider, but It would require alot of effort.
<garyvdm> Maybe I'll do it ....
<garyvdm> ... when I run out of things to do on qbzr
<bialix> ha ha
<bialix> garyvdm: can you add this at line 117 in diff.py:             self.menu_button.setFixedWidth(24)
<bialix> and check if in gtk style it's better now?
<bialix> width could be ~20
<garyvdm> Yes - it does look better
<garyvdm> but we need to make the width dynamic
<garyvdm> Maybe guess it as 1/2 the height?
<bialix> or maybe play wit Size Policy
<bialix> with
<garyvdm> ok
<bialix> 1/2 is ok for me
<bialix> it seems I need to get some sleep.
 * bialix ~
<RainCT> Hi
<RAOF> Howdie.
<RainCT> I think no, but just to be  sure, does bzr have something like "git branch"/"git checkout" (ie, several branches in the same directory)?
<Peng_> RainCT: No. There's some work-in-progress stuff. Co-located branches or something.
<RainCT> And like "git format-patch" neither, right?
<RAOF> bzr send
<jelmer> hey RainCT
<RAOF> And looms can work for some of the use-cases of multiple branches in the same directory.
<RainCT> jelmer: hey :)
<lifeless> as can a shared treeless repo
<lifeless> hi jelmer
<lifeless> jelmer: does tdb allow repeated keys?
<jelmer> lifeless: hi
<RAOF> Shared, treeless repo + checkout working tree is about it, just a bit more fiddly :)
<jelmer> lifeless: nope
<sensae> Hello
<sensae> How can I disable interactive login via ssh while allowing bzr commands through bzr+ssh?
<lifeless> man 5 authorized_keys documents it
<lifeless> under the AUTHORIZED_KEYS FILE FORMAT heading
<sensae> lifeless: Sorry, I believe I asked my question poorly. I shouldn't have said interactive - I didn't mean password-based login. I meant disabling any login that will spawn a shell. Launchpad seems to do something similar - if I try to ssh, it kicks me out with "No login shells.", but I can still run bzr+ssh commands.
<sensae> I'm trying to mirror that behavior on my own system.
<lifeless> sensae: I answered what you intended to ask
<lifeless> I wasn't talking about password vs non-password
<sensae> Ah, I see it further down. Thanks.
<mib_t7vnj1> Is it possible to change a commit author on a commit?
<lifeless> no; you can uncommit it and commit it again with a diferent author.
<mib_t7vnj1> Oh my
<krisfremen> umm, i just moved my branch from a linux box to a windows box, using cygwin, and i can't get diff to work
<krisfremen> everything else seems to work, except the diffs
<lifeless> krisfremen: does bzr status work?
<krisfremen> yes
<lifeless> what does diff seem to be doing wrong?
<krisfremen> it doesn't print anything
<krisfremen> bzr just exits and doesn't print anything at all
<lifeless> is there anything in the bzr.log
<lifeless> you can get the path for that from 'bzr --version'
<krisfremen> 1.666  return code 0
<lifeless> it thinks there are no differences
<krisfremen> http://pastebin.com/d69f6f59c
<krisfremen> but i just made a commit
<lifeless> well it wouldn't expect any changes after a commit
<sensae> lifeless: Do you know what option would give me the desired effect?
<lifeless> sensae: command=bzr serve --allow-writes
<lifeless> sensae: or something like that
<lifeless> I don't remember the exact command line
<poolie> thanks for the tip spiv, you're probably right
<poolie> yes, you were right
<poolie> i think it's fixed in a later release of bzr-svn
<sensae> lifeless: At this point, I'm stumped. Googling found "command="bzr serve --allow-writes --inet --directory=/"", and I'm having no luck.
<spiv> sensae: bzr asks ssh to run "bzr serve --inet --directory=/ --allow-writes", FWIW.
<spiv> sensae: see also contrib/bzr_ssh_path_limiter in the bzr source tree
<sensae> spiv: No dice with that either. I've tried a lot of different commands, I'm just getting "Please check connectivity and permissions"
<sensae> Alright, I'll take a look
<spiv> sensae: maybe you need to specify command="/usr/bin/bzr ...", or something like that?
<spiv> sensae: $PATH might not be set how you expect at that point, because no .bashrc or whatever would have been run.
<sensae> spiv: No luck with that either :/
<spiv> where is bzr installed on your system?
<spiv> (on the remote system you are trying to configure)
<wgrant> spiv: .bashrc should be run, actually. That's a common vulnerability.
<sensae> spiv: /usr/bin/bzr , I verified with a whereis
<spiv> wgrant: oh really?  wacky!
<spiv> sensae: *nod*
<wgrant> spiv: Yep - it runs the command in a shell.
<sensae> spiv: Hm. This path limiter seems useful anyway, guess I'll try using it and see where it gets me.
<sensae> spiv: ..and it got me nowhere.
<spiv> sensae: yeah, I'd expect it to have the same issue you were already having, although I don't know what that could be.
<poolie> lifeless: why is bug 387555 a bug?
<ubottu> Launchpad bug 387555 in bzr "aliases can override main command names now" [Critical,Triaged] https://launchpad.net/bugs/387555
<spiv> sensae: perhaps check ~/.bzr.log on the remote side, and also try "ssh -vvv user@host" directly.
<lifeless> poolie: I'm not entirely convinced that it is. However Aaron reported the change in behaviour, and I'll comment further once I look at it.
<lifeless> poolie: if it *is* a bug it will bit people badly in the next release unfixed, by making 'bzr shelve' run the wrong shelve.
<mwhudson> poolie: that bug doesn't mean by 'alias' what i first thought when i read the summary
<garyvdm> Updating branch...  Launchpad is processing new changes to this branch and will be available in a few minutes. Reload to see the changes.
<sensae> spiv: Hm, log doesn't exist for the user I'm trying this as
<garyvdm> Very cool!
<spiv> sensae: ok, so bzr almost certainly isn't getting run.
<spiv> sensae: maybe try using a really simple command, like 'command="/bin/echo hello" ssh-rss ...' as a sanity check?
<mwhudson> beuno, rockstar, Peng_: have any of you looked at https://code.edge.launchpad.net/~zigarn/loggerhead/nested-branches/+merge/7307 ?
<rockstar> mwhudson, nope, I hadn't.
<mwhudson> i don't think i want to merge it
<mwhudson> but i guess i should think of some reasons other than a gut feeling
<poolie> lifeless: the guide for upgrading to 2a seems reasonable
<poolie> you could run it past some lp people too...
<sensae> spiv: Debug messages say "forcing command: /bin/echo hello" but without the debug flags, I get nothing.
<Peng_> mwhudson: I haven't. It sounded complex, so I didn't even try. :D
<lifeless> thumper: jml: mwhudson: any comments on my draft for upgrading repositories across the rich root barrier?
<Peng_> Hey, look over there! *points*
 * Peng_ sticks bug #382765 on someone's back.
<ubottu> Launchpad bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged] https://launchpad.net/bugs/382765
<spiv> sensae: weird.
<jml> lifeless: I have been meaning to look at it for 1.5 days now, but have not had the opportunity.
<sensae> spiv: Fixed it, and I feel pretty stupid now. My test user's shell was set to /bin/false in /etc/passwd :/ Works as expected now.
<spiv> sensae: ah!
<spiv> sensae: glad it's working for you
<sensae> spiv: Thanks for all the help, I think without it I would have given up.
<spiv> sensae: not a problem :)
<RenatoSilva> Do tags always tag the whole branch or is it possible to tag sub-directories or single files?
<lifeless> tags tag commits
<lifeless> so 'whole thing'
<RenatoSilva> oh, then so
<RenatoSilva> then no
<RenatoSilva> I have a problem
<RenatoSilva> myutils = Branch(); myutils.add(one_util_v1.2); myutils.add(another_util_v5.9)
<wgrant> RenatoSilva: This is part of why we suggested that you use separate branches.
<RenatoSilva> I'd have to tag myutils, but I would like to tag each file
<RenatoSilva> wgrant: I see
<RenatoSilva> wgrant: but I'll need to set up one dir for each file right?
<wgrant> RenatoSilva: Yes.
<RenatoSilva> can the same .bzr dir store multiple branches?
<wgrant> That's complicated.
<RenatoSilva> yeah, the whole issue is
<sensae> Now I just have to figure out why bzr is crashing on a push. x.x
<RenatoSilva> wgrant: I think that cvs allows to tag any tree
<spiv> RenatoSilva: Launchpad only stores single branches.
<lifeless> RenatoSilva: bzr|hg|git != CVS
<wgrant> RenatoSilva: Yes, but CVS is veeeeery different from Bazaar.
<lifeless> RenatoSilva: few patterns that work well in CVS work well in any of the modern version control systems.
<RenatoSilva> wgrant: it would be nice maybe if we could have 'contextual' tags, they would not tag full commits but commits on a target sub-dir or file
<wgrant> RenatoSilva: Why?
<RAOF> Is there any way with bzr-git to push to/pull from a non-master branch?
<mwhudson> RAOF: not yet, no
<mwhudson> RAOF: i think you can git-import which will get you a repo containing all branches
<lifeless> RenatoSilva: are you tagging releases?
<RAOF> mwhudson: But you can't push to a non-master branch.  OK.
<mwhudson> RAOF: afaik
<RenatoSilva> wgrant: so that I create myutils and global tags like Release_1.0, Release_1.1 etc... but could also have independent release tags with the 'contextual' tags: myutils/util_one --> Release_5.6, etc...
<lifeless> RenatoSilva: again, it sounds like you want to treat these files as separate things
<wgrant> RenatoSilva: You're not meant to colocate lots of separate pieces of software in one branch.
<lifeless> RenatoSilva: separate things should be in separate branches if you want to put metadata like that
<wgrant> It's not like Subversion, where you throw hundreds and hundreds of projects into one repository.
<RenatoSilva> lifeless: the contextual tags would be just for reference / browsing, to track the history of a subdir or file
<RenatoSilva> lifeless: If I separate the things, I would need one directory for each file
<RenatoSilva> to create a branch
<lifeless> RenatoSilva: I must admit I don't really see the benefit of tagging only part of a tree
<AfC> wgrant: I tried bzr-svn branching a small project out of Apache's Subversion repo... only to discover they had >700,000 revisions there. I decided not to wait :|
<wgrant> AfC: Yep... Zope does it too.
<mwhudson> AfC: svn.apache.org really hate launchpad :)
<AfC> mwhudson: I bet
<mwhudson> at one point all of canonical's ip addresses were banned even
<AfC> mwhudson: last year when I was trying to get gtk+ out of svn.gnome.org, it took ~30 minutes to get 100 revisions. Subversion performs *horribly* when asked for historical editions of files.
<AfC> Apache really is in its own little world
<RenatoSilva> lifeless: let's say you have a myutils branch, with tags R10, R11 R12 and you have the specific_abc_utility wich has it's own versioning like 9.04, 9.10 etc. If you could do something like $bzr tag R9.04 -d abc_utility.py, then you could later take a look at that particular revision of that file, using something like $bzr tags -d abc_utility.py.
<wgrant> RenatoSilva: You don't have that sort of branch, though.
<lifeless> RenatoSilva: yes; OTOH you will have a horribly confusing set of tags
<lifeless> or you'll have to run commands to query 'all tags' specfically
<RenatoSilva> it's like eclipse, galileo  is eclipse 3.5, this is the main line of versioning, but every sub-project has its own different versioning
<lifeless> we put sub projects into different branches
<lifeless> it makes it clear
<lifeless> not that I'd hold eclipse up as a paragon of clarity for its module and versioning system
<RenatoSilva> lifeless: not confusing maybe, they could be separate tags, contextual tags, they would appear only if you ask to, like $bzr tags --include-contextual or so
<wgrant> That is confusing...
<lifeless> that is itself confusing
<RenatoSilva> :)
<RenatoSilva> it would continue to work the same way, only people who noticed such issue would be interested about it...
<wgrant> Assuming that you weren't terrified of having an extra directory segment, what is the benefit?
<lifeless> RenatoSilva: it would have significant knockon effects: firstly when saying to a user 'get version X' the user would need to know that there are invisible tags they need to supply a magic path to see.
<lifeless> secondly, the data storage model would be made more complex. We'd have to write code to support it in the CLI, web UI, gtk/qt interfaces and more.
<lifeless> What I'm saying is that there is a signficant, measurable cost in doing what you propose.
<lifeless> So we should get a greater benefit by doing it than it costs, or it is likely not worth doing.
<lifeless> (we) is the users+developers of bzr combined.
<RenatoSilva> lifeless: I don't get your 1st point
<lifeless> at the moment, if I say, version 10.6, there are two ways, and only two, to get it. A branch called 10.6, or a tag in trunk called 10.6
<lifeless> your proposal adds a third way
<lifeless> a tag in trunk that 'bzr tags' *does not list* called 10.6
<RenatoSilva> it should not list if it's not a branch tag (a contextual tag)
<RenatoSilva> when you do bzr tags, you're doing it under the branch
<lifeless> the point is about the cognitive overhead of learning yet another way to categorise things
<RenatoSilva> only if you ask so, it would operate under a subset
<lifeless> now, I'll agree that we may have gone too far with whole-tree versioning; I've made that argument myself from time to time.
<lifeless> but we need to accurately measure and assess the costs of thingslike this, not just assert that they are worth doing.
<RenatoSilva> lifeless: you mean each dir could be a branch?
<lifeless> with the nested trees feature that is being finished at the moment, yes they can be
<RenatoSilva> just like cvs modules
<lifeless> not at all. Like a small subset of cvs modules perhaps.
<lifeless> cvs modules are actually far more complex than most users think they are.
<lifeless> [complex and problematic]
<RenatoSilva> if you have a cvs repo in front of you, a big tree, and you wonder: "well where are the modules/branches/projects"? The answer is: your project can be anything you want, because each dir is a cvs module (ok, there's no atomic commit but I guess svn works this way)
<lifeless> svn works differently again
<RenatoSilva> wouldn't branch inside branches be a complicated stuff? more than the sub-tags?
<lifeless> it is complicated but it has very significant benefits
<lifeless> it lets you do things you can't do without
<RenatoSilva> it would let you have sub-tags right?
<lifeless> not unless you split your project up into nested projects
<RenatoSilva> I wonder how git adresses all this
<RenatoSilva> and hg
<AfC> RenatoSilva: You might find that 3rd generation distributed revision control has different ("best") practises than perhaps you are used to. You might just want to give things a try the way they work well in [in this case, Bazaar] and see how you get on.
<lifeless> git and hg do exactly what bzr does
<RenatoSilva> AfC: in my example it means one dir for each single file
<AfC> Because they are also 3rd generation distributed version control systems :)
<lifeless> there are some minor spelling differences, but at the level this discussion is at they are identical.
<RenatoSilva> AfC: which is a bit annoying
<AfC> RenatoSilva: {shrug} ... whether one file or one hundred, if the branches have separate identities, so be it.
<lifeless> RenatoSilva: so you have a choice. You can either: use CVS. Use one branch per file. Tag releases for all files at once.
<RenatoSilva> calm donw guys
<RenatoSilva> I'm jsut talking about it
<lifeless> RenatoSilva: there is an inconsistency in what you are asking: you're saying you have files that are sufficiently well managed that they get individual releases, but you aren't willing to pay the [tiny] cost of having a separate branch to achieve that management.
<RenatoSilva> lifeless: because they's just single files, it could be together in one single dir, I think it's annoying one dir + .zr for just one file, repeated several times. Just my opinion. As you said the choice is mine. I'm just trying to know how it works
<AfC> lifeless: incidentally, I would value your comment or contribution on the email thread on bazaar-list titled "I pulled HOW much?". I suspect I have observed a similar behaviour, and am curious if indeed there is a quick "fix" (sic).
<Peng_> AfC: The second reply *did* say there's a patch up.
<Peng_> AfC: (And it works, too.)
<AfC> Peng_: yes. No kidding.
<AfC> Peng_: but as John went to quite some trouble to suggest that perhaps his implementation needed consideration, I thought I would see if Robert had anything to say on the topic.
<Peng_> AfC: Okie dokie.
<RenatoSilva> (!) how about if I apply a tag like Utility_ABC_Release_10 in the branch?
<Peng_> (Okey dokey? I dunno.)
<lifeless> AfC: I'll have a look
<lifeless> RenatoSilva: if that works for you, great.
<sensae> Urgh, anybody have a solution for making bazaar create files with a group permission of 7, without using umask on every dev account? :/
<AfC> Peng_: it's one of those things you hear spoken (by American presidents and other illiterate peasants). I don't think you'd ever see it written down, except maybe in a movie script.
<lifeless> sensae: you can set it in /etc/ssh/rc I think
<lifeless> sensae: or something like that
<spiv> AfC: I believe the branch jam linked to fixes it; I'm actually reviewing that code atm.
<spiv> AfC: (I spent some time at UDS discussing and pairing on that issue with jam)
<RenatoSilva> lifeless: real example: http://bazaar.launchpad.net/~renatosilva/+junk/utilities.ruby/files
<RenatoSilva> the branch itself is not versioned, but some files inside it
<RenatoSilva> currently it's revision 1, but take a look at:
<lifeless> RenatoSilva: branches can't be versioned in bzr.
<RenatoSilva> http://bazaar.launchpad.net/~renatosilva/%2Bjunk/utilities.ruby/annotate/head%3A/trf.rb
<RenatoSilva> inside the file it stands it's the version 2009.4.22, the same way for the other files
<RenatoSilva> so my idea is to $bzr tag trf_2009.4.22 and $bzr tag ganyclean_2009.2.28
<spiv> RenatoSilva: if you want to manage that file as its own independent entity, make a separate branch for just that file.  Really :)
<RenatoSilva> I think it would replace the sub-tags nicely
<lifeless> RenatoSilva: you can do that. can I ask.. what do you want the tags for anyway?
<spiv> RenatoSilva: I'm not sure why that wouldn't work well for you?
<lifeless> spiv: cognitive overhead I think.
<RenatoSilva> lifeless: to find previous _release_ versions of the files
<lifeless> RenatoSilva: 'bzr log filename' can report on that for you.
<Peng_> I just realized I accidentally disabled all plugins in Loggerhead. Maybe that's why it stopped leaking memory.
<Peng_> (or, well, gaining memory at least.)
<lifeless> RenatoSilva: if when you are doing a release you say 'release 2009.2.28' in your commit message for the file.
<RenatoSilva> lifeless: I mean _release_ tags, not raw revisions
<lifeless> RenatoSilva: yes, I know what you mean. But for individual files it seems like they *have* to change when you do a per file release.
<lifeless> so I don't see why tags are preferrable.
<RenatoSilva> lifeless: oh I see, put that in the commit comment is another option, altough I don't know which one is better
<lifeless> the way people generally manage releases with bzr is to run 'bzr branch trunk RELEASE-X'
<RenatoSilva> I think search in the tags could be easier than searching in the comments
<RenatoSilva> the comments would better explain the changes, I think tag is better for tagging such commit as "this is release x or y"
<lifeless> RenatoSilva: 'bzr log -m release FILENAME'
<RenatoSilva> lifeless: ok
<RenatoSilva> I have to read more on bzr (more than those 5 minutes :) )
 * spiv -> lunch
<RenatoSilva> but I'm pretty happy because I can do the basics and I will solve a problem at work
<RenatoSilva> I have a project at work versioned with CVS, but I change it at home too (and can't commit to work). I will solve this by using bzr...
<lifeless> good luck, I hope it works smoothly for that
<sensae> lifeless: I need a little more push in the right direction than just what file :p How would I go about it?
<RenatoSilva> thank you guys for helping
<lifeless> as per man 5 authorized_keys:
<lifeless>  If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; o...
<lifeless> so you can put commands to set umask etc in those scripts
<sensae> So you'd recommend setting the umask for devs as a fix?
<lifeless> that + sticky bit is the easiest way to ensure consistent permissions in a unix server
<sensae> lifeless: Alright, thanks. That's what I was looking for - an opinion of the best way to go about it :)
<RenatoSilva> why would I want QBzrEclipse rather than the non-Q?
<RenatoSilva> What does Qt has with Eclipse? It has its own gui in SWT, I couldn't understand really
<RenatoSilva> RenatoSilva: The bzr-eclipse plugin uses SWT for its interface whereas this plugin uses the QBzr plug-in. This does mean that the interface may not have the same look and feel as Eclipse does. The advantage of this approach though is that you get a consistent graphical user interface to Bazaar whether you are using the command line, TortoiseBzr or Eclipse. The QBzr plugin also provides a very nice interface for Bazaar.
<AfC> spiv: nice.
<AfC> spiv: [I hope you guys can land that before 1.16]
<RenatoSilva> I I write an utility for eclipse, would it be suitable to link the branch with eclipse project?
<RenatoSilva> Or should the branches be direct work on the project, patch proposals?
<wgrant> RenatoSilva: It wouldn't be suitable to have on the eclipse project.
<wgrant> As it's not a branch of the eclipse project.
<wgrant> All of a project's branches should ideally have a common ancestor.
<lifeless> wgrant: I think thats a misconception
<lifeless> wgrant: lp is overly strict with its divisions in this area
<wgrant> lifeless: It's not strict at all...
<wgrant> lifeless: What do you mean?
<lifeless> wgrant: needing a separate project to deal with code that is for the same project but organised into different trees
<wgrant> lifeless: But a utility for Eclipse is not code for the Eclipse project.
<lifeless> wgrant: I agree. I wouldn't put that in the same place.I was responding to your ideal statement, not the concrete advice.
<RenatoSilva> so branches are just for merging
<dash> what else could they be for?
<wgrant> lifeless: Oh, right.
<RenatoSilva> dash: :)
<RenatoSilva> is there a way to send an automatic email when I commit to my branch?
<wgrant> RenatoSilva: Launchpad sends them automatically.
<wgrant> And there's a plugin for bzr (bzr-email?) to do it locally.
<RenatoSilva> wgrant: I mean in local branch
<RenatoSilva> wgrant: I can't put corp emails there in lp
<RenatoSilva> ok bzr-email I'll tae a look
<RenatoSilva> I would like also to run some specific command which would receive the commit info.. I want to do something like this:
<RenatoSilva> bzr commit -m "Implemented the feature abc."
<jml> wuuu triage!
<RenatoSilva>   mail sent to your-boss@your-company.com
<lifeless> jml: ?
<RenatoSilva>   additiona trigger executed: smart-dot-project-task-logger
<jml> lifeless: you are changing lots of bugs that I'm subscribed to from "New" to $OTHER_STATE
<jml> lifeless: that makes me happy :)
<lifeless> jml: I'm doing performance runs on check
<lifeless> so I'm just bit twiddling while I wait
<wgrant> RenatoSilva: It sounds like you want to look at hooks.
<lifeless> yay lp oops on bug page
<lifeless> RenatoSilva: bzr help hooks
<RenatoSilva> ok thanks
<RenatoSilva> the ahrd part is to write dot-project integration tough.
<RenatoSilva> it's so boring to commit, copy comment, open browser, paste comment, and commit to the task
<jml> poolie: btw, am near halfway through "The Mauritius Command" and have recently read "HMS Surprise".
<jml> poolie: the phrase, "Jack, you have debauched my sloth!" came up. :)
<poolie> did i tell you i read O'Brian's "The Catalans" in Catalunya? it was good.
<poolie> oh jack.
<poolie> (: (:
<jml> poolie: no you didn't.
<RenatoSilva> does bzr-email accept only one mail?
<lifeless> to send to?
<RenatoSilva> yes
<SoftCoder> hello?
<RenatoSilva> it does not mention multiple addresses :(
<SoftCoder> Using Ubuntu 9 and Olive isn't working anymore gives me: nable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 15, 0), and the maximum is (1, 15, 0)
<SoftCoder> Any ideas what I can do?
<lifeless> RenatoSilva: likely; feel free to file a bug if you like. You could set an alias in your mail environment
<lifeless> SoftCoder: upgrade your bzr-gtk plugin
<SoftCoder> I'm on 0.95 (isn't that the latest)?
<lifeless> SoftCoder: bzr-gtk is version-locked to bzr
<SoftCoder> bzr is running 1.15.1
<lifeless> sure. All I'm saying is that the bzr-gtk version doesn't match.
<lifeless> there shouldhave been a release fixing it
<lifeless> a
<lifeless> are you using the pPA?
<SoftCoder> I didn't see any release yet and wondered if anyone knew where I could find a fix?
<RenatoSilva> lifeless: fortunately there's a devel-team alias at work :)
<SoftCoder> I think I added the ppa let me double check
<RenatoSilva> how do I rollback to the latest commited version?
<RenatoSilva> it's like revert to base in cvs
<lifeless> 'bzr revert' will undo all your changes
<RenatoSilva> thanks!
<thumper> $ bzr info -v
<thumper> bzr: ERROR: Unknown repository format: 'Bazaar development format - chk repository with bencode revision serialization (needs bzr.dev from 1.15)\n'
<thumper> ???
<thumper> I created the repo yesterday
<thumper> upgraded bzr from the nightly ppa today
<thumper> now it doesn't understand
<lifeless> yup
<lifeless> dev format
<thumper> huh?
<thumper> so what do I do now?
<lifeless> install the old package
<thumper> and ...
<lifeless> upgrade to the 2a format
<thumper> it didn't know about the 2a format
<lifeless> odd
<lifeless> I'm not sure why that string isn't recognised
<lifeless> poolie: ^ you were the last one touching this area I think
<jml> a patch went through that changed the string from 1.15 to 1.16, I think.
<SoftCoder> I beleive I havce the pps for bzr and still have the API issues.. my software sources in Ubuntuy says: http://ppa.launchpad.net/bzr/ppa/ubuntu DISTRO: jaunty Components: main
<lifeless> ugh
<SoftCoder> softcoder@softhauslinux:~$ bzr check
<SoftCoder> Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 15, 0), and the maximum is (1, 15, 0)
<lifeless> jml: if you can find who did that, hint them up
<lifeless> thumper: edit .bzr/repository/format
<thumper> SoftCoder: you need to upgrade bzrtools
<lifeless> change 15 to 16
<lifeless> thumper: thats gtk thats erroring
<lifeless> thumper: see the start of the line ;)
<thumper> oh
<lifeless> SoftCoder: so, apt-get update
<lifeless> SoftCoder: and apt-get upgrade, that may get you a newer version
<lifeless> SoftCoder: failing that file a bug on bzr please; we maintain that ppa
<poolie> yes, what lifeless said should work
<poolie> hi thumpber
<lifeless> and its meant to be kept in lock-sync
<thumper> aarh
<thumper> I edited the repository format
<thumper> bzr info worked then
<thumper> but upgrade fails
<thumper> bzr: ERROR: Cannot convert to format <RepositoryFormat2a>.  Does not support nested trees
<lifeless> \o/ bzr smash time
<SoftCoder> how do i manually install bzrtools? (doing apt did not get anything new)
<SoftCoder> I d/l bzrtools 16 manually how do i install it?
<SoftCoder> nevermind
<SoftCoder> found INSTALL file
<lifeless> poolie: please not be setting things to new *after* triage work.
<poolie> lifeless: our edits overlapped
<lifeless> on bug 387158? looks like 20 minutes apart to me ;)
<ubottu> Launchpad bug 387158 in bzr "bound branch reports "pack-names is not an index of type..."" [Undecided,Incomplete] https://launchpad.net/bugs/387158
<poolie> nevertheless
<lifeless> ok
<thumper> jml: is the upgrade issue above a 1.16 blocker?
<lifeless> whats the code submit address again?
<poolie> sorry anyhow
<thumper> lifeless: to LP?
<lifeless> thumper: yes
<jml> thumper: the "nested trees" one? don't know.
<thumper> merge@code.launchpad.net
<lifeless> thanks
 * thumper heads off for the day
<RenatoSilva> SimpleXMLRPCServer is missing in BzrEclipse, any ideas on how to solve this? How to make bzr use other python than its built-in?
<lifeless> poolie: so I'd like to understand whether you meant to change the status to new, or whether LP saved too many variables and it was essentially a conflict
<lifeless> poolie: so that we can file a bug if needed
<poolie> i did say to change the state from incomplete back to new
<lifeless> ok
<lifeless> RenatoSilva: the bzreclipse wiki page has complete installation instructions
<poolie> i did not realize you'd already changed it to something else
<RenatoSilva> lifeless: I followed the doc, this error is happening in ' get log ' for example
<fullermd> jml: I'd vote for it being one...
<lifeless> RenatoSilva: oh. Anyhow, you can run 'python <path>/bin' to run with a specific python
<lifeless> verterok_: may know though
<lifeless> path/bzr I mean :)
<lifeless> RenatoSilva: if this is on windows, with our bundled installers, please file a bug.
<fullermd> (makes all those dev formats traps)
<poolie> igc: you have about 5 approved merges in launchpad
<poolie> if you're still awake you should land some...
<igc> poolie: except for the eol-doc one, the rest need some tweaking and probably resubmission
<RenatoSilva> how can I change the python, bzr from windows installer is exe only
<lifeless> RenatoSilva: you can't easily. Please file a bug.
<RenatoSilva> I have 2.6 here iwth such RPC file
<poolie> RenatoSilva: you might need to separately install python from python.org?
<igc> poolie: though this one probably just needs me to reply to jam: https://code.edge.launchpad.net/~ian-clatworthy/bzr/faster-log-file/+merge/6805
<RenatoSilva> poolie: ^
<lifeless> RenatoSilva: we have alternate installation instructions for installing with an existing python
<lifeless> RenatoSilva: you will need to follow those to work around until a new installer is spun with the libraries you need.
<RenatoSilva> lifeless: yeah, maybe that's what I'll have to do :(
 * igc takes a break - bbl
<RenatoSilva> lifeless: https://bugs.launchpad.net/bzr-eclipse/+bug/387651
<ubottu> Launchpad bug 387651 in bzr-eclipse "Error on log command: no module named SimpleXMLRPCServer" [Undecided,New]
<lifeless> thanks
<RenatoSilva> np
<RenatoSilva> QBzrEclipse don't want to get out of my Eclipse o.O
<cellofellow> how do I create a patch file I'd attach to a Launchpad bug report?
<RenatoSilva> cellofellow: diff command
<cellofellow> so, bzr diff > my.patch
<cellofellow> something like that?
<lifeless> cellofellow: or bzr send -o my.patch
<cellofellow> which is preferred and why?
<lifeless> bzr send preserves metadata and sends your commits as a group
<lifeless> bzr diff shows uncommitted changes
<cellofellow> ah, ok
<cellofellow> ok, will use send, thanks
<wgrant> cellofellow: Why not attach the branch to the bug?
<cellofellow> cause I'm not that smart :P
<cellofellow> so, I'd push that to lp:~cellofellow/project/branches/mybranch
<cellofellow> or something like that?
<wgrant> Without the /branches, but yes.
<cellofellow> ok
<RenatoSilva> cellofellow: to lp:~cellofellow/project/mybranch-purporse
<vila> hi all
 * RenatoSilva meant diff command itself
<wgrant> cellofellow: https://help.launchpad.net/Code/BugAndBlueprintLinks#Fixing%20bugs%20in%20dedicated%20branches
<lifeless> EODing
<poolie> night lifeless
 * vila feels a crash coming....
<bialix> http://www.ericsink.com/entries/hg_denzel.html
<scor> davidstrauss: I should ask here instead
<scor> is there a way to get bzr diff to show the function in which each hunk applies (like in cvs diff -up)?
<scor> from the cvs docs: "    -p  --show-c-function  Show which C function each change is in.
<scor> "
<Peng_> Does "write a patch adding support for that" count as "a way"?
<Peng_> You can probably do it with an external diff program that supports that.
<verterok_> lifeless: regarding RenatoSilva issue with bzr-xmloutput, and installer is provided that includes SimpleXMLRPCServer.py for bzr.exe users
<verterok_> btw, good morning!
<basti_> Hi everyone! Is there a way to change the parent of a particular revision to a another branch?
<basti_> I started work on a branch from SVN trunk but need to put it into a SVN branch of its own again. Any thoughts?
<vila> basti_: did you look at 'bzr rebase' ?
<basti_> I keeps telling me that the brnches have no common ancestor
<basti_> Alternatively, is there a quick way of re-applying revisions as patches?
<vila> basti_: sorry, I don't know bzr-svn nor svn good enough to help you there :-/
<vila> jam: ping
<basti_> Never mind but thanks anyway
<vila> basti_: I suspect you didn't build your branches as bzr-svn expect them to be built (they should have a common ancestor if you start them from the same svn branch) but that's all I can think of
<pygi> basti_: you want to apply commits from bzr to a svn branch?
<pygi> hi vila
<vila> pygi: hi
<basti_> pygi: yes but it is a bit more complicated than that (isn't always)
<pygi> basti_: tell me?
<basti_> pygi: I started some months ago with a bzr branch from SVN trunk
<basti_> Now I need to put i back on a SVN brnch again
<basti_> That was before the bzr-svn plugin was able to create SVN branches
<pygi> basti_: http://bogdano.googlecode.com/svn/tools/bzr2svn/bzr2svn.py
<pygi> can this help?
<pygi> it patches revisions from a bazaar branch to a subversion working copy and commiting them one by one.
<pygi> s/commiting/commits
<basti_> pygi: I'll give it a try. Thanks
<pygi> most welcome
<pygi> vila: how are you doing? :)
<vila> pygi: overcommitted :-)
<pygi> and I told you not to do it :p
<jam> vila: pong
<jam> rockstar: happy birthday, (according to skype)
<ablmf1> Could TortoiseBZR use proxy?
<ablmf1> I mean, http proxy
<vila> ablmf1: it should (relying on bzr for that), did you try ?
<ablmf1> vila: I don't know hot to set that for bazzar on windows.  I googled a while, can not find some clue
<vila> how do you set it for your browser ?
<ablmf1> I set it in IE.
<ablmf1> And in firefox.
<ablmf1> But bazzar still can not download code
<ablmf1> I can browser web pages
<ablmf1> Does bazzar use https?
<vila> ablmf1: ok, but how ? Manual proxy. automatic via URL ?
<ablmf1> But using Internet Options in IE, of course.
<ablmf1> By using Internet Options in IE, of course.
<vila> ablmf1: ok, but do you use a '.pac' file or do you specify a host and a port
<ablmf1> No, not by a .pac file.  I manually specify it.
<vxnick> can anyone point me to some docs for the bazaar server (is this the same as SmartServer)? there's a smattering of docs on the bzr site but nothing complete by the looks of it
<vila> ablmf1: hmm, python is tricking us then, it's supposed to provides the proxy in that case,
<ablmf1> OK, maybe that's because other problems.
<ablmf1> vila: thanks anyway
<vila> ablmf1: you will need to do that "manually" by setting an environment variable like: http_proxy with a value of 'http://<host>:<port>'
<ablmf1> vila: I will see if it works.  thanks
<ablmf1> I found a command like this "call bzr branch lp:oah -rtag:0.3 trunk"
<ablmf1> What does "lp:oah" mean?
<rockstar> jam, thanks.
<ablmf1> How can bzr locate the repository without a full URL?
<ablmf1> OAH build system depends on bazaar.  It really confuse me.
<LarstiQ> ablmf1: lp: is shorthand expanded by the launchpad plugin
<LarstiQ> ablmf1: so lp:oah is the development focus of https://launchpad.net/oah
<LarstiQ> ablmf1: see `bzr info lp:oah` for instance
<ablmf1> I could open it in web.  But "bzr branch lp:oah -rtag:0.3 trunk" always fail.  Python says "time out"
<LarstiQ> ablmf1: it works for me, so that suggest there is something wrong at your end.
<LarstiQ> ablmf1: could you pastebin the output of `bzr info lp:oah`?
<LarstiQ> ablmf1: do you use a https proxy, can you branch anything from launchpad at all?
<ablmf1> You have not informed bzr of your Launchpad ID, and you must do this to
<ablmf1> write to Launchpad or access private data.  See "bzr help launchpad-login".
<ablmf1> Oh, God.  It works now...
<ablmf1> Perhaps it's the problme of network.
<ablmf1> Thans a lot
<LarstiQ> ablmf1: possibly.
<LarstiQ> ablmf1: the 'time out' you mentioned looks like a network timeout
<LarstiQ> ablmf1: that is either because you can't reach launchpad at all, or because of an intermittent network problem
<LarstiQ> ablmf1: a firewall could cause it for example
<ablmf1> Perhaps because of the network condition.  The downloading speed is very slow, 5 - 10 kB/s
<ablmf1> Might took hours for downloading these code I want.
<mrooney> How might I go about un-adding everything added in a current working copy? I have modified things so I can't just revert the whole thing
<fullermd> bzr rm has a --new option...
<ddaa> so that would be "bzr rm -R --new ."
<ddaa> make a copy of the whole thing before
<fullermd> -R?
<ddaa> oh, no recursive :)
<ddaa> then "bzr ls kind=file | xargs bzr rm --new"
<ddaa> then "bzr ls --kind=file | xargs bzr rm --new"
<fullermd> Actually, I assumed that just 'bzr rm --new' would do it.
<fullermd> I'd assume that passing filenames would make it always rm them, sorta like passing filenames to add overrides ignores.
<ddaa> oh
<ddaa> that would make sense, but it's a bit counter intuitive to do "rm" without any argument.
<ddaa> you could say the same about "add", but I guess I'm more used to this one.
<fullermd> (I don't know if it actually works that way, it's just what I expect)
<fullermd> It certainly calls for some experimentation before you run with it.
<jonnydee1> bzr rm --keep should work
<mrooney> okay now I am confused as to what command would actually work while keeping the files and not actually changing anything
<mrooney> but just un-adding newly added files
<jonnydee1> mrooney: I tested this one: bzr rm --keep `bzr added` which seems to work...
<jonnydee1> on linux/unix, at least
<kfogel> What's the currently recommended Best Tool for converting from Subversion to Bazaar?
<kfogel> (opinionated opinions welcome)
<Tak> converting what?
<kfogel> http://developer.berlios.de/projects/python/
<kfogel> Tak: a Subversion repository, presumably including branches
<kfogel> (let me see if he has any...)
<Tak> bzr help svn-import?
<kfogel> Tak: no branches even.
<kfogel> Tak: oh!  didn't know about that command.  thanks
<kfogel> Tak: bzr-svn seems to be the best option
<beuno> kfogel, I think bzr-svn is the best
<beuno> there's fastimport
<beuno> but I think that's for one-time imports only
<kfogel> beuno: this guy is doing a one-time, but even so I think bzr-svn is probably the way to go.
<beuno> yeah, branch once from it, forget
<RenatoSilva> Hi. "If you have Python 2.4/2.5 already installed on your system, then you could use the Python-based installer instead of the standalone Windows installer"
<RenatoSilva> Won't it work with 2.6?
<beuno> RenatoSilva, it does
<RenatoSilva> ok
<RenatoSilva> http://bazaar-vcs.org/BzrWin32Installer#bzr-dependencies
<RenatoSilva> are they all optional?
<RenatoSilva> what about bzr win32 too?
<RenatoSilva> actually, pywin32
<RenatoSilva> doesn't it come with standard python?
<sidnei> RenatoSilva: no it doesn't
<beuno> spiv, lifeless, ping
<beuno> (good morning, actually)
<beuno> I've been hitting what I believe is a a bbc smart server bug
<RenatoSilva> sidnei: sorry I cleaned the screen and I can't recall what is your answer for :(
<beuno> after upgrading to 1.16rc1
<beuno> bug 388020
<ubottu> Launchpad bug 388020 in bzr "UnknownErrorFromSmartServer when pushing with 1.16rc1" [Undecided,New] https://launchpad.net/bugs/388020
<SamB> oh no! you won't be able to watch the newest episode of Monty Python!
<sidnei> RenatoSilva: you asked if pywin32 ships with standard python
<RenatoSilva> sidnei: ah ok, I checked it out, and I just nedd it if I don't use plink to talk with pageant, something like that
<spirov92> is there a way to see the commits I did today?
<beuno> spirov92, you should be able to do something like:   bzr log -r date:today
<beuno> spirov92, bzr log -r date:today..
<spirov92> yay, it works
<beuno> to be more precise
<beuno> (otherwise you only get one)
<Peng_> Is it a bad idea to use --2a?
<Peng_> Oh, I forgot, I need to keep some 1.9-rich-root repos around, so all of the conversions would probably hurt performance.
<RenatoSilva> Oh it's hard to install bzr separate from python!
<RenatoSilva> I run setup.py and get this error for bzr itself: building 'bzrlib._btree_serializer_c' extension,  Cannot build extensions.  Use "build_ext --allow-python-fallback" to use slower python implementations instead.  error: Unable to find vcvarsall.bat
<RenatoSilva> Besides teh downlaod mentioned here is a windows installer with built-in python! http://bazaar-vcs.org/WindowsInstall
<RenatoSilva> however it is supposed to be standalone bzr sorces
<RenatoSilva> It seems an old non-sense page
<RenatoSilva> bzr 1.15-1 python2.5 installer --> it installs into python 2.5 (I hope into 2.6 too) not installs python together
<RenatoSilva> it's not clear
<RenatoSilva> doesn't work with 2.6! grrr
<garyvdm> RenatoSilva: bzr does work with python 2.6. It's just there is no python 2.6 installer.
<garyvdm> Why don't you want to use the Windows Standalone Installer?
<RenatoSilva> garyvdm: because of bug 387651
<ubottu> Launchpad bug 387651 in bzr "Error on log command: no module named SimpleXMLRPCServer" [High,Confirmed] https://launchpad.net/bugs/387651
<garyvdm> RenatoSilva: I think what Guillermo Gonzalez was trying to tell you is that you did not use the Windows Installer for bzr-xmloutput. If you did, it would install SimpleXMLRPCServer for you
<garyvdm> bzr-xmloutput is used by BzrEclipse
<verterok> RenatoSilva: Hi, garyvdm is right, using the bzr-xmloutput windows installer is enough to get all the dependencies in place
<RenatoSilva> I installed xmloutput before and successfully bzr log --xml
<verterok> RenatoSilva: how did you installed it?
<RenatoSilva> I'm trying to remeber
<RenatoSilva> bzr branch
<verterok> RenatoSilva: that should work if you'r using bzr with a full python install
<verterok> RenatoSilva: but bzr.exe don't include SimpleXMLRPCServer, so if you are using bzr.exe you need to install bzr-xmloutput with the installer or get a copy of SimpleXMLRPCServer.py a put it the bzr.exe pythonpath
<RenatoSilva> ok
<RenatoSilva> verterok: I will install python 2.5
<verterok> RenatoSilva: be aware that in order to use a bzr in windows (not bzr.exe) you need to install all the bzr dependencies
<RenatoSilva> verterok: it seems that I don't need anyof them
<verterok> RenatoSilva: take a look to: http://bazaar-vcs.org/WindowsDownloads
<RenatoSilva> since exe for xmloutput will solve the problem, well it may be better to use bzr.exe
<verterok> RenatoSilva: belive me, you need them :)
<verterok> RenatoSilva: sure, it's the easies way. :)
<verterok> *easiest
<RenatoSilva> *easy :)
<verterok> heh :)
<RenatoSilva> verterok: that bug is invalid isn't it? Or would they want to include that dependency into the main bzr installer?
<verterok> RenatoSilva: that idea was discussed some time ago, and the result was the bzr-xmlotuput installer...so I think it's invalid ;-)
<RenatoSilva> verterok: could you tell this to them
<verterok> RenatoSilva: sure
<RenatoSilva> ok
<RenatoSilva> tahnks everybody
<verterok> RenatoSilva: np, glad to help
<Peng_> Aww, I tried to work around bug #348308 with monkeypatching, os.execv, and a nice helping of evil, but it didn't work. :(
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
 * Peng_ /away!
<treeform> hi all! Bzr on windows is super slow, any explanations?  it must be the Turtoze like overlay icons
<treeform> the update for them seem very delayed and it takes some serous CPU
<garyvdm> treeform: Yes, TortoiseBzr unfortunately still suffers from bad performance.
<treeform> can its functionality be disabled?
<jml> james_w, you still around?
<garyvdm> treeform: You can uninstall it, or...
<garyvdm> treeform: you can go into the options, and disable icon overlays for all drive types.
<garyvdm> It then still loads, but doesn't do a status for every file.
<treeform> cool
<treeform> the numbers of crazy bugs make me uneasy https://bugs.launchpad.net/tortoisebzr/+bugs?search=Search&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed&field.status=Fix+Released&field.status=Invalid&field.status=Won%27t+Fix&field.omit_dupes.used=
<thumper> lifeless, jam or other hard core bzr type hacker: how can I force an upgrade from --development7 to --2a?
<thumper> bzr: ERROR: Cannot convert to format <RepositoryFormat2a>.  Does not support nested trees
<thumper> I'm guessing --development7 was configured to support nested trees
<thumper> I know my repo doesn't use nested trees
<thumper> how can I force the conversion?
<garyvdm> treeform: and unfortunately there is currently no one working on it.
<treeform> why was it stopped?
<thumper> treeform: the developer got a full time job
<garyvdm> treeform: that bugs query contains lots of fix released and invalid bugs. This is more accurate representation: https://bugs.launchpad.net/tortoisebzr/+bugs
<garyvdm> Alex is working on the critical bug 335362
<ubottu> Launchpad bug 335362 in tortoisebzr "[master] UnicodeDecodeError when processing paths that have the non-ascii characters" [Critical,Confirmed] https://launchpad.net/bugs/335362
#bzr 2009-06-17
<lifeless> moin
<lifeless> thumper: fixed in trunk I think
<jelmer> 'morning lifeless
<jml> hello everybody
<poolie> hello all
<mwhudson> lifeless: that means, if thumper uses bzr.dev he'll be able to upgrade?
<garyvdm> HI
<mwhudson> hi jelmer, thanks for the cscvs comments
<jml> should that fix go into 1.16final?
<garyvdm> Is there a mirror of bzr.dev in a bzr 1.3 compatible format?
<garyvdm> For Richard Wilbur (see mailing list)
<lifeless> jml: np
<lifeless> jml: no
<lifeless> jml: dev7->2a should be exceedingly rare
<lifeless> jml: and multiple fixes are needed
<lifeless> thumper: init a 2a tree somewhere else
<jml> lifeless: cool.
<lifeless> thumper: copy the repo/format file across; dev7 and 2a are identical
<RenatoSilva> is lp: bzr+ssh?
<RenatoSilva> is bzr+ssh on port 22?
<jelmer> mwhudson: you're welcome
<lifeless> RenatoSilva: lp: is an XMLRPC query, done on port 80, and then bzr+ssh on port 22 *or* http on 80
<jelmer> does bzr do any sort of normalization on symlink paths?
<thumper> lifeless: ok, I'll try that
<thumper> lifeless: bzr trunk still fails the upgrade
<RenatoSilva> lifeless: so lp: is 80 then bzr+ssh, which is 22 or 80 (in this case httpS don't?)
<wgrant> jml: Is there a 6 year delay for bzr 1.16, or did you mess up the date?
<lifeless> RenatoSilva: no, 80 then either 22 or 80
<RenatoSilva> lifeless: that's what I said don't?
<RenatoSilva> lifeless: but the latter 80 is over https right?
<jml> wgrant, oops!
<mwhudson> wgrant: he means wednesday in the us
<RenatoSilva> How do I brz branch behind a proxy and with no access to external SSH?
 * mwhudson hides
<RenatoSilva> I'm trying bzr branch lp:~renatosilva/+junk/moin.theme.solenoid
<RenatoSilva> with HTTP_PROXY=http://aaaa
<thumper> lifeless: is it branch format 6 or 7 that enables stacking?
<RenatoSilva> and HTTP_PROXY_PORT=1234
<mwhudson> thumper: 7
<thumper> why then are new branches still being created with 6 FFS
<mwhudson> thumper: all the new formats look like they should be branch7
<thumper> --development7 wasn't
<thumper> or...
<thumper> when I branched from another branch that was in format 6 it kept it
<mwhudson> it is ow
<mwhudson> *now
<thumper> I've upgraded the branches now to 2a
<thumper> I've not tried bzr 1.16, just bzr.dev
 * thumper gets lp:bzr/1.16
<lifeless> thumper: there is a bug open; in a shared repo 'bzr init' creates the default format not the repos matching format.
<lifeless> thumper: secondly, branching existing projects preserves formats.
<lifeless> thumper: if you aren't running 'bzr init' then you simply need to upgrade all your branches.
<thumper> lifeless: do we have a nice command to upgrade all branches in a repo?
<jelmer> lifeless: does bzr do any sort of normalization on symlink target paths?
<RenatoSilva> Guys the port and host must be in one var, solved
<RenatoSilva> bzr branch http://bazaar.launchpad.net/bzr-email/bzr-email --> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/bzr-email/bzr-email/".
<RenatoSilva> but lp:bzr-email?
<lifeless> http://bazaar.launchpad.net/bzr-email/bzr-email isn't a branch
<RenatoSilva> Tried one bzr-email, trunk in the end (which is a series)
<RenatoSilva> none worked
<lifeless> http://bazaar.launchpad.net/~bzr/bzr-email/trunk is the branch
<RenatoSilva> I wonder what lp:bzr-email does
<lifeless> I don't know where you got http://bazaar.launchpad.net/bzr-email/bzr-email from.
<RenatoSilva> sure it's the project, but how does it find the branch
<wgrant> It asks the Launchpad XML-RPC RPC server for the real path.
<lifeless> thumper: igc has been working on making upgrade more capable
<wgrant> s/ RPC//
<RenatoSilva> lifeless: from my mind hehe
<RenatoSilva> wgrant: ah ok!
<lifeless> RenatoSilva: lp:bzr-lp does an XMLRPC call, as I said when you asked about half an hour ago :)
<RenatoSilva> lifeless: I'm missing the ~bzr
<lifeless> jelmer: ECONTEXT. Inside inventories?
<RenatoSilva> lifeless: sorry
<lifeless> np
<poolie> hi lifeless
<poolie> hi spiv, if any
<poolie> jesus, this progress bar thread...
<mwhudson> poolie: :)
<mwhudson> i think i'm on fullermd's side
<poolie> me too, but that's a lot of heat
<jelmer> lifeless: yeah
<jelmer> lifeless: If I add a random byte string as symlink_target, will bzr modify it in any way?
<lifeless> jelmer: depending on layer; it must be either unicode or utf8
<RenatoSilva> lifeless: I sucessfully installed it here
<RenatoSilva> thanks
<RenatoSilva> however I get this error: bzr: ERROR: socket.sslerror: (1, 'error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure')
<lifeless> jelmer: but we won't randomly change it
<RenatoSilva> is bzr-email trying to use ssh with smtp by default?
<RenatoSilva> our internal server doesn't require auth to send mails
<lifeless> email servers can request TLS
<lifeless> which is like SSL
<RenatoSilva> sure the server doesn't request any kind of auth
<RenatoSilva>  File "C:/Arquivos de Programas/Bazaar/plugins\email\smtp_connection.py", line 84, in _create_connection
<RenatoSilva> it is  try:  self._connection.starttls()
<RenatoSilva> http://www.mibbit.com/pb/qpen81
<lifeless> RenatoSilva: it looks like your server is offering TLS but doing it badly
<lifeless> you could comment out that line if you like
<RenatoSilva> lifeless: humm
<RenatoSilva> lifeless: ha, that's what I did, I commented the try block
<RenatoSilva> lifeless: I would expect it to raise an exception to be catched tough
<RenatoSilva> lifeless: it seems that another kind of error happens
<RenatoSilva> is post_commit_url a bzr option or bzr-email option?
<lifeless> its for bzr-email, but only needed if your public url is set incorrectly
<RenatoSilva> I don't have one
<RenatoSilva> Actually I hacked the option to put a friendly title for the email
<RenatoSilva> post_commit_url = My Project Name
<garyvdm> RenatoSilva: btw - launchpad sends email when you push to a branch on launchpad.
<RenatoSilva> hum maybe I could just branch bzr-email to do my customizations :)
<jelmer> lifeless: not even removing double backslashes and that sort of thing?
<garyvdm> RenatoSilva: People who want email should click on the "subscribe to this branch" button on the branch page.
<RenatoSilva> garyvdm: I can't push to launchpad at work: ssh blocked and lp does not support http push
<garyvdm> OK
<jelmer> lifeless: kirkland seems to've hit a problem importing from git that suggests it does, but it'll probably be a bzr-git bug
<lifeless> jelmer: I'm pretty sure we don't normpath or anything
<RenatoSilva> garyvdm: does lp uses bzr-email
<RenatoSilva> is tehre any work on pretty html emails?
<garyvdm> RenatoSilva: I don't know. You could ask at #launchpad, or may be someone here will know
<jml> it doesn't.
<jelmer> lifeless: ok, I'll keep looking in bzr-git then. Thanks
<RenatoSilva> jml: do you know what they use?
<jml> RenatoSilva, some custom stuff that integrates with the Launchpad web application.
<RenatoSilva> jml: maybe bzr-email wouldn't exist if they released such component
<jml> RenatoSilva, I think it would.
<fullermd> mwhudson, poolie: A lot of heat over wildly unimportant details is my specialty  ;p
<RenatoSilva> jml: why
<RenatoSilva> wold that be easy if I had a rev_id and a branch object, to get the committer?
<RenatoSilva> Inside a bzr plugin
<lifeless> RenatoSilva: branch.repository.get_revision(rev_id).committer
<spiv> lifeless: beat me to it :)
<lifeless> RenatoSilva: there is another email sender for bzr branches, I don't remember the name offhand. Anyhow, it has a template system available.
<lifeless> spiv: ;)
<garyvdm> Is it possible to get a inventory from a WorkingTree that includes unknown items?
<RenatoSilva> lifeless: oh, thank you so much!
<RenatoSilva> lifeless: another better mail plugin?
<jml> lifeless, I'll be a bit later than 1ish to yours if that's ok
<jml> If I don't clean the dishes soon they will stage a bloody revolution.
<lifeless> RenatoSilva: a different one
<lifeless> jml: Sure.
 * thumper doesn't like projects with broken trunks
<thumper> not bzr
<thumper> Please note that code you get from this repository is not intended for productive use (unless it's tagged as a released version, of course, in which case the usual alpha/beta disclaimers apply ;-)). We like to break our codebase, config files, database schemas and all kinds of stuff. We sometimes commit non-compiling revisions to facilitate collaborative development. Running such an unstable version might trash your settings, your backlog and ma
<thumper>  your computer. You have been warned!
<thumper> I like bzr's concept of a good trunk
<thumper> why do people do this to themselves?
<RenatoSilva> is branch.conf fetched when I copy a branch?
<RenatoSilva> I want to use bzr-email at work, bring branch home, stop using bzr-email, work, commit, and push
<lifeless> RenatoSilva: branch.conf isn't copied around
<RenatoSilva> oh nice, then I can use bzr-email at work only
<lifeless> RenatoSilva: you can configure bzr-email in locations.conf, then the config would be specific to that machine
<lifeless> (as another option)
<RenatoSilva> you mean in my app data?
<RenatoSilva> in my ~
<lifeless> whereever your bazaar.conf is you can also have locations.conf
<lifeless> bzr --version
<lifeless> will tell you the place that is stored
<RenatoSilva> this way it will work for any branches in my machine right
<RenatoSilva> I think it's better for now leave it for the branch itself
<poolie> hello spiv? what are you up to today?
<RenatoSilva> but it's good to know of locations.conf, thanks!
<garyvdm> Hi poolie - Please can you help me or point me to some who can.
<poolie> garyvdm: with what?
<garyvdm> I want to get an inventory from a WorkingTree that includes unknown items?
<garyvdm> and merge that with information from iter_changes
<poolie> oh i see
<poolie> garyvdm: at the moment no, you need to call .unknowns() (??) separately and merge that
<poolie> i think
<poolie> fullermd: maybe you can ease off on it a bit?
 * garyvdm looks
<poolie> oh
<poolie> actually there is iter_changes(want_unversioned=True)
<poolie> will that do it?
<RenatoSilva> Is there a way to change history to replace the committer for some commits
<garyvdm> poolie: I'm going to merge iter_changes into a inventory. That would help if there was also iter_changes(.., want_ignored=True)
<RenatoSilva> bzr log --replace-commiter "Renato Silva mail@company" "Renato Silva mail@other"
<RenatoSilva> Is this possible?
<AfC> No
<lifeless> garyvdm: want_unversioned=True
<lifeless> garyvdm: and then filter the unversioned files
<lifeless> oh poolie already answered :P
<garyvdm> poolie: But there is not, so I think I'm going to use tree.extras which I found from you .unknowns() pointer
<garyvdm> lifeless: I also may need to get ignored to.
<lifeless> Have you checked that want_unversioned doesn't include ignored files?
 * garyvdm checks
<garyvdm> lifeless: it doesn't.
<lifeless> hmm
<lifeless> well, I thin it would be reasonable to add a want_ignored then
<lifeless> if your use case is at all common
<garyvdm> lifeless: yes - maybe I should submit a patch.
<garyvdm> poolie, lifeless: I also will want to drill into a dir (only when the user expands it in the gui)
<garyvdm> is there anything that will help me with this?
<poolie> garyvdm: i see iter_changes lets you specify a directory to list
<poolie> i'm not sure if there's a way to say "but don't go any deeper"
<spiv> poolie: hi, currently (after sleeping in...) I'm looking at landing http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090424063000.GA29688%40steerpike.home.puzzling.org%3E, which has been approve (tweak) for ages.
<poolie> perhaps there should be
<garyvdm> poolie: ok - let me look at that
<poolie> lifeless: re bug 351459 would i be right in thinking subunit is used in the implementation of parallel testing?
<ubottu> Launchpad bug 351459 in bzr "Error in parallel selftest: cannot import name ConcurrentTestSuite" [Undecided,Incomplete] https://launchpad.net/bugs/351459
<poolie> spiv, jolly good
<garyvdm> poolie: Last question: To merge the information from iter_changes into a Inventory, I need to create a in memory copy of the inventory, and then add the unversioned items into that?
<garyvdm> would that be possible, or should I create my on Inventory like object to do that?
<garyvdm> s/on/own
<poolie> there's a create_by_apply_delta function on inventory
<poolie> i think you can use that
<lifeless> garyvdm: re: single dir expansion
<lifeless> garyvdm: we found via testing that its faster to do all at once
<lifeless> garyvdm: its a lot simpler and more consistent.
<lifeless> garyvdm: I think igc has some patches towards making a nonrecursive flag; I'm not at all convinced that this is needed.
<lifeless> or in fact beneficial
<lifeless> garyvdm: re: Inventory - generally as a client of bzrlib you shouldn't be mutating inventories; what is the goal/use case you're working towards
<garyvdm> lifeless: Goal: I have a widget that displays a inventory
<garyvdm> and a widget that displays iter_changes.
<garyvdm> And I want to merge them into one.
<garyvdm> lifeless: re: single dir expansion - I only want to expand into a dir only when, and if the user specifically asks for it (by expanding the dir on the widget)
<lifeless> garyvdm: sure. consume the whole iterator and then only show the bits you want
 * garyvdm looks at create_by_apply_delta
<lifeless> I don't quite follow the widget combining though
<garyvdm> lifeless: We have a widget that shows you the tree for a revision (run bzr qbrowse). This consumes a inventory.
<garyvdm> lifeless: I want to extend that to something that can show you the working tree, where you can say show unknown, show ignored, hide unchanged
<jelmer> kirkland: hi
<kirkland> jelmer: howdy
<garyvdm> lifeless: To make the code that gets that data from the inventory simple, I want to just add the unknown/ignored into the inventory
<jelmer> kirkland: the bug in bzr-git importing live-helper you were seeing should be fixed now
<kirkland> jelmer: rolled out to LP?
<garyvdm> lifeless: but I guess that I can make it just get data from both the inventory, and what we got from iter_changes at the same time.
<jelmer> kirkland: no, it'll only work for manual imports
<jelmer> kirkland: I can upload my personal import though, if that would be useful
<lifeless> garyvdm: you should make it show a 'Tree' not an 'Inventory'
<lifeless> garyvdm: Inventories cannot have unknowns/ignored
<kirkland> jelmer: hmm
<lifeless> garyvdm: inventories in the bzr 2 format are immutable, you can't change them.
<kirkland> jelmer: glad to hear you have the bug fixed
<kirkland> jelmer: I'm mainly interested in this from a vcs-imports into LP perspective
<lifeless> garyvdm: and if you just want it to show the working tree, using the working tree extras and unknowns methods are much better than doing iter_changes
<lifeless> iter_changes is a delta operation, and you aren't describing a need to do a delta.
<jelmer> kirkland: Ah, ok. I'm not a lp dev, mwhudson, jml or thumper should be able to tell you when this would/could land.
<garyvdm> lifeless: But I also need to show a status for a changed item.
<kirkland> jelmer: so i'll lean on those guys to get it rolled out to LP :-)
<kirkland> jelmer: thanks for your help, as always
<mwhudson> it shouldn't be a big deal
<lifeless> garyvdm: oh ok. Well then yes iter_changes is appropriate
<mwhudson> jelmer: did you have to change dulwich too?
<jelmer> mwhudson: no, just bzr-git
<mwhudson> dead easy then
<kirkland> mwhudson: sweet
<kirkland> fwiw, this is the broken import: https://code.edge.launchpad.net/~vcs-imports/qemu/git
<jelmer> kirkland: Oh, I was actually talking about the live-helper one, not sure about qemu
<kirkland> jelmer: oh, hmm, i'm confused
<kirkland> jelmer: pointer?
<jelmer> kirkland: I'm sorry, I messed up two bug reports :-(
<kirkland> jelmer: heh!
<jelmer> although I guess my last round of fixes could've taken care of the qemu one as well
 * jelmer checks
<jelmer> cody-somerville: hi
<jelmer> cody-somerville: the live-helper imports should work now.
<cody-somerville> jelmer, w00t
<kirkland> jelmer: cool, let me know!
<cody-somerville> jelmer, Is this with the latest bzr-git or with the version launchpad uses?
<jelmer> cody-somerville: latest bzr-git as of a few minutes ago, not yet on lp
<jml> as a rule we don't run few-minutes-old code on lp :)
<garyvdm> jml: $ bzr qannotate .  >  bzr: ERROR: bzr qannotate only works for files (got 'directory')
<garyvdm> </brag>
<garyvdm> jml: would be cool if that was in bzrlib.
<ablmf> Which proxy does bazaar use on windows? IE or default browser's setting?
<lifeless> I think it only uses the http_proxy environment variable setting
<abadger1999> Any bzr-gtk people about?
<abadger1999> I just want to know what I need to package to go along with our bzr-1.16 release (a snapshot?  Which tree?  A patch?  Where?).
<jelmer> abadger1999: we should do a release at some point, but for now I'd package a snapshot of trunk
<jelmer> at least that's what I expect to end up doing for debian
<jelmer> kirkland: confirmed that qemu also imports fine now
<kirkland> jelmer: \o/
<kirkland> jelmer: thanks
<kirkland> mwhudson: cool, that getting rolled out to edge anytime soon?
<abadger1999> jelmer: lp:bzr-gtk ?
<jelmer> abadger1999: yep
<abadger1999> jelmer: Thanks!
<mwhudson> kirkland: no, there's no edge for code imports
<kirkland> mwhudson: ah
<mwhudson> kirkland: you'll have to wait for the rollout in c. a week
<kirkland> mwhudson: cool, thanks.
<jelmer> mwhudson: so, the only bug I'm aware of now is that submodules don't work. All other import bugs I'm aware of should be fixed now.
<mwhudson> jelmer: sounds good
<mwhudson> jelmer: what are submodules?
<lifeless> nested trees
<jelmer> mwhudson: gitspeak for nested trees
<mwhudson> ah ok
<mwhudson> i can understand why they don't work yet then :)
<igc> hi all
<ablmf> Oh,  I use "set http_proxy=http://10.0.0.3:80" to set the enviroment variable, but bzr still can not reach the repository.
<ablmf> Web access is OK.
<mwhudson> it seems to take bazaar quite a while to figure out that it needs to download all revisions when getting a branch for the first time
<mwhudson> it seems to be sending 30k get_parent_map requests :/
<mwhudson> (this is launchpad, so plenty of ghosts and all that)
<lifeless> mwhudson: bzr versions?
<mwhudson> lifeless: 1.16rc1 on both sides
<lifeless> odd
<lifeless> its meant to cache misses
<lifeless> file a bug, gather data, etc.
<spiv> mwhudson: also, I guess you're fetching into an empty shared repo rather than into a new standalone branch?
<mwhudson> spiv: you are correct
<mwhudson> spiv: i can try standalone in a bit if you like
<spiv> Well, that explains why it's doing walk_to_common_revisions, although why it's so slow is a bit of a mystery.
<spiv> mwhudson: standalone will be much faster; bzr in that case just asks the branch what the last_revision is, then asks the repo to send a complete stream for that revision.
<spiv> For that revision's ancestry, I should say.
<mwhudson> spiv: presumably the streaming itself will be the same
<spiv> Right, it should be.
<mwhudson> bah, seems to have stalled
<lifeless> mwhudson: we still want a bug
<lifeless> the 'shared repo is slower' is a defect we need to fix.
<spiv> lifeless: just need an "is_empty" method on Repository ;)
<mwhudson> lifeless: i was thinking of posting a .bzr.log when it's done
<mwhudson> lifeless: which it isn't yet
<lifeless> spiv: ENOTAFIX
<lifeless> mwhudson: start with a bug :)
<lifeless> spiv: or rather, EYETANOTHERPARTIALFIX
<spiv> Yeah.
<ablmf> My bzr refused to use proxy.  Nothing seems to work.  I set IE proxy.  I "set HTTP_PROXY=10.0.0.3:80", I "set HTTP_PROXY=10.0.0.3:80"
<ablmf> It just ignore all this and try to connect directly.
<lifeless> it should be in lower case, like 'http_proxy=http://10.0.0.3:80/
<spiv> ablmf: set http_proxy=http://10.0.0.3:80/
<lifeless> ablmf: note that 'lp:' URL's won't use the proxy
<lifeless> ablmf: its a known bug in the python xmlrpc library, which we haven't [yet] worked around
<ablmf> lifeless: Ah, then there is no work around now?
<lifeless> you can go to the elaunchpad website and get the bzr+ssh or http equivalent url for branches
<ablmf> OK.  I will try
<spiv> ablmf: use http://bazaar.launchpad.net/... URLs (or bzr+ssh://...) rather than lp: URLs.
<ablmf> But what is the full url of a lp:xxx ?  I can not find it on their web site
<lifeless> ablmf: go to code.launchpad.net/xxx
<mwhudson> spiv, lifeless: https://bugs.edge.launchpad.net/bzr/+bug/388269
<ubottu> Launchpad bug 388269 in bzr "getting a branch into an empty shared repository takes a long time to figure out revisions to send" [Undecided,New]
<spiv> mwhudson: thanks
<lifeless> ablmf: once on that web page, lcok on the branch  - the lp:xxx link there
<lifeless> then you'll be at
<lifeless> code.launchpad.net/<user>/<xxx>/<branchname>
<lifeless> in bzr you should use http://bazaar.launchpad.net/<the rest the same>
<ablmf> OK.  finally I found I should use "bzr info https://code.launchpad.net:443/oah"
<ablmf> Seems that 443 is required
<ablmf> It starts to downloading!
<ablmf> Thanks a lot.  But I really think it should be included in the "trouble shooting" in bazaar's document.
<poolie> mwhudson or others: do you care about the 'dots' progress bar type?
<mwhudson> poolie: no
<mwhudson> poolie: by 'mwhudson' do you mean launchpad?
<poolie> heh
<mwhudson> (either way the answer is still no)
<poolie> either way
<poolie> hello abentley
<RenatoSilva> How to apply a merge directive into a branch?
<poolie> RenatoSilva: cd ~/my/branch; bzr merge /tmp/mergedirective
<RenatoSilva> thanks, I'll try that
<RenatoSilva> bzr branch lp:bzr-email: FATAL ERROR: Disconnected: No supported authentication methods available
<RenatoSilva> why is it trying to authenticate?
<poolie> i think it's trying to pull from launchpad over ssh
<RenatoSilva> if I'm not logged then it should use http
<RenatoSilva> unless bzr launchpad-login is persistent
<poolie> it is persistent
<RenatoSilva> poolie: http://pastie.org/514743
<RenatoSilva> something like bzr branch --annonymous, and bzr lp-logout would be nice
<poolie> interesting point
<poolie> see bug 349143
<ubottu> Launchpad bug 349143 in bzr "no lp-logout command" [Low,Confirmed] https://launchpad.net/bugs/349143
<RenatoSilva> nice
<poolie> it shouldn't be an option to branch
<poolie> it could be eg lp+anon://blah
<RenatoSilva> or lpa:
<RenatoSilva> what'sa this message: Preview patch does not match changes
<RenatoSilva> when bzr merge
<poolie> the diff in the bundle is not what the metadata says it should be
<poolie> maybe because
<poolie> 1- someone edited the diff after running bzr send
<RenatoSilva> oh I just cleaned the screen :(
<poolie> ok
<RenatoSilva> I missed your 1s msg
<poolie> ?
<poolie> maybe because
<poolie> 1- someone edited the diff after running bzr send
<poolie> 2- you copy-and-pasted it and that messed it up slightly
<RenatoSilva> I created a branch and applied the directive
<RenatoSilva> oh I edited the diff!!
<poolie> :)
<RenatoSilva> it seems that it was applyed tough
<RenatoSilva> Preview patch does not match changes --> is this some kind of hash check?
<RenatoSilva> preview patch == the hash
<RenatoSilva> changes == the actual patch
<RenatoSilva> ?
<poolie> yes
<SuperMMX> I got this error after C-c "bzr shelve", bzr 1.14. http://paste.ubuntu.com/197472/ , any idea ?
<RenatoSilva> poolie: ah ok
<SuperMMX> anyone /
<SuperMMX> my dirstat get corrupted ?
<RenatoSilva> Hey! https://code.launchpad.net/~renatosilva/bzr-email/mail-customization :)
<SuperMMX> can anyone see my problem? (13:52:03) SuperMMX: I got this error after C-c "bzr shelve", bzr 1.14. http://paste.ubuntu.com/197472/ , any idea ?
<SuperMMX> I can't do anything useful now with my tree.
<vila> hi all
<Peng_> SuperMMX: Beloved dirstate got screwed up. I'd move .bzr/checkout out of the way and run "bzr checkout". I'm pretty sure it won't clobber your working tree, but not 100%.
<vila> jml: ping
<vila> jml: Where should I land https://code.edge.launchpad.net/~vila/bzr/284038-push-strict/+merge/7373 ? 1.16 or trunk ? It should apply cleanly in both (modulo NEWS conflicts)
<poolie> hello vila
<SuperMMX> Peng_, thanks, I will try
<jml> vila, busy right now, gimme a few minutes -- sorry
<poolie> vila, hi?
<vila> jml: np as long as you reply before the end of your day :)
<vila> poolie: hi !
 * vila swears about losing sound support in its VM...
<poolie> vila did you see my pm?
 * vila meant curse
<vila> ho !
<poolie> 'swears' means what i think you think it means there :)
<SuperMMX> Peng_: yes, it works, except some modified files are moved.
<jml> vila, I'll do that.
<lifeless> vila: if its not a regression, it should only be landed in trunk
<lifeless> vila: standard policy
<lifeless> [regression or otherwise deemed 'really important'
<ablmf> A problem when downloading code by brz : http://pastebin.com/d15ad9e89
<lifeless> I would guess you have in intercepting proxy where you are,  one that is broken (e.g. older versions of squid)
<lifeless> vila: ^ we *do* handle a 200 response to a range request correctly don't we?
<lifeless> poolie: EODing
<jml> vila, what lifeless said.
<poolie> bye lifeless
<vila> lifeless: 99% sure, want 100% ?
<lifeless> vila: huh?
<vila> lifeless: 200 response is a while file even if range was requested right ? So without looking at the code, I'm 99% sure
<vila> s/while/whole/
<lifeless> vila: good enough for me
<lifeless> sugguests that whatevere made it into a 200 broke on a subsequent request
<vila> lifeless, jml: Ok, I'll land to trunk then
<Peng_> I can confirm that getting the whole file is handled properly. I don't remember if the response was 200 or 206, though.
<lifeless> vila: you should only ever land to trunk FWIW. cherrypicks to release branches are separate ;)
<jml> vila, thanks.
<Peng_> (I mean, it's inefficient as hell, but it won't break anything.)
<lifeless> Peng_: if you ask for ranges and get 200, is the specific case.
<lifeless> 206 *is* a range response.
<Peng_> lifeless: Yeah, but it could be a range over the whole file. Or something.
 * Peng_ shrugs.
<vila> lifeless: right, you want 100%, let me look at when we issue that message :)
<Peng_> I am 100% sure -- I did it a few weeks ago.
<ablmf> Ah, it seems that the only way to bzr work for me is to find a computer which doesn't need a proxy to access internet.
<ablmf> Hope some day bazaar will be stable enough to avoid these kind of small problems. :)
<Peng_> (When testing Loggerhead's server, FWIW. Paste's static file server doesn't support Range requests -- or at least the version I have.)
<vila> lifeless: so that message is issued when we realized the problem and we warn only once
<vila> lifeless: if realized you EODed, but I'm not sure I understand: "sugguests that whatevere made it into a 200 broke on a subsequent request". Hmm, in fact I'm sure I don't understand :-)
<vila> Peng: can you shed some light ? The warning intent is to help people realize they get poor performance because their server... sucks :)
<lifeless> vila: see the pastebin ablmf linked
<lifeless> ablmf: bzr doesn't generally have trouble with http proxies; its just some proxy versions are broken.
<Peng_> vila: Me? It's dark over here. :P
<vila> Peng: sorry for the noise then
<vila> lifeless:  The warning intent is to help people realize they get poor performance because their server... sucks :) As in: without ranges many bzr optimizations are useless. Other than that the processing should be fine. Modulo broken proxies detection for which we never found a reliable way (AFAIR).
<lifeless> vila: yes, I know.
<lifeless> vila: but *see the pastebin*
<RenatoSilva> bug 388300
<ubottu> Launchpad bug 388300 in bzr-eclipse "Error after installing bzr-xmloutput" [Undecided,New] https://launchpad.net/bugs/388300
<RenatoSilva> what could that be?
<vila> lifeless: I have already read it twice, hoooo, the second part, invalid boundary, I need a -Dhttp for that, it may be two different requests
<vila> bah, launchpad involved, good server, so that's a broken proxy, 90% sure
<vila> ablmf: I'm pretty sure you have a broken proxy, as far as I recall, even issuing whole file requests may not be enough to cure your problem,
<vila> ablmf: try issuing the same command but adding '-Dhttp' so that we get more precise informations in .bzr.log
<vila> lifeless: sorry, I need one more coffee :-)
<ablmf> vila: ok, I am trying.
<ablmf> vila: Maybe I met a bad proxy, but it's good enough for surf internet.  And it also works fine with other version control tools.
<vila> ablmf: It will help if you can find what proxy software you're using, each time that bug has been hit in the past, upgrading the proxy was the true solution
<ablmf> :(  That's out of my control
<Peng_> ablmf: Bazaar over HTTP makes uncommonly large range requests, which some broken proxies can't handle.
<Peng_> ablmf: If you register on Launchpad, you can use bzr+ssh.
<vila> Peng: nope. the bug is triggered by small requests over very large files
<Peng_> vila: Oh. That's weird.
<vila> ablmf: and that's why it has such an impact on perfs, it will consume a lot more bandwidth
<vila> ablmf: knowing that may help address 'not under your control' by providing a really good reason to upgrade
<vila> ablmf: it's a company proxy right ?
<ablmf> vila: yeah, it's my company's proxy
<vila> ablmf: anyway, even if you can't upgrade, it will be good for us to *know* what software/version causes that (if only to report the problem0
<vila> ablmf: bzr triggers the bug, but the bogus proxy behavior (downloading whole files instead of ranges) can be experienced by other softwares without trigerring the bug
<ttyType> hi all
<vila> hi alone ;)
<ttyType> i am new to bazaar, having used SVN previously. i have read some stuff, and am wondering, is it possible for two people to "push" to the same branch server location(sftp)
<vila> ttyType: sure
<ttyType> ah, hmm
<ttyType> ok
<ttyType> ty
<vila> ttyType: additionally, if bzr is installed there, using bzr+ssh instead of sftp may provides better performances
<ttyType> vila: is that similar to the svn+ssh system, whereby an svnserve-like program is invoked on the server?
<AfC> ttyType: yes
<ttyType> ah, could be an issue. you see, my server has 32MB of RAM
<ttyType> and a 150MHz CPU
<ttyType> and no swap space
<lifeless> yes, could well be an issue ;)
<ttyType> with svnserve -t, it was just running out of memory
<AfC> (The same code is also invoked if you run bzr as a full-time standalone [read-only] server, bzr://)
<ttyType> i'm using one of these jobbies: http://bifferos.bizhat.com/
<ttyType> it's a little power hungry for it's MIPS, but it was Â£30
<vila> ttyType: forget bzr+ssh then :)
<ttyType> :)
 * vila notes that dumb server support rocks ;-)
<Peng_> So, um. I'm messing around with bzr+http's jailing, and I want to make sure I didn't screw up and make it horribly insecure. How do you think I should do that?
<ttyType> w00t
<AfC> ttyType: that looks like fun to play with
<ttyType> AfC: indeedy. sure it's not a powerful as a gumstix board, but doodd!!!! Â£30!!
<AfC> I was just going to suggest gumstix
<ttyType> actually, if i wanted that kind of power, i would probably use a beagleboard
<ttyType> same guts as teh gumstix
<ttyType> *th
<ttyType> *the
 * ttyType fails at typing
<ttyType> yeah, get a beagleboard, run a windows CE server :D
<ttyType> it's a shame the beagleboard has no ethernet :-/
<Peng_> spiv: ping
<spiv> Peng_: pong
<spiv> Peng_: about bzr+http jailing?  A good way to experiment would be with hitchhiker.
<spiv> Peng_: see if it lets you access unexpected stuff.
<Peng_> spiv: I wrote an evil monkeypatch that works (just for me, not for other users), and was hoping you could tell me if it's horribly unsafe.
<Peng_> spiv: http://paste.pocoo.org/show/123617/
 * igc dinner
<spiv> Peng_: that looks ok off the top of my head, please add it to the bug
<Peng_> spiv: FWIW, I made it a bit more paranoid by making sure it is a ChrootTransport.
<lifeless> Peng_: I don't know that that is beneficial, for all that its typical.
<Peng_> Paranoia is fun.
<Peng_> lifeless: Unless you meant something else?
<lifeless> it could be a ReadOnlyDecorator
<lifeless> legitimately I mean, you have three layers: t, readonly+, chroot+
<lifeless> and I don't know that forcing the chroot to the top is good
<Peng_> So, get rid of the paranoia?
<lifeless> I would
<Peng_> OK.
<Peng_> spiv & lifeless: Thank you! :)
<Peng_> This was only a few minutes of work. I really should've thought to do it 3 months ago. :\
<vila> Peng_: But shouldn't you add part of that 3 months of though to the few minutes of work ?
<lifeless> vila: ?!
<lifeless> what are you doing to bug 388020
<ubottu> Launchpad bug 388020 in bzr "UnknownErrorFromSmartServer when pushing (or committing to a bound branch) with 1.16rc1 " [High,Confirmed] https://launchpad.net/bugs/388020
<vila> lifeless: it was assigned to bzr-search, I've seen it without bzr-search, doesn't make sense to leave assigned to bzr-search, no ?
<lifeless> check the back traces
<lifeless> you have a different bug
<lifeless> UnknownError just means its an error that can't be translated
<lifeless> you really do need more coffee I think
<AfC> EINSUFFICIENTCAFFEINE
<vila> 2 backtraces out of the 3 doesn't involve bzr-search
<vila> Let me look my .bzr.log, right, mine seems to be triggered by bzr-email instead :-) ...
<lifeless> vila: then yours is a bzr-email bug
<lifeless> vila: my rule of thumb is 'file new bugs'
<lifeless> dups are easier to deal with than conflated bugs
<vila> lifeless: yeah, sorry, doing that right now
<vila> I didn't realize the error was generic (as mentioned, it was lost in the noise)
<ttyType> lo, all
<ttyType> is there a way to make bzr push via HTTP?
<ttyType> or any other protocol for that matter, just nothing that involves invoking something on the server that will suck up memory like svnserve does
<lifeless> ttyType: sftp:// is your best bet
<lifeless> you could use webdav if you want, but thats in a plugin
<ttyType> that's what i was going to do, but the only ftp servers in the opkg repo are vsftpd and pure-ftpd
<wgrant> sftp is over SSH.
<wgrant> It's not real FTP.
<ttyType> vsftpd fails, and pure-ftpd doesn't wanna do ssl for some reason
<ttyType> hmm
<wgrant> OpenSSH implements SFTP by default.
<wgrant> So you should just need an SSH server on there.
<wgrant> Which I presume you already have.
<ttyType> wgrant: indeed i do, but i tried doing svn+ssh before, and it just nommed all of my memory(32MB)
<wgrant> ttyType: svn+ssh and bzr+ssh actually execute svn or bzr on the server. sftp doesn't.
<wgrant> sftp just pushes the files up.
<ttyType> wgrant: ah! this sounds like what i want
<ttyType> so how do i set up the server to take sftp?
<ttyType> a link to a guide would be fine
<wgrant> ttyType: You don't need to do anything.
<wgrant> Just try pushing.
<wgrant> It should work.
<ttyType> wgrant: ah, hmmm
<ttyType> awesomes :)
<Peng_> ttyType: SSH servers usually have SFTP enabled by default.
<ttyType> wgrant: so where on the server's filesystem does the push go to?
<Peng_> ttyType: It's relative to the root.
<wgrant> ttyType: The root.
<ttyType> ah..hmmm
<ttyType> this sounds like a good idea
<wgrant> So, 'bzr push sftp://some.server/home/user/blah' would work.
 * ttyType disables pure-ftpd on his teeny linux SBC
<Peng_> ttyType: You can use sftp://server/~/relative/to/your/home
<fullermd> poolie: Already [not] done.
<ttyType> hi again, people
<ttyType> after pushing a revision via sftp to a server, how would i go about updating another branch to that?
<ttyType> (without redownloading the whole thing
<ttyType> )
<ttyType> like if it was on another computer
<poolie> cheers, goodnight fullermd
<fullermd> Good morning  ;p
<lifeless> ttyType: in that other branch, bzr pull <url>
<ttyType> lifeless: ah...hmm, well, i just googled around some more and found "bzr merge, and that seems to do it"
<ttyType> here's the output from my script, could i have a free sanity check from one of you people who knows what they are doing? http://pastebin.com/m5bb7ae37
<lifeless> you can use pull or merge depending on your needs
<lifeless> if you're moving from one machine to the other and back, push + pull is likely whast you want
<lifeless> if you're making concurrent edits you'll want to be doing push then merge+commit
<ttyType> lifeless: commit first, i imagine, otherwise merge gets upset about uncommitted changes
<lifeless> ttyType: doing a merge doesn't commit what it merged,
<lifeless> ttyType: so if you had uncommitted changes before merging, yes you should commit them first, but still do the commit after the merge.
<ttyType> you just said two opposite things i think :-S
<ttyType> lifeless: so..i would do commit -> merge  -> commit -> push
<spiv> ttyType: probably, yes.
<spiv> ttyType: the reason why you need to commit after merge is that merge *creates* uncommitted changes (the changes that are being merged in from the other branch).
<ttyType> spiv: i see
<ttyType> thanks
<ttyType> spiv: the commit after the merge is giving this:
<ttyType> aborting commit write group: PointlessCommit(No changes to commit)
<ttyType> bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow.
<ttyType> should i just ignore that
<lifeless> ttyType: then you had nothing to merge
<lifeless> ttyType: and the merge would have told you that
<ttyType> lifeless: isee
<ttyType> what is the difference between bzr branch and bzr checkout?
<lifeless> ttyType: branch makes a new branch [and sets you up to edit it]. checkout lets you edit an existing branch
<ttyType> lifeless: but both commands pull the repo from a server, and edit it, don't they?
<ttyType> s/and edit it/and let you edit it/
<lifeless> yes. In a new branch when yo ucommit the original branch isn't altered. In a checkout when you commit the origin branch *is* altered.
<lifeless> I'm heading off now
<ttyType> ok, bye
<ttyType> thanks
<fullermd> ttyType: For a checkout, you can think of the repo it pulls as just a local cache, to speed some things up.  It's not an independant branch, even though it has everything it needs to be.
<fullermd> Man, I speak up, and everybody quits or loses connection...   :(
<ttyType> fullermd: ah, i see
<ttyType> so what is bzr pull?
<ttyType> my synchronization process involves: add -> commit -> merge -> commit -> push
<ttyType> why would i need a pull?
<fullermd> pull is for updating one branch to contain what another does; think of it as 'mirror'.
<fullermd> This is as opposed to merge, which brings over the revisions from the other branch, and prepares them as a merge into your branch (which may have additional changes not in the other)
<fullermd> So, generally speaking, if you want to keep up a local mirror of another branch, you'd use 'pull'.  If you're doing work separate from another branch, but want to keep bringing in its changes and combining them with yours, you'd use merge.
<ttyType> ah ok, thanks
<ttyType> very helpfulz
<fullermd> I have my moments  :)
<ttyType> :D
<ttyType> ok, i have a problem
<ttyType> when i push to the server, it repushes all the files
<ttyType> is there a way to make it only push what it needs?
<fullermd> It generally does.  What makes you think it's repushing everything?
<ttyType> fullermd: because i moved 1 file into a folder, and when i ran push, it transferred 1530 or something
<ttyType> oh...wait, it appears to be not doing that now
<ttyType> i think it's because i have to do it once
<ttyType> ok, we are all done :D
<ttyType> and my script is working too :D http://pastebin.com/m23361a03
<ttyType> hi again
<ttyType> an odd thing i have noticed - if i have modified my main repository, and i merge to it on a different computer, the next push i do UPLOADS all that stuff to the server i merged from
<ttyType> :-S
<vila> ttyType: s/i merge to it /I merge *from* it/ ? 'all that stuff' what do you mean ?
<ttyType> vila: yeah,  i mean merge from it. and by all that stuff, i mean what came down in the merge
<ttyType> bzr for some reason sees a need to push it to the server
<ttyType> even though it's definitely present on there, because i merged from there.
<vila> bzr should push only the revisions that are not know on the remote server
<ttyType> vila: that's what i thought
<vila> if you commit locally, you create a new revisions, it should be pushed
<ttyType> indeed
<vila> so only that new revision is pushed, not the ones you merged
<ttyType> i committed to the remote host from another computer, and merged that host's repository with the local one of another computer
<ttyType> now, if i ask the other computer to do a push, it pushes everything that came down in the merge
<ttyType> which takes ages
<ttyType> if i do the push once, that seems to make it happy, and future pushes are only stuff the remote host DOESN'T have(like it should)
<ttyType> but the push itself is insanely long, and seems to take up extra space on my server!
<ttyType> s/server/remote host/
<ttyType> this is the sequence of steps i perform leading up to the push, which, if never done before, pushes everything: merge -> commit -> push
<ttyType> should i be using a pull command in there somewhere??
<Keybuk> bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr'
<Keybuk> hmmm... ;)
<beuno> Keybuk, yes, Launchpad isn't incredibly upgrade-friendly
<beuno> lftp into it, and delete the backup.bzr
<vila> jam: lp:~vila/bzr/gdfo-heads, I'll appreciate a reality check before going further and/or any talk about it and related impacts
<jam> vila: downloading now
<Keybuk> beuno: lftp into what?
<beuno> Keybuk, bazaar.launchpad.net
<Keybuk> beuno: with what protocol?
<Keybuk> quest scott% lftp sftp://bazaar.launchpad.net
<Keybuk> lftp bazaar.launchpad.net:~> cd /srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr
<Keybuk> cd: Access failed: No such file: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr'
<jam> vila: it is still a 2-pass
<jam> dict.fromkeys(nodes.keys()) == 1 pass
 * beuno tries to remember the magic encantation
<beuno> mthaddon, around?
<beuno> Peng_, ?
<vila> jam: not really all I need is *a* size, I don't process the nodes
<jam> 'dict.keys()" == 1 pass
<jam> it has to walk all the nodes to get the names
<beuno> rockstar`, do you remember how to lftp into Launchpad to delete a backup dir?
<vila> jam: strictly speaking, yes, but there alternates implementations for C
<vila> jam: alternatively I can use an attribute in each node, but doing that didn't change the perfs
<jam> vila: was it actually faster?
<jam> well, I guess you are competing with the C version
<vila> jam: not really, I tried to compare to your python version, but mostly I wanted to avoid processing a node more than once (do it right)
<jam> oh, and your impl is still a > 1 pass
<jam> for gdfo
<jam> since you walk all of "nodes.itervalues()"
<jam>  and *then* you walk all of pending + children
<jam> still 2 pass
<vila> jam: yes, but again, that could be pre-calculated for free at __init__ time if needed
<jam> vila: we only "_find_gdfo" 1 time during init
<vila> jam: right, but initializing pending can be done there without additional cost
<jam> vila: so ultimately, optimizing _find_gdfo is not the best spent time, though it is interesting, I'll admit
<jam> it is <800ms on OOo, and we are spending many *seconds* in heads()
<jam> so I would focus on making heads() faster.
<vila> jam: then have a look at heads then :)
<jam> For _find_gdfo() as long as it is correct, I don't really mind
<jam> Whatever method is reasonably fast, and easy to maintain.
<jam> (I realize I'm guilty of it, too :)
<jam> vila: does you're new version of heads() pass the whole test suite still?
<jam> I'm also guessing that our >2 heads tests are a bit incomplete
<vila> yes (the only failures are unrelated, one I mentioned while reviewing your patch, the other is about assertion (not mine :-P))
<jam> vila: KnownGraph has landed in bzr.dev, btw
<jam> so I think the main difference here is the "min_gdfo" change
<jam> and the fact that you don't track *which* parents have been seen at a node
<vila> jam: my fear too about >2 heads (but in other parts of the code)
<jam> just that it has been seen by someone
<vila> time_graph.py says: 0.220s instead of the previous 7.350s, what does that represent in terms of code validation ?
<jam> so... node.parent_keys can be None if the node is a ghost, I'm not sure that you would get that for a *candidate* node
<abentley> jelmer: For some reason, your merge directive for lp:~jelmer/trac-launchpad-migrator/merge didn't cause a branch to be created.  Do you mind sending me a copy of that email?
<vila> jam: I added tests for it
<vila> jam: but more importantly my question was did you leave parent_keys at None on purpose at __init__ time ? Or can we do that and get rid of the checks
<jam> vila: you have to explicitly walk the list again to set them to something else
<jam> I think it is *useful* to have a way to know that a node is a ghost rather than just has no parents
<jam> as for "time_graph"
<jam> we do assert the value is the same as the slow path
<jam> but only for the 'last' method
<jam> just a sec
<jam> I'll run it again and see
<jam> seems to still be correct for the bzr.dev revs
<vila> jam: so, should I try a pyrex version or cancel the pyrex version ? or do you want more tests for corectness ?
<jam> vila: so just adding "min_gdfo" to the pyrex version drops the time down to 0.137s
<jam> from 0.453s
<jam> (of the python version)
<jelmer> abentley: sure
<jam> so the pyrex version seems still a bit worthwhile
<jelmer> abentley: I sent a unsigned version of that merge request earlier that was refused, perhaps that's relevant?
<abentley> jelmer: Seems unlikely to be relevant.
<vila> jam: Err, I don't understand what modification you made. Just min_gdfo into your heads() version ?
<vila> jam: not the new algorithm ?
<jam> vila: just adding the "if parent.gdfo < min_gdfo: skip"
<jam> I sent you a patch
<vila> jam: ok
<jam> note that this doesn't seem to have a big impact on 'time bzr annotate' times, but it probably has a much more significant impact on the ancestry graph stuff
<jam> since you know you have unique heads there
<jam> I take that back. 11.2s => 10.1s for NEWS
<jam> vila: nice catch
<jam> the pure python version is 11.9s
<jam> so slower than the existing pyrex version for NEWS
<jam> though only just
<vila> jam: and there are more tricks I can do in C...
<jam> vila: btw, you should have "seen" be a *set* not a dict
<jam> no reason to set True everywhere
<jam> since you never set anything *but* true
<vila> jam: nice catch ! :-) I did two implementations, the first one was buggy :)
<jam> so thinking about using 'seen' rather than using the list of ancestors
<vila> jam: and more complicated...
<jam> let me think if I can come up with a way to break it
<jam> It does make things simpler
<jam> but I'm thinking of a case where you have 3-candidates that share some nodes, etc.
<vila> jam: Yes please ! The huge perf difference makes me more nervous than happy so far :-)
<jam> also, you don't use linear_dominators anymore
<jam> which is... maybe unimportant?
<vila> jam: I have no idea so far... it's just that I was cautious and could still be a useful optimization
<jam> well, it is more important when you are walking more ancestry
<jam> min_gdfo caps how far back you go, which is good
<vila> The more I think about them the less reason I see to break the new algorithm
<jam> I think it would be worthwhile to instrument to see how much linear_dominators, etc give us now that we have min_gdfo
<mthaddon> beuno: hi
<jam> and see if it is worthwhile
<jam> I can say that pyrex is faster than your implementation, but I don't know *why* :)
<jam> (something like 4x faster still... :)
<vila> jam: and was about my implementation in pyrex ? ;P
<vila> jam: I didn't try because: 1) I wanted some rough validation, 2) I've yet to deep dive in pyrex ;-)
<jam> so... I think your algorithm is always *correct* but in some cases it walks more of the graph than it needs to
<jam> maybe
<jam> we may need to always walk to min_gdfo anyway
<jam> in which case, it is minimal anyway
<jam> yeah, I think we do
<vila> the basic assumption is: a node can't appear in another node ancestry if they have the same gdfo
<jam> because you have to walk until you know that your current tips could not be children of all heads
<jam> and that is min_gdfo
<vila> yes
<jam> so even if 2 heads converge, if you have a third you have to walk until you know you don't have convergence
<vila> jam: yes, at first I thought about soring pending by gdfo, but it's useless anyway, then is difference the best way to exclude the seen keys ?
<vila> s/soring/sorting/
<jam> vila: so avoiding pop() only to push() is a 'niceity' that helps for very linear histories
<jam> which is one of the heapreplace tricks
<jam> otherwise you're right that sorting isn't particularly helpful
<jam> seen() grows with the size of the graph
<jam> while nodes.ancestor_of() doesn't
<jam> not a big deal
<jam> it is nice to use a structure that cleans up itself
<jam> rather than having to track "_cleanup"
<jam> (which grows with how much you walked anyway... :)
<vila> jam: One C trick I have in mind is that I can malloc(size(graph)) and free() at the end, (or even alloca() if available)
<jam> vila: easier to do in C than in Pyrex, since it wants to manage objects a bit differently
<jam> I have that comment "# slab allocate"
<vila> jam: since there is really no python involved in that method, may be C is relevant ?
<jam> vila: however, realize that PyMalloc does slab allocation as well
<jam> IIRC it does 256k allocations for objects < 256 bytes in size
<vila> jam: ha, that's the meaning of slab... I should have ask :-/
<jam> vila: "a slab" is a large chunk
<jam> http://www.google.com/search?q=define%3Aslab&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
<jam> at least in my head :)
<vila> jam: hehe, my dictionary gave me at least 6 different meanings, you usage in context was far more enlighting ;)
<jam> vila: sure, though realize that is how *I* use it, which may not conform to English standards :)
<vila> jam: ok :)
<jam> I think of a slab as something like a large block of concrete
<jam> sort of the key being "bigger than normal" and "all one big piece"
<jam> which seems to fit "slab allocate"
<jam> http://en.wikipedia.org/wiki/Slab_allocation
<jam> Actually, I think that fits just fine :)
<jam> So I guess it is standard terminology
<jam> And I wasn't just making it up
<vila> lol, once again, I reinvented the wheel (16 years ago in that case ;-)
<vila> this was, indeed, my silver bullet against fragmentation
<fullermd> Well, if people would stop making square wheels, we'd stop having to reinvent them  ;p
<jam> fullermd: but I like the way they go "bounce bounce bounce" down the road
<fullermd> That can be reproduced with round wheels and explosives...
<vila> or sinusoidal roads
<vila> jam: so, if the approach sounds conceptually sound, I'd like to continue with a pyrex version, submit that and then see about topo_sort
<jam> vila: I think the approach is quite good
<jam> I'm curious about linear dominators
<vila> jam: You're damn right ! Gee, I almost forget
 * vila still needs to optimize his revision belief system
<vila> jam: turning seen into a set is... slower 8-/
<vila> jam: argh, no, bad measure (aanotate NEWS is too big to be relevant)
<alaa_> hey guys. So silly question. I want to set up a central repo on a server where everyone has accounts. The repo needs to have universal write permissions, right? If we're using bzr+ssh?
<fullermd> alaa_: It'd have to have write to everybody one way or another.  Group probably beats world...
<alaa_> fullermd: thanks.
<Muttley> hi, I currently have a wordpress plugin in the bzr repository on launchpad. However I want to host the plugin with wordpress.org. Part of that is you have to use their subversion repository. I know I can use bzr to push my changes to SVN. However I'd still like to have them on Launchpad too
<Muttley> is it possible to push them to both?
<fullermd> Probably.  You can use bzr-svn to push a mirror of the bzr branch into svn, and just keep using bzr and updating that mirror 'once in a while'.
<fullermd> That's pretty simple.  It gets more complex if there's intended to actually be development happening in svn at the same time, but...
<Muttley> I suppose I could just push to svn when I have a new release
<Muttley> so to switch between where I want to push to I just put that on the command line? e.g. bzr push lp:blahplugin
<Muttley> or the svn address when i want to push to svn
<Muttley> and it remember the last one?
<fullermd> It remembers what you push --remember (or push when there isn't one rememeber yet).  You could type it manually when you want to do the svn mirror, you could bang up a bzr or shell alias for it, you could have a separate branch that you use just to gateway...   number of possibilities.
<Muttley> cool, thanks
<Muttley> I guess best option is to just use the svn when I'm doing a new release
<Muttley> happy enough keeping currently development in launchpad, it's just a requirement by wordpress for hosting your plugin
<fullermd> Oh, it probably wouldn't be too hard to just do it every few days, or whenever you've done a far bit of work.  A shell/bzr alias would make it pretty easy; "bzr push ; bzr push-to-svn"
<Muttley> fair enough
<Muttley> thanks for the help
<vila> jam: no list().extend() in pyrex ?
<jam> vila: nope
<jam> well, you can do 'foo.extend()'
<vila> haa
<jam> but no PyList_Extend
<vila> and sets ? http://docs.python.org/c-api/set.html says new in 2.5 ? wtf ?
<dash> before that, there was the 'sets' module
<jam> I'm pretty sure it is 2.4
<vila> jam: ok, not a big deal, it's only for 'seen' anyway
<jam> well, try it, see if it fails on PQM :)
<vila> jam: hehe, *you* are my pyrex PQM ;-)
<eydaimon> how can I show what files were modified in a particular rev?
<fullermd> eydaimon: `bzr stat -cREV`
<eydaimon> thanks
<alaa_> So looking for opinions. I want to keep a php website under bzr. So typically, apache would be serving the working tree. Is there anyway i can hide the .bzr dir?
<eydaimon> why is it using -c for the rev instead of -r?
<mario__> alaa_: htaccess? :p
<beuno> alaa_, you can use bzr-upload
<fullermd> eydaimon: A lot of commands have a -c.  -cREV is shorthand for -rparent:REV..REV.
<eydaimon> ok, thanks
<beuno> alaa_, which will just upload the files, not the repostory
<eydaimon> fullermd: understanding helps me remember :)
<fullermd> eydaimon: It doesn't make sense to say things like 'stat REV' or 'diff REV', since stat/diff/etc are for comparison between TWO revs.
<fullermd> eydaimon: So since you often want to ask "what changed in X relative to its parent", -c gives a convenient shorthand.
<alaa_> beuno: yes, i've used that before. i don't know why i'm thinking i'd like to do a bzr up within the working tree that is being served, but without the branch itself...that doesn't seem possible, right?
<eydaimon> fullermd: oh, I've been using just -r anyway, especially with diff. doesn't it default to the current head if nothing is specified?
<fullermd> eydaimon: Well, for stat/diff, with no arg given, it compares the base rev of the WT (which usually means the head of the branch) against the current working files.
<beuno> alaa_, right
<fullermd> eydaimon: Doing "stat -r5" would compare rev 5 against the current tree.  "stat -r5.." is the same as "stat -r5..-1", comparing 5 against the current head.
<alaa_> beuno: alright thanks.
<alaa_> mario__: thank you too
<eydaimon> fullermd: thank you much for taking the tim eto explain. I appriciate it :)
<volodya> Can I somehow make bzr-svn not do this "analyzing repository layout" step on each pull? Making cache enabled caused it to try fetch something about every single revision, eating >500MB of disk space.
<SamB> volodya: what version of SVN are you using?
<SamB> how did you create your working tree?
<SamB> and do you have commit access?
<bizarrefish> hi people
<volodya> good question. It is 1.5.1 locally. It is supposed to be 1.5 remotely (and I took extra painful steps to that effect), but I still got warning about "upgrade to 1.5", so maybe the repository is not upgradeted
<volodya> I've used "bzr branch URL trunk"
<volodya> I do have commit access.
<SamB> volodya: did you do a dump and reload of the repository ?
<volodya> no, that's why I suggest it's 1.4 still.
<volodya> it's probably not gonna happen soonish
 * SamB wonders if that can possibly be done incrementally
<volodya> unlikely, I'd guess.
<SamB> I find it rather easy to imagine how that could be done
<bizarrefish> i want to use bazaar to keep a personal repository for a few computers. i need to come up with a 'syncing' method, to synchronize each computer's repository with the master repository.
<bizarrefish>  so far i have this script for each machine: add -> commit -> merge with master repo -> commit -> push to master repo over sftp
<alaa_> Another question. I am using the upload plugin, and it is not preserving group ownership bits. Does anyone know why?
<SamB> alaa_: not preserving them between what and what ?
<volodya> SamB: but, do you expect 1.5 on server will stop bzr from analysing repository layout all over?
<bizarrefish> the problem is, say if during the merge, a file came down, when i do the final "push", that file would be re-uploaded to the master
<SamB> volodya: not sure
<volodya> or just make it so fast as to be unimportant?
<SamB> volodya: it's not the only way to get it tolerable, though
<alaa_> SamB: I need my files with www-data group and they are. but when i bzr upload them, it creates the files with my group.
<volodya> alternatively, maybe those 1000 revisions it analyzes can be cached -- without grabbing metadata of all 250K of revisions
<SamB> jelmer: is it possible to add a "bzr help svn-faq" topic?
<SamB> jelmer: or perhaps just include the FAQ's web address in "bzr help svn" ?
<volodya> SamB: FWIW, the bzr svn faq is unhelpful. Unless there is more than one FAQ
<jelmer> volodya: what's the problem exactly?
<jelmer> SamB: Perhaps a help topic would be useful I guess, though it'd be annoying to keep up to date
<volodya> jelmer: I've done "bzr branch URL trunk", and I had no-cache set for SVN repository at this time. Now, 'bzr pull' spends a minute analysing reposiotry layout. If I try to enable caching back, bzr pull appears to try get metainfo for every revision, which takes huge time.
<volodya> And in my earlier tries, caching of metainfo ate 500MB, and were not even half-way through
<jelmer> volodya: what version of bzr-svn?
<jelmer> volodya: do you have python-tdb installed?
<volodya> Bazaar (bzr) 1.15. I guess latest release in ppa.
<volodya> I don't have python-tdb
<huf> hi. how do i debug errors like this: [Wed Jun 17 18:28:53 2009] [warn] mod_fcgid: read data timeout in 40 seconds
<huf> i'm running a bazaar server with apache + mod_fcgid + a bzr-smart.py
<jelmer> volodya: I would recommend trying with python-tdb installed, that should reduce the size of the cache
<huf> and this python script seems to be dying hard
<jelmer> volodya: Do you have a slow svn server perhaps? The only thing that's done to guess the repository layout is basically 'svn log -v <url> --limit 300'
<volodya> jelmer: it appears to fetch around 2000 revisions; the server is across the globe. Why can't bzr remember guessed layout?
<jelmer> volodya: newer versions do
<volodya> jelmer: I assume those versions not in PPA yet?
<jelmer> volodya: actually, only development snapshots (also reduces the number of revisions that is fetched to 300)
<jelmer> volodya: the remembered guessed layout is used now, if the location you're pulling from matches that layout
<jelmer> volodya: you can set the layout to use explicitly and it won't try to guess it
<jelmer> volodya: even in 0.6.1 (which is what's in PPA I think)
<volodya> jelmer: command line option or config file?
<alaa_> Is it safe to expose the .bzr of a lightweight checkout on the web? I wouldn't want anybody to see the code or the history.
<jelmer> volodya: e.g. "layout = trunk0" in the right section in ~/.bazaar/subversion.conf
<volodya> jelmer: where are possible values are documented?
<jelmer> volodya: "bzr help svn-layout" has some explanation
<jelmer> volodya: actually, "bzr svn-layout" may be a better way to set this value
<jelmer> volodya: but at the moment it's readonly
<volodya> jelmer: thanks. Putting "branches = ..." in the subversion.conf stops guessing of layout from happening
<volodya> I'll now trying using bzr for real.
<huf> is there some place a bazaar smart server would log errors?
<jelmer> volodya: is this a very large repository? It seems quite unusual to have such a large cache file
<jelmer> volodya: e.g. the cache file for OpenOffice.org (270k revisions, 75k files in each tree) is "only" 380Mb
<volodya> jelmer: there's 250K revisions, it's hard to estimate the number of files.
<huf> what do you people do when a bazaar repo just shits itself and you can no longer commit to it?
<volodya> jelmer: but given that linux tree is just one of the components kept there, I'd imagine the total number of files to be fairly high
<jelmer> huf: why would you no longer be able to commit?
<huf> the only solution i know is to ssh to the server, remove the dir and push the whole thing from another mirror)
<huf> jelmer: how should i know? the smart server dies hard, and all i get back is a useless error msg
<huf> but even that is from the fcgi level, so it's just a timeout
<huf> we run into this once every few months
<fullermd> Never had such a thing happen.  But have you tried 'check'ing it?
<huf> bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://host/branch/.bzr/smart: Unable to handle http code 500: Internal Server Error
<huf> bzr check? on the server or remotely?
<fullermd> On the server, since remotely things are being questionable.
<jelmer> huf: nothing about the actual error in the apache logs?
<fullermd> Cut down the number of variables.
<huf> jelmer: nope. just that fcgi timed out and got no headers
<fullermd> How big a repo are we talking about?
<huf> 25M
<huf> so pretty small
<fullermd> So, somewhere between disk and bzr+http client, things are going screwy.  Doing a 'check' on the server would give you a pretty good guess as to whether the problem is in the branch/repo there.
<fullermd> If that's good, I'd try doing something with sftp:// or [non-bzr+]http://.  Then try bzr+ssh (to try the SS without the Apache/FCGI layers).  Add on layers until it dies.
<huf> if i rm the entire dir on the server and re-push it from a local branch, it works again
<huf> but i'm running the check now
<huf> check didnt report any errors
<fullermd> 'k.  So the branch/repo is itself probably fine.
<fullermd> What dies over the SS?  push, pull, commit, branch, anything you do?
<huf> fullermd: commit and push died, missing and up worked
<fullermd> Hm.  So, maybe the problem is just things that write?
<fullermd> Try a push over bzr+ssh, see if cutting out the CGI layer does anything.
<GPHemsley> Is there a specific format for tags?
<jelmer> GPHemsley: all modern formats support tags
<GPHemsley> I meant for tag names
<jelmer> GPHemsley: ah
<jelmer> GPHemsley: there are some conventions in use
<GPHemsley> hmm... can you not push tags?
<jelmer> GPHemsley: The two most common ones seem to be using the version number as the tag or using PROJECT-VERSION
<jelmer> GPHemsley: "bzr push" will push tags
<GPHemsley> even if there aren't any new revisions?
<GPHemsley> because that's what it says
<GPHemsley> it doesn't mentiont ags
<GPHemsley> tags
<jelmer> the message could be clearer
<jelmer> it did actually push the tags
<GPHemsley> OK, thanks
<GPHemsley> Is there a way to see them in Loggerhead?
<jelmer> GPHemsley: afaik not yet
<GPHemsley> k
<GPHemsley> jelmer: BTW, are you in charge of bzr-svn?
<jelmer> GPHemsley: yeah
<GPHemsley> or, subvertpy?
 * GPHemsley forgets
<GPHemsley> because I haven't been able to get it set up
<GPHemsley> subvertpy causes trouble
<jelmer> GPHemsley: in what way?
<GPHemsley> it doesn't compile
<GPHemsley> no matter what way I try to install it
<jelmer> GPHemsley: what platform are you on?
<jelmer> what errors do you get?
<GPHemsley> Mac OS X 10.4
<GPHemsley> oh
<GPHemsley> um
<GPHemsley> hang on
<GPHemsley> jelmer: Exception: Subversion development files not found. Please set SVN_PREFIX or (SVN_LIBRARY_PATH and SVN_HEADER_PATH) environment variable.
<jelmer> GPHemsley: do you have the subversion development libraries installed?
<GPHemsley> this is where I was getting into trouble
<GPHemsley> they're somewhere
<GPHemsley> but setting SVN_PREFIX via export doesn't do anything
<GPHemsley> and/or no, I don't, and I don't know where to get them
<GPHemsley> I've been through this a number of times that I don't even remember anymore
<jelmer> I don't know much about Mac OS X so I can only give you some generic pointers
<GPHemsley> ah, OK
<GPHemsley> also, I'm using Python 2.5
<jelmer> On Linux the distributions usually provide packages that include the Subversion development files, not sure if there's anything like that on Mac OS X
<jelmer> For Windows, you can download the headers from the Subversion web site
<GPHemsley> fink and MacPorts are the two main ones, I think
<GPHemsley> but I can't seem to find the right dev files
<jelmer> I think one of them was also packaging bzr-svn
<GPHemsley> it's possible, but even that wasn't installing because it couldn't compile
<GPHemsley> I think that's what I tried at first, using macports
<GPHemsley> but that installation errored out
<GPHemsley> so I tried to do things manually, with no more luck
<jelmer> GPHemsley: Sorry, I'm afraid I can't provide much help here. This sounds like it is Mac OS X-specific. :-(
<GPHemsley> Yeah, I think so
<GPHemsley> thanks, though
<jelmer> I know there's various people using bzr-svn on Mac OS X
<GPHemsley> I'm sure... but, for one thing, how many of them are on 10.4?
<GPHemsley> most are probably on 10.5
<jelmer> Some are on 10.4
<GPHemsley> ah, well, then IDK
<GPHemsley> Exported releases do not contain any bzr information, correct?
<bizarrefish> hi all
<bizarrefish> when i run "bzr push", it complains about not specifying a push location, how do i specify it?
<bizarrefish> is there a config file somewhere?
<fullermd> Just specify it on the command line.
<bizarrefish> i know i can just provide it like "bzr push sftp://someaddr/apath", but for some reason, that makes it PUSH the whole repository to the place i just branched it from :S
<beuno> bizarrefish, bzr push LOCATION
<fullermd> Well, pushing to the location you specify is what it's supposed to do  ;p
<bizarrefish> fullermd: but how can i make it just push changes?
<bizarrefish> rather than update the whole repo
<bizarrefish> the weird thing is that all subsequent pushes do just that
<bizarrefish> but the first push the branch ever does, pushes the whole thing, and that's.....annoying
<fullermd> If it's pushing the whole history, then you're pointing at at a location that doesn't already have a repo with the history.
<bizarrefish> fullermd: but i used that location to do bzr branch.
<bizarrefish> that's how i got hold of the local repo in the first place
<awilkins> Does SFTP still try packing once in a while?
<fullermd> Well, if you're just pushing back to the same location, you could shortcut the command line with 'bzr push :parent'...
<fullermd> It's certainly _possible_ there's a bug that causes it to push the whole history into a repository that already contains it.  It seems unlikely though.
<bizarrefish> ah, ok i have got it working.....somehow
<bizarrefish> the trick seems to be to do a push RIGHT after you create the branch
<bizarrefish> no adding, commiting, merging beforehand
<bizarrefish> then you can do all the adding, committing etc... you like, and the push works
 * fullermd is pretty sure something different is going on than you think.
<bizarrefish> fullermd: so am i
<bizarrefish> there is another interesting problem though - i have broken off a few big transfers in the past, and these half-revisions appear to be taking up some space on the filesystem
<bizarrefish> i know git has a prune thingy for this
<bizarrefish> is there an equiv for bzr@?
<bizarrefish> *bzr?
<fullermd> Not builtin, no.
<bizarrefish> right, ok....
<fullermd> In-progress uploads go into a staging dir somewhere and can probably be deleted manually.  Not sure, I've never had it happen.
<fullermd> Presumably the smart server will clean up stuff from broken connections, though that doesn't help when you're using dumb protocols.
<bizarrefish> fullermd: hmm, you are right, something different WAS going on
<bizarrefish> it seems i was simply creating the branch with a different hostname to which i was doing the push
<bizarrefish> even though they both point to the same host
<fullermd> That hardly seems that it would matter.
<bizarrefish> well, i'm giving them the same now, and it's not doing the peculiar "push everything" thing
<bizarrefish> fullermd: you are right again, i am incorrect
<bizarrefish> i just tried adding a file to the local repo, committing, then pushing to the server, and it's deciding to push everything there
<fullermd> What makes you think it's pushing everything?
<bizarrefish> it seems it only refrains from pushing everything as long as the local repo is the same as the remote repo
<bizarrefish> fullermd: because i added an empty file, and it's transferring dozens of megabytes
<bizarrefish> the whole thing is about 100MB at the moment
<awilkins> How big is the repository?
<awilkins> Is it because you are using SFTP?
<bizarrefish> awilkins: that would cause it?
<fullermd> Check the repository after the push is finished, I suspect you'll find one new smallish pack, not a new huge one.
<awilkins> Can you use the smart server? If you have SFTP access you are likely to also have SSH access? Can you get bzr installed on server?
<fullermd> It may well have to transfer a very large amount of information over a dumb protocol to figure out what it need to push.  And I think there's some bugorother that makes them worse than they have to be.
<bizarrefish> awilkins: the server itself has 32MB of RAM
<bizarrefish> fullermd: i see
<bizarrefish> :-/
<awilkins> Well, that could be awward
<bizarrefish> indeed
<awilkins> wakward
<awilkins> aGah, typing. Tired.
<fullermd> It has WHAT?
<bizarrefish> the server is about 1 x 2.5 inches big
<bizarrefish> it has a 1GB flash drive for a filesystem, and a 150MHz CPU
<awilkins> It's one of those wallplug things with a HD attached, yes?
<bizarrefish> nah, they don't make them for the UK
<bizarrefish> and those plug thingies have WAY more grunt than this
<awilkins> Router with a USB port?
<bizarrefish> (also more expensive)
<bizarrefish> this doohicky: http://bifferos.bizhat.com/
<bizarrefish> Â£30
 * bizarrefish couldn't let that pass
<bizarrefish> alas, it's x86, so it chomps 1 watt
<bizarrefish> for only 50bogomips
<bizarrefish> it's just sitting in my lounge at the moment, being warm
 * bizarrefish mutters something about ARM supremacy
<bizarrefish> aaanyway, i gotta be up early tomorrow. 'nite all.
#bzr 2009-06-18
<poolie> good morning spiv, igc, lifeless
<poolie> jam, are you still around?
 * Peng_ goes insane.
<mwhudson> Peng_: goes?
<Peng_> mwhudson: Good point. But now I'm even less sane!
<dash> isn't sanity just a one-trick pony anyway
<Peng_> Loggerhead is refusing to serve one branch over http. :\
<Peng_> Which is kind of annoying when I wanted to use that branch to *test* serving over HTTP. :P
<Laney> did bzr push --fixes disappear?
<poolie> fullermd: what do you mean by "inability to upgrade from dev formats"?
<spiv> Good morning.
<Peng_> Laney: --fixes is an option on commit, not push.
<Laney> Peng_: oh right, tahnks
<Laney> thanks
<fullermd> poolie: % bzr init --development6-rich-root x ; bzr upgrade --development7-rich-root x
<fullermd> For any permutation of dev6, dev7, 2a in the init/upgrade.
<fullermd> bzr: ERROR: Cannot convert to format <RepositoryFormatCHK2>.  Does not support nested trees
<fullermd> I don't know of a filed bug on it.  It's come up here and on the ML a few times; I was under the impression that somebody was working on it.
<fullermd> jelmer, maybe.
<poolie> could you search or file one please?
<mwhudson> poolie, fullermd: i think that bug is fixed in bzr.dev, from things i overheard
<fullermd> Well, the error I just posted is from trying it on my up-to-date bzr.dev...
<fullermd> (well, OK, I'm missing jam's win32 packaging fix, but I'm guessing that doesn't solve it ;)
<poolie> the upgrade bug?
<Peng_> mwhudson: ping
<mwhudson> Peng_: hi
<Peng_> mwhudson: Is it just me, or is Loggerhead serving .bzr over HTTP broken?
<mwhudson> Peng_: no idea
 * mwhudson tries 
<Peng_> bzr+http works (I just landed that), but regular old nosmart+http does not.
<fullermd> Well, nothing in my =bazaar-bugs is jumping out at me, so I guess there isn't one filed...
<mwhudson> Peng_: jelmer said something about the smart server support only working for standalone repositories, i think?
<mwhudson> standalone branches, sigh
<Peng_> mwhudson: Yeah, thanks to bug #348308, but my issue is HTTP.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<Peng_> It should be possible for Loggerhead to monkeypatch around that bug, but it's probably a bad idea.
<mwhudson> Peng_: yes, seems .bzr requests are 404ing
<Peng_> mwhudson: Thanks for confirming it.
<mwhudson> you know what would make loggerhead better?
<mwhudson> tests
<Peng_> I manually test several different things, but I never run the test suite. :P
<mwhudson> Peng_:
<mwhudson> Invalid url supplied to transport: "readonly+file:///home/mwh/canonical/repos/loggerhead/": local urls must start with file:///
<mwhudson> lalala
<Peng_> I was just going to say: NotBranchError: Not a branch: "readonly+file:///trunk/.bzr/branch-format/".
<fullermd> It's also kinda annoying how upgrade moves everything into backup locations BEFORE blowing up in that case...
<fullermd> bug 388727
<ubottu> Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed] https://launchpad.net/bugs/388727
<Peng_> mwhudson: Looks like both get_local_path and check_is_a_branch fail, in different ways. I'll file a bug.
<igc1> morning
<poolie> hello igc
<igc> morning poolie
 * Peng_ goes /away to eat.
<garyvdm> Hi poolie.
<garyvdm> poolie: create_by_apply_delta is only available in CHKInventory
<jelmer> garyvdm: You can also use Repository.add_inventory_by_delta()
<jelmer> garyvdm: which works on all repositories
 * garyvdm look
<garyvdm> Hi jelmer
<jelmer> hi Gary
<jelmer> I ran into the same problem trying to find what function to use for bzr-svn/bzr-git
<garyvdm> jelmer: I want to create a in memory inventory.
<garyvdm> jelmer: won't Repository.add_inventory_by_delta add an inventory to the repository?
<jelmer> garyvdm: yeah, it'll write out to disk
<garyvdm> i.e. write it to disk?
<jelmer> garyvdm: You can steal some of its logic though
<jelmer> garyvdm: which it uses to apply deltas to non-CHKInventory's
 * garyvdm looks :-)
<garyvdm> There's Inventory.apply_delta - I need to test if that just changes the inventory in memory, or to disk.
<jelmer> garyvdm: it changes in memory
<garyvdm> jelmer: even WorkingTree.inventory?
<jelmer> garyvdm: yeah, but you'd probably don't want to change that directly since WorkingTree would just return its own copy
<jelmer> garyvdm: WorkingTree.inventory.apply_delta() will not directly write out to disk, but will probably cause strnage behaviour
<garyvdm> jelmer: is there a way to create my own copy of the inventory?
<jelmer> garyvdm: you can make an in-memory copy of WorkingTree.inventory though, and apply the delta to that
<lifeless> garyvdm: in general no.
<lifeless> garyvdm: you shouldn't be working with Inventory
<lifeless> s/working with/mutating or modifying/
<garyvdm> lifeless: Hi
<lifeless> the only objects that should modify inventories are implementations of Repository or Tree
<Peng_> ...I just pulled down 1 revision of bzr.dev. It took 100 seconds, nearly all of which was bzr-search indexing. o_O
<garyvdm> lifeless: even a in-memory copy?
<Peng_> Sorry, _two_ revisions of bzr.dev.
<lifeless> garyvdm: an in memory copy of a working tree inventory is shared with the tree and will be saved when write lock is released
<lifeless> garyvdm: it is the trees /internal/ state
<lifeless> garyvdm: so no, you should *never* modify an inventory unless your code is part of the implementationof the appropriate Tree or Repository subclasss.
<Peng_> ...Wait a minute, why did Loggerhead work? Shouldn't the ProgressBarStack thing have broken it?
<garyvdm> lifeless: Is there not a way to create a copy that does not affect the internal state?
<lifeless> garyvdm: there is but its slow and expensive
<lifeless> garyvdm: and as previously noted Inventory can't represent the concepts you want like unversioned or ignored files.
<garyvdm> lifeless: ok.
<garyvdm> lifeless: btw - I was wrong about iter_changes returning ignored files. It does.
<lifeless> :)
<garyvdm> That makes things easier for me :-)
<lifeless> jml: perhaps this channel works for you?...
<garyvdm> lifeless: would it be safe to set a new instance var on a inventory item? e.g. tree.inventory[fileid].status = "modified"
<lifeless> they use slots; it won't work.
<garyvdm> ok
<lifeless> jelmer: what does alioth need
<lifeless> jelmer: in more precise terms than 'another config file'
<poolie> jml, as you probably saw, there are some new bugs targeted to 1.16
<Peng_> Pulling another revision of bzr.dev took 45 seconds. Again, almost all bzr-search. :\
<Peng_> Are bzr.dev's search indices supposed to be 61 MB?
<dash> indexing is hard
<Peng_> 18 MB is just from the last 2 days.
<Peng_> lifeless: ping ^
<lifeless> Peng_: yes
<lifeless> Peng_: can it be shrunk? yes. There are several things that can be done. The index contents can be revisited now we have faster facilities for 'what path is this fileid.revisionid at'.
<lifeless> We got to bit indices rather than int indices
<lifeless> we can filter extremely common terms[though this is not necessarily a win]
<Peng_> I don't really mind the index size. What I mind is that 1/3 of it is from the last 2 days, and indexing during pull is taking 40-45 seconds per revision of bzr.dev.
<Peng_> Maybe it autopacked?
<lifeless> Peng_: so it autopacks
<lifeless> I really doubt that 1/3 is new from 2 days of changes
<lifeless> further, indexing requires extracting much data and we're not in bbc yet.
<Peng_> Yeah, you're right. I just checked the obsolete directory. ~4.3 MB from the last week.
<Peng_> No crisis, then, I guess. :)
 * Peng_ /away!
<thumper> do we have a way yet to say "Don't stack" even if the remote server suggests a branch to stack on?
<lifeless> no
<thumper> arse
<lifeless> not exactly a common use casse
<lifeless> if the server is misconfigured, fix it :)
<thumper> the server isn't misconfigured
<thumper> sometimes we want to say this
<lifeless> sure; like I said its not _common_.
<jelmer> lifeless: somethin that can run as a system service basically
<lifeless> jelmer: BZR_HOME=/etc/bazaar
<jelmer> lifeless: something sustainable, not a quick hack
<lifeless> jelmer: that is sustainable
<jelmer> lifeless: at the very least it would be nice if that was more easily accessible, e.g. serve-branches --config=foo would do BZR_HOME=foo under the covers
<lifeless> jelmer: that would be problematic for me
<lifeless> because it makes BZR_HOME=foo server-branches --config=foo less clear
<jelmer> lifeless: also, it's a bit redundant to have every variable in a configuration file prefixed with "http_"
<lifeless> jelmer: that seems unnecessary and likely inaccurate - public_url's etc should be from the stock bzr information
<jelmer> lifeless: loggerhead prefixes all its variables with http_ in ~/.bazaar/bazaar.conf at the moment
<jelmer> lifeless: this specifically is about those variables, not about whatever would usually live in .bzr/branch/branch.conf
<lifeless> jelmer: well, up to beuno etc. I don't think a specific config file is a good idea though.
<lifeless> Because using the stock stuff lets you use locations.conf to configure different loggerhead servers
<lifeless> and if a global config is needed, well there is a bug open on bzr to support /etc configuration already.
<jelmer> lifeless: I don't see how locations.conf is related here, this isn't about branch-specific settings
<lifeless> I definitely think BZR_HOME will work reliably for alioth
<jml> poolie, yeah, I haven't had a chance to look at them yet today, but I will
<lifeless> jml: testresources: review requested.
<jml> poolie, I haven't had a chance to do anything other than _react_
<jml> lifeless, yeah, I saw the email and flagged it for answer.
<jml> with luck & a spare energon cube I'll get it done tonight.
<poolie> all jml, you don't need to look at them now, just making you aware
<jml> poolie, cool :)
<jelmer> lifeless: alioth wants a backport package with init script etc they can use, but I'd like to see loggerhead settle on something first so I don't have to worry about providing an upgrade path in two months
<AfC> I see a lot of conversations in Git projects (cairo being the present instance) saying things like "rebase your work to current master" as a long lived branch gets closer to being considered for acceptance into the project.
<AfC> Isn't that just "hey, merge current 'mainline' into your branch, please"? Followed by healthy use of things like `bzr diff -r ancestor:....../mainline` ?
<lifeless> jelmer: I don't see why BZR_HOME would stop working.
<lifeless> AfC: in bzr we would just merge yes. because that preserves prior testing etc.
<AfC> lifeless: (not to mention not creating new revisions that say exactly the same thing). Ok, that's what I thought.
<lifeless> AfC: rebasing deletes test results :). If it wasn't long lived, and would just a short lived private branch rebase would matter a lot less.
<AfC> lifeless: is it because of their "I want to see individual patches building towards a result which are the only thing I'm [to be] looking at" culture?
<lifeless> yes
<AfC> hm
<lifeless> which is the history presentation aspect of the RFC I put together
<lifeless> and it *is* easier to review a series of small patches than a single monolith
<AfC> So, while I'm over that, I do wonder what on earth we can do to make Bazaar acceptable to that desired workflow [without needing rebase]
<AfC> lifeless: granted
<lifeless> looms
<AfC> hm. Yeah, I guess
<lifeless> thats what they are designed for
<AfC> ah
<lifeless> implementation bugs and polish aside
<lifeless> I do think we need rebase as a core polished utility
<lifeless> but we need to have versioned versions of the same tools for when people are collaborating
<AfC> lifeless: so taking a slightly different gloss on this, if individual patch or revision {1,more} cherry picking worked in some way that explicitly and strongly said "this Â«newÂ» revision came from and essentially is _that_ revision"
<AfC> lifeless: then rebasing (hypothetically using that) would be a lot less evil to us.
<AfC> s/us/our viewpoint/
<AfC> [right?]
<AfC> I realize that "what tree state did you test" is very important... but if we can have a dotted line between "what I'm merging" and "what actually was tested by its author" maybe things would be ok
<AfC> dunno
<lifeless> AfC: I think such cherrypicking would be necessary but not sufficient
<lifeless> merge is the key
<AfC> [I do know that I don't think I'm going to be able to work on any Git based projects ... the DVCS culture I've been taught here is too different from what goes on there]
<AfC> lifeless: (well, cherrypick as in `bzr merge ../other_branch/.../filename`
<AfC> cherrypick is another brutal overload around here
<lifeless> AfC: merging *after* the cherrypick for people that had merged the original revision
<AfC> up there with history editing ^W commit message fixing
<jelmer> lifeless: If loggerhead started reading settings from some other file, I wouldn't necessarily expect it to also check http_* in BZR_HOME/bazaar.conf
<lifeless> mwhudson: ^ can you reassure jelmer
<AfC> lifeless: yeah, after
<AfC> lifeless: that really is the key, isn't it
<lifeless> its easy to cherrypick
<lifeless> its relatively easy to record that you did
<mwhudson> lifeless: this hasn't been my work, i have no real opinions
<AfC> lifeless: (I would be impressed if I didn't have to because the tool & it's UIs did said recording for me)
<jelmer> lifeless: Or to put it in a different way, I wouldn't expect apache to read settings from /root/.apache.conf either by default
<lifeless> its still freaking-hard to merge the cherrypicked thing accurately without security issues or spurious conflicts
<mwhudson> though i prefer reading http_* options from a bazaar.conf to inventing our own formats and locations
<jelmer> lifeless: and not have an easily disocverable way to override that
<lifeless> mwhudson: has there been a release of loggerhead that does
<AfC> lifeless: so I gather.
<mwhudson> lifeless: no
<AfC> Right. Lunch time rush at this cafe. Time to move.
 * mwhudson is not paying attention here any more, sorry
<mwhudson> send me email if you want a conversation on this
<Peng_> When pulling, what happens after post_change_branch_tip hooks fire? In other words, if the hook throws an exception, what didn't happen? E.g., it looks like the branch updated correctly, but not the working tree.
 * Peng_ randomly goes /away again.
<lifeless> right
<lifeless> update to recover
<RenatoSilva> if I clone a branch, and that branch is updated after I did a few commits on the clone, what should I do to merge the clone with that branch?
<garyvdm> RenatoSilva: Clone? did you do a checkout, or branch?
<garyvdm> RenatoSilva: if you create a checkout, you can do bzr update. If you did a branch, you can do bzr merge.
<RenatoSilva> by clone I mean bzr branch
<lifeless> RenatoSilva: you can bzr pull, if no changes were made to the origin branch in the interim, or you can (bzr merge; bzr commit)
<RenatoSilva> imagine the original branch is at rev 40, then I copy it and commit 5 revisions (my local branch is now rev 45), but in the meatimeremote branch was updated and is now in rev 43. A merge between the branches woulnd't get confused?
<lifeless> not at all
<lifeless> its what bzr merge is meant to be used for
<RenatoSilva> yeah I can do a bzr pull, but what happens if I don't?
<RenatoSilva> bzr merge will pull the changes before merging?
<spiv> You can't do bzr pull (try it), it will tell you it's can't pull because the branches have diverged.
<spiv> So you need to bzr merge, because you changes to merge.  It won't get confused, because bzr is not CVS :)
<krisfremen> lol
<spiv> s/you changes/you have changes/
<RenatoSilva> spiv: ok
 * igc lunch and medical appointment - bbl
<RenatoSilva> can multiple tags point to the same version?
<lifeless> yes. technically to a revisionid
<garyvdm> lifeless: how come item.revision for a item from a WorkingTree.inventory is allways none?
<garyvdm> Could it not tell you the revision from the basis tree?
<spiv> jml: I'm working on https://bugs.edge.launchpad.net/bzr/+bug/388675, do you want this fix in 1.16?
<ubottu> Launchpad bug 388675 in bzr "automatic stacking format upgrade doesn't work over the smart server" [High,In progress]
<spiv> jml: I have the issue diagnosed and a quick fix, just making proper patch with tests etc now.
<ablmf1> I typed "bzr branch lp:oah/gst-plugins-base", it starts to download, but it only download a directory containing ".bzr", nothing else.  Where is the code?
<lifeless> garyvdm: the working inventory doesn't have that data
<garyvdm> :-(
<garyvdm> I'll just have to hide the revision columns when showing the wt.
<lifeless> garyvdm: the basis inventory does (but we're looking at getting rid of most of the basis inventory stored in the tree because we don't need to look at it very often, its largely dead weight)
<ablmf1> [###########/        ] http >   2638KB     3KB/s | Copying content texts:Copied
<ablmf1> It looks like it have download a lot things
<lifeless> ablmf1: it's building a local bzzr branch. Once it has the history it will build the working tree
<ablmf1> lifeless: Should I wait till all the progress bar reach the end
<ablmf1> or should I give up now?
<lifeless> ablmf1: wait
<lifeless> ablmf1: its all working normally
<Peng_> ablmf1: Why do you want to give up?
<ablmf1> Peng_ : because it has been downloading for 20 m but only give me a .bzr ...  Quite slow to access lp from here
<lifeless> ablmf1: it *only* does a .bzr until right at the very end
<lifeless> ablmf1: thats normal.
<RenatoSilva> ablmf1: the .blz contains the whole history
<Peng_> Hmm, that branch is like 25-30 MB.
<RenatoSilva> s/blz/.bzr
<ablmf1> Is there any quicker way?
<lifeless> ablmf1: if you're using http, you probably have a broken http proxy, based on the discussion from yesterday.
<ablmf1> lifeless: No.  I am the one discussing proxy with you yesterday.
<ablmf1> Toady I stayed at home for downloading the source code I need
<lifeless> ablmf1: do you mean yes?
<lifeless> oh, ok.
<lifeless> so anyhow
<lifeless> over http bzr has to do many readv operations
<lifeless> it shouldn't be *that* slow
<ablmf1> svn has a "svn export" command which do not download the history
<ablmf1> does bzr have one?
<RenatoSilva> It would be nice to download branches as zip files
<lifeless> RenatoSilva: loggerhead can do that; its just not enabled on launchpads logerhead
<lifeless> ablmf1: bzr has one, but it works by downloading the history
<RenatoSilva> lifeless: good to know
<lifeless> ablmf1: (svn doesn't download history *ever* anyway, svn export isn't as different as you might think)
<RenatoSilva> Well, I just merged a directive to a branch, and it opened a file with the commit messages of the patch now that I'm trying to commit the directive changes
<RenatoSilva> -- This line and the following will be ignored --, what should I do? The command is waiting for the text editor.
<lifeless> You should type in a commit message above the line
<lifeless> whatever you want to say about the merge.
<RenatoSilva> was this caused by an empty bzr commit as I did?
<lifeless> no
<lifeless> its normal
<RenatoSilva> if I did, it would be 2 commit messages then?
<RenatoSilva> if I put a message I mean
<dash>  
<garage_seb> i messed up, but i dont know how much damage i caused
<ablmf1> [###########\        ] http >   6861KB     6KB/s | Copying content texts:Copied
<garage_seb> i have a server with a shared repo with a bunch of related branches in it
<ablmf1> It looks like it has download 6MB
<ablmf1> But I only find 200kb in the working directory
<garage_seb> on a development machine i have another shared repo with copies of those "central" branches, plus a bunch of local branches branched from them
<garage_seb> my mistake was:
<garage_seb> i accidentally pushed one of the development branches from the devel machine to the *repo* dir on the central server without specifying a target branch dir
<lifeless> RenatoSilva: huh? You'll only get one commit message.
<lifeless> RenatoSilva: I don't really understand what you're asking.
<lifeless> ablmf1: you could try stracing the process to see what is happening
<lifeless> ablmf1: as for how much is in the working directory, there are buffers on whats written to disk and so on; I assure you if you let it finish it will have achieved what you want.
<RenatoSilva> lifeless: bzr commit -m "message 1", then shows text file, then I type in the file "message 2"
<garyvdm> RenatoSilva: You may find it easier to use bzr qcommit - This shows a gui for commit
<wgrant> garage_seb: I don't think that should break anything. Has it?
<RenatoSilva> lifeless: the merge will contain all directive commits? Is it smart enough?
<lifeless> RenatoSilva: it should not have popped up an editor if you used -m
<RenatoSilva> lifeless: oh, so...was this caused by an empty bzr commit as I did?
<RenatoSilva> lifeless: the answer is yes
<RenatoSilva> you had said no and I get confused :)
<lifeless> empty can mean 'no message' or 'no changes', I thought you meant the latter.
<RenatoSilva> lifeless: ok sorry, my mistake then :)
<RenatoSilva> it all makes sense now :)
<lifeless> cool
<RenatoSilva> btw, it will never allow empty message?
<lifeless> I don't think so
<RenatoSilva> bzr: ERROR: empty commit message specified
<RenatoSilva> after I just closed the file
<lifeless> thats right
<lifeless> if you're doing a merge
<lifeless> write a message describing what you are merging. You can skip the details as they will still be present in the commits you are merging.
<RenatoSilva> ok, then it will deny only for merges
<spiv> ablmf1: also, there's some overhead in figuring out what content to transfer before it actually transfers the content.
<spiv> ablmf1: especially over a dumb transport like http
<spiv> ablmf1: so you may well find that the final size on disk is noticeably smaller than the total network traffic.
<lifeless> spiv: with readv batching it should be 1-2% no more
<lifeless> for an initial branch
<garyvdm> lifeless, poolie, jelmer: Thanks for the advice. I have achieved what I wanted to (a browse tree widget, that shows unversioned files and change status)
<RenatoSilva> I think as they're little changes, it makes more sense to aplly them manually, because I just have to reason to give a bout the merge. The reason is just because they were 2 commits at work, and I couldn't push them there :)
<lifeless> RenatoSilva: if you haven't made local changes you can just pull from the directive
<RenatoSilva> s/to reason/no reason
<lifeless> rather than merging
<RenatoSilva> humm, nice!
<garyvdm> lifeless, poolie, jelmer: If you are intrested in what I have done, the code it here: http://bazaar.launchpad.net/~garyvdm/qbzr/trees/annotate/head:/lib/treewidget.py
<RenatoSilva> how do I undo the merge?
<RenatoSilva> bzr revert?
<lifeless> RenatoSilva: yes
<lifeless> 'bzr revert'
<RenatoSilva> ok
<RenatoSilva> bzr: ERROR: These branches have diverged. Use the missing command to see how. Use the merge command to reconcile them.
<lifeless> so you do need to merge
<RenatoSilva> bzr missing > Using saved parent location: bzr+ssh://bazaar.launchpad.net/~renatosilva/bzr-email/mail-customization/ Branches are up to date.zr+ssh >      0KB     0KB/s |
<lifeless> I would just merge them with -m "Small fixes from work" or some such
<RenatoSilva> ok but I'm trying to learn :)
<RenatoSilva> Hummm let me see...
<RenatoSilva> The work branch is a branch from bzr-mail!
<RenatoSilva> My branch here is the mail-customization
<RenatoSilva> You can skip the details as they will still be present in the commits you are merging. --> actually they're not there :(
<RenatoSilva> After my last commit comment from lp, the next one is from the merge.
<lifeless> RenatoSilva: run bzr log -n0
<RenatoSilva> it is in rev 41 in lp, there were 2 revs in the merge, but when I commited I'd expect the local branch go to rev 43
<garyvdm> RenatoSilva: try running qlog
<garyvdm> err - bzr qlog
<lifeless> RenatoSilva: have you tried running log -n0
<garyvdm> You should be able to expand rev 41 - under it you will see the revisions that you merged.
<seb_> lifeless, any words of wisdom on the situation i reported above, in a previous incarnation when i was known as garage_seb?
<RenatoSilva> bzr log -r40..
<lifeless> RenatoSilva: with "-n0"
<lifeless> so "bzr log -n0 -r40..
<lifeless> "
<spiv> seb_: did you see wgrant's question?
<seb_> oops no that must have been while my dsl modem blinked out :-(
<lifeless> seb_: nothing should be broken
<spiv> seb_: < wgrant> garage_seb: I don't think that should break anything. Has it?
<seb_> oh good :-)
<seb_> things seem to be working just fine
<lifeless> seb_: if you want to get rid of the branch you pushed, you can remove the .bzr/branch directory it will have created
<seb_> heh, i just did that and things *still* seem fine
<RenatoSilva> http://pastie.org/515988, http://pastie.org/515990
<lifeless> [but be sure to leave .bzr/repository alone, as that is your shared repo :P]
<seb_> ok thanks guys :-)
<seb_> yes i didnt remove that one
<lifeless> RenatoSilva: right, in 515990 you can see the messages
<RenatoSilva> lifeless: so, the merge revisions become sub-revisions?
<spiv> jml, mwhudson (and anyone else interested): https://code.edge.launchpad.net/~spiv/bzr/default-stacking-again/+merge/7601 fixes that stacking bug.
<mwhudson> spiv: is it client side or server side?
<lifeless> RenatoSilva: yes, thats a reasonable way to think about it
<lifeless> mwhudson: client
<mwhudson> cool
<RenatoSilva> lifeless: ok thanks
<lifeless> this is one of the key, critical diferences vs CVS
<jml> spiv, thanks, I'll take a look at it.
<spiv> mwhudson: client
<spiv> Oh, I'm too slow today :)
<RenatoSilva> pushed \o/
<garyvdm> RenatoSilva: have you tried bzr qlog?
<RenatoSilva> garyvdm: yes
<garyvdm> RenatoSilva: And? did it help?
<jml> spiv, thanks I'll take a look at it.
<jml> spiv, sorry for the lag -- I needed to have a lunch break afk :)
<spiv> jml: I understand :)
<RenatoSilva> garyvdm: now yes, I didn't note the "+"
<spiv> jml: I'm actually planning on doing the same shortly :)
<RenatoSilva> garyvdm: nice view, thanks! btw, Qt for windows?
<garyvdm> RenatoSilva: qt is multi-platform
<garyvdm> RenatoSilva: used by KDE
<RenatoSilva> garyvdm: oh I didn't know that, the widgets look pretty native
<RenatoSilva> garyvdm: it's embedded in bzr installer?
<garyvdm> RenatoSilva: yes
<RenatoSilva> garyvdm: ok, thank you!
<garyvdm>  /quit zzzzz
<mwhudson> spiv: thanks for fixing that bug so quickly :)
<spiv> mwhudson: once I untangled the particular confusions it wasn't too hard.
 * spiv -> lunch
<RenatoSilva> Does TortoiseBzr use Qt?
<RenatoSilva> I'm afraidn to install it, because TortoiseCVS was not working well
<poolie> lifeless, spiv, the bug editing collisions were i think bug 28459
<ubottu> Launchpad bug 28459 in malone "Handle mid-air collisions in bug reports" [Low,Triaged] https://launchpad.net/bugs/28459
<lifeless> poolie: our one wasn't, unless you'd had the bug open for 30 minutes or so... I guess that is possible ;)
<lifeless> poolie: still, its a nice low bug number ;)
<vila> hi all
<poolie> i did have it open
<poolie> because, probably someone started talking to me
<poolie> also i was wondering what the magic number at the start was
<poolie> hello vila
<poolie> lifeless, re bug 308403,
<ubottu> Launchpad bug 308403 in bzr "bzr add should optionally fail if explicitly named files are ignored" [Medium,Confirmed] https://launchpad.net/bugs/308403
<poolie> do you in pracitice commonly add files matching ignore patterns?
<vila> hi poolie
<lifeless> poolie: Its not that I commonly do it; its a design principle I have.
<lifeless> poolie: which is that its better to do whats asked and make reverting mistakes easy.
<lifeless> poolie: and we already have that.
<lifeless> poolie: I don't object to bzr add having a --strict mode or something for people that prefer to have the command fail.
<poolie> mm maybe there should be a global --strict
<lifeless> Stopping on many little things and forcing things to be re-run is just irritating in my experience. Clippy leads down that road ;)
<jml> some people like being irritated.
<jml> perverse creatures that they are
<lifeless> jml: Whats better for most of our users is the question.
<jml> lifeless, I thought we were talking about an option?
<lifeless> jml: Yes but: a) An option has its own overhead. b) options have defaults so they need to be chosen.
<poolie> so specifically i want some satisfactory solution to bug 322767
<ubottu> Bug 322767 on http://launchpad.net/bugs/322767 is private
<poolie> which complains about people adding conflict files
<lifeless> .BASE/.OTHER/.THIS
<poolie> blocking adds of ignored files is a somewhat indirect way to stop it
<poolie> yes, and .moved
<lifeless> so
<lifeless> doesn't commit abort on conflicts?
<poolie> yes, of course
<lifeless> and doesn't resolve delete those files?
<poolie> it's kind of user error
<poolie> people are apparently just banging harder on it to resolve the conflicts
<lifeless> well, specifically, I'm confused about *how they manage it*
<poolie> because, i guess, they're confused
<poolie> how they manage to do it?
<lifeless> right
<lifeless> running bzr resolve should delete those files; commit won't work until they have resolved, and then the files should be absent.
<lifeless> So my first instinct is 'what bug in the resolve->commit cycle is permitting this to happen'
<poolie> so
<poolie> they may do 'bzr add foo.c.OTHER'; bzr resolve ;bzr commit
<poolie> but why wouldn't resolve delete them?
<lifeless> exactly.
<jml> lifeless, on https://bugs.edge.launchpad.net/bzr/+bug/388727 you suggest that it's not critical for 1.16 because it dev6->2a works, but later it's revealed that it doesn't work. Does that mean it probably should be critical about it?
<ubottu> Launchpad bug 388727 in bzr "upgrade fails between dev formats" [High,Confirmed]
<jml> s/about it/for 1.16/
<lifeless> jml: depends on whether we plan to delete dev6 during 1.17's cycle.
<lifeless> if so we really have to fix the upgrade for 1.16
<lifeless> if not, it would be good but isn't life-ending if we don't, IMO.
<jml> do we plan to delete dev6 during 1.17?
<lifeless> I think it is reasonably important to make dev6->2a upgrade ok.
<jml> poolie, thoughts?
<poolie> jml, i'd be most concerned to know whether it's because of an actual inconsistency in the format
<poolie> as the patch seemed to indicate
<lifeless> it is
<lifeless> a bug, from when we disabled 'subtrees' for the format
<poolie> so is it correct that 2a doesn't have the subtree flag set?
<lifeless> yes
<lifeless> the check in CHKFormat* for subtree during is_compatible orwhatever the method is called, is the bug
<poolie> what i'm really getting at is, does this reflect any problems in 2a or code that will still be active there
<poolie> or only for the dev formats?
<lifeless> dev and 2a
<lifeless> EOD time; {actually late, startedearly}
<lifeless> ring me if you need me
<jml> lifeless, ciao
<poolie> lifeless: so why
<poolie> do you say this matters only if we're going to delete dev6 in the 1.17 cycle?
<bizarrefish> hi
<bizarrefish> i have a problem - whenever i do a "push" to a master repository(over sftp), having committed changes, the entire repository is transferred and it takes AGES.
<bizarrefish> why can't bzr just push the files that the server DOESNT have?
<jml> spiv, your patch @ https://code.edge.launchpad.net/~spiv/bzr/default-stacking-again/+merge/7601 -- the tests it adds are just the test_bzrdir ones?
<jml> bizarrefish, actually, bzr can be quite good at just pushing things the other side doesn't have
<bizarrefish> jml: how do i tell it to do that, then?
<bizarrefish> :-/
<jml> bizarrefish, how exactly do you have things set up?
<bizarrefish> jml: i have a master repository, from which i have branches on different machines
<bizarrefish> when each machine's repository is modified, i need to be able to push the changes to the master
<jml> bizarrefish, it sounds like there might be other factors at play, but bzr+ssh is a lot faster than sftp -- particularly with bzr 1.15 or 1.16
<jml> bizarrefish, "bzr push sftp://server/master-branch" ?
<bizarrefish> jml: yeah, that's what i'm doing
<bizarrefish> the branches were created with: bzr branch sftp://server/master-branch
<bizarrefish> and the pushes take place as you have stated
<jml> bizarrefish, is it possible for you to try bzr+ssh?
<jml> bizarrefish, you just need to have bzr installed on the server -- the more recent the better.
<bizarrefish> jml: i suppose so, unfortunately the master repo is held on a machine with 32MB of RAM and no swap :-/
<jml> I see :)
<bizarrefish> and svn+ssh didn't take too kindly to being run in such a machine :)
<jml> bizarrefish, don't run bzr+ssh then
<bizarrefish> kkl
<bizarrefish> *k
<jml> bizarrefish, what makes you think it's sending the whole thing?
<bizarrefish> jml: oh...hang on, it seems to be because the branches have diverged
<bizarrefish> :-/
<jml> bizarrefish, that makes sense
<jml> bizarrefish, you need to merge your changes in, rather than simply pushing
<bizarrefish> jml: yeah, that would normally have preceeded the push
<jml> ok cool.
<bizarrefish> the sync sequence: add -> commit -> merge -> commit -> push -> have a nice day
<spiv> jml: yes
<spiv> jml: it's a pretty simple patch, despite LP's attempts to make it look more complicated :P
<jml> spiv, right.
<jml> spiv, the reason for the confusion is that lp:bzr is a mirrored branch
<jml> and can be as much as six hours out of date.
<spiv> Right.  And I made my branch off current bzr.dev.
<jml> of course, bzr's pqm could easily trigger a mirror on commit.
<mwhudson> clearly mirrored branches are only for hippies
<jml> or there could be a post-commit hook
<bizarrefish> what is the difference between doing a bzr update and a bzr merge
<bizarrefish> ?
<mwhudson> we really should write a post commit hook that launchpadlibs up a requestMirror
<mwhudson> bizarrefish: quite a lot
<jml> mwhudson, yes.
<mwhudson> bizarrefish: though because you say 'up' i guess you're using checkouts?
<jml> mwhudson, my plan at EuroPython is to write awesome launchpadlib/bazaar things
<bizarrefish> mwhudson: no, a branch
<jml> or to make it falling-off-a-log easy to write such.
<bizarrefish> is there somewhere which actually details what these things do?
<mwhudson> jml: cool
<mwhudson> bizarrefish: then 'up' probably doesn't do anything
<mwhudson> bizarrefish: the difference between pull and merge is that pull maintains a mirror and merge combines lines of development
<jml> bizarrefish, 'bzr help merge' etc
<jml> also...
<jml> (looking...)
<jml> (specifically, looking for the doc link on the wiki with my slow net connection)
<jml> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
<jml> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html
<bizarrefish> hmm...
<bizarrefish> This will perform a merge into the working tree, and may generate
<bizarrefish>   conflicts.
<bizarrefish> ^from bzr help update
<bizarrefish> so...update == merge??
<bizarrefish> :'(
<mwhudson> if you're not using checkouts, pretend update isn't there
<jml> bizarrefish, "merge" brings in a divergent line of history
<mwhudson> (not a fantastic bit of ui)
<bizarrefish> right...ok
<jml> bizarrefish, which can cause conflicts
<jml> bizarrefish, and only changes the working tree -- you still need to commit.
<bizarrefish> so update brings in history too??
<bizarrefish> riiight...
<bizarrefish> i see
<jml> bizarrefish, 'update' brings a working tree up to date with a branch.
<jml> bizarrefish, rather than combining two divergent lines of history (like merge)...
<poolie> anyhow jml i think we should just merge jelmer's patch
<jml> it simply updates a working tree
<jml> poolie, yeah, that's what I was thinking.
<poolie> and maybe test it fixes it
<jml> poolie, I'm also going to bring in spiv's patch.
<bizarrefish> jml: right, so bzr can work in a non-distributed fashion?
<bizarrefish> (using checkouts/updates instead of branches/merges)
<jml> because it's small and stacking bugs have given me a scar so deep it makes me look like a lost a samurai fight.
<jml> bizarrefish, exactly
<bizarrefish> i see
<bizarrefish> in that case, i think i should be using checkouts..
<jml> bizarrefish, some people also use checkouts / updates in a distributed fashion, but that's very weird and complex and much easier for you to read about than for me to explain :)
<bizarrefish> is "push" still used to update the main branch?
<jml> bizarrefish, it sounds like lightweight checkouts would fit your situation better.
<bizarrefish> yeah...it does.
<jml> bizarrefish, if you used lightweight checkouts, i.e. 'bzr checkout --lightweight sftp://server/master-branch' ...
<jml> bizarrefish, then each commit inside that checkout would contact the server and change the master-branch there.
<jml> bizarrefish, just like a subversion commitc.
<jml> poolie, is jelmer's patch in bzr.dev yet?
<bialix> igc1: what's your short term plans for bzr explorer?
<bizarrefish> hehe this sounds like just what i'm looking for
<jml> bizarrefish, cool. :)
<bizarrefish> i've been at this for a couple days
<bizarrefish> thanks
<jml> np.
<jml> poolie, jelmer's patch is missing tests
<jml> poolie, should we land it sans tests?
<jml> poolie, or are you willing to write one?
<poolie> sans gas
<poolie> i mean sin gas
<jml> rock & roll.
<spiv> jml: is it really "easy" to make our pqm (via post-commit or whatever) trigger a mirror?  If so, we should absolutely do that, please file a bug or something.  I'd love that.
<spiv> jml: (but first I'd rather you released 1.16 followed by having a pleasant evening's relaxtion basking in the glow of your shiny new release)
<jml> spiv, http://paste.ubuntu.com/198291/
<RenatoSilva> My 1st merge proposal: https://code.launchpad.net/~renatosilva/bzr-email/mail-customization/+merge/7606
<RenatoSilva> Thanks to you guys!
<spiv> jml: somehow that feels like about 2-3 more lines of code than I would expect, but cool nonetheless.
<spiv> RenatoSilva: glad it's working out for you :)
<RenatoSilva> spiv: thanks to all of you so helpful :)
<jml> spiv, actually that also won't work with trunk launchpadlib.
<jml> spiv, I made a branch to reduce the number of lines you need to cache authentication data
<jml> spiv, so uhh if you want to make it work...
<spiv> jml: I see :)
<jml> you need to look at https://help.launchpad.net/API and change the load() method to be more like what that page suggests.
<jml> also, that script has the same skeleton as the one I wrote for setting official package branches
<jml> it probably doesn't *need* its own class :)
<RenatoSilva> the whole idea of dvcs + personal branches + merge proposals is a very interesting approach
<jml> RenatoSilva, it's an awesome approach.
<RenatoSilva> yeah, I mean awesome :)
 * RenatoSilva gtg
<jml> RenatoSilva, bye :)
<RenatoSilva> bye, tahnks
<jml> spiv, is your branch merged into trunk?
<jml> spiv, would you mind submitting it to pqm for 1.16?
<spiv> jml: It is.  I'll submit it.
<jml> spiv, thanks.
<spiv> Well, I'll submit the cherrypick I prepared earlier, which is basically the same thing (being a cherrypick).
<jml> :)
<bizarrefish> I'm doing a bzr export to another dir, and it's STILL downloading it's up to 200MB now, which is at least twice the size of my checkout
<bizarrefish> what is going on?
<bizarrefish> what is this extra datas?
<Peng_> It has to download enough history to reconstruct each file.
<bizarrefish> Peng_: but this is only 3 revisions deep
<Peng_> Maybe they're 3 really epic revisions? :D
<bizarrefish> and i have only added a few hundred bytes worth of files in those revisions
<bizarrefish> :'(
<bizarrefish> well, something is epic
<bizarrefish> the -v flag isn't telling me what it's currently exporting
<spiv> It may just be that "bzr export" isn't particularly optimised for the network :(
<bizarrefish> or there is some killer bug
<spiv> With only 3 revisions, it is likely it has to fetch the full history to construct the current state of every file, though.
<bizarrefish> i mean, the little "progress bar" isn't even past the first segment at the 200MB mark
<bizarrefish> this is only 100MB worth of files heere
<bizarrefish> *here
<spiv> Yeah, I'd suspect a performance bug.  Sorry :(
<bizarrefish> you will be!
<spiv> Please file a bug at https://bugs.launchpad.net/bzr
 * bizarrefish runs up behind spiv
 * bizarrefish drags him by the eye into the sea
<bizarrefish> *filing*
<spiv> (Did I just stumble into a role playing channel by mistake?)
<bizarrefish> spiv: maybe...whos to say?
<Peng_> Version Control the Roleplaying Game?
<spiv> Peng_: The Repository hits you.  The Repository hits you.  (more)
<lifeless> power failures suck
<Peng_> spiv: I was trying to come up with a joke about a file system or power failure eating your history.
 * igc1 dinner
<lifeless> Peng_: heh. It was only a short one. But I wish I knew why we're getting them. Or did spiv have a power outage too?
<Peng_> lifeless: No, it's just that RPGs had come up in the conversation, so I was trying to think of a hoke.
<Peng_> joke. Wow.
<Peng_> lifeless: You don't have a UPS?
<lifeless> Peng_: surge protector only at home
<Peng_> Oh. You should get one!
<Peng_> O' course, half of my power failures are *because* of the UPS freaking out, but... :P
<lifeless> so my theory is 'ext3 is solid'
<lifeless> and most power failures are longer than a cheap UPS will survive
<Peng_> A cheap UPS can give you time to whine about it and shut down.
<Peng_> (depending on how cheap)
<lifeless> right, but I don't care about that
<lifeless> the most annoying thing is reconnecting to freenode
<Peng_> Use a bouncer/irssi. :D
<lifeless> I do
<lifeless> to keep up my link during a power failure I need:
<lifeless>  - UPS
<lifeless>  - firewall
<lifeless>  - adsl modem
<lifeless>  - server
<lifeless> to be kept running during the failure
<lifeless> assuming the exchange isn't affected
<Peng_> I mean a remote server.
<lifeless> it is remote. its in the other room
<lifeless> :)
<Peng_> I mean data-canter-with-UPSes remote. :P
<jml> im in ur irc channel releasin ur software
<LarstiQ> :)
<jml> heoastuheoashiseo
<jml> wrong submit branch :(
<jelmer> poolie: hi
<jml> jelmer, g'day
<jelmer> jml: Hey
<jelmer> jml: Enjoying life as a RM?
<jml> jelmer, it's certainly keeping me on my toes :)
<jelmer> :-)
<jelmer> I saw you submitted my upgrade fix, is a test still necessary for that?
<jml> jelmer, it would be nice :)
<jml> jelmer, but it won't go into 1.16
<bizarrefish> hi, i'm just playing around with bzr, and am currently at revision 6. i deleted "afile" at this revision, so the file existed at revision 5.
<bizarrefish> i used this command to retrieve the file from revision 5: http://pastebin.com/m2e6af935
<bizarrefish> unfortunately, that produced an error :'(
<bizarrefish> it's a checkout, not a branch, btw
<bizarrefish> haha, got it: bzr revert -r5 afile
<jml> doing a --dry-run before this pqm-submit
<jtv> lifeless, have you heard of abentley's idea of committing a preview tree?
<lifeless> jtv: I worked with him on it @ allhands
<jtv> lifeless: then you're the person I need
<lifeless> he had working code
<jtv> lifeless: I'm probably missing something silly.
<lifeless> jtv: If its quick I can give you a hand now, otherwise I suggest we look at it when you start your day tomorrow - its 9pm here
<jtv> lifeless: I've got it running without bombing out (believe me, if you know as little as I do about bzrlib that's a lot)
<jtv> lifeless: well the problem is I've got changes in my transform, and they seem to be going into my tree, but afterwards I open a new Branch on the same URL and don't see any files.
<lifeless> Branch's don't have files
<jtv> well, I do branch.repository.revision_tree(NULL_REVISION).walkdirs
<jtv> (and I cargo-culted that off someone who got it handed down by one of the gurus)
<lifeless> so
<lifeless> NULL_REVISION is the empty revision
<lifeless> it has no content
<lifeless> I think what you may prefer is 'branch.basis_tree()'
<jtv> ahhhh
<jtv> I thought it was the starting revision for changes, and passing NULL_REVISION would give me everything from the beginning of time.
<jtv> Running updated test.
<lifeless> tree objects are not deltas
<lifeless> they are snapshots
<jtv> So I want the latest revision there.
<jtv> Now I get "no such revision."
<lifeless> from basis_tree ?
<jtv> Oh, wait, basis_tree() is the tree I want to walk.  Thank you, duck typing!
<jtv> lifeless: bit of delay here... the change is suddenly exercising code that never ran in my test.  Which is a good sign.  :-)
 * jtv does see certain advantages in a compiler...
<jtv> lifeless: more trouble, but I'm sure it's not worth keeping you for.  You've helped me a lot though!
<jml> 'make dist'!
<lifeless> gnight
<jml> lifeless, g'night.
<jml> what do I have to do to get http://doc.bazaar-vcs.org/bzr.1.16/en/release-notes/NEWS.html regenerated?
<jml> hmm. cronjob.
 * jml gives it time.
* jml changed the topic of #bzr to: Bazaar version control system | 1.16 released 18th June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<jtv> Anyone up for another bzrlib question?
<jml> don't ask to ask, just ask.
<jtv> jml: ah yes.  I'm doing a walkdirs(), and I'm expecting to find a file a/b/c.txt, but I seem to get only the b and c parts.
<jml> jtv, walkdirs on which object?
<jtv> jml: on branch.basis_tree()
<fullermd> jml: Do you know why the md5/sig links for 1.16 are broken?  Are they made by you or LP?
<jtv> jml: each item in that iteration seems to be (dirname, id): [files]
<jtv> jml: but for a/b/c.txt, dirname seems to be 'b'.
<jml> fullermd, the links on which page?
<jtv> Might be a bug in my code, but trying to figure out what's normal here.
<jml> jtv,
<fullermd> jml: https://launchpad.net/bzr/1.16/1.16
<jml> fullermd, by "broken", do you mean they 404?
<jml> fullermd, the md5 link is made by Launchpad, I uploaded the sig files
<fullermd> Well, they don't give me a MD5 or a signature  ;)
<jml> e18b38e2c4e33203c8f6c9b4029cea7a bzr-1.16.tar.gz
<jml> http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-1.16.tar.gz/+md5
<fullermd> (the rc didn't either)
<jml> that's what I get
<jml> fullermd, what do you get?
<Peng_> jml: Congrats on the release.
<jml> Peng_: thanks :)
<fullermd> Hm.  Well, I see the md5 on that page, but the links don't go there (even mod the edge thing)
<fullermd> http://launchpad.net/bzr/1.16/1.16/+download/bzr-1.16.tar.gz/+md5  has the MD5
<fullermd> But the link from https://launchpad.net/bzr/1.16/1.16  goes to  http://launchpad.net/bzr/+milestone/1.16/+download/bzr-1.16.tar.gz/+md5
<fullermd> (which gives Page Not Found)
<fullermd> (the link on https://edge.launchpad.net/bzr/1.16/1.16 goes to the right place)
<fullermd> So I guess it's a LP bug.
<jml> if it works on the edge page, then it might well be a fixed lp bug
 * jml checks
<jml> http://launchpad.net/bzr/+milestone/1.16/+download/bzr-1.16.tar.gz/+md5
<jml> http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-1.16.tar.gz/+md5
<fullermd> Yah.
<jml> fullermd, https://bugs.edge.launchpad.net/launchpad-registry/+bug/383788
<ubottu> Launchpad bug 383788 in launchpad-registry "md5 and sig links are broken on the milestone-release page" [High,Fix committed]
<fullermd> Good enough.
<vila> jml: congrats for the release !
<jml> vila, thank you :)
<fullermd> Always nice to get an update to the bzr port submitted before breakfast  ;)
<jml> :)
<jml> jtv, sorry I got distracted.
<jtv> jml: ah, I thought it was some form of IRC "RTFM" that I wasn't aware of.  :)
<jml> jtv, I don't know what's going on there, I'm afraid -- I haven't used that API much.
<bialix> vila: hi
<jml> jtv, perhaps mucking around with it in a Python interpreter might help figure things out.
<vila> bialix: hi !
<jtv> jml: sort of what I'm doing.
<bialix> can you recall what the bug #376582 was about?
<ubottu> Launchpad bug 376582 in bzr "Authentication prompt goes to standard out" [Undecided,Fix released] https://launchpad.net/bugs/376582
<jml> jtv, alternatively, it's morning in Toronto soon, so you might be able to get abentley to lend you a hand.
<bialix> you've fixed it recently
<jtv> jml: yeah, thing is, it's already dark here.  :/
<vila> bialix: yes. If we prompt on stdout, users can't redirect output (think diff or log) or they will not see the prompt
<bialix> this is for password prompt?
<vila> for any prompt, including password
<bialix> hmm
<bialix> I thoiught
<bialix> I thought bzr uses direct access to console to get user input
<bialix> at least on win32
<bialix> from getpass std module. is not?
<vila> bialix: hooo, now that you mention it... yes, we were passing the prompt to getpass.getpass()
<vila> and *there* there may have been some win32 specific code path
<jtv> jml: \o/ figured it out, tests pass
<jml> jtv, yay
<bialix> you talk in past time
<jtv> jml: just what I was writing into this commit message here...
<bialix> vila: so today things are different, that's right?
<jml> g'night all.
<vila> bialix: yes, stderr is used instead, which should be easier to redirect
<bialix> it seems like stderr forced to use utf-8 encoding. it's bad and wrong for win32
<vila> bialix: Are you sure it's not the default stderr behavior instead ? Anyway, AFAIK, stderr is left untouched as far as UIFactory is concerned...
<bialix> well, in trace.py
<bialix> oh no
<bialix> it seems I have false memory
<bialix> don't mind
<bialix> .bzr.log is utf-8 encoded, it's ok
<cocooncrash> Hi. I want to writea pre_commit hook which rejects commits if they contain certain words.
<cocooncrash> I can't work out how to access the diff though.
<bialix> jam: good day
<jam> hi bialix
<bialix> there is small problem with bzr.exe and some plugins
<bialix> some plugins require standard python modules that absent in lib/library.zip
<bialix> do you think it reasonable to add these python modules explicitly?
<bialix> add to setup.py
<bialix> or just left this problem to plugins
<bialix> jam: I'm asking your opinion because 1.16 is out but problem only get worse. Now bzr explorer require additional lib. And I think we should package this plugin into bzr.exe installer.
<bialix> s/we/you/
<jam> if we package bzr-explorer it will bring in the extra libs
<jam> if we don't then they need todo an installer like bzr-xmloutput does
<jam> which installs the deps
<bialix> another solution is to explicitly add required libs to the list of includes in setup.py
<bialix> and make the life easier for xmloutput too
<bialix> I can provide the patch for this, but will be nice to have this patch into bzr.exe 1.16
<Spabby> please help me, I am stupid, how can I replace a local branch and working copy with the one from the server? I have loads of shitty changes on my local copy and I want to go to the good version on the central branch
<bialix> jam: ok, it seems you're busy. but I'd like to point your attention on my recent answer in ML about selftest for bzr-svn @windows.
<jam> bialix: sorry about that. Anyway, to be "nice" we'd have to bundle every possible library so that every possible plugin could work
<jam> we also don't want to bundle all of GTK if we aren't going to bundle bzr-gtk
<jam> (PyGTK)
<jam> so we *can* bundle things
<jam> but I think it is better to make it easier for plugins to write installers that include dependencies
<bialix> jam: currently we know which modules are missing. they are few
<bialix> don't need to bundle the whole universe
 * bialix disagrees with jam point
<jam> bialix: we are missing some modules for *certain* plugins
<jam> but there are *lots* of potential plugins that potentially need a lot of dependencies
<bialix> I understand your point, ok, thanks
<jam> If the list is obvious and small, that is no big deal
<bialix> ha ha
<bialix> awilkins just asked about xmloutput
<jam> but it makes more sense to help the plugins do the work themselves
<bialix> I know how to work this
<bialix> I'm asking because it seems there is needed few of modules
<bialix> today: SimpleXMLRPCServer (for xmloutput) and HTMLparser (for explorer)
<bialix> this list could grow over the time
<bialix> but today it's reasonable small
<bialix> sometimes I think hg approach of bundling all plugins and enable them by user is better suited for this kind of issue
<jam> igc1: what are you still doing up
<igc1> jam: several hours at the hospital today and again tomorrow so ...
<jam> igc1: sorry to hear that. I'm happy to see your activity, sad to see it so late in the day :)
<jam> then again, it is nice to see you at the same time I'm on
<jam> all you AU guys have been getting up extra late recently
<jam> And I'm on a pretty strict "stop at 5" routine
<igc1> jam: :-) also, trying to roll out Explorer 0.3 tonight to coincide will the 1.16 release
<igc1> jam: but it can wait till tomorrow afternoon
<igc1> hopefully bialix will have a chance to test out the latest changes before then
<bialix> igc1: I think I should write installer for bze explorer
<igc1> hi bialix - just talking about you :-)
<bialix> because explorer require HTNLParser lib that missing in bzr.exe
<bialix> hi Ian
<bialix> glad to hear you, sad you're busy with hospital
<igc1> bialix: you can wrap that import in a try/except - not required for production code yet
<bialix> well https://bugs.launchpad.net/bzr-explorer/+bug/389028
<ubottu> Launchpad bug 389028 in bzr-explorer "[bzr.exe problem] can't start explorer: bzr: ERROR: No module named HTMLParser " [Undecided,New]
<igc1> bialix: tests and appointments - no treatment fortunately
<bialix> I have solution for this
<bialix> I can do installer for you
<bialix> I'm good in writing installers
<igc1> bialix: true! but just pulling the branch ought to work if we simply wrap that import
<bialix> igc1: if you plan to release 0.3 then setup.py need to fix
<bialix> igc1: let me check
<igc1> bialix: see http://bazaar-vcs.org/BzrExplorer (and the roadmap link)
<bialix> igc1: try-except does not work
<bialix> igc1: http://pastebin.com/m46f6a876
<igc1> bialix: yeah, 0.3 either 10-15 hours from now or Monday is the plan
<bialix> so we have to provide installer!
<hexmode> Any easy way to find the current revision number of a directory?
<bialix> see file-revision plugin
<bialix> or use qbrowse command from QBzr plugin
<hexmode> bzr revno
<hexmode> doh
<jam> hexmode: or bzr version-info --all, etc
<jam> bzr revno does the whole branch
<jam> just depends what you are looking for
<hexmode> jam: ok, so if I do "bzr revert -r 28", I would expect bzr revno to show 28.  Instead it shows the version of HEAD
<bialix> igc1: I'm eagerly need support for lightweight checkouts+feature branches workflow in bzr explorer
<hexmode> (which is 29)
<bialix> hexmode: you need uncommit
<jam> hexmode: revert doesn't change the current revision
<jam> just the content of files
<hexmode> ok, well, this will do for now, I think....
<igc1> bialix: try rev 53
 * bialix pulling
<bialix> igc1: IMO acronym BE is already used for Bugs Everywhere
<SamB> I thought it meant Build Environment
<SamB> ... but I guess that was in the next channel over, #reactos ..
<igc1> hmm - maybe I need to start using BEX instead
<igc1> or BzrE  or whatever
<bialix> http://en.wikipedia.org/wiki/Bex
<bialix> BEX is shorter, I guess
<bialix> or call it something like REALLY COOL BAZAAR FRONT-END!!!
<bialix> well, maybe without all this caps
<igc1> BzrEx comes up empty enough on google so it will probably do
<igc1> so bialix, did that work?
<bialix> igc1: yes, ii is
<bialix> it is
<bialix> it works fine now
<igc1> time for me to call it a night
<bialix> goodnight
<igc1> bialix: if you want anything else in 0.3, I need patches
<bialix> I have problem with opening shred repo
<bialix> I'm debugin the problem right now
<igc1> I'll send out an announcement tomorrow, unless there are show-stoppers
<bialix> igc1: patch for windows installer will count?
<bialix> I'll fix setup.py today
<igc1> bialix: I'd prefer to see it bundled in the normal Windows installer, for 1.17
<bialix> as you wish
<igc1> assuming enough people like it, of course
<igc1> night all
<bialix> see you later
<igc1> bialix: if you're really keen, please add some windows screen snapshots to http://bazaar-vcs.org/BzrExplorer !
<bialix> with pleasure!
<VSpike> I'm still immensely puzzled by a problem of a file marked as "removed" that when I try to do "bzr mv --after" on it, says it's not versioned.
<VSpike> I just downloaded the latest Windows bzr in case it was Cygwin specific, but the problem is still there
<VSpike> Any idea what I can do to solve it?
<bialix> VSpike: looks like the problem with case of characters in filename
<bialix> use standard ren command in DOS shell to fix the case of the file
<VSpike> bialix: I think I managed to fix it, after some fiddling.  I ended up with two parent directories versioned at one point
<VSpike> I saved the code file, reverted both of them and then did bzr mv ... and then overwrote the new location with the saved file
<bialix> ok
<Davey> Hola! :)
<Davey> I'm thinking about maybe switching from SVN to bzr, but I'm curious about 2 things; first: how is the migration path? can I keep my current revision history? and second: what about an equivalent to svn:externals, does it exist?
<dash> bzr-svn will import your SVN repository pretty easily (in fact, I use bzr to make checkins to our SVN repo at work)
<dash> svn:externals doesn't have support yet -- I believe support for that (what bzr calls "nested trees") is currently underway
<bialix> Davey: though if you dare enough you can try scmproj plugin as emulation of svn:externals
<Davey> yeah... no svn:externals is a deal breaker for me; I have 4 separate third-party libs I have to hack on :/
<Davey> I don't think git supports any similar mechanism either mind you
<dash> Davey: separate checkouts have worked just fine for me :)
<dash> i'm mainly familiar with using svn for development rater than deployment though
<bialix> git has submodules
<bialix> scmproj plugin is roughly did the same
<bialix> the same as git
<bialix> but a bit better
<Davey> the thing that turns me off git, is the whole empty directory not versionable BS... that seems like such a basic thing that if they forgot that I wonder what else they forgot ;)
<bialix> bzr can track empty dirs
<Davey> this I know :)
<bialix> take a look at scmproj
<Davey> we're just outgrowing SVN; our merging needs are growing as our team grows and we're tackling more ambitious simultaneous projects. We have 4 branches (old-stable, new-stable, enterprise edition, and trunk); eventually, trunk will replace /both/ the new-stable and enterprise editions, but we've got two major projects to add to it immediately, and then there's the re-write coming up shortly. blech :)
<bialix> maybe it's not very elegant, but it works
<Davey> you can sit bzr over svn, right?
<Davey> perhaps that's the solution? :)
<bialix> you can work with svn repo directly
<bialix> if you asking this
<dash> yeah, bzr-svn supports most svn operations -- it doesn't support svn:externals yet, of course
<bialix> some people just using svn as central server to store bzr branches there
<Davey> bialix: that's kinda where I'm headed, TBH
<bialix> scmproj can be used for this
 * bialix have to go
<bialix> I'll glad to help with scmproj if needed
<bialix> I'll be there later
<flvr8> hello. how do i debug bzr-email? i have bzr-email installed and set up as the post-commit hook on the server. the branch.conf in the shared branch on the server specifies the smtp_server. i can send email from the server w/ postfix (echo test | mail 'foo@bah'). but, no email when i commit to the branch, and i don't see any logs anywhere saying what's going wrong. ideas?
<LarstiQ> flvr8: my guess is that it isn't picking up on the config due to your branch name being different than you think
<LarstiQ> flvr8: see ~/.bzr.log on the server
 * LarstiQ dines
<flvr8> LarstiQ: thanks, will see if i find something in there
<statik> hello bzr hackers!
<statik> i'm using lp:config-manager to manage a bunch of branches that I depend on in a project. config-manager only lets me specify which branches to pull. Is there a way that I can specify in a bzr url which revision or tag should be pulled?
<ddaa> Hey. Is there a bzr command I can use for shell scripting that lets me determine whether the tree is clean?
<ddaa> Oh, I found my answer myself: bzr diff
<ddaa> if bzr diff -q ; then echo "no change"; else echo "changes found"; fi
<statik> hey ddaa, it's been a long time. how are you?
<ddaa> hey statik
<ddaa> Got a consulting job in a bank hacking some python stuff, resigned because I hated the bank part of the job. Now associate of a web startup that does not have money to give me a pay yet.
<ddaa> Inherited a "working" webapp without any useful automated test suite. Currently hacking on automated deployment scripts.
<statik> ddaa, sounds scary but like an adventure
<ddaa> Missing Canonical.
<Keybuk> help!
<Keybuk> bzr push gives me:
<Keybuk> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%7Escott/upstart/0.3/.bzr/)
<Keybuk> is not compatible with
<Keybuk> KnitPackRepository('file:///home/scott/co/upstart-0.3/.bzr/repository/')
<Keybuk> different rich-root support
<ddaa> you need to "bzr upgrade" your local repo
<Keybuk> my local repo is upgraded, it's the remote repo that's the problem
<beuno> Keybuk, what does "bzr info" say locally?
<beuno> the online branch seems to not be rich-root
<Keybuk> Standalone tree (format: 1.14-rich-root)
<beuno> Keybuk, so, bzr upgrade --1.14-rich-root lp:~scott/upstart/0.3
<beuno> it'll take a while
<ddaa> statik: I like adventures.
<Keybuk> bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr'
<Keybuk> beuno: &
<Keybuk> ^ even
<ddaa> use a sftp client to nuke that
<ToyKeeper> Eh, I've found it faster and easier to delete the launchpad repo and push a new one...  upgrade takes forever.
<Keybuk> ddaa: example?
<beuno> argh
<Keybuk> quest scott% sftp bazaar.launchpad.net
<Keybuk> Connecting to bazaar.launchpad.net...
<Keybuk> sftp> cd /srv/bazaar.launchpad.net
<Keybuk> Couldn't stat remote file: No such file or directory
<Keybuk> ddaa ^
<beuno> no, I think Peng uses hitchhiker
<beuno> I know sftp doesn't work beacuse we have a custom ssh server
<beuno> abentley, ping?
<ddaa> in my time, it used to work
<abentley> beuno: pong
<beuno> abentley, hello
<beuno> could you help us out?
<beuno> 14:39 < Keybuk> bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/17/d0/backup.bzr'
<beuno> Keybuk wants to upgrade but it seems he's done it before
<ddaa> Keybuk: lftp sftp://bazaar.launchpad.net/~bzr/bzr/trunk
<ddaa> you need to specify the full branch url from the start
<ddaa> the VFSTP does not provide intermediate listings
<ddaa> and you need to use lftp because it provides a nice rm -rf feature.
<abentley> Keybuk: Or hitchkiker lp:~scott/upstart/0.3 rmtree backup.bzr
<dash> any bzr-eclipse people around? trying to figure out how to import an existing branch into an eclipse project
<ddaa> yeah, same difference :)
 * beuno spots verterok hiding in the back
<ddaa> and you should annoy rockstar and spiv so they automatically nuke those bzr.backup dirs away
<ddaa> on session close
 * verterok start running
<verterok> hi dash!
<dash> verterok: ello
<dash> so I see "branch as a new project"
<dash> but not how to use an existing branch
<dash> there's nothing on eclipse's "import" meny
<dash> menu
<verterok> dash: you have a local branch you want to import?
<dash> yes
<verterok> dash: it's already an eclipse project?
<dash> there's eclipse project files in the branch, yeah
<verterok> dash: just file --> import --> existing project into workspace :)
<verterok> dash: bzr-eclipse will detect the .bzr at the root of the project, and enable bzr support
<dash> hmm. this is perhaps complicated by the fact that the branch root doesn't contain a .project file, there are multiple projects in the branch
<verterok> dash: oh, just like bzr-eclipse itself
<verterok> dash: it's a limitation of eclipse team support, and I didn't found a solution yet (apart from reimplementing a big chunk of eclipse internals :p)
<verterok> dash: you can import the projects, and then select all the just imported project: right click --> team --> share
<dash> hm, ok
<verterok> dash: choose bazaar for each one, and you'r done :)
<verterok> dash: maybe adding a wizard to simplify this would help
<Keybuk> ddaa: thanks, that appears to work :)
<verterok> dash: would you mind to file a bug with the use case and the problem?
<dash> verterok: well, just mentioning that it's necessary would help :)
<dash> looks like that sorted it out
<verterok> dash: great to know!
<hazmat> trying to utilize loggerhead for web serving up some repos.. found an example config file in the root of the trunk.. but no directions in readme or otherwise on how to get the the serve-branches cli to utilize the config file.. any ideas?
<verterok> beuno: ^
<beuno> hazmat, it serve-branches doesn't use the config file
<beuno> did you grab trunk or a release?
<hazmat> trunk
<hazmat> i wanted to serve up multiple project branches from a single loggerhead instance..
<beuno> hazmat, and they're all in different directories?
<hazmat> their all under a single dir
<beuno> hazmat, so just run serve-branches on that dir
<beuno> and it will serve them
<hazmat> cool, i see that now.. thanks
<hazmat> config file threw me off
<beuno> yeah, we're dropping that very soon
<dash> hm. anybody know what it takes to build the osx installer for bzr? i'd like to make one for my coworkers with bzr-svn etc included
<jrwren> is there an equiv of svndumpfilter ?
<dash> there's bzr-fastimport
<dash> that may not be what you want though :)
<kfogel> If I have did "bzr init-repo foo" ages ago, and now have foo/bar/, foo/baz/, foo/qux/, etc, can I just do "mv foo new-name" and everything will still Just Work?
<Peng_> FYI, I used hitchhiker to "rename backup.bzr .bzr/backup.bzr".
<Peng_> I'm sure LP doesn't appreciate me keeping 2 backups, but whatever.
<kfogel> Peng_: not sure I understand.  "LP" = ?
<kfogel> launchpad?
<Peng_> kfogel: It was in reply to a conversation an hour ago.
<Peng_> kfogel: You can rename repositories and branches as much as you want, as long as the branches still exist in the repo.
<kfogel> Peng_: Ah.  So even inside foo/ (or inside "new-name", post-rename), I could do "mv bar bar2; mv qux fish", and everything would still work?
<Peng_> kfogel: Some branches may have the full path stored as their parent, push, etc. locations, but if you run into that, it's easy to fix with e.g. "bzr pull --remember".
<Peng_> kfogel: Yup.
<kfogel> great, thanks
<Peng_> kfogel: Bazaar just searches up the directory tree for a shared repo. It doesn't care about the names themselves.
<kfogel> good
<kfogel> I expected that, but wanted to be sure, before I made some names that might end up being permanent.
<Peng_> kfogel: You could even do "mv bar baz/bananas" if you wanted to. :)
<kfogel> Peng_: so it really just searches upward -- doesn't even need the relative distance to repos root to remain stable?  That's great, although perhaps also comes at a bit of a time cost, dunno.
<Peng_> kfogel: Yup. It probably does have a cost, but it would be minimal. Just a couple more stat()s among the hundreds/thousands Python'll already wind up doing.
<kfogel> heh, true
<flvr8> i am confused. i have a bzr repository on my server at /opt/bzr/Main/trunk (an import from svn). i checked it out onto my workstation, modified the existing file "foo", and checked it back in. the file "foo" on the server (i.e. in /opt/bzr/Main/trunk) does _not_ contain my changes to it, but checking out the branch from a different machine picks up the change, and running bzr log on "foo" on the server shows my commit messages. so my 
<dash> flvr8: pushing to a remote branch doesn't update its working tree
<dash> you have to do 'bzr up' to get that
<Peng_> You can also use the bzr-push-and-update plugin.
<flvr8> ah indeed. so where are those changes persisted until i do that?
<Peng_> flvr8: .bzr
<Peng_> flvr8: .bzr contains all of the history; the working tree is unnecessary.
<flvr8> got it
<jrwren> bzr up -v is showing me a list of files, but then it dies with "bzr: ERROR: [Error 2] The system cannot find the file specified"
<Peng_> More recent versions of bzr will usually be more helpful, including the filename in the error message.
<jrwren> this is 1.15
<Peng_> Sorry, i dunno. What OS? Are you using a weird file system?
<jrwren> -Derror at least tells me its a exceptions.WindowsError
<jrwren> any other debug-flag that may help?
<Peng_> Sorry, I dunno.
<Peng_> Hopefully someone else does!
<jrwren> i hope so too
<jrwren> so who can I call to pay for bazaar support?
<garyvdm> canonical?
<garyvdm> jrwren: Please will you pastebin the error.
<jrwren> http://pastebin.ca/1465290
 * garyvdm looks
<garyvdm> jrwren: I've taken a look - I'm way out of my league.
<garyvdm> jrwren: Can you rembember what you did, and see if you can reproduce this?
<garyvdm> jrwren: Whether you can or can't, log a bug on https://bugs.launchpad.net/bzr/+filebug
<garyvdm> jrwren: Most of the bzr devs will be asleep atm. Maybe jam is around?
<jam> jrwren: When updating a tree
<jam> we stage the changes in several steps
<jam> first we write down what we are about to generate
<jam> then we move the source files to a pending-deletion dir
<jam> and move the new files into place
<jam> then we deleted the pending-deletion
<jam> that way we can 'rollback' at any time
<jam> the error I'm seeing looks like it is trying to remove a file from your working tree
<jam> and put it into limbo
<jam> but it is already gone
<jam> any idea how that could happen?
<jam> (It could also be a permission issue, such that we think the file is gone, but really it is just unaccessible by your user, etc.)
<garyvdm> Hi jam
<jam> hi garyvdm
<jrwren> jam: I had the user run find \! -perm -u=rw -ls
<jam> jrwren: are you running on Win32 ? cygwin?
<jrwren> and nothing showed, so she has read write
<jrwren> yes win32, no cygwin
<jam> (a bit strange to run 'find' with a WindowsError)
<jrwren> well, cygwin is installed, but we are using bzr from MSI
<jam> sure
<jam> so... I think I see the prob
<jrwren> will the file list of changes show per each file, or at the end
<jrwren> becuase I confirmed that every file in the list does exist on the file system.
<jrwren> i mean, every file that is listed as M or -D
<jam> we have this block http://pastebin.ca/1465315
<jam> Which is trying to handle the ENOENT case
<jam> however, you are getting a WindowsError that is not ENOENT
<jam> for whatever crazy reason... :(
<jrwren> from what file is that, is there an easy way for me to log that full_path value on that call? or can I go hack that file?
<jam> jrwren: you might try doing 'touch myfile' before doing the 'bzr up'
<jam> jrwren: you are using the installed version, so it is 'compiled' python
<jrwren> jam: so you think it is the last file in that list?  ok.
<jam> If you are comfortable grabbing the source, I can do it from there
<jam> jrwren: I honestly don't know when that list is generated versus when the renames, etc are done
<jam> but it is a good first start :)
<jrwren> gah, cursed compiled python.  I'm comfortable with installing python and the http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-1.16-1.win32-py2.6.exe
<jam> jrwren: so... it looks like the list of what will be printed is generated *before* it starts touching your working tree
<jam> so the last item on that list *should indeed* be the item causing problems
<jam> jrwren: well py2.6 will also be the "compiled" version, IIRC
<jam> however, you can download the tarball from there
<jam> and run from source
<jam> we have some compiled externsions that are useful but optional
<jam> and shouldn't have an effect here
<jam> jrwren: and if you want to write a patch that adds a "trace.mutter('failed to rename XXX')" as part of the exception clauses
<jam> that would be a good start to making this easier to debug
<jam> or even trace.note()/trace.warning()
<jrwren> jam: I just tried to touch, but it didn't work.
<jam> k
<jrwren> i'm stealing a file copy of the branch so that I can try it myself instead of on her computer.
<jam> jrwren: sure
<jam> good idea
<flvr8> anybody know how to rescue a broken svn repo? there's something in one of the modules that i'm importing which is causing very bad things to happen:   https://bugs.launchpad.net/bzr-svn/+bug/380621
<ubottu> Launchpad bug 380621 in bzr-svn "pull from svn repo gives: bzr: ERROR: base checksum mismatch: " [Undecided,Incomplete]
<flvr8> (i'm the latter comments in there, but kevin - the original reporter - works on a different project at my company. i wonder if somehow our svn repo got snarled)
<jam> flvr8: did someone manually edit the svn repo?
<jam> like changing the author/committer/message/timestamp on an old rev
<jam> use svndumpfilter that sort of thing?
<jam> anyway, I would say "start from scratch" but that can be ugly, I realize
<flvr8> hm, no manual edits that i know of, but it is on a managed host, so there's no telling
<flvr8> i.e. the host may have "fixed" an issue one of the developers were having using similar
<flvr8> hm, i ran svnadmin verify on the svn repository and it reports that all is well
<jam> btw vila, what are you still doing up?
<vila> jam: writing the cover letter :-D I had a hell of a day (starting with a hell of a last night :) and then crashes all around...
 * vila fall asleekl;'mm .f .bh,hmasldf b.
<jam> vila: sleep well
<jrwren> huge kudos to the addition of the nonadmin zip file build for windows!  I love it!
<lifeless> moin
<beuno> hiya lifeless
<jelmer> hey lifeless, beuno
<beuno> heya jelmer
<thumper> lifeless: can I skype you?  I have a few questions
<lifeless> thumper: what about?
<thumper> how bad inconsistent parents are
<thumper> I had reconciled my LP repo
<thumper> and created the 2a repo from it
<thumper> but later pulling into my packs repo to bring it up to day
<thumper> date
<thumper> introduced more inconsistent parents
<thumper> now I'm unsure of the state of the 2a core repo
<lifeless> so
<lifeless> they affect annotate and per-file log
<lifeless> the data that had be reconciled wouldn't have been altered by the pull
<lifeless> you can't [yet] check and reconcile only some revisions, but that is planned
<thumper> why are we still getting inconsistent parents being generated? I don't get it
<lifeless> if you check with -v it should report them
<lifeless> if their revnos are recent, you shouldn't be getting them, so its a matter of tracking down why.
<lifeless> if they were created by PQM, PQM hadn't been upgraded for some time
<thumper> I had reconciled, I ran a check on the packs repo and found  2918 inconsistent parents
<thumper> I reconciled just before all hands
<thumper> so the new revisions would have been since then
<thumper> how can we propagate the proper parents ?
<lifeless> they have to be right before pull/merge/push or they don't propogate
<lifeless> and you have to reconcile to fix
<thumper> if I use -v will it tell me which revids are inconsistent?
<thumper> what about reconcile -v?
<thumper> if there is a flag like that
<thumper> I'm concerned with the new 2a repo for LP and making it good and clean
<thumper> however our deadline for getting it up and distributed to users was 2 days ago :)
<thumper> and any delay hurts us more...
<thumper> it appears that someone(s) are still generating revisions with inconsistent parents
<thumper> pqm is on 1.13 I think
<lifeless> yes, its very traumatic at the moment. I think I've mentioned this :P
<thumper> ATM
<lifeless> pqm is doing 1.16 new
<lifeless> upgaded yesterday as part of the lp upgrade process
<thumper> ok
<lifeless> 1.16rc1 specifically
<lifeless> doing a reconcile is technically a choice
<lifeless> it won't [anymore] affect fetch.
<thumper> as of when?
<lifeless> it now only affects log FILE, annotate & pack.
<thumper> why pack?
<ddaa> Hello. What's the recommended way to get the revid of a lightweight checkout?
<lifeless> around 1.15, but 2a is definitely safe.
<ddaa> I presume "bzr log --show-ids" is not the righ approach as it gives the revid of the branch, which is different if the checkout is out of date.
<lifeless> ddaa: of the tree? bzrlib.workingtree.WorkingTree.open(PATH).last_revision()
<ddaa> lifeless: anything that I can run easily from the shell?
<lifeless> thumper: because pack sorts by topology
<lifeless> ddaa: python -c !$
<ddaa> writing rollout scripts in in sh
<ddaa> uh
<lifeless> ddaa: or perhaps bzr version-info
<ddaa> oh, I'll look into that
<lifeless> thumper: it won't make pack /wrong/ but it can affecct compression
 * thumper nods
<ddaa> lifeless: thanks, so the answer is "bzr version-info --custom --template '{revision_id}\n' [PATH]"
<lifeless> ddaa: :)
<ddaa> mwhudson: slacker
<ddaa> (re: identi.ca)
<mwhudson> :)
<mwhudson> ddaa: i went to bed at 12 and got up 6:30, tim went to bed at 3 and got up at 8, jono went to bed at 1 and up at 7...
<ddaa> mwhudson: and then, you still feel the need to justify yourself? :)
<garyvdm> lifeless: Any sort of querying of WorkingTree.inventory requires a lock on WorkingTree. Is there a way that I can create a in memory copy of WorkingTree.inventory so that I don't have to hold a lock?
<garyvdm> I found .copy(). I'm going to give that a try.
<lifeless> garyvdm: so, as I said before, I'm not sure that inventory is the right tool for what you're doing. However, yes, you can use .copy, but its extremely wasteful. Dirstate trees don't even /need/ an inventory to do most operations.
<garyvdm> lifeless: Oh - I did not realise that there was a tree.iter_children. - Is that what think I should be using?
<lifeless> garyvdm: well it seems to me like you want to cache a bunch of data that bzr normally accessess just-in-time
<garyvdm> For WorkingTrees - Yes, but for RevisionTrees - no.
<lifeless> garyvdm: tree.walkdirs for instance can be very fast
<lifeless> garyvdm: anyhow; as long as you don't use .copy on a RevisionTree.inventory it is probably ok
<lifeless> on a 2a format, .copy has to do scatter-gather IO across all the nodes for the tree.
<garyvdm> lifeless: Ok.  tree.walkdirs may work for me.
<lifeless> garyvdm: I'm mainly worried about performance for historical revisions
<lifeless> garyvdm: its quite a bit cheaper on massive trees to be doing on-demand loading
<jelmer> spiv, lifeless: Shouldn't bug 252945 be fixed by your recent hpss work?
<ubottu> Launchpad bug 252945 in bzr ""bzr push" uploads 1-2 MB just to send a one-line change revision" [Undecided,New] https://launchpad.net/bugs/252945
#bzr 2009-06-19
<lifeless> very much so
<poolie> hello jelmer
<poolie> and lifeless and gary
<lifeless> hai
<poolie> jelmer: when you use bzr-svn on a svn repo that's had changes merged from a branch into trunk
<lifeless> jelmer: not all bugs need tags :P
<poolie> will bzr see the history of changes to a file on the branch before they're merged in?
<jelmer> hi poolie
<jelmer> poolie: In what context?
<jelmer> lifeless: It's so easy to add them now I'm trying to add some that seem relevant when possible
<jelmer> lifeless: I find them useful when looking for dupes
<poolie> i think it's worth adding tags about proportional to the frequency you use them
<poolie> i didn't use them much previously, now they're a bit useful
<poolie> jelmer, well if you run log or annotate within bzr for example
<poolie> the specific case was
<jelmer> being able to edit them without having to go to a different page makes them a lot more useful
<poolie> > 1. import /trunk/foo.txt
<poolie> > 2. branch /trunk to /branches/mybranch
<poolie> > 3. edit /mybranch/foo.txt
<poolie> > 4. merge /mybranch to /trunk
<poolie> will bzr see step 3?
<lifeless> jelmer: I think tags that are reused a lot are great
<jelmer> poolie: depends on how (4) was done
<jelmer> poolie: if it was a merge done using bzr and pushed using bzr-svn, then bzr will see it
<mwhudson> jml: is bzr 1.16 in any ppa yet?
<jelmer> poolie: otherwise, it won't, even with svn 1.5 (since it only supports tracking cherrypick merges, not "full" merges)
<lifeless> jelmer: but when there are few bugs for that tag its no better than searching
<jelmer> lifeless: right
<poolie> mwhudson: "apt-cache madison bzr"
<poolie> well, assuming you have them all added
<lifeless> poolie: rmadison bzr
<lifeless> oh damn
<lifeless> ppas
<lifeless> rmadison should be able to query ppa
<poolie> what's rmadison?
<mwhudson> seems not
<poolie> remote madison?
<lifeless> yah
<lifeless> queries lp/debian
<lifeless> rmadison -u debian bzr
<poolie> jelmer: in the mail i have, the person asserts that svn can follow the distory of that file
<poolie> maybe because it didn't exist on trunk at all before the merge?
<poolie> so svn just represented it as a copy (speculating)
<poolie> in that case i think bzr-svn will track it?
<lifeless> spiv: ping
<poolie> where should we put the ppa debs?
<poolie> i guess we could manually maintain an archive somewhere...
<jelmer> poolie: svn would be able to see which revisions have been cherrypicked onto trunk
<jelmer> poolie: but bzr isn't able to deal with cherrypicks, so bzr-svn ignores that data
<jelmer> poolie: it could do analysis to see if a range of merged revisions is a "full" merge and then add the appropriate parents, but I'm worried about the performance of that analysis if it has to be done for each revision and it seems like it'd just be a stopgap until proper cherrypicking tracking is in place
<poolie> right
<garyvdm> Hi poolie
<poolie> spiv, any ideas about bug 389087?
<ubottu> Launchpad bug 389087 in bzr "ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ..." [Undecided,New] https://launchpad.net/bugs/389087
<lifeless> jml: mwhudson: thumper: is https://bugs.edge.launchpad.net/bzr/+bug/372881 still affecting you ?
<ubottu> Launchpad bug 372881 in bzr "RevisionNotPresent in insert_record_stream - bzr cannot branch from rocketfuel" [Critical,Confirmed]
<jml> lifeless, I couldn't say.
<mwhudson> lifeless: haven't heard anyone complain about it for a while
<jrwren> jam: i'm back to where I was at 16:45 EDT.  what is this trace class of which you speak for me to trace.mutter ?
<jrwren> nvm, google first.
<thumper> lifeless: not me personally
<jrwren> will mutter messages always been output to STDOUT or STDERR?
<jelmer> jrwren: only to ~/.bzr.log afaik
<RenatoSilva> If I have two different features to implement and propose for merging, should I use one branch for each one, or one single branch?
<jrwren> i don't have that file, do I need to touch it?
<jrwren> or maybe on windows it goes to that APPDATA place?
<Peng_> RenatoSilva: Two branches, if it makes sense. Obviously, if one depends on the other, that'd be harder.
<Peng_> Could still use looms, I suppose.
<RenatoSilva> Peng_: the problem is that the branch is a bzr plugin, and I'm using both modifications locally. They don't rely on each other, but I do reply on both of them :)
<RenatoSilva> Peng_: maybe I could have 3 branches locally, 2 of them for development, and one for local use. I would merge the 2 branches into the thrid one once in a while. How about it?
<Peng_> RenatoSilva: Sure.
<RenatoSilva> ok, thanks
<spiv> lifeless: pong
<lifeless> network deltas
<lifeless> I'm blocked on check, and picking the next thing to do
<ebroder> How do people usually submit one-line patches to LP projects? Branch it and request a merge? Just file an LP bug?
<lifeless> #launchpad might have a better answer; I'd say branch and submit a merge (without doing that its rather hard to test :P)
<lifeless> but if its just a typo or something, sure  abug with a diff inline
 * ebroder nods
<lifeless> whatever gets the devs attention and is appropriate for the ammount of work really
<ebroder> *shrug* I'm used to the amount of prep work for a fix being disproportional to the fix itself :)
<spiv> poolie: regarding that AbsentContentFactory bug, it's almost certainly a dupe of 354036, those are both stacked branches that were created before 1.14.1.
<spiv> (and I see it's already been marked as a dupe)
<lifeless> spiv: 'network deltas' wass in reply to your pong
<poolie> spiv, lifeless, thanks, i thought it probably was
<lifeless> poolie: 'bzr info <branch>' is a fast way to check if branches are stacked
<spiv> lifeless: network deltas would be great to do, I still haven't got to them :(
<poolie> lifeless: i know, why?
<poolie> i mean, why do you mention that?
<lifeless> poolie: just seemed like the time to handoff that bug was about the same as doing a quick check and duping
<RenatoSilva> Peng_: optionally, I can merge the 2 branches to the 3rd one, and keep the merge uncommitted. When I have new changes in the 2 branches, I just bzr revert and merge again. I think it's the easiest way...
<poolie> sigh
<lifeless> poolie: it was just a though
<lifeless> t
<poolie> if you actually mean to say "checking that it's stacked is a 100% reliable way to know it's a dupe" then that i didn't know
<poolie> and i'm not sure i believe it
<lifeless> poolie: its extremely high probability. In this particular case I know 100% that the current branch was a dupe, because I ran the fixer and it found missing inventories.
<poolie> ok
<lifeless> poolie: the lp-code people have not yet run the fixer across launchpad stacked branches
<RenatoSilva> humm I can't merge twice without commiting the first merge :(
<lifeless> RenatoSilva: you can by passing --force to merge; but its unusual to do this.
<poolie> jam, are you still around? want to talk sometime?
<RenatoSilva> lifeless: I'm afraidn you're following the discussion, but I think it's a good solution in my case, I'll try --force, thanks!
<RenatoSilva> clear
<lifeless> I did follow it.
<RenatoSilva> clear
<RenatoSilva> lifeless: ok
<AfC> Is there a technical reason why the text metadata in a bundle all has to come at the beginning, _above_ the patch? Could we not have a one or so line header
<RenatoSilva> the 3rd branch is read-only
<AfC> # Bazaar merge directive format 3 (Bazaar 1.17)
<AfC> and then the patch
<AfC> and then the revision id crap?
<AfC> or better yet,
<poolie> AfC: probably not a good reason
<poolie> possibly showing the target branch there is useful
<lifeless> RenatoSilva: that doesn't make a difference AFAICT
<lifeless> RenatoSilva: doing merge,commit,merge,commit and merge,merge--force,commit is not altered by the read state of the third branch
<AfC> poolie: oh, still showing it (if necessary) but down below, after the patch, above the base64 [or whatever] blob of data
<poolie> jam, nice work on bug 345998
<ubottu> Launchpad bug 345998 in bzr "MYSQL/BZR P3: Python-based Windows installers are not available for python2.6" [High,Fix committed] https://launchpad.net/bugs/345998
<RenatoSilva> lifeless: I mean that I won`t deliver the 3rd patch
<RenatoSilva> lifeless: If I want to change something, I will do it in the other branches
<RenatoSilva> lifeless: s/3rd patch/3rd branch
<lamont> lifeless: how soon do you think 1.16 will be released?  (as in installable on an ubuntu box)
<lamont> s/lifeless/poolie/
<RenatoSilva> clear
<lifeless> lamont: PPA should be up shortly
<lifeless> johnf is reasonably prompt
<lamont> yay
<lifeless> he offers a two day SLA
<lifeless> but - 1.16rc1 is pretty close to 1.16.
<lamont> actually, there's a 1.16-1 in debian, I assume that should just work, no?
<lifeless> and thats alrady in the ppa
<lifeless> I'd expect so,yes
<lifeless> just get it synced()
<lamont> lifeless: I'm pretty sure you know why I'm asking, and what the rules are for me to live within.
<lifeless> lamont: wasn't, but just noticed now.
<lifeless> jam: are you still around at all?
<lifeless> jelmer: help me understand https://bugs.edge.launchpad.net/bzr/+bug/386079
<ubottu> Launchpad bug 386079 in bzr "bzr-svn throwing procedure entry point errors" [Critical,Confirmed]
<jelmer> lifeless: as far as I've understood it the problem is that if there's other svn dlls in directories in PATH those get used rather than the DLLs that subvertpy was linked against
<jelmer> lifeless: so it's probably not important enough to be critical, but John would be better able to tell you
<lifeless> thanks
<garyvdm> lifeless: I got my widget to load lazily :-) And so for working trees, I only create copies of items that are shown.
<lifeless> james_w: if you're around, is there a good link on bzr packaging at the moment?
<lamont> lifeless: in the painful case, it's a merge of the diffs in 1.15->1.15-x to s/5/6/g
<lifeless> there are diffs?
<lamont> which is part of why I got out of that business
<lamont> apt-get source is your friend
<lamont> some of them are only a diff in debian/changelog
<lifeless> garh
<lamont> others have debian/control and debian/rules changes
<lamont> others... well, ISTR one setup.py patch one time
<poolie> jml, lamont suggests not doing the announcement mail until we have installers for say ubuntu and windows at least
<poolie> interesting idea
<lifeless> I don't like it
<lifeless> because redhat + bsd + suse etc
<lifeless> unless we want to take responsibility for building all of them too
<lamont> lifeless: I do.  makes it get done before I get the privilege of explaining that it's not out to people who think I should install it NAO
<lamont> lifeless: you could block on $everyplatform - that'd be more software industry standard
<jml> poolie, for that to work & still have time-based releases, building those installers would have to be the RM's job, I think.
<lifeless> lamont: the people in question should know better :)
<poolie> well, making sure that someone builds it
<jml> poolie, which would mean that building those installers would have to be as easy as falling off a log.
<poolie> it tends to make the RM's job bigger
<thumper> if I have a light weight checkout, can I just switch the underlying repository format under it?
<poolie> which is undesirable
<poolie> thumper: probably yes
<lifeless> thumper: yes
<thumper> move my packs repo out of the way, move 2a in and have it work
<thumper> cool
<lifeless> oh
<jml> poolie, making sure someone builds it drags out the process further, because of hand-offs & TZ issues.
<lifeless> actually 'no'
<lifeless> thumper: the root data in the dirstate will be invalid
<thumper> lifeless: why?
<lifeless> of course, its likely that I've just realised that 'bzr upgrade' has a critical bug with respect to rich root changes
<thumper> :(
<lifeless> thumper: recreate the tree
<thumper> ok
<lifeless> thumper: you should do this for all trees when you upgrade the repo across a model change (non-rich-root to rich-root)
<thumper> ok
<lamont> lifeless: if the announcement said "we'll have binaries shortly" or some such, that'd help.
<poolie> i think it normally does
<lamont> right now, if I go to bazaar-vcs.org and click on what appears to be the link to go get ubuntu install info for 1.16, I get.... 1.15-1
<lamont> which is kinda confusing to a newbie
<poolie> which link?
<lamont> Downloads and installation instructions
<lamont> then  	
<lamont> ppa repository,
<lamont> downloads and install being a link under 1.16
<lamont> which, of course is one of 2 ways that I check to see if it's out already.
<lamont> the other being apt-get update; apt-get showsrc bzr | grep Version
<thumper> lifeless: branching from my server to my laptop where both repos are 2a over bzr+ssh I'm getting CPU maxing on the server, and very little network traffic
<thumper> lifeless: fetching revisions
<RenatoSilva> clear
<lifeless> thumper: is it an initial branch?
<lifeless> thumper: that is, is the target repo empty?
<lamont> anyway, family time gluing a floor down.  later.
<thumper> lifeless: yes
<lifeless> ciao lamont
<lifeless> bug 388269
<ubottu> Launchpad bug 388269 in bzr "getting a branch into an empty shared repository takes a long time to figure out revisions to send" [High,Triaged] https://launchpad.net/bugs/388269
 * thumper nods
<thumper> ok
<thumper> we probably want this fixed before everyone tries to grab LP :)
<lifeless> not going to happen
<lifeless> theres a bunch of stuff we /have/ to get done which if we don't things will be consistently bad much more often
<lifeless> and you have a fixed date for the LP code; I don't see us getting through everything for 2 before then; *if* we do then perhaps - but this isn't a regression
<lifeless> its been like this for a long time, and the LP code base is no worse than mysql's, AFAIK
<Peng_> lifeless: ...I totally didn't know about merge --force. I'll have to remember that!
<lifeless> igc1: ping
<lifeless> jelmer: hi
<lifeless> jelmer: I have a small request for you while you are touching bugs
<ahn> I'm new to bzr and am trying to figure out a way to merge converted repositories.
<Peng_> ahn: What exactly do you mean?
<lifeless> jelmer: as you qualify as a dev, perhaps you could try to move the bug forward a step at the same time?
<ahn> I have a bzr repository A, which is a conversion from CVS with full history, that includes versions from say 2000-2005.
<ahn> I have a bzr repository B, which a conversion from darcs with full history, that includes version from say 2006-2009.
<ahn> I'd like to know if there is a way to essentially "concatenate" the two repositories so that the histories are in series.
<lifeless> jelmer: specifically, after you touch it, it should be either incomplete needing more info, waiting for someone more knowledgable than you to comment/analyse, or ready-to-code.
<lifeless> jelmer: ^ not a requirement, but if you can, its actually more useful than merely categorising many bugs to do that to a smaller number of bugs
<lifeless> ahn: what you may find works best is to export B as a fast-export and use fast-import to append it to A
<ahn> lifeless: fast-import appends to an existing repository while preserving full history?
<lifeless> I'm fairly sure it can
<lifeless> of course, work on a backup until you've got the process tuned for you
<lifeless> fast-export and fast-import are in the bzr-fast-import plugin
<ahn> I will investigate, thanks.
<Peng_> jelmer: FYI, you had a revision of bzr-rebase's trunk that marked it as compatible with bzr 1.16 and 1.17, but it's been replaced by the 0.5.1 release.
<treeform> i am trying to get another project member using bzr
<treeform> he he is running into all sort of porblems like this
<treeform> http://pastebin.com/d58e1f99
<lifeless> treeform: use a newer version, that bug was fixed
<treeform> lifeless: thanks!
<treeform> lifeless: hmm there is no 1.1.6 windows build yet
<treeform> 1.1.6*
<treeform> grr
<treeform> 1.16*
<lifeless> should be a 1.15.x one though
<treeform> no they got new on up in another place
<jml> https://edge.launchpad.net/bzr/1.16/1.16 has windows builds
<treeform> thanks
<treeform> but its not main link at the site
<igc> hi all
<igc> pong lifeless
<treeform> sup igc
<lifeless> igc: iter_changes; are you blocked/its on the shelf/its all done vis-a-vis commit?
<lifeless> igc: if its on the shelf I may do it next week
<jml> treeform, is now :)
<igc> lifeless, it's on the shelf for at least a few more days
<jml> (yay wikis)
<igc> igc: if you got to it, that would be really great
<igc> lifeless: ^^
<lifeless> igc: ok. Monday I'll page it in and make a call about doing it/not.
<treeform> jml: i love open source :)
<igc> lifeless: sweet. I did put a fair amount into it but nothing beyond my initial terrible-to-ok-but-not-great patch that's worth sharing
<lifeless> igc: kk
<treeform> "bzr: ERROR: Unable to look up default port for ssh" ?
<treeform> hmm its 20 or 22?
<treeform> should bzr know that?
<treeform> 22 wins!
<lifeless> never seen that error before
<lifeless> you might like to file a bug
<treeform> http://pastebin.com/d79ccb48f
<treeform> i think his problem is that
<treeform> he cant break lock
<treeform> because of this stupid ssh error
<treeform> and he cant rebind
<treeform> because of the stupid lock
<lifeless> if you run with -Derror you will get a backtrace that may help debugging
<treeform> is there a way to break lock manually?
<lifeless> I'm not sure why you have a lock that needs breaking anyway
<lifeless> that should be very rare
<spiv> treeform: have you tried "bzr break-lock bzr+ssh://host:22/..." ?
<treeform> no
<treeform> there is no lock on the server
<treeform> its local
<treeform> i ran bzr break-lock on the server
<treeform> nothing cameup
<lifeless> run bzr unbind; bzr break-lock; bzr bind
<spiv> Also, maybe your %SYSTEMROOT%\System32\Drivers\Etc\Services
<spiv> needs fixing?
<spiv> (that's just a wild guess, though)
<lifeless> the backtrace will tell us
<treeform> hmm
<treeform> how to disable default bzr-tortouze stuff on windows?
<treeform> his computer is lagging like hell because of it
<lifeless> treeform: I'm not sure
<treeform> i think i found it
<RenatoSilva> any bzr-eclipse folk here?
<johnjosephbachir> hey folks
<johnjosephbachir> workflow question: i'm working on some code, i want to merge in upstream changes. i get the message "ERROR: Working tree "blah blah/" has uncommitted changes"
<johnjosephbachir> what are my reasonable options here?
<lifeless> either commit before merging, or shelve before merging
<lifeless> merging changes your tree and then you need to commit what you merged
<johnjosephbachir> what i want to do, is bring in the new changes, and then carry on with what i was doing.
<johnjosephbachir> to do that, do i shelve, merge, unshelve?
<lifeless> shelve; merge; commit; unshelve
<johnjosephbachir> ahhhh
<johnjosephbachir> okay
<johnjosephbachir> thanks!
<lifeless> or
<lifeless> commit; merge; commit
<lifeless> depending on whether you have reached a suitable point to commit your own changes
<johnjosephbachir> yeah, i haven't
<johnjosephbachir> okay, i just did bzr shelve, and then y y y y
<johnjosephbachir> but bzr status still shows modified files
<johnjosephbachir> do i need to manually rever them?
<johnjosephbachir> by manually i mean, explicitely, with bzr
<lifeless> uhm
<johnjosephbachir> and/or: won't merge still complain?
<lifeless> 'bzr shelve --all' should save everything such that 'bzr st' will show no changes
<johnjosephbachir> okay
<lifeless> if it doesn't, what bzr version are you using?
<johnjosephbachir> --all did it
<johnjosephbachir> i wonder if i was hitting y / return so fast that it missed a couple ys
<lifeless> johnjosephbachir: I'd say so ;)
<ttyType> hi people
<ttyType> my kitteh just managed to catapult my spoon out of my cereal bowl, so my monotor was covered in soy milk spatter
<ttyType> (it's a lappy)
<ttyType> it looked like someone has been looking at pr0n
<ttyType> *monitor
<poolie> anyone want to comment on the proposed phrasing in bug 346677?
<ubottu> Launchpad bug 346677 in bzr "message about launchpad-login is confusing" [Medium,Confirmed] https://launchpad.net/bugs/346677
<spiv> poolie: commented
<poolie> thanks spiv
<treeform> hmm lifeless, jml  windows bzr just not working for us... the guy i was working with gave up
<jml> treeform, that sucks.
<treeform> i dont know what to do
<treeform> i been using bzr for so long
<treeform> but when other people try to use it it just breaks for them
<jml> treeform, there's a couple of things I can think of.
<treeform> part of the problem might be that the bzr repo is 1GB of data
<jml> treeform, the first is look for the failures in Bazaar's bug tracker: https://bugs.launchpad.net/bzr
<treeform> and we dont have great network connectsion
<treeform> so its always a bother pushing this much data around
<treeform> jml: i have opend some bugz in that list
<jml> treeform, although my mental powers are to be greatly feared, they do not extend to mind-reading.
<vila> hi all
<treeform> well what do you want me to do?
<jml> treeform, explicitly describing the observed failures is often half the battle.
<treeform> yeah
<jml> vila, hi :)
<lifeless> treeform: where did you get stuck with your friend?
<treeform> when working with some one who is not verly technical its a real pain
<vila> jml: hey !
<lifeless> I'm not really here right now
<lifeless> but I'd say
<lifeless> be sure they don't run random commands, if they are having trouble flailing will make it worse.
<lifeless> if bzr gives an error that you don't recognise file a bug etc
<treeform> well it started out with sftp
<treeform> basically i did an update
<treeform> it did a repack
<treeform> and it when redownloading everything
<treeform> so i say
<treeform> hmm
<treeform> ok lets switch to bzr+ssh
<treeform> just kill the update
<treeform> which was running now for 2 hours
<treeform> so he broke it
<treeform> now lets rebind
<treeform> cant
<treeform> its locked
<treeform> lets break lock
<treeform> cant break lock
<treeform> then you guys suggested to update
<treeform> ok we update
<treeform> still cant break lock
<treeform> because now we cant ssh
<treeform> so another thing broke during update
<treeform> on the other hand i cant really blame bzr
<treeform> because its turning more into people problem then a software problem
<treeform> --- end of rant --- sorry
 * igc dinner
<jml> treeform, the situation certainly sounds complex.
<jml> treeform, maybe sending an email to the bazaar list is your best bet.
<treeform> bzr is being blamed for making computer run really really slow
<treeform> it can be a virus
<treeform> he is uninstalling to conform
<jtv> jml: more bzrlib complications...  I think I need to get a trans-id for a directory in my revision tree.
<jtv> I know how to get its id, but not its trans id.
<lifeless> doesn't exist
<lifeless> trans-ids only exist during a tree transform, they are transient
<lifeless> why do you think you need it
<lifeless> ?
<jtv> lifeless: nm, I've got it now, from the transform preview.
<jtv> lifeless: this is still for the direct-commit-to-branch stuff.
<poolie> spiv, lifeless, bug 389413 is strange
<ubottu> Launchpad bug 389413 in bzr "ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked running diff across hpss" [Medium,Confirmed] https://launchpad.net/bugs/389413
<poolie> is that a dupe maybe?
<lifeless> poolie: are you burning out? logoff :)
<poolie> mm, why?
<poolie> should i know what it is?
<spiv> I think he's saying it's nearly 8pm :)
<lifeless> no, uhm have you seen Jono's talk on burnout?
<spiv> (I'm certainly about to logoff...)
<poolie> i believe it is that time in the northern suburbs too :)
<poolie> i am too actually
<poolie> i'm staying on because i'm enjoying it
<lifeless> I'm online, but doing personal stuff
<spiv> poolie: if it's a recent regression, the traceback suggests it may be fallout from my get_rev_id_for_revno patch.
<poolie> mm i thought so
<spiv> In which case I'd guess cmd_diff isn't locking early enough...
<poolie> it should go without saying you don't need to fix it tonight :)
<poolie> i was just wondering
<poolie> otoh launchpad seems pretty fast after the 1.16 rollout
<LarstiQ> moin
<spiv> Yeah, I won't fix it tonight :)
<spiv> cmd_diff isn't exactly trivial ;)
<spiv> Well, it is, but the helper it calls isn't...
<spiv> G'night all :)
<lifeless> spiv: more likely a remote.py bug
<lifeless> unless its using --old or something
<spiv> lifeless: maybe, either way it's my fault ;)
<lifeless> :P just trying to aim things :)
<lifeless> as pack_repo is very strict on locks itself
<poolie> ok, good night
<vxnick> hi guys - I'm getting the following error when trying to commit: bzr: ERROR: No such file: '/home/vxnick/bzr/repo_name/trunk/.bzr/branch/last-revision': [Errno 2] No such file. This happened after I had to break-lock because bzr commit was hanging
<vxnick> this is also a remote repo
<lifeless> you shouldn't ever need to break-lock
<lifeless> unless bzr advises you to
<lifeless> have a look in that directory, see if there is a last-revision.* - some sort of tem file
<lifeless> temp
<vxnick> yeah there is
<vxnick> there's two - one with a prefix of tmp and one with a suffix of tmp
<lifeless> check the datestamps
<lifeless> and/or the contents
<lifeless> one will will have higher revno and be newer
<lifeless> rename that to last-revision
<lifeless> why did you think commit had hung?
<vxnick> I think my connection to the server was dodgy
<vxnick> it took 6 minutes to commit a couple of lines
<lifeless> are you using sftp ?
<vxnick> yeah
<lifeless> ok, that could explain it; with sftp we cannot do atomic operations so we emulate
<vxnick> I've been looking at using the bzr server but am unsure as to how stable it is atm
<lifeless> that should be the only oddity you'll have; if you can use bzr+ssh it will be faster and more robust
<lifeless> we're still evolving it but as a user you shouldn't notice that.
<vxnick> is "bzr serve" the same as SmartServer?
<lifeless> yes
<vxnick> thanks
<lifeless> you can just install bzr on the server
<lifeless> and then replace sftp with bzr in your urls
<vxnick> I need to use ~/.bazaar/authentication.conf for the server don't I?
<lifeless> unless you have /~/ in your url, in which case you need to change that to an absolute path
<fullermd> ITYM "with bzr+ssh".
<lifeless> sorry, as fullermd says, with 'bzr+ssh'
<lifeless> vxnick: no, it uses ssh, same as sftp
<vxnick> gotcha
<lifeless> vxnick: there should be no need to change anything else.
<fullermd> vxnick: The smart server actually has 3 different interfaces, but you can ignore two of them and just use bzr+ssh (no need to config anything on the server beyond having bzr installed and in $PATH)
<vxnick> it's more efficient than using sftp right?
<fullermd> In general, it's somewhat more efficient.  Occasionally, it's mind-zonkingly more efficient.
<vxnick> :)
<vxnick> lifeless: thanks for your help with the last-revision, it seems to be working now :)
<vila> jam: Pping
<vila> err, ping I meant
<ddaa> Hey. Where can I read about bzr new shiny beta branch format?
<ddaa> ("in the mind of bzr devs, Spock-style" is not an acceptable answer)
<vila> ddaa: ML archives, doc/developers, sources :)
<ddaa> vila: can you give me a single URL?
<ddaa> I stopped reading the ML eons ago because I want to have other sources of informations and still do something in my day.
<vila> ddaa: bazaar-vcs.org has docs online AFAIR
 * LarstiQ has a look
<LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/improved_chk_index.html is not what you're looking for I suppose
<LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/development-repo.html
<ddaa> definitely interesting, I'll put it on my reading list, but a weeeee bit too detailed.
<LarstiQ> yes
<LarstiQ> and the later one is a bit stingy on details
<ddaa> the later one appearst to be a process document
<ddaa> not a technical summary
<LarstiQ> ddaa: sorry, at the very end
<LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/development-repo.html#format-details
<ddaa> Right, thanks.
<ddaa> So in summary: 1. groupcompress delta 2. CHK inventory store
<bialix> jam: hi
<ddaa> could use something intermediate between that and the chk_index spec :)
<vila> ddaa: patches welcome :)
<ddaa> I'll just wait for the bargraphs
<ddaa> sooner or later jam will generate new ones because they are known to make Mark happy :)
<bialix> Ð¸ÑÐºÐ¿ÐºÑÐ·ÑÑ,
<bialix> bargraphs?
<vila> bialix: graphics  with bars to show results (sales, performances, etc)
<bialix> sales... sounds good
<LarstiQ> bialix: the ones jam makes are usually about performance :)
<jam> hi bialix, ddaa
<bialix> jam: hi
<jam> ddaa: http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html ?
<ddaa> jam: hi
<bialix> LarstiQ: vila knows better ;-) I guess
<jam> vila: pong
<ddaa> jam: thanks, readitlatered
<bialix> jam: I think the size of imageplugins could be dramatically reduced
<bialix> I'm just not sure how to write the support for bundling them into bzr.exe
<bialix> what version of PyQt4 you have installed on your build machine?
<vila> jam: The needds fixing was about gdfo to be declared as long right ?
<vila> jam: auddenly I had a doubt about 'Needs Fixing' == 'tweak'
<jam> vila: and generally pyrex improvements
<jam> vila: which I was willing to work on before we land
<vila> ha, so I don't submit then ?
<jam> I have no idea what is "tweak" versus what is "resubmit"
<jam> bialix: I'll check
<vila> jam: resubmit exists as such...
<jam> vila: resubmit actually *resubmits* the request
<jam> as in, start a new merge request
<jam> not, "come back later with a new one"
<jam> more "I updated my branch, here is a resubmitted version"
<jam> bialix: py -c "import PyQt4.QtCore; print PyQt4.QtCore.qVersion()" gives
<jam> '4.4.1'
<bialix> thx
<abentley> jam, there's a bug in reconcile that's affecting mars.  Any chance you can take a look at it? https://pastebin.canonical.com/18735/
<jam> abentley: I think that is the wrong paste
<jam> that is a 'bzr info' one
<abentley> jam: Sorry, it's a bit hectic in #launchpad-code today.  https://pastebin.canonical.com/18733/
<abentley> jam: We upgraded to the 2a format overnight.
<jam> ah
<jam> abentley: .... the traceback makes no sense
<jam> build_details is a dict
<jam> but "iteritems" is just a method
<abentley> jam: could it be a mismatch between the .py and the .pyc?
<jam> abentley: possibly
<jam> certainly _get_components_positions() is used all the time
<jam> and not just for reconcile
<jam> I wonder if there might be a bug in the compiled extensions.
<jam> He might try without them
<jam> (at least that random of an error makes me wonder about random memory corruption.)
<mars> hi jam
<mars> jam, would you be able to tell me how I would go about running bzr without the extensions?
<jam> mars: well, the easiest is to grab a tarball of bzr, extract it into a folder
<jam> and then run from there
<jam> without running 'make' first
<jam> https://edge.launchpad.net/bzr/1.16/1.16
<jam> you can just do "~/path/to/bzr reconcile"
<jam> (we support running directly from the source tree)
<jam> sorry, I'll be a bit in and out for the next couple of hours
<mars> jam, ok, I'll give that a try
<vila> jam: if you intend to work on it, be sure to grab the latest from lp:~vila/bzr/gdfo-heads/
<jam> mars: As an added bonus, that makes it easier for us to tweak things and see what works
<jam> if it *does* work that way
<jam> then try running "make"
<jam> mars: (first copy your repo)
<jam> and see if "bzr reconcile" breaks after "make"
<jam> (well, "~/path/to/bzr")
<mars> right
<vila> Oook ?
<vila> abentley:     from bzrlib.plugins.bzrtools.tests import test_fetch_ghosts
<vila> ImportError: cannot import name test_fetch_ghosts
<vila> abentley: I was so sure you fixed that 8-/
<abentley> vila: Should be there as of revno 709
<mars> abentley, before running the bzr reconcile, should I reset the repository state?  Perhaps by copying backup.bzr to .bzr, or something similar?
<vila> 715...
<abentley> mars: I'm not clear whether reconcile creates backup.bzr
<vila> abentley: eeerk ! system-wide plugin ! Sorry for the noise
<mars> abentley, ah, right, it could have been the 1.6 upgrade
<abentley> vila: np
<visik7> hi
<visik7> a question
<visik7> if A commit to revision 1 than B commit to revision 2 than A modify a file and update to rev 2
<visik7> does the file get a conflict ?
<mars> hmm.  if bzr reconcile runs the disk out of space, it doesn't clean up after itself after aborting, thus cleaning up the space it used :(
<luks> visik7: that depends on the changes
<visik7> luks: in which sense ?
<luks> visik7: they might conflict or not :)
<luks> if they change the same code in a different way, it will report a conflict
<luks> but if they change e.g. different function, it will not
<visik7> no wait
<visik7> A put a revision 1
<visik7> with 2 files
<visik7> for example with main.c and functions.c
<visik7> B commit rev 2
<visik7> modifying file function.c
<visik7> now A modify main.c
<visik7> and before commit he run an update
<visik7> the conflict should not happen, right ?
<luks> right
<visik7> ok now I'm going to check why it had happen
<mars> abentley, found a new bzr reconcile issue using the tarball, san-extensions, as jam suggested: SHA1KnitCorrupt: https://pastebin.canonical.com/18752/
<abentley> mars: I'm not sure what to do about that.
<jam> abentley: given that this is an inventory, and that it is mismatching the raw content, I'm guessing its our old friend
<jam> inventories not consistent with inconsistent ghosts
<jam> it is also failing on the Knit side
<jam> not the GC side
<jam> certainly that is a different error, but I don't understand why you would ever be getting the first one
<jam> hmm... maybe in an exception clause, let me check
<flacoste> I'm trying to move a LP branch from my old repo to a 2a repo
<flacoste> and i get this error:
<flacoste> KnitCorrupt: Knit <bzrlib.groupcompress._GCGraphIndex object at 0x7f925da0e510> corrupt: inconsistent details in add_records: ('53507751 66036 91238 118445', ((('01creation.txt-20071122132843-ajpxh023ndwrzebk-2', 'kiko@canonical.com-20080801032521-84uzp66nlpu511ur'), ('01creation.txt-20071122132843-ajpxh023ndwrzebk-2', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6')),)) ('65 580329 1680183 1707390', ((('01creation.txt-
<flacoste> 20071122132843-ajpxh023ndwrzebk-2', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6'),),))
<flacoste> i did run bzr reconcile in the old repo beforehand
<jam> flacoste: weird. for the file "01creation.txt" in a given revision
<jam> one side claims 2 parents
<jam> the other side claims only a single parent
<jam> both claim "abel.deuring..." but the first claims "kiko@canonical"...
<flacoste> unfortunately, i have no idea on why this is happening
<jam> so... you *do* have inconsistent information for that entry... but I couldn't tell you why
<jfroy> jelmer: thanks for the two bug fixes
<flacoste> jam: anything i can do about it?
<jam> flacoste: well, other than cry?
<flacoste> jam: or should I just recreate a new branch and apply a diff?
<flacoste> ok!
<jam> flacoste: how big is the branch?
<jam> how important?
<flacoste> it's trivial to recreat
<jam> We can try, but it would take time and effort
<flacoste> e
<flacoste> not even a 100 lines
<flacoste> i'm reporting it more as part of the dogfood effort
<flacoste> and making it a super experience for everyone else
<flacoste> i think it points either to a bug in reconcile
<flacoste> or in the uprade to 2a
<jelmer> jfroy: can you still reproduce bug 269669?
<ubottu> Launchpad bug 269669 in bzr "Tried to branch a svn checkout on another machine" [Undecided,New] https://launchpad.net/bugs/269669
<jfroy> jelmer: I have not seen that bug again
<jfroy> I doubt I can reproduce it either.
<jfroy> Closing as invalid.
<jelmer> jfroy: thanks
<jfroy> For the record, Invalid is a lame status :p
<jfroy> I'd prefer "No to be fixed" or "Works as designedâ¢"
<bialix> jelmer: did you saw bzr-svn test.log @ win32?
<jelmer> bialix: no, where was that?
<bialix> yesterday
<bialix> http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/59156
<jelmer> bialix: thanks
<bialix> maybe you need to persuade jam to get tdb bundled into bzr.exe
<jelmer> I doubt it builds on windows
<bialix> ah
<johnjosephbachir> how do i view the differences between my local committed code, and the code in the remote repo to which i push?
<beuno> johnjosephbachir, I use:  bzr send REMOTE_BRANCH -o review.diff
<johnjosephbachir> beuno: muy bueno, thanks, i'll read the docs on send and the -o flag
<dash> hm, i think the other way is "bzr diff -rsubmit:"
<bialix> bzr diff -rbranch::push
<dash> hah, ok. I didn't know about :push
<bialix> there is a few of them
<bialix> :parent, :submit
<bialix> I'm not sure where these aliases actually documented
<bialix> but I'd stick to beuno reciepe
<fullermd> I'm pretty sure they're not.
<jskulski> hey I'm using bzr-svn to work with a svn repository (initially i bzr branch file://var/svn..) now I am trying to get updates from that repository, bzr update says i am updated, bzr pull and merge fail saying I have uncommited changes
<jskulski> can anyone give me some direction
<dash> 'bzr update' just makes sure your working tree is in sync with your local branch
<bialix> look what `bzr status` says
<dash> jskulski: you can't bring in new changes from a remote branch (your svn repo) if you have uncommited changes to your working copy
<Tak> what? since when?
<dash> jskulski: what I usually do in that case is 'bzr shelve' if it's changes I want to keep
<jskulski> dash is that just part of the bzr workflow? (I am new to bzr and DVCS in generall)
<jskulski> bialix i have a few unknown files and one modified
<bialix> dash: I think pull should work even if you have uncommitted changes
<dash> jskulski: yes
<bialix> try bzr pull
<bialix> bzr pull ~= svn update
<Tak> pull Works For Me when I have uncommitted changes - I do this all the time
<dash> oh, true. pull works
<dash> i got confused :)
<jskulski> i get
<jskulski> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<bialix> I suspect this
<dash> right. so in that case you _do_ need to shelve or commit (or revert) your changes until the merge is done
<bialix> you can bzr merge --force
<bialix> but better if you to do as dash said
<Tak> if you commit changes, you'll still have to merge
<dash> well. no matter what you'd still have to merge
<bialix> jskulski: you can compare 2 branches with `bzr missing` and you'll see what the difference in histories
<jskulski> yaya
<bialix> naturlich
<jskulski> i shelved my changes and bzr merged, it pulled it changes, and unshelved
<jskulski> thanks bialix Tak dash
<jskulski> !
<dash> <3
<bialix> it was easy
<jskulski> yeah
<bialix> dash: what it means? (<3)
<jskulski> <3
<bialix> interesting...
<dash> bialix: it is supposed to be a heart shape.
<bialix> and?
<bialix> igc made incredible work with bzr explorer
<jfroy_> jelmer: do you foresee problems with doing uncommits?
<jfroy_> on a local branch of a svn branch
<fullermd> bialix: Oh, BTW, since I got my new workstation up, I finally got to try out qlog.  Pretty nifty.
<bialix> fullermd: kudos to garyvdm
<fullermd> I did come across one or two wishlist items...
<bialix> about?
<fullermd> I'd like to be able to 'expand all' on the merge revs.
<bialix> yep, sometimes me too
<fullermd> And maybe set the diff window to default to unidiff mode rather than SxS.
<bialix> you can send your feedback to qbzr ml, or file a bugs
<bialix> qdiff should be controlled via command-line options
<bialix> or you talking about invoking qdiff from qlog?
<fullermd> From qlog, yah.
<bialix> yep
<bialix> bug a file
<johnjosephbachir> how can i see the results of bzr revert?
<beuno> johnjosephbachir, bzr diff
<johnjosephbachir> beuno: okay, i'll check that out... but what about, just simply obvserving the basic state of my repo?
<johnjosephbachir> i.e., what i have reverted back to?
<bialix> bzr cat?
<johnjosephbachir> haha
<dash> 'bzr log -l1' maybe
<johnjosephbachir> dash: exactly-- that does NOT change after i run revert
<dash> not sure i understand the question
<bialix> johnjosephbachir: your question is also haha
<fullermd> johnjosephbachir: revert doesn't change anything in the branch/repo; it only affects your working tree.
<dash> yeah i was just thuinking that
<dash> thinking
<fullermd> So it would never affect log or like commands.
<johnjosephbachir> okay
<johnjosephbachir> bzr diff has no output.
<bialix> anybody knows how can I made good looking screenshot page at http://bazaar-vcs.org/BzrExplorer/Screenshots?
<bialix> for some reason moin stretch the images
<johnjosephbachir> bialix: when you suggested cat, i was hahaing my own ineptness at presenting my question
<johnjosephbachir> fullermd: after i run revert, how can i then observe the changes that it made to my working tree?
<bialix> if you revert then you lost your changes
<Tak> bzr time-machine?
<dash> johnjosephbachir: are you talking about 'bzr revert -r somerev'?
<johnjosephbachir> dash: i thought revert went back a changeset at a time with each invocation
<dash> no
<fullermd> Well, it'll [under some circumstances] make backups of the files it changes named like $FILE.~1~.  That's not necessarily reliable across multiple reverts though, and it doesn't tell you anything about renames etc. that it reverted.
<johnjosephbachir> Tak: lol
<dash> johnjosephbachir: with no args, revert just removes existing differences with the branch tip from the WC
<johnjosephbachir> dash: Oh. Okay. That sounds very subversion-like. for some reason i thought it was different. so revert is still the best way to roll back changesets, right? (with the -r flag)
<bialix> no, you need uncommit for this
<fullermd> I think a much more precise definition of "roll back changesets" is needed to answer that...
<dash> yeah, this is different from svn, 'bzr revert -r X' is equivalent to 'svn up -r X'
<johnjosephbachir> bialix: fullermd: dash: okay, that clears everything up -- thank you!
<fullermd> Not exactly it's not...
<dash> so if you want to create a new revision that undoes the changes of a previous one, sure. 'bzr revert -r X', 'bzr ci'
 * bialix nods
<dash> fullermd: i should have said "analagous to"
<dash> since bzr and svn are obviously different. :)
<johnjosephbachir> bialix: yeah i was thinking of uncommit dash: right, so that is the svn way, but uncommit is the bzr way (more or less)
<dash> johnjosephbachir: eeeeh
<fullermd> But that doesn't undo [X+1], it commits the state exactly as of X.  So it would undo _any_ changes you made post-X, not just those in [X+1].
<dash> johnjosephbachir: uncommit actually removes commits from your branch
<johnjosephbachir> dash: yep, that's what i want in this case.
<dash> johnjosephbachir: the main use case for that is when you check stuff in, and befor you push, realize you made a mistake
<johnjosephbachir> yeah
<johnjosephbachir> exactamente
<dash> if you've already shared this revision with other people, it's often a good idea to not do that. :)
<Tak> hmm, if you uncommit, it tells you the branches diverged when you try to push, doesn't it?
<dash> Tak: if you uncommit stuff that's in the remote branch, yes
<bialix> push --overwrite can do magic
<dash> "do magic" means "break things" ;-)
 * fullermd grabs a Dremel and does magic.
<bialix> rats
<bialix> this moinmoin made me crazy
<bialix> what's wrong with my png?
<bialix> pheww
<bialix> firefox increase images
<johnjosephbachir> grrr. my ports system doesn't have bzrtools up to date for my version of bzr
<johnjosephbachir> so i can't use clean-tree
<fullermd> Which ports system?
<bialix> install by hands, no?
<johnjosephbachir> macports
<fullermd> What versions does it have?
<johnjosephbachir> bzr 1.15, bzrtools 1.13
<johnjosephbachir> i'm installing from source now... does the main source distribution have bzrtools or do i have to install that separately?
<fullermd> Well, the quick short solution would be to grab the bzrtools 1.15 tarball and stick it in your ~/.bazaar/plugins/.
<fullermd> That saves you from doing any system-wide screwing around.
 * fullermd grumbles at the wiki.
<johnjosephbachir> fullermd: ah okay-- fantastic
<johnjosephbachir> fullermd: worked perfectly, thank you so much, you saved me 30 minutes of pain
<fullermd> You'll get my bill in the mail   ;)
<johnjosephbachir> bzr is throwing an exception when i try to unshelve something... is there any way i can save my shelved changes?
<dash> they're in .bzr/checkout/shelf
<johnjosephbachir> yay
<dash> what's the exception?
<johnjosephbachir> https://bugs.launchpad.net/bzr/+bug/389674
<ubottu> Launchpad bug 389674 in bzr "exception encountered when unshelving" [Undecided,New]
<dash> Oh dang
<dash> that's not happy
<mwhudson> jelmer: hi, do you know anything about this failure? https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne
<lifeless> wow, odd to have maemosyne in git... mnemosyne is bzr
#bzr 2009-06-20
<jelmer> mwhudson: current bzr-git doesn't have a problem with that branch
<mwhudson> jelmer: cool
<mwhudson> jelmer: have you released bzr-git yet?
<jelmer> mwhudson: yeah, 0.4.0
<mwhudson> does that have all the relevant fixes in?
<jelmer> yeah
<mwhudson> cool
<abentley> spiv: around?
<spiv> abentley: not really...
<jrwren> can I ask bzr ls for find -ls style output?
<AfC> jrwren:
<AfC> $ bzr ls -R | ls -ld
<johnf> LarstiQ: do you have time to package latest version of bzr-svn?
<mwhudson> johnf: will 1.16 be in the ~bzr ppa soon?
<johnf> mwhudson: need to wait on bzr-svn before I can copy it across. I'll make a start on it later on tonight if I don't hear frm LarstiQ. It's in ~bzr-beta-ppa now if you're keen
<mwhudson> johnf: ah, cool
<hsn_> i am using python based windows install. If i run bzr info, python complains about missing zlib1.dll
<Peng_> Oogh. What version?
<hsn_> 1.16
<Peng_> There have been problems (and changes) with zlib on Windows. I dunno anything, though.
<hsn_> it probably needs to be added to list of libraries needed to run bzr
<Peng_> zlib is a little complicated.
<hsn_> but why you are not using zlib python module? it works
<Peng_> Or, yeah, the installer might just be missing it completely or something.
<Peng_> hsn_: This is from C, not Python.
<Peng_> hsn_: They investigated using Python's copy of zlib, but it's not possible.
<lifeless> hsn_: we do use the python zlib module; the C groupcompress extension however is much faster by using zlib directly from C
<lifeless> hsn_: so you need to install zlib1.dll from the zlib site :)
<hsn_> it can not be added to installer?
<lifeless> it is I think; you're using the python install method though
<lifeless> and python statically links zlib
<lifeless> or something like that
<Peng_> Oh, you need to install zlib yourself now?
<hsn_> i will update wiki then
<hsn_> it seems to work without zlib just fine, except you must press 'enter' on every popup message box
<Peng_> C zlib is only used if you're using the development6-rich-root or 2a repo formats, so you probably won't actually run into it.
<hsn_> oh man, you updated wiki, it have different syntax now
<lifeless> hsn_: its still moin
<lifeless> hsn_: just uses ReST rather than wiki-specific syntax
<hsn_> ReST is probably worst markup language ever made
<Peng_> Is there a LOLMARKUP?
<lifeless> Peng_: you could make one, based on intercal?
<Peng_> Heh, nice.
<hsn_> how to write backslash in ReST?
<lifeless> \ ?
<hsn_>  '\?' doesnt work
<hsn_> it renders to '?'
<lifeless> try \\
<lifeless> if you're writing a path, you might want ``c:\\foo\\bar``
<hsn_> done.
<lifeless> hsn_: is 1.16 working better for you now?
<garyvdm> Hi lifeless
<lifeless> hi garyvdm
<garyvdm> lifeless: Tree._comparison_data - How come it is _private?
<lifeless> its not meant to be called by code outside the implementation of Tree
<hsn_> lifeless: no, but at least it doesnt complains about missing zlib1.dll
<garyvdm> lifeless: It would be nice if there was a Tree.is_executable(path) method.
<lifeless> garyvdm: you can of course, but its not fixed as an api and we're allowed to change it as desired
<lifeless> garyvdm: you could make one
<garyvdm> ok
<lifeless> note that it may be faster to call iter_changes() and use the tree.basis_tree() to get data
<lifeless> iter_changes is _the_ optimised code path for getting data from the tree
<garyvdm> lifeless: I'm making my control walk through a unversioned directory
<garyvdm> I don't know how to get iter_changes to do that.
<lifeless> oh, it won't
<lifeless> for that you'd need walkdirs
<lifeless> which is a component of iter_changes, and also highly optimised
<hsn_> http://pastebin.ca/1467426 - it seems that some windows related issues are still not fixed in 1.16. Last working version for me is 1.9
<lifeless> it has enough data to answer 'executable', at least on linux
<lifeless> hsn_: there is a guy working on the exception printing stuff
<lifeless> he was discussing it on the list yesterday
<aboSamoor> Hi, I am using launchpad with bzr and I had problem to understand the version numbers. For example, I have this version number 65.1.3 ? What does it mean ?
<lifeless> it means that that revision is the third revision on a branch made from rev 65
<aboSamoor> lifeless: I am using my laptop and desktop to commit changes to my branch, I get confused with merge and branches, what do you suggest the best practice/workflow to follow ?
<lifeless> what is confusing
<aboSamoor> lifeless: I am new to the idea of control version systems
<lifeless> simple workflow then is:
<lifeless> at site A) work work work, commit, push
<lifeless> at site B) 'bzr pull'. work work work, commit, push
<lifeless> as its just you, you can't be in two places at once, so you have no need to be merging.
<lifeless> going back to A), 'bzr pull', work work work, commit, push
<lifeless> rinse and repeat
<aboSamoor> at site B I usually do bzr update, what if I have local changes on B that they are not commited yet, do bzr pull overwrite them ?
<lifeless> pull won't overwrite
<lifeless> it merges in
<aboSamoor> lifeless: perfect :)
<lifeless> update won't do much unless you made your local workspace by doing 'bzr checkout'
<lifeless> if you did, then you should use update rather than pull, and not run 'push'
<aboSamoor> lifeless: usually I start my workspace by bzr branch
<lifeless> then my first answer was appropriat
<aboSamoor> lifeless: what is the difference between branch and checkout ?
<lifeless> branch mamkes a new branch, checkout only lets you edit an existing branch
<Nafallo> so. when will 1.16 be available in the PPAs? :-)
<Nafallo> even the nightly's seem to have 1.15 right now.
<mwhudson> Nafallo: 1.16 is in the ~bzr-beta-ppa
<mwhudson> apparently, the bzr ppa is waiting on a 1.16 compatible packaging of bzr-svn
<Nafallo> ah. so it isn't then...
<glyph> Hello... people
<glyph> what's the name for bzr users anyway
<glyph> bizarros?
<glyph> So, I've noticed a periodic problem as I've been introducing people to bzr and launchpad
<Nafallo> oh. never mind me.
<Nafallo> 9 hours ago... :-)
<glyph> inevitably, the first couple of checkins they do will end up having the wrong 'id', they'll forget to do 'bzr whoami' until it shows up on an lp page and doesn't link to their profile
<Nafallo> mwhudson: thanks
<glyph> non-bzr users tend to get it wrong for longer
<glyph> erm
<glyph> non-lp bzr users get it wrong for longer, I mean
<glyph> Is it reasonable to fix your user-ID in old revisions?
<glyph> if so, how do you do it?
<mwhudson> sadly no, not really
<lifeless> if they haven't been pushed, its reasonable
<lifeless> fast-export, uncommit, fast-import
<glyph> lifeless: yeah, but what if they have been pushed? :)
<lifeless> if they've been pushed then other people may already be depending on their revisions
<glyph> it would be really neat
<glyph> to have revisions which were updates to other revisions :)
<lifeless> you can do that
<glyph> so you could have very explicit "im in ur revision graph, fixin ur changelogs"
<lifeless> branch from the first rev
<lifeless> commit a no-text change new commit message
<lifeless> merge the second commit, and whenc ommitting do the same thing
<lifeless> etc
<glyph> lifeless: dang
<glyph> lifeless: If anybody has conflicts, isn't that going to be a terrifying mess to resolve?
<lifeless> no, why would it be?
 * glyph thinks
<glyph> I guess it wouldn't, at that.
<glyph> lifeless: how does one branch from a particular revision?
<lifeless> branch -r revspec
<glyph> oh, of course.
<glyph> if you can diff -r why wouldn't you be able to branch -r
<Adys> hi all. I need to include the bzr version in one of my pages in my project. All I can find is this extension: https://code.launchpad.net/~ian-clatworthy/bzr-keywords/trunk
<Adys> and its kinda out of date and undocumented. any better solution?
<ddaa> the latest branch format advertises support for content modification (that is, newline conversion and keyword substitution)
<ddaa> oops, he's gone
<RenatoSilva> Is there any shortcut for http transport?
<RenatoSilva> a shortcut for http://bazaar.launchpad.net I mean
<beuno> RenatoSilva, lp:...
<RenatoSilva> that's for bzr+ssh
<Peng_> It uses http if you're not logged in.
<Peng_> ...Why do you want http, anyway?
<RenatoSilva> but there's no bzr logout yet :)
<RenatoSilva> Peng_: for not having to open pageant
<RenatoSilva> Peng_: for branching, pulling etc
<RenatoSilva> Does Loggerhead have permalinks?
<RenatoSilva> sorry, this is for #launchpad
<lifeless> RenatoSilva: bzr+ssh is faster than http for branching and pulling
<Peng_> lifeless: Perhaps not if pageant is really slow.
#bzr 2009-06-21
<lifeless> Peng_: pageant has to kick in once; latency kicks in hundreds of times
<lifeless> Peng_: if the CPU is so slow that starting pageant and having it hand a key out once is slower than some hundred * latency, bzr will be having many other issues ;)
<RenatoSilva> maybe you want for any reason use http, a shortcut would be nice
<RenatoSilva> lph: or so
<RenatoSilva> or lpa: for ignoring -lp-login
<lifeless> RenatoSilva: the link you asked about in #launchpad is stable, its got the GUIDs embedded
<lifeless> RenatoSilva: if you want to point to the most recent version of a file, you can use head: or -1, for the revision component.
<RenatoSilva> http://bazaar.launchpad.net/%7Erenatosilva/%2Bjunk/moin.macro.childpages/download/renato_silva-20090620220448-vcluh5vueefsrn2i/childpages.py-20090620220344-3uvqg24v5ninpo1x-1/ChildPages.py
<RenatoSilva> where do I put head: ?
<Peng_> RenatoSilva: You'd replace the revid, renato_silva-20090620220448-vcluh5vueefsrn2i
<Peng_> RenatoSilva: Of course, in a future revision, that file could be deleted, so the URL isn't stable.
<Peng_> RenatoSilva: Or it could just be modified into something different.
<lifeless> Peng_: well, it would be stable, but not reliable :)
<lifeless> and only in the case that the file gets deleted
<RenatoSilva> It would be nice to have something simpler like http://bazaar.launchpad.net/~renatosilva/+junk/moin.macro.childpages/download/head:/ChildPages.py
<RenatoSilva> how do I cancel a bzr add?
<RenatoSilva> bzr remove is not working
<dash> bzr revert
<RenatoSilva> ok thanks
<lifeless> mtaylor: dropping by ?
<mtaylor> hey lifeless
<mtaylor> lifeless, dropping by what?
<lifeless> bzr ;P
<mtaylor> I'm _always_ in #bzr :)
<lifeless> :>
<mtaylor> something is unhappy with my laptop
<mtaylor> I shut it down and started it again and now nothing seems to be able to find any of my settings
<lifeless> ouch
<mtaylor> even though the files are in the home dir
<mtaylor> like, .mozilla-thunderbird contains an intact profile, but thunderbird can't find it - xchat didn't remember that I want : for nick completion instead of ,
<lifeless> check $HOME?
<mtaylor> yup: /home/mtaylor
<mtaylor> I'm going to blame xfs
<mtaylor> I'm pretty sure stewart is wrong about it being any good
<mtaylor> this is really going to wind up pissing me off
<lifeless> reboot again? :<
<mtaylor> already did
<lifeless> ah
<lifeless> so, its not temporary buffer issues
<lifeless> what about perms? xacls?
<mtaylor> lifeless: I don't even know how those work
<mtaylor> well, I know how perms work
<RenatoSilva> thanks everybody
<lifeless> I'd find the smallest app that fails; and strace it
<mtaylor> well... I'm going to say that the thunderbird problem is that my pref.js file is truncated
<lifeless> ah yes
<lifeless> thats the 'posix compliant but useless' behaviour we expect from fast file systems.
<lifeless> [you've seen the ext4 threads/bugs about this right?]
<mtaylor> lifeless: no. ... but I'm running xfs
<mtaylor> is this what I get for listening to stew? a fast but useless filesystem?
<lifeless> on a laptop, fast and dangerous
 * mtaylor throws something in the direction of melbourne
<mtaylor> no kidding
<lifeless> so here's the basic problem
<lifeless> writes are slow
<mtaylor> yup
<lifeless> apps routinely *don't* fsync or fdsync because it makes ext3 machines die
<mtaylor> bleh
<lifeless> so, when you do the following: write, close, rename
<lifeless> to atomically replace a file foo
<lifeless> its possible for the directory link for foo to be flushed to disk without the data for foo
<mtaylor> so - when I go to shutdown my system now and it sits there with a blinking cursor for forever, I'm guessing I should _not_ force power it off, because perhaps it's syncing data to disk?
<lifeless> yes
<mtaylor> ass
 * mtaylor is going to re-install without xfs
<lifeless> now to be 'correct' you can do
<lifeless> fdsync(tmpfile)
<lifeless> rename
<mtaylor> but noone is doing that, are they?
<lifeless> sorry, fsync(tmpfile), rename, fsync(dirfd)
<lifeless> people that do it, like FF, make linux desktops incredibly slow
<lifeless> its appropriate for server environments do say 'force X to disk' but its not appropriate for most software
<lifeless> posix doesn't let you explicitly describe 'file A or file B' except in the roundabout way of the write+rename idiom
<lifeless> so when ext4 started routinely hosing peoples configs in the same way
<lifeless> there was a huge furor
<lifeless> ext4 has been fixed
<mtaylor> hrm.
<mtaylor> should I perhaps use ext4 instead of xfs?
<mtaylor> although - for that matter... why is my _prefs.js_ file _ever_ being written to except when I edit my config?
<lifeless> give you one guess
<mtaylor> I'd think that after editing a config file, doing a force X to disk would be acceptable
<mtaylor> and other times, for things like "last email opened" those could be stored in, oh, I don't know, a separate slightly more acceptably volatile file
<lifeless> sure
 * mtaylor punches firefox people in the throat
<lifeless> but really
<lifeless> the main thing is 'all of old, or all of new never just the existence of new'
<lifeless> if you need more performance than ext3, I hear ext4 has been shaping up very well
<lifeless> and like I say, this pattern is supported on it now
<lifeless> ted tso's rants about it not being required by posix aside.
<mtaylor> well... it's tough to say - it's a new laptop with better disks anyway
<mtaylor> but stewart just keeps carping about how superior xfs is to everything
<lifeless> http://mjg59.livejournal.com/108257.html
<lifeless> this is worth reading
<lifeless> stewart is right *for servers with battery backed up raid and hardware with no driver quirks and none of this 'suspend' bullshit
<mtaylor> mmm
<mtaylor> I don't have that on my laptop
<mtaylor> actualy - with the new video card, suspend works nicely, thank
<mtaylor> thanks
<mtaylor> on the other hand - I can't seem to get 1600x1050 working, and now there is actually nothing in xorg.conf anymore
<mtaylor> so I can't actually fix it
<lifeless> is it ubuntu?
<mtaylor> when did we stop having useful config files?
<mtaylor> yes
<lifeless> several releases ago
<mtaylor> sigh
<lifeless> dpkg-reconfigure xorg-xserver IIRC
<mtaylor> yup. doesn't do squat
<mtaylor> hrm. that time I got it to add Option		"UseFBDev"		"true"
<mtaylor> lets see if that helps...
<mtaylor> lifeless: nope
<mtaylor> ctrl-alt-backspace seems to not work anymore too, and neither does ctrl-alt-+ or ctrl-alt--
<lifeless> cab is disabled by default in recent ubuntu's
<lifeless> + and - depend on the virtual size + modes
<lifeless> if they are the same, nothing will happen
<mtaylor> m. fair enough
<lifeless> what driver are you using?
<mtaylor> so, where are the available screen resolutions actually configured these days
<mtaylor> intel?
<lifeless> xrandr
<lifeless> you can persist them in Xorg.conf
<mtaylor> ah
<mtaylor> well, it tells me: Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
<lifeless> but its all geared around dynamic changes
<johnf> LarstiQ: you about?
<lifeless> poolie: btw I have a slug membership card for you for this year
<lifeless> rockstar: mwhudson: http://werkzeug.pocoo.org/
<mwhudson> lifeless: anything in particular?
<lifeless> ran into thelink
<lifeless> seemed relevant to loggerhead
<mwhudson> the only part of paste i'd like to replace is the server, perhaps, and werkzeug doesn't have anything special in that department
<lifeless> debugging aspects
<mwhudson> (we should look at spawning)
<lifeless> if you already know of it, cool
<mwhudson> yup
<mwhudson> thanks though
<nekohayo> hey there, I can't seem to get bazaar to acknowledge that I manually resolve my conflicts
<nekohayo> "0 conflict(s) auto-resolved."
<nekohayo> what to do at times like this?
<nekohayo> oh, seems like doing a bzr resolve the-file instead of just bzr resolve ... solved the problem
<Septi> hi
<Septi> how can i get a diff from revision 8 to revision 9?
<lifeless> diff -c 9, or diff -r 8..9
<bialix> bzr diff -r8..9
<Septi> lifeless, bialix, thanks
<bialix> igc: hi
<igc> hi bialix
<RenatoSilva> Can I create a "pointer" project? A project which only makes reference to the original one?
<garyvdm> Hi igc
<igc> hi garyvdm
<pygi> nooo, garyvdm is back :p
 * pygi hides
<garyvdm> Hi pygi
<pisecx> Hi, is there any good user-friendly UI for ubuntu?
<pygi> pisecx: Olive?
<pygi> its included in bzr-gtk package
<pisecx> installed, but can not start it
<pisecx> ops. started now..
<_gpg_> hello
<_gpg_> we were using cmsynergy and switched few months a go to subversion. Actually i"m very interested by bazaar
<_gpg_>  The "Decentralized with automatic gatekeeper" is what i need with my team actually, i cant find any documentation about how to use/set PQM
<magcius> Is there a way to get a diff between two different branches?
<kizzo> "bzr rebase ../opencog" errors with NoSuchRevision: KnitPackRepository('file:///home/kizzo/python-bindings/.bzr/repository/') has no revision ('kizzo@crashtest-20090619010527-8dhvulrdodnszrtj',)
<kizzo> If anyone would want to try, they can do "bzr branch  lp:opencog; bzr branch lp:~kizzobot/opencog/python-bindings; cd python-bindings; bzr rebase ../opencog".
<theAdib> hello folks. I want to push my bzr repo to my web domain using the ftp account. Buz bzr fails. I do not understand where is the error.
<theAdib> here is the error message : http://pastebin.com/m11ce7fe4
<theAdib> I use bzr on my Ubuntu 8.10.
<bialix> try bzr --no-plugins push aftp://web613f1@theadib.net/TDD/trunk
<bialix> if it works file a bug against bzr-svn
<theAdib> bialix: thx for the hint. Now I come closer. Still some errors:
<theAdib> FTP temporary error: 451 /TDD/trunk/.bzr/repository/upload/nax1mcnkw7hpb8bffyso.fetch: Append/Restart not permitted, try again. Retrying.
<theAdib> bzr: ERROR: Transport error: Error setting up connection: 530 Sorry, we dont allow more than 3 connections per host! 530 Sorry, we dont allow more than 3 connections per host!
<theAdib> I tried using aftp// and ftp//
<bialix> it seems like your ftp server can't append
<bialix> I'm not sure if can workaround this
<kizzo> Here is the error I am getting: http://pastebin.com/d4bddf102
<bialix> try to pull lp:opencog first
<RenatoSilva> it would be nice to bzr push lp:project/*
<RenatoSilva> * pull
<RenatoSilva> grrr, * branch
<lifeless> RenatoSilva: at a project level you need to make a series to do that
<lifeless> RenatoSilva: lp:project/series works. as does lp:~user/project/branch
<RenatoSilva> I tried lp: ~renatosilva/* but doesn't work
<lifeless> oh
<lifeless> no, you can't wildcard
<RenatoSilva> maybe in the future :)
<lifeless> pull pulls from a single branch
<lifeless> I'm not sure what it would /mean/ to tell it to pull many branches
<lifeless> what do you have in mind?
<RenatoSilva> actually I just thought about bzr branch
<RenatoSilva> bzr branch lp:/~user/project/* for example would fetch all branches under ~user/project
<lifeless> well, we have a planned review of the way bzr presents branches and repos that may make it easier to do things like that
<lifeless> not sure that it would end up being spelt identically ;P
<meoblast001> hi
<meoblast001> if i have a diff, how do i apply it?
<meoblast001> have some uncommited code on my laptop
<lifeless> is it a plain old diff, or a bundle?
<meoblast001> wanted to move it over to my desktop
<meoblast001> just a plain diff
<lifeless> patch -p0 < diff
<meoblast001> ok... thanks
<lifeless> myself, I'd usually commit and push it
<lifeless> then uncommit on the far end
<meoblast001> i didn't finish the feature though
<lifeless> doing this can handle more situations than plain old diffs
<lifeless> its ok that its not finished - see where I say 'and uncommit on the far end'
<meoblast001> lifeless: this way should be easiest as it's just a few changes in a few files
<RenatoSilva> lifeless: you mean bzr patch -p0 < diff?
<lifeless> RenatoSilva: no
<RenatoSilva> ok
<lifeless> RenatoSilva: you can do that too, but its generally not needed, and for this case, thigns that plain patch won't handle would still be handled wrong by bzr patch - e.g. file adds would show up as parallel imports
<lifeless> meoblast001: a small note if I may - you don't need to finish features to do commits in bzr; because you can have your own branch, you can make as many commits as you want while developing the feature.
<meoblast001> yeah i know
<meoblast001> just harder to make my own branch
<meoblast001> than to pastebin a diff and patch it
<glyph> meoblast001: not really
<glyph> you could pastebin the output of 'bzr send'
<glyph> presumably if you can get the output of 'bzr diff', you already have a branch, it already has changes in it ;)
<glyph> actually
<lifeless> glyph: he may be working in a checkout
<glyph> lifeless: still
<lifeless> glyph: or there may be other factors
<glyph> oh I didn't even see the earlier scrollback
<glyph> meoblast001: one of the reasons I love bzr is exactly that case
<glyph> moving code from my laptop to my desktop
<glyph> I do it by doing 'bzr push bzr+ssh://my-desktop/home/me/mybranch'
<Sheepherd> hi all... just trying to get the GUI working but i dont know where to "After this, you can start the GUI by typing olive-gtk" :/
<RenatoSilva> Sheepherd: OS?
<Sheepherd> win xp 32bit
<Sheepherd> sp 3
<RenatoSilva> Sheepherd: start > run
<Sheepherd> thats all?
<meoblast001> ssh was the easiest way by far
<RenatoSilva> Sheepherd: I'm not sure what's olive-gtk tough, but that's how I'd read the message. I just tried and didn't work here :P
<RenatoSilva> Sheepherd: what are you doing, installing bazaar?
<Sheepherd> RenatoSilva: followed every step here correctly: http://bazaar-vcs.org/WindowsInstall
<Sheepherd> RenatoSilva: yea exactly
<Sheepherd> RenatoSilva: olive-gtk comes from the 2nd last line of the site
<RenatoSilva> Sheepherd: oh I had a bit of trouble setting up bzr on my win xp to.
<RenatoSilva> Sheepherd: just forget all of this, undo everything.
<RenatoSilva> Sheepherd: then use http://edge.launchpad.net/bzr/1.16/1.16/+download/bzr-setup-1.16-1.exe
<Sheepherd> RenatoSilva: :/
<RenatoSilva> Sheepherd: next, nextm finish, and you're [almost] done
<RenatoSilva> Sheepherd: this installer has an embedded python
<Sheepherd> ya thats why i didnt use it
<Sheepherd> cuz i already have python
<RenatoSilva> well, I have python too, but I had some trouble setting it up separately
<Sheepherd> RenatoSilva: hope this proceeds smoothly now ...
<RenatoSilva> I read that page too, which is confusing imho, but I'm fine now after just installing the all-in-one
<RenatoSilva> Sheepherd: what would you like bazaar for? launchpad by any chance?
<Sheepherd> RenatoSilva: first time hearing about that. but someone from #python recommened some svcs or how those tools are called to get a good overview over changes made to my app
<RenatoSilva> Sheepherd: never heard of vcs or dvcs?
<Sheepherd> RenatoSilva: ok installed the whole thing... how do i access the gui now?
<Sheepherd> RenatoSilva: yea dvcs... thats what i meant :) and i never heard about that until like 30mins
<RenatoSilva> did you get the idea of dvcs?
<Sheepherd> RenatoSilva: something to trace down changes made to a file?
<RenatoSilva> Sheepherd: useful links...
<RenatoSilva> http://en.wikipedia.org/wiki/Revision_control
<RenatoSilva> http://en.wikipedia.org/wiki/Distributed_revision_control
<RenatoSilva> http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf
<RenatoSilva> When you're done with the overview of vcs and dvcs, you can read the 5 minutes tutorial for Bazaar: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<RenatoSilva> and to learn more, the user guide: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
<mwhudson> jelmer: does bzr-git 0.4.0 require a new dulwich?
<Sheepherd> RenatoSilva: thx :) and where should all those lead me to?
<Sheepherd> RenatoSilva: was bazaar the wrong choice for me?
<lifeless> Sheepherd: bazaar is a fine choice for you; but you've just started to learn a new tool. VCS tools are not about inspecting your current code, they are about controlling it [and reporting] over time
<Sheepherd> lifeless: k... hope ill get used to this new system soon
<RenatoSilva> Sheepherd: have you even used any vcs tool before?
<Sheepherd> RenatoSilva: nope, today is even the first day i heard about that
<Sheepherd> first time*
<Sheepherd> RenatoSilva: why are u asking?
<lifeless> Sheepherd: it helps us understand the things you already know, so we don't tell you too little or too much
<RenatoSilva> Sheepherd: humm, try having some time to read the links, in the order I mentioned. I think this can avoid many trouble
<Sheepherd> k thx both of you :)
<Sheepherd> gonna read them carefully tomorrow
<RenatoSilva> :)
<Sheepherd> should be sleeping already xD
<Sheepherd> im off then... thx again and cya tomorrow maybe
<RenatoSilva> bye
#bzr 2010-06-21
<lifeless> spiv: ping
<lifeless> spiv: do we still exit-hard from bzr? and if we do, does that run finally blocks.
<spiv> lifeless: we do
<spiv> lifeless: but we do it at the top level, i.e. in the 'bzr' script
<spiv> lifeless: so there won't be any finally blocks on the call stack, because the call stack will only have one frame on it :)
<spiv> (There may be finally blocks in generators that haven't run, but those would be unlikely to be run as a result of final garbage collection anyway)
<lifeless> ok cool
<lifeless> I wants a review from you
<lifeless> (waiting for LP API's)
<lifeless> and bzr
<lifeless> \o/
<lifeless> oh darn. forgot to merge trunk
<lifeless> I'll do that after, it will be just NEWS to move stuff to the right section
<lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/fix-terminal-spew/+merge/28024
<spiv> Will take a look, thanks.
<lifeless> thank you
<lifeless> I guess for correctness, now I've seen that, I really should grab sys.info etc
<lifeless> and pass it down
<lifeless> it wasn't obvious that that should be done in Aaron's patch, though the issue still existed
<lifeless> I'm inclined to not bother until we'd behave differently in an __exit__ call thought.
<lifeless> spiv: I'd like to land the cleanup stuff soonish :)
<spiv> lifeless: just finishing review :P
<spiv> lifeless: just sent
<lifeless> thanks
<lifeless> so
<lifeless> DebugMedium
<lifeless> I mean
<lifeless> _DebugCounter
<lifeless> spiv: turtles all the way down
<lifeless> context managers have all the same issues as cleanups :)
<lifeless> ohhh nice
<lifeless> I can use this to make the test log handling better.
<spiv> lifeless: tangentially: https://bugs.edge.launchpad.net/launchpad-code/+bug/596726
<ubot5> Launchpad bug 596726 in Launchpad Bazaar Integration "Poor support for merge proposals superseded by different branch (affected: 1, heat: 6)" [Undecided,New]
<lifeless> thanks
<lifeless> I was asking in lp-dev earlier about it
<spiv> lifeless: turtles all the way down, but some of those turtles are in shark-infested waters ;)
<spiv> I've been meaning to file a bug about that for a while, having a contemporary example to point at was just enough of a spur to make me to it :)
<lifeless> :)
<lifeless> so
<lifeless> you can read my mails
<lifeless> but top level
<lifeless>  - test log support is the same logic needed to make this object better
<lifeless>  - it looks like a cleanup stack to me
<lifeless> except for deprecation warnings, they are special.
<lifeless> I don't think you can reenable them, I mean.
<lifeless> but I don't want to increase scope more than needed
<spiv> Hmm, cleanup stack does fit nicely.
<spiv> It is a pretty large scope creep for this patch.
<lifeless> I think I'll do a minimal job now and more in a separate patch this avo
<spiv> My suspicion is that in practice the _DebugCounter's weakref callback will trigger early enough to make the atexit irrelevant
<lifeless> We should either fix it
<lifeless> or delete it
<lifeless> I'm happy to fix it
<spiv> But I'd want to do some interactive testing or something to be confident about that, rather than just cross our fingers :)
<spiv> IIRC, and I might not, the atexit was best-effort paranoia, but the goal was that it wouldn't be triggered.
<lifeless> we almost certainly lead ssh processes if the atexit triggers
<lifeless> leak
<spiv> If a bzrlib-wide cleanup stack existed then that would fit much better than atexit :)
<spiv> I guess you'd make BzrLibraryState an ObjectWithCleanups?
<lifeless> yes
<spiv> Cool.  I was a bit unsure about the value of this change initially, but I'm totally sold now :)
<spiv> Btw, you're right about the implicit None return, I think that would propagate the way we want.  It's nice that it defaults like that.
<spiv> I'd forgotten about that :)
<lifeless> I've added
<lifeless>         return False # propogate exceptions.
<lifeless> for clarity
<lifeless> and, I can start adding tests with just a little more work.
<lifeless> hmm I think I want to put this in a new module soon
<MTecknology> There is a 'bzr serve' command - is there some incredibly awesome bzr server daemon that might make life for my code server management easier?
<lifeless> spiv: actually no; I'll decorate.
<lifeless> spiv: because circular imports.
<spiv> lifeless: whee
<ferringb> random query; say I've got an integration branch, w/ tags for specific releases.  say said branch has moved on from 0.1, but I need to cut a 0.1.1
<MTecknology> Is 'bzr serve' for a server with a single user that holds all the branches and access is granted to anyone?
<ferringb> I build the changes up, and the new tag in a branch off of 0.1.  what exactly is the resultant graph if I try to merge it back?  will the tag that gets pulled in actually include the >0.1 changes w/in that branch, or properly be just hte 0.1->0.1.1 branch to the side that occured?
<spiv> 'bzr serve' doesn't (yet) do any sort of access control.
<spiv> It leaves that to the OS.
<lifeless> ferringb: I don't quite understand the question
<spiv> (well, it restricts access to files inside the directory given to --directory, but aside from that)
<MTecknology> spiv: I'll be extremely excited when it can - that's coming... next week?
<spiv> MTecknology: ha, if only :)
<ferringb> lifeless: possibly because I'm just confusing myself ;)
<MTecknology> spiv: thanks
<spiv> MTecknology: not coming soon, sadly
<lifeless> MTecknology: its not on the roadmap at all
<lifeless> MTecknology: we'd accept a tasteful patch, I'm sure :) - why do you need it?
<ferringb> lifeless: ok.  got a branch releases are cut from- specifically releases from tag's, right?  said branch is already well past 0.1... I need to cut a 0.1.1, aka just minor bugfixes... so I build out a 0.1.1 branch, including the tag.
<spiv> We may tackle it as part of the 3.0 UI revamp, but even there it's not a great priority.
<ferringb> lifeless: when I merge it back to the central branch, the 0.1.1 tag will point at just the changeset for 0.1.1?  or will it be those changes for 0.1.1 including the other crap in the main branch?
 * ferringb figures it'll behave, but is just checking
<lifeless> spiv: http://pastebin.com/8cC31j76
<lifeless> ferringb: perhaps if you sketched this in bzr commands I'd understand :)
<lifeless> like
<MTecknology> lifeless: right now I have different user accounts for each team - It's getting kind of messy - not that managing it is hard - I made a plugin to make it easier too
<spiv> MTecknology: as lifeless says, we'd welcome a patch for it, we certainly aren't opposed to the concept, but it isn't work we're planning to do ourselves any time soon.
<lifeless> bzr branch -r 0.1 trunk 0.1
<lifeless> cd 0.1
<lifeless> do stuff
<lifeless> bzr commit -m '0.1.1
<lifeless> bzr tag 0.1.1
<lifeless> cd ../trunk
<lifeless> bzr merge ../0.1.1
<lifeless> bzr commit -m 'merge 0.1.1 into trunk'
<lifeless> ferringb: ^ is that what you mean ?
<MTecknology> spiv: I think I'm committed to a little too much to learn python right now - but I can put this on the list for when i do learn it
<ferringb> lifeless: integration ==> more like 0.2, ok?  bzr branch integration -r tag:0.1 mine-0.1.1; cd mine-0.1.1; set of bzr merges/commits; bzr tag 0.1.1;cd ../integration;bzr merge ../mine-0.1.1
<lifeless> sure
<lifeless> ok so bzr log -r tag:0.1.1
<lifeless> in integration
<ferringb> lifeless: so with that setup, having done that, if I go an do bzr branch integration -r tag:0.1.1 ; it will come through as just that side branches changes, correct?
<lifeless> yes
<lifeless> the tag won't change the revision it points at when it gets copied by a merge
<lifeless> you need to explicitly run 'tag' again to change the revision a tag points at.
<ferringb> yep
<ferringb> just verifying.  mostly it's the fact that it's kind of retroactively inserting a dead branch into the target's history is all
<spiv> lifeless: +1, although separately we should consider what to do about e.g. SFTPLock.__del__ and other __del__ methods, that in principle could trigger any time.
<ferringb> bad phrasing, but that's where I was curious if bzr would behave properly- haven't tried this yet with it.
<lifeless> spiv: I'm adding some docs
<spiv> lifeless: and SFTPLock.__del__ at elast expects trace.warning to work
<lifeless> ferringb: no worries; I wanted to be sure I answered the right question:)
 * ferringb wonders why you're not using a weakref finalizer there
<lifeless> ferringb: we call os._exit()
<spiv> ferringb: yes, that would be better, although for the specific issue at hand it won't help
<lifeless> ferringb: to avoid the very slow gc of (potentially) a GB or more of memory
<ferringb> figured, more I spotted the __del__
<lifeless> oh right
<ferringb> http://www.pkgcore.org/trac/pkgcore/browser/snakeoil/snakeoil/weakrefs.py <-- might be of interest; specifically the metaclass
<lifeless> we are largely deleting the __del)) methods
<ferringb> been experimenting with it lately... basically is the full power of __del__ w/out any of the issues, although it doesn't play perfectly w/ any isinstance checks people use due to it slipping a proxy in
<spiv> lifeless: for that specific flavour of "warn if __del__ happens on unclean object", I think a "warn_if_bzrlib_still_initialized" method would be an ok solution
<ferringb> the code there is a bit rough also, mainly since I'm still playing with it to verify there isn't some insane corner case that causes me holy hell
<spiv> it's not critical if that warning happens in the window between "tear down bzrlib" and "stop the VM"
<ferringb> lifeless: re: moving away from __del__... same, there just have been several cases where I really needed something like that, and it was way too much of a mess to write a weakref finalizer for each instance.  hence coming up w/ the full proxy/metaclass trick instead.
<lifeless> spiv: well, it could hold onto the library state
<ferringb> re: that metaclass trick, I'd be curious also if either of you see a flaw with it.  there are some variants (most of which require you to specify exactly what the finalizer will access), thus implementing another (doesn't need specifying what is needed for finalizing).
<spiv> ferringb: Sorry, that code is a bit too gnarly for me to consider properly right at the moment
<spiv> ferringb: it does sound like an interesting idea... although at the extreme if a __del__ method could be mechanically turned into a weakref callback without any downsides I'd hope that Python would do that automatically ;)
<ferringb> it can't fully transparently, technically
<ferringb> roughly... snakeoil has a rather extreme proxy implementation.  it lies it's ass off completely- matches special methods, methods, etc.  you can spot that the proxy is in use, but it's only in a couple of cpython level cases.
<ferringb> thats part of the key trick here.
<spiv> Right.  There are edge-cases like how __del__ can resurrect the object.
 * ferringb notes proxy isn't even getting to that
<ferringb> the trick here is that people are using the proxy itself
<ferringb> when the proxy falls out of memory, the weakref gets fired, which finalizes the proxy target
<ferringb> said finalization punts the strong refs holding it in memory in the process
<ferringb> you could do a resurrect I suspect in this case, but it would be hard to actually pull it off by it's nature.  when the weakref fires, the bugger is pretty well dead in every scenario I can come up with
<ferringb> spiv: reason for the special method proxying namely comes down to that the vm would behave differently w/ the proxy... consider if the proxy target has an __iadd__ or something.  no special method on the proxy (which the vm decides on it's own), it takes a different route
<ferringb> hence this particular proxy scanning the target class and making a class w/ all of the necessary special methods in place
<spiv> That's what I mean: there's a fundamental difference in capability there between __del__ and a weakref callback, so there's a limit to what you can do to automatically replace one with the other.
<ferringb> resurrection is about the only thing I can think of that is missing.
<ferringb> literally.  because all that's tracked is the proxy falling away (which has zero data), when it goes out of memory it just turns around and tells the real object "hey asswipe, pretend like a __del__ just got ran on ya" (specifically real_object.__finalizer__(), which is whatever __del__ method was defined... moved to said name to avoid the known gc issues w/ __del__)
<ferringb> rephrasing... resurrection of the proxy itself.  the real instance (the target) still is strong ref'ed at that point.
<ferringb> spiv: roughly that answer your concern?
<lifeless> spiv: incremental eyeball please; I think this is sufficient to land. rev 5231
<spiv> ferringb: possibly!  It's a bit much to digest when I'm about to go get lunch :)
<spiv> lifeless: ok
<ferringb> spiv: well, if it's of interest feel free to poke me/yell.  may not be in here, but am looking to get a second set of high level eyes on that one
<lifeless> spiv: ok, its up now
<lifeless> spiv: I thought it had gone, but wifi glitched it
 * ferringb notes he needs to clean up the implementation and flesh out tests in fully also, but so far it's behaving exactly as expected
<spiv> "We hope you enjoy this library." Aw :)
<lifeless> spiv: :)
<spiv> lifeless: typo: "my looking it up" should be "by ..." in __init__.py
<lifeless> thanks
<lifeless> 12 lines of comment => global variables suck
<spiv> lifeless: typo: "needs to be alled" should be "... called", same file
<lifeless> bah
<lifeless> the table here is too high
<spiv> lifeless: why the switch to making the caller of initialize have to call __enter__ manually?
<lifeless> spiv: I wrote some docs that looked odd
<lifeless> spiv: so I changed them to be nice and then altered the code to match
<lifeless> bzrlib.initialize is nicer if you can say
<lifeless> with bzrlib.initialize() as bzrstate:
<spiv> *nod*
<lifeless> rather than having to lookup the actual class in use to use the with statement
<lifeless> as we're changing the contract anyway
<spiv> I thought that might be it.  Seems reasonable, but I wanted to make sure I understood.
<lifeless> (to must call __exit__ or your log statements are not guaranteed)
<lifeless> I figured adding in  'please call __enter__' wasn't much worse.
<lifeless> which reminds me
<lifeless> we didn't make that explicit in NEWS
<spiv> lifeless: aside from those two typos in comments, all good.  Merge at will!
<spiv> Oh yeah, feel free to highlight this more in NEWS too :)
<lifeless> gimme 2 secs
<lifeless> I'll pastebin and you can shoo to eat
<lifeless> http://pastebin.com/2tXXy0v9
<lifeless> thats the full NEWS diff now
<lifeless> spiv: ^
<lifeless> I'll assume you're off eating and land witha promise to tweak later if needed, in 5 or so
<spiv> lifeless: +1
<lifeless> thanks!
<lifeless> parthm: hi
<parthm> lifeless: hi
<lifeless> parthm: do you want to talk about the regex compilation stuff
<parthm> lifeless: my personal preference is towards an error based approach.
<lifeless> great
<parthm> lifeless: i am ok with warnings for operations like 'st' but specifically 'add' is something i would really prefer to error out.
<parthm> it sort of reminds me of bug #549310
<ubot5> Launchpad bug 549310 in Bazaar "bzr should not try to guess username but require setting it with whoami (affected: 1, heat: 6)" [Wishlist,Fix released] https://launchpad.net/bugs/549310
<lifeless> yes
<lifeless> I think we should just error across the board, because if the file is damaged, nothing is going to be behaving sensibly anyway
<lifeless> I've seen error modes in other programs that spew a bunch of junk
<lifeless> and then say 'oh, XXX is wrong'
<lifeless> and users just get flummoxed at the sheer volume of info attacking them
<parthm> lifeless: i agree. i was just typing out my opinion on the mp. hopefully we can have some discussion there and come to an agreement.
<parthm> i think it may be best to keep the discussion on the mp (rather than the mailing list) as its one of those bikeshed topics :)
<lifeless> well
<lifeless> I think it can go either way
<lifeless> I can give you a detailed review
<parthm> lifeless: do you prefer the mailing list?
<lifeless> but it seems to me that we can use much clearer code if we do errors; and its much more visually clear to the user as well
<lifeless> parthm: MP is fine.
<lifeless> I'm going to take a break and organise dinner ingredients and so forth
<lifeless> I'll pop in in a bit to discuss where we go in detail
<parthm> lifeless: sure. i will update the mp with my comment. i think you and i are in agreement. maybe with some more discussion with jam, poolie and vila we can all agree on one thing :)
<lifeless> its been stalled for a bit
<lifeless> I'm patch pilot this week
<lifeless> so I want to
<lifeless>  - unblock it
<lifeless>  - land something that is clearly better than what we have
<lifeless> what we have is backtraces
<lifeless> changing that to a single line or so error will be a clear improvement
<lifeless> it doesn't preclude a warning based approach in future
<lifeless> but neither is it contingent on us deciding that we don't want a warning based approach.
<lifeless> that is to say, we don't actually need agreement here, because it can be changed in the future and we're not making it much different to the status quo
<lifeless> uhm by agreement I mean 'capital A Agreement' if that makes sense
<lifeless> we do need agreement that its an improvement over the status quo, but I think that that is triival
<parthm> lifeless: yes. both (warning or error) are an improvement over the current situation. i can cleanup the error based patch and put it up for review.
<parthm> lifeless: i have put up my thoughts on the mp. https://code.edge.launchpad.net/~parthm/bzr/300062-invalid-pattern-warnings/+merge/26809
<chx> how can i specify the last revision of a branch? HEAD, tip , call it whatever bzr help revisionspec talks about a lot of stuff but i can't find this.
<Bambi_BOFH> hi all. is this traceback something that would be worth reporting as a bug? http://paste.ubuntu.com/452801/ (i included the yum install, so you can see where the packages are from)
<Bambi_BOFH> bzr has printed an actual error, but then backtraced anyway
<spiv> chx: -1
<chx> -1 ???
<chx> that's like 1 revision before HEAD, no?
<Bambi_BOFH> (i suspect its died because its on nfs, but thats by the by)
<spiv> chx: it's HEAD
<spiv> chx: e.g. compare 'bzr log --line -r -1' with 'bzr log --line | head -1'
<spiv> chx: FWIW, 'bzr help revisionspec' tries to say so explicitly in the 'revno:' section
<spiv> Bambi_BOFH: yes, except that I happen to know this bug is fixed in 2.1.2 :)
<spiv> Bambi_BOFH: but any time bzr gives a traceback is a bug
<spiv> Bambi_BOFH: (sometimes it's a bug in a plugin rather than bzr itself, but still a bug, and if you're unsure bzr devs are happy to reassign the bug report to the appropriate plugin for you)
<Bambi_BOFH> spiv: fab! fixed before i found it, the way i like bugs. i'll branch onto local disk until the package is updated. thanks very much :)
<spiv> Bambi_BOFH: you're welcome :)
<Bambi_BOFH> :)
<chx> spiv: hrm, my brain is too convoluted for 'last'
<Bambi_BOFH> sorry about ask-and-run, but back to work ;) *waves*
<vila> hi all !
<lifeless> hiya
<vila> sheesh, get away you
<lifeless> ?
<vila> xchat spurious launch
<vila> lifeless: the test suite run on windows in 1h10 now, onlya couple of failures left,  not related to the leaks (but masked by them previously)
<lifeless> cool
<spiv> Woo!
<vila> I no longer fail a test that encounter a hung thread (since there are few enough now to let the test suite complete), but I'd like some way to collect the info and report about them
<lifeless> addDetails
<lifeless> on the test
<vila> yeah, you mentioned that, how will they be displayed ?
<lifeless> and in the result look for a specific name || mime type
<lifeless> aggregate the info that matches, print in stopTestRun
<lifeless> I love it when API's come together
<lifeless> vila: it will look however you want it to
<vila> and is there some way to collect them to display a nice total in the end..ohh, I need to look at that then
<vila> but can these summaries be carried by subunit too ?
<vila> and any idea about making them apparent in hudson ? (And are there different steps/features needed ?)
<vila> and where is lp-loom-propose so I can run a single command and have multiple mp with their pre-requisite branch set ? :-P
<lifeless> addDetails will be carried by subunit
<lifeless> hudson - defer that, possibly depends on how much effort we're willing to put in :)
<lifeless> for looms I think one large MP may make more sense most of the time
<lifeless> but certainly you should file a bug on bzr-loom now, saying that it doesn't do what you need with lp-propose - set a task on bzr too saying that lp-propose needs appropriate extension points for loom
<vila> cough, the whole diff is now ~6000 lines, nobody will review that this century :-)
<vila> there are some heavy cleanups there (heavy in lines, not intent, aka trivial)
<lifeless> vila: 'most of the time'
<vila> yeah, kidding ;)
<lifeless> vila: I don't mean one diff btw
<vila> I know, that's what I do generally
<lifeless> vila: N diffs, one merge proposal.
<vila> oooohhhh
<vila> lifeless: but without your annotated review into place...
<lifeless> what do you think ?
<spiv> lifeless: N diffs, one merge proposal is an interesting idea.
<vila> N diffs will be nice, but some diffs overlap
<spiv> lifeless: I suspect that for sufficiently large work you might end up with more than 1 conversation, though
<spiv> lifeless: although it's hard to know without the experience of trying it :)
<lifeless> I'm sure you will
<vila> yup, I *expect* multiple discussions on the leaking-tests loom
<lifeless> right now there is no room for experimenting
<spiv> At the same time, N unlinked conversations is unlikely to be a good match either.
<lifeless> so we need to write some code ;)
<spiv> It's interesting, actually.
<vila> lifeless: regarding the up-thread commits in a loom, you said: don't commit until a conflict occurs (or something close enough) right ?
<lifeless> near enough yes
<lifeless> though this week I'm PP, not expecting to do much loom loving
<vila> lifeless: does that mean you do merges with non-conflicted threads as additional parents ?
<vila> lifeless: just talking :)
<lifeless> vila: uhh
<lifeless> I don't know, does it ?
<vila> lifeless: not today, but how do you leave a clean committed tree to work with ?
<spiv> I bet for many things I do that I can a) think of a nice split into N related diffs for review to make the pieces digestible for reviewrs, and b) that I could also guess which parts would tend to generate the most discussion.  And I bet the boundaries of a) and b) don't exactly line up.
<vila> spiv: split more :)
<lifeless> vila: you don't
<vila> lifeless: you mean you leave the tree uncommitted ?
<lifeless> vila: needs to subtract merged-and-not-committed from status/diff and commit
<spiv> vila: at some point splitting harms reviewability because you lose the sense of how the piece tie together
<vila> spiv: that's why I want a graph rather than a list of threads
<lifeless> vila: alternatively, phrased, the tree basis need not match any thread tip, we'd get a commit, then rebase the commit to the thread they committed to.
<lifeless> vila: or something.
<spiv> vila: partly that might be solved by a nice way for a reviewer to flip between viewing a piece by itself and viewing it in the integrated whole, or possibly steps in between
<lifeless> vila: I expect to find many bugs and limitations doing this
<vila> spiv: certainly
<spiv> vila: I want a graph of threads too, but I think that's tangential
<lifeless> spiv: I really don't like the UI that I expect that to generate.
<vila> lifeless: I'm pretty sure there should be a solution that doesn't involve rebase
<lifeless> vila: rebase isn't intrinsically wrong
<spiv> vila: e.g. sometimes you refactor something in a very low level of the patch stack/graph driven by a need near the top of the stack
<lifeless> avoiding it because its rebase is a mistake
<spiv> vila: the discussion of "I think this bit should be done differently" really wants to have as context all of that (but still somehow with as little of the rest of the patch stack/graph as possible, to minimise noise)
<spiv> lifeless: I fear the UI too, but the model is just too irresitably nice I think.
<vila> I'm not against rebase, but I think it's an incomplete concept. Good enough to use in many cases but being able to filter the ancestry in various parts of the UI should provide the best of both worlds
<lifeless> vila: filtering non-intentional ancestry is a hack, I think
<vila> well, the UI should be s/up-thread/go-thread/
<spiv> lifeless: My intuition is that a good UI is tractable, partly because the graphs people want aren't going to be *that* complex.
<lifeless> vila: the reason looms are so noisy is because I once held the view that filtering non-intentional changes wsa sufficient
<vila> my intuition there is that the loom history should be displayed nicely in qlog (whether it can do that today is not part of this discussion :)
<spiv> lifeless: It might be interesting to try a limited graph: where you can at have N threads in parallel, but they must all join together again at the next level.
<lifeless> sounds more like a desire than intuition :)
<lifeless> spiv: loom supports that today
<spiv> lifeless: technically, yes
<lifeless> spiv: albeit manually.
<spiv> lifeless: the UI doesn't make it very usable
<vila> lifeless: how so ?
<lifeless> vila: intuition is a guess
<spiv> lifeless: but I think that's easily 90% of the cases people (well, me at least :) want more-than-a-linear-stack for :)
<vila> yes, a guess waiting for concrete steps to become real :)
<lifeless> spiv: I still haven't heard a case that is uniquely solved by graph that my less-merges stack isn't entirely suitable for
<lifeless> vila: still, if you replace 'intuition' in your sentence about qlog, with guess, it doesn't parse.
<vila> spiv, lifeless: Indeed the leaking-tests have threads to prepare a feature and parallel threads that uses this feature in different areas, each of them worth reviewing independently
<lifeless> spiv: and I'm sure that the UI for a stack is so much nicer than a graph :)
<lifeless> spiv: if there was a compelling 'I need a graph' argument, I'd be in like a flash
<vila> s/should/could/,, I meant, each thread should be a vertical line and the whole graph shows when each thread have been taken into account in upper threads
<lifeless> spiv: there's only one graph based patch manager out there that I know of - topgit - and I hear interesting things about its usability.
<vila> a stack is fine as long as each node can be a loom too :)
<spiv> lifeless: can you point me to the less-merges stack parts?
<lifeless> spiv: no code yet
<lifeless> spiv: only the discussions at UDS + various back of head thoughts
<lifeless> spiv: I've been mulling on this a while, but not written it up.
<lifeless> I should
<spiv> lifeless: part of what I'm after UI-wise is to make it hard to accidentally mix threads that I as a user consider parallel, and to have that situation shown nicely in show-loom etc
<spiv> lifeless: please do :)
<lifeless> spiv: look back a few days in this channel
<lifeless> I laid out the technical bits to vila
<lifeless> 'vila.*lifeless.*loom' should be a good search
<lifeless> spiv: the basic idea is to only record a merge during up-thread when a conflict occurs, and then only with the causative branch.
<lifeless> spiv: to give someone the full set of merged branches together when they're working in the working tree, using some sleight of hand - e.g. a hidden temporary commit.
<spiv> lifeless: that would be a nice incremental improvement
<lifeless> the two things are tied together
<spiv> lifeless: but I don't think that's enough to really nicely support what I'm thinking of
<vila> haaa, hidden commit, ok
<spiv> lifeless: I don't have a concrete use case in front of me to drive my opinion at the moment, though, so it's hard to be sure if I'm right or not :)
<spiv> lifeless: I need to get back in the habit of using looms regularly :/
<spiv> lifeless: but part of the reason I fell out of the habit was the mental friction with forcing a mental DAG of work into a linear stack
<lifeless> spiv: so, do you routinely have 3+ branches on disk, merged non-stacklike together ?
<spiv> lifeless: I routinely don't separate out the work at all, because I'm not using looms.  I make exceptions for obviously unrelated bits :)
<vila> routinely, no, but I currently have a loom with 8 threads, 3 of them being parallel
<spiv> lifeless: my recollection from when I was using looms is that I tended to want trunk->something, then something->X, something->Y, something->Z, then [X,Y,Z]->integrated, and maybe integrated->put-icing-on-the-feature-cake :)
<vila> spiv: hehe, very close to my current loom :)
<vila> spiv: something == ServerInAThread, X == http-leaks, Y == smart server leaks, Z == sftp leaks, ice-on-cake == socket leaks aka transport.disconnect
<vila> X, Y and Z being independent from each other
<lifeless> spiv: does ->X mean 'X builds on something'
<lifeless> spiv: or 'something needs X'
<vila> spiv: by the way, regarding smart server, the tests use a TCP server (no ssh) and seem to create a lot of different  (independent) connections, does that ring a bell ?
<spiv> lifeless: "builds on"
<spiv> vila: what does "the tests" refer to here?
<vila> spiv: the observation is that there are a lot of independent threads created (one for each connection) which means multiple client connections not sharing a single connection
<lifeless> spiv: so, in the form I'm describing you would do the following:
<spiv> vila: generally speaking each test that uses a smart server makes its own server, and thus its own client connection when get_transport is called
<vila> spiv: AFAICS all the tests that use SmartTCPServer_for_testing and its variants
<lifeless> spiv: sitting on something; hack hack hack; bzr commit --to-thread:X
<lifeless> spiv: which would:
<vila> spiv: I'm talking about a single server receiving multiple connections (~10/20) for a single tests
<vila> test, no s
<spiv> vila: I wouldn't expect that, no
<vila> spiv: ok, good to know, we may have a bug or two there then
<lifeless>  - make a thread X based on trunk; get the diff against the synthetic base for tree:, confirm the resulting diff, save it.
<lifeless> once you have X
<spiv> vila: unless those tests are actually constructing ~10-20 transports from scratch, rather than reusing them
<vila> spiv: the test code itself doesn't seem to support this idea (and I didn't observe that for other servers)
<spiv> (i.e. calling get_transport a lot, or passing URLs rather than transports around without also passing possible_transports, etc)
<vila> spiv: but ssh may mask that somwhow
<lifeless> then the diff for the next --to-thread would be checked for conflicts against both X and trunk
<spiv> vila: very few tests involve SSH
<vila> spiv: if you exclude sftp, yes
<lifeless> the one after that against X, Y and trunk, etc (probably by walking back down till it gets a hit)
<spiv> vila: I do, because we are talking about smart server tests :P
<vila> spiv: sure, I was making sure we were still on the page
<lifeless> spiv: essentially, to model it simply, I'm talking about keeping all the threads integrated all the time, in a floating set of rebased revisions.
<lifeless> but never logging or working directly with them in the UI
<spiv> lifeless: I'm not immediately grasping this concept, or how I'd use it.
<spiv> lifeless: which may be a good or bad sign ;)
<vila> lifeless: it's close to the mental model I've built since our last discussion
<spiv> lifeless: give that it's almost EOD here, probably best to write it up properly somewhere rather than try to clarify it for me on IRC :)
<vila> (close because it doesn't run yet even in my head ;)
<vila> and that I'm unclear about which commits should be part of the final result or filtered out or something
<vila> But I'm sold on the idea that each thread ends up with a cleaner history than today
<spiv> lifeless: perhaps I should counter with a proper proposal of the UI I'm thinking of, I *think* it wouldn't be very complex at all, but writing it up will help me find out if I'm missing something.
<lifeless> spiv: writing it up will require some untinterrupted tuit time
<lifeless> spiv: so next week, perhaps
<lifeless> spiv: that said, I would love to see a good description of how you see a graph based one working
<lifeless> spiv: I would like to note two things of particular concern I'd be looking to understand
<vila> eeerk, AttributeError: 'ObjectWithCleanups' object has no attribute 'addCleanup' with bzr.dev@5310 py2.6.0 on osx
<lifeless> merge bases
<spiv> vila: 'add_cleanup' is the name...
<lifeless> oh wow
<spiv> So, um, wow :)
<lifeless> htf did that pass pqm
<spiv> what lifeless said.
<lifeless> I bet I know
<vila> smart/medium.py line 506
<lifeless> I bet _DebugCounter or whatever it is called
<lifeless> isn't tested.
<vila> lifeless: exactly
<lifeless> spiv: so merge bases - how do we avoid lots of criss crosses
<lifeless> spiv: CLI ui representation of the graph - including a sensible 'merge' or some such
<vila> http://paste.ubuntu.com/452826
<lifeless> not that we should limit ourselves to cli
<lifeless> but I'd like usable on CLI, for loom, because Ubuntu devs loves their consoles
<vila> s/addCleanup/add_cleanup/ fixes it
<lifeless> yes
<spiv> vila: right. +1 land it :)
<lifeless> whats that saying about untested code?
<vila> +1 on using addCleanup instead :)
<spiv> lifeless: In my head I think I have good answer for the CLI ui
<spiv> lifeless: not sure why you expect more criss-crosses, though
<vila> lifeless: that we should thank our testers ? (NOT !) :)
<lifeless> spiv: I've simulated DAGs by hand
<lifeless> spiv: and universally had equal-distant common ancestors along each path, leading to criss-cross complains and merge hell
<spiv> lifeless: interesting
<spiv> lifeless: I'll have to chew on that.  Thanks!
<vila> spiv: sent to pqm
<lifeless> spiv: a posible explanation is - consider trunk->X, trunk->Y, (, Y -> something)
<lifeless> spiv: both X and Y are commonly one-commit on trunk
<lifeless> spiv: and clearly equally good  the next time you merge trunk->something
<desen> greetings. i want to translate an open source application. can i use the bazaar + launchpad solution with ease ?
<desen> i have registered a SSH key and i'm really stuck - dunno what to do next
<desen> T_T
<Kamping_Kaiser> ask the proejct how they want patches submitted :)
<spiv> Ooh, a way to reproduce https://bugs.edge.launchpad.net/bzr/+bug/522637
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 10, heat: 54)" [High,Confirmed]
<cbz> is there any bzr-svn command to rationalise the cache on windows?
<spiv> rationalise in what way?
<cbz> remove the bits that aren't needed/used
<spiv> You can probably use the sqlite3 command-line tool to VACUUM the cache database, I guess.
<spiv> Well, to be pedantic, it's a cache, so none of it is *needed*... so you can just delete the svn-cache directory entirely ;)
<spiv> I don't think there are any commands in the bzr-svn plugin for that.
<spiv> File a bug asking for them, maybe?
 * spiv -> zzz
<cbz> :)
<maxb> cbz: How do you define "bits that aren't needed"?
<MTecknology> spiv: but it's only 08:30
<MTecknology> How hard would it be to make a section in bzr that's available to anyone w/o setting up shared keys?
<CaMason> hi guys. Just installed bazaar explorer on windows, and it wont launch
<CaMason> if I run `bzr explorer`, it says ERROR: No module named trace. You may need to install this Python library separately"
<CaMason> nvm I reinstalled the full package and it works. I'd like to get rid of tortoisebzr though
<MTecknology> !info python-tracer | CaMason
<ubot5> CaMason: python-tracer (source: pytracer): Centralized trace management using sys.settrace. In component universe, is optional. Version 0.2.3-1 (lucid), package size 8 kB, installed size 104 kB
<lifeless> morning
<lifeless> bbiab, taking lynne -> airport
<DanC> broken link on http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html "In the event that weâre wrong and another tool completely takes over, you can use fast-export to switch your code base across if and when another tool better meets your needs."
<DanC> to http://doc.bazaar.canonical.com/migration/en/data-migration/fast-export.html
<ciss> hi, i need some help with reverting to a previous revision: i reverted to a tagged revision, 3 revisions ago, but the files changed after that revision are listed as modified. shouldn't their content be reverted to that revision instead?
<ciss> i used bzr revert -r tag:mytag
<ciss> ah, ok ... so revert only reverts the file contents, but doesn't "undo" the revisions that followed. how do i "uncommit" each revision since that specific one?
<ciss> never mind, got it.
<ciss> grmpf. i uncommitted a few revisions, tried to do an upload, but bzr tells me that the branch and the uploaded tree have diverged, even if i use --full. am i missing something?
<ciss> got it. one has to use --overwrite.
<jono> hey all
<jono> quick q
<jono> I can push a branch to LP fine, but how do I push something to something other than LP?
<jono> such as a webserver
<ciss> jono, "bzr upload" will creates a working tree in the destination
<jono> ciss, so do I use bzr push or bzr upload?
<jono> what is the difference?
<jono> I just have a branch locally and I want to push it regularly to another machine
<jono> so someone else can pull from it
<jono> and we both have access to the same sftp destination
<lifeless> abentley: I hope the tweaks I made to your terminal spew patch are ok with you
<abentley> lifeless, me too.
<lifeless> hah
<jam> jono: if you just want to share a branch via sftp, then ... do so
<jam> bzr push sftp://host/path
<jam> you might want to
<jam> bzr init-repo sftp://host/path/repo
<jam> first, but it isn't strictly necessary
<jono> ok cool
<jono> thanks!
<lifeless> abentley: I take it that means you haven't looked ?
<abentley> lifeless, right.
<lifeless> kk
<lifeless> please do let me know before 2.2 final is released, I'll be happy to tweak further
<lifeless> andrew and I went over it with some care though, I'm fairly sure you'll approve
<abentley> lifeless, actually, I do see at least one problem.  The ContextManager protocol demands that you call __exit__ on the return value of __enter__, but you're calling it unconditionally on library_state.
<lifeless> abentley: oh! we must have misunderstood the protocol.
<lifeless> I followed what I saw you had done in the ui_factory
<lifeless> so both of the uses must be wrong
<lifeless> I'll read the context manager protocol PEP and submit a fixup branch
<lifeless> abentley: http://docs.python.org/reference/datamodel.html 3.4.10 says you call __enter__ and __exit__ on the same object
<lifeless> abentley: the return value of __enter__ is bound to the name used in the as clause
<lifeless> so the example I gave was wrong, but the code itself is fine
<lifeless> hmm, and __enter__ in both cases could usefully return self, for now.
<lifeless> thanks for calling that to attention
<abentley> lifeless, you're right.
<lifeless> abentley: proposal proposed
<abentley> lifeless, approved.
<lifeless> thanks
<lifeless> abentley: the draft patch you gave me for pqm was very useful
<lifeless> abentley: the api turned out to be rather more rabbit warren, but it got me started
<abentley> lifeless, I'm glad.
<james_w> lifeless: getting mixed up between "testr run --failing" and "testr failing" is very confusing :-)
<lifeless> james_w: I can imagine
<lifeless> james_w: we should fix that
<james_w> show-failing or something would avoid it at least
<lifeless> james_w: testr st --failing ?
<lifeless> james_w: I dunno, having a direct simple command is noce too
<lifeless> james_w: perhaps testr run --auto
<james_w> I would prefer testr show --failing to st
<james_w> I would imagine st would be something like "104 tests, 56 failures, 4 skips"
<lifeless> yea
<lifeless> stats is pretty basic at the moment
<lifeless> heck, testr is pretty basic
<james_w> lifeless: testr run --auto would loop by itself?
<lifeless> james_w: no, I meant auto as in 'automatically choose the tests to run'
<lifeless> james_w: so all tests if none are failing, or failures only if there are failures.
<james_w> right
<lifeless> james_w: maybe that is what you meant by loop by itself
<james_w> I was just thinking that a loop around that could be quite useful, depending on how long your testsuite took
<lifeless> inotify++
<lifeless> + a background status window in your editor
<james_w> for my fast testsuite projects a "run everything as fast as possible, then iterate over failing", in a pane of my terminal would be good
<james_w> yeah
<poolie> lifeless, i think requiring people to call __enter__ and __exit__ is a bit ugly in python2.4 code
<james_w> plus some way to go from path -> test filter to run would be good for larger projects
<lifeless> james_w: yes, I'm looking forward to the new subunit discovery patch - you saw it needs tweaking right ?
<james_w> yeah
<james_w> just been distracted the last few days
<lifeless> poolie: It is a bit ugly. OTOH I don't know any python 2.4 library users other than loggerhead, and it supports being a plugin now as well.
<james_w> any thoughts on a way to infer test patterns based on path in testr?
<lifeless> poolie: being a context manager is quite a bit nicer for python2.5 and up
<james_w> might seed my thoughts for a flight sometime soon
<poolie> mm and i guess showing that it's a context manager is worthwhile on 2.4
<lifeless> james_w: please; be nice to be friendly for C etc
<lifeless> james_w: it is perhaps a general problem, and one that a separate tool should solve, testr could use that. Thats perhaps too fine grained: just offering food for thought
<james_w> yeah, that's where I'm stuck. Would be easy to write a way to call a python function and pass the path, but that doesn't fit too well with .testr.conf
<james_w> hmm, that would make it easier
<james_w> perhaps something like urlconf from django if you know it?
<lifeless> james_w: I'm open to doing a plugin system for testr too
<lifeless> james_w: vaguely, but not intimately
<james_w> mapping of regexes -> values, pick the tightest regex that matches
<lifeless> james_w: another related problem you might enjoy
<lifeless> james_w: 'I changed file FOO, what tests do I need to run'
<james_w> plus a way to substitute groups from the match in to the value would be greaet
<james_w> lifeless: ah, that's exactly the problem I'm considering :-) What were you thinking?
<lifeless> james_w: many people have stabbed at this problem; theres some prior art I can dig up in python space, but essentially we are perhaps wanting that top level contract
<lifeless> james_w: a database of call graphs (for python code). something similar for C (using gprof); write a interface, implement the languages we care about; profit.
<lifeless> james_w: the complex bit is that you need test run instrumentation tunneled through to the db
<lifeless> james_w: which perhaps subunit can help with.
<james_w> that's more involved than I was envisaging
<james_w> much more powerful and hands off, but...
<lifeless> james_w: precisely ;)
<lifeless> james_w: so, I've been building towards this for a while, finding good building blocks and making them nice.
<lifeless> james_w: like testr
<james_w> yeah
<lifeless> james_w: I'd be delighted to have a regexp based approximation in testr
<lifeless> james_w: I'd just like it to have a contract which is fairly close to what one might want for an automated solution
<james_w> path -> arguments for the test command was what I was thinking, would that fit?
<lifeless> jam: https://code.edge.launchpad.net/~lifeless/bzr/py3/+merge/28113 btw
<lifeless> james_w: command to get paths (e.g. bzr st); command to do paths->test id list as string or filename
<lifeless> james_w: perhaps
<lifeless> james_w: I suggest some experimentation
<lifeless> james_w: don't worry about code quality etc for now, just play around and see what tickles your fancy
<james_w> yeah
<james_w> I was thinking inotify, but yeah, that split would work ok
<lifeless> james_w: yes, we will want a way to specify the path[s] explicitly too, both for non-vcs cases and for manual control
<lifeless> inotify too
<lifeless> long as we define a sensible contract, one can write backends for inotify, bzr, etc etc as well as paths just being supplied on the command line
<james_w> I wouldn't want "test id list" though, because I don't want to enumate tests at that level, unless testr had a way to enumerate tests too
<lifeless> james_w: testr works on enumerated tests fairly intrinsically
<lifeless> its how run --failing works: it filters the stream to get failure test ids, then uses that to construct the command line to run.
<james_w> yeah, but I just want to say "given bzrlib/foo.py run bzrlib.tests.test_foo"
<lifeless> james_w: which is a wildcard on the test id
<lifeless> james_w: inside bzrlib
<james_w> lifeless: ok, I thought you meant test id list in the -F sense: an exact list of tests to run
<lifeless> james_w: I did, and I can see the use for a wildcard here
<james_w> ok
<lifeless> james_w: I think supporting both is useful
<james_w> I'll try and take a first pass at this sometime
<james_w> I have my head full of another problem right now though
<lifeless> naturally
<lifeless> feel free to braindump wishlist bugs
<lifeless> I don't mind 'it would be nice if frogs could jump
<lifeless> style bugs
<fullermd> Do they have to jump?  Can they sort of sashay?
<lifeless> poolie: on context managers
<lifeless> poolie: we could provide friendly functions that call enter and exit, but I don't think its really a big deal [yet], and doing so may make the API ambiguous further down the track.
<poolie> mm
<poolie> i was wondering if it was worth doing the initialization at construction time
<lifeless> poolie: it is clearly documented, which offsets some of the ugliness in my mind
<poolie> so that it matters less whether you call enter()
<poolie> probably not worth it though
<poolie> iirc this function is new in 2.2 anyhow
<poolie> yes it is, new in 2.2b1
<lifeless> poolie: that would be buggy I think, consider the fixture intent/use separation
<poolie> what's the correspondance?
<lifeless> actually, bad analgoy
<lifeless> bah, analogy
<poolie> anyhow,
<lifeless> a better one is perhaps, for testing it would be good to be able to poke at this quite precisely
<lifeless> and changing global variables in __init__ would likely make that tricky
<poolie> i think if we're going to use a contextmgr, it really should be an idiomatic contextmgr
<lifeless> hah, - went to say 'affects me too' from the bug filing form on bug 421360
<ubot5> Launchpad bug 421360 in Bazaar "switch won't let me switch with a pending merge (affected: 1, heat: 0)" [High,Confirmed] https://launchpad.net/bugs/421360
<lifeless> and I filed it :P
<lifeless> poolie: https://code.edge.launchpad.net/~lifeless/bzr/encoding-option/+merge/28126
<lifeless> poolie: I'd like to talk about the buffering patch some
<poolie> on phone atm
<lifeless> sure
<lifeless> I mean, its not urgent, just I'd like to explore what we're doing in the area in a concentrated fashion :)
<poolie> lifeless, what did you change?
<lifeless> in the encoding-option branch? NEWS - moved to right section, added a mention of the new option, and the years in the new file copyright statements were too broad
#bzr 2010-06-22
<poolie> lifeless, i just wondered why you wanted to push a separate branch for it
<poolie> was it blocking you?
<lifeless> poolie: having reviewed it there seemed no real point not JFDIing it
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: lifeless | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
<poolie> i see
<lifeless> poolie: I would have pushed to your branch and mp, but lp doesn't really support that as a workflow
<poolie> you're pilot this week too?
<lifeless> poolie: yes
<poolie> i think that given lp's current state pushing new ones makes a lot of noise
<lifeless> poolie: so it took me; oh 30 seconds to pull your branch, another minute ot make the change, bzr lp-propose to make the new proposal was all cli driven
<poolie> sure
<lifeless> its pretty slight to that extent
<poolie> but now i have a big old diff in my mailbox :)
<poolie> i'm not really complaining
<poolie> it's just a bit of a change from the normal practice of committers landing their own code
<lifeless> there is a backlog
<lifeless> I could nag folk, but I know people are just busy
<lifeless> so am doing; I think people will respond by getting there first if they want to avoid the noise ;)
<poolie> i haven't had any work hours between some of these being reviewed and you landing them
<lifeless> poolie: heh, I didn't notice that
<poolie> that seems a bit overoptimized :)
<lifeless> perhaps
<lifeless> OTOH for all noncommitters we roughly need this anyway
<poolie> ah
<lifeless> and if the fixes aren't trivial to such branches, they will deserve a peer review too; so its worth noting the rough edges - and spiv filed a bug about part of it yesterday
<poolie> please let me read the review comments on my branches and land them myself
<poolie> unless you know i'm away
<lifeless> I think its important we make this easy to do; I appreciate there is some noise now, lets make sure there are good bugs and think about how to reduce the noise.
<lifeless> poolie: for most of yours I have
<poolie> it's a bit like the pqm thing
<poolie> if you're going to change the patterns in which people work it's nice to tell them first
<lifeless> poolie: uhm, I've landed one of yours
<poolie> two?
<lifeless> and added a patched version of a second
<lifeless> I landed your external base deprecation patch
<poolie> i appreciate the help i'm just a bit surprised
<lifeless> poolie: I'm really not sure how to react
<poolie> I agree with > I think its important we make this easy to do; I appreciate there is some noise now, lets make sure there are good bugs and think about how to reduce the noise.
<poolie> perhaps send an rfc saying that any contributor (or especially the pp) can finish off and land other people's patches?
<poolie> if this is what you generally want to do?
<mgz> evenin' all
<poolie> i guess it's just that with lp reviews as they exist today this seems to generate more noise than me doing the updates in the existing branch
<lifeless> poolie: this isn' actually a change you know; we've variously landed stuff when people are busy for years
<poolie> ok
<poolie> i don't know then
<lifeless> poolie: I can send an email saying 'is the amount of email when I do this too much'
<poolie> my answer is yes
<poolie> but, whatever
<poolie> it's only two patches
<lifeless> its worrying that two patches makes you feel overloaded :(
<poolie> heh
<mgz> urk, hung on "Inserting missing keys" pushing to launchpad again
<mgz> I won't interrupt it, broke things horribly last time I did that
<mgz> better not take hours though I need sleep.
<mgz> done. only three minutes with no ui update there:
<mgz> 17.046  creating new compressed block on-the-fly in 0.015s 172124 bytes => 58366 bytes
<mgz> 196.281  creating new compressed block on-the-fly in 0.000s 4194098 bytes => 2161 bytes
<lifeless> -> food
<mgz> bytes!
<mgz> or just nybbles...
<poolie> that's a lot of compression
<poolie> hi lifeless
<poolie> hi spiv
<parthm> i am trying to clean up a testcase http://pastebin.com/t6KvPff0 . if i replace the ".bzrignore" creation with "self.build_tree_contents([('.bzrignore', 'RE:*.cpp\n')])" it fails (run_bzr returns 0 instead of 3).
<parthm> doesn't build_tree_contents put a file on disk?
<parthm> sorry. mybad. looks like i did something wrong there. its working now :)
<lifeless> parthm: the u'' there is almost certainly wrong
<lifeless> parthm: you don't have any unicode in there, and you're not opening an encoded file
<parthm> lifeless: yes. i cleaned that up. thanks.
<lifeless> parthm: cool
<lifeless> parthm: the alarm bells went off because of the regular file: we write bytes to regular files, unicode to encoded file.s
<parthm> lifeless: have you seen the "class _Pattern" in rejected https://code.launchpad.net/~parthm/bzr/300062-invalid-pattern-warnings/+merge/26809 ? that seem like a good cleanup to me.
<parthm> i can port it to the error based mp. what do you think?
<lifeless> its odd that its a class with no methods
<lifeless> and no global mutatable state
<lifeless> I think I'd want to see separate patches
<lifeless> one to introduce such a thing
<lifeless> and one to change the error handling
<parthm> lifeless: sounds fine. i can try a separate patch for that. thanks for the quick review :)
<lifeless> parthm: I think if you do it, that you should make it a real object w/out static methods
<lifeless> and either a single global instance, if you really need that, or one instance for the each Globster, or something
<lifeless> or even
<lifeless> make it a base class of the globsters
<lifeless> the file looks half-refactored from functions to objects, to me.
<parthm> lifeless: yes. while implementing it i was thinking that much of it fit well in globster.
<lifeless> spiv: whats the bug # you filed yesterday about LP MP continuations
<spiv> lifeless: bug 596726
<ubot5> Launchpad bug 596726 in Launchpad Bazaar Integration "Poor support for merge proposals superseded by different branch (affected: 2, heat: 10)" [Undecided,New] https://launchpad.net/bugs/596726
<lifeless> thanks
<jibbles> 'Ello, all!
<jibbles> I want to try versioning all my work in a centralized fashion, pushing and pulling from various machines to one server. I have a hierarchy of folders for my work...I assume this should be added to the same repository; is there any point in adding E.g. schoolwork and writing (if unrelated) as different projects? Will I lose any flexibility if I just import it all as one project?
<lifeless> jibbles: if you make it all one project, you can't push just part of it somehere
<lifeless> jibbles: bzr works on an entire project (we call it tree, or branch) at a time
<lifeless> poolie: night (signing off work, still around tho in various ways)
<poolie> lifeless, good night, thanks for the note about mps
<lifeless> no probs; we should wait for jam who has expressed pain in this area before deciding what to do
<jibbles> so I should just manually init each project folder like /stuff/cplusplus/foo with E.g. "bzr init-repo --no-trees sftp://host/srv/bzr/cplusplus/foo" ? Is this how most people do it?
<jibbles> oops, I meant "bzr init", not "init-repo"; assume the repo was already created
<jibbles> be back in 20
<maxb> jibbles: init-repo creates a repository, which is a storage/speed optimization to allow multiple branches/trees to share a single copy of history they have in common. init, on the other hand, creates a new branch
<jibbles> Ok, if you were going to version a lot of personal work in one folder hierarchy, what workflow / project divisions would you choose? Any takers?
<lifeless> jibbles: I'd just make branches for each project
<lifeless> and ignore the hierarchy
<vila> hi all !
<jibbles> so something like "bzr init sftp://host/srv/bzr/foo" rather than "bzr init sftp://host/srv/bzr/work/programming/cplusplus/foo" ?
<lifeless> jibbles: the latter
<jibbles> do you type the whole path for commits, etc.?
<spiv> jibbles: no, bzr remembers a default location for commits to checkouts, and for pushes, etc.
<spiv> So, maybe the first time you might, but afterwards usually not.
<lifeless> jibbles: also normally you'd just init on your local disk
<lifeless> jibbles: and use push to push stuff to host
<jibbles> Thank you very much for answering my questions, lifeless :)
<jibbles> Goodnight
<thrope> how can I find %BZR_HOME on windows?
<thrope> I would like to create a RULES file
<thrope> does it have to be done on a per-user basis or is it possible to have a global one/
<lifeless>  bzr --version
<lifeless> and yes, per user
<thrope> ok thanks
<thrope> if I change an eol rule on windows
<thrope> do I need to delete and recheck out the repo
<thrope> to get the windows line endings put it
<thrope> *in
<thrope> hmmm I have set eol native
<thrope> and recheckout my repo
<thrope> but now in windows all files have changed icon
<thrope> I am guessing becuase of the different line endings
<thrope> when I do diff it is completely empy
<spiv> thrope: sounds like a bug in tortoisebzr (or whatever it is that shows those icons), please file a bug report about it
<thrope> spiv: after doing a commit it seemed to be ok
<thrope> and the commit doesnt seem to have changed my other checkouts on linux machines
<iainfarrell> hello BZR people! I come with limited knowledge seeking help :)
<iainfarrell> I am trying to add a blog to the Ubuntu planet but it won't go
<iainfarrell> get this error
<iainfarrell> ERROR: Cannot lock LockDir(lp-69469520:///~planet-ubuntu/config/main/.bzr/branchlock): Transport operation not possible: readonly transport
<iainfarrell> any ideas?
<parthm> iainfarrell: did you "launchpad-login"? if you don't login lp default branch to use https which is readonly.
<iainfarrell> hello parthm - I have logged in, yes
<parthm> iainfarrell: whats the command thats failing? push?
<iainfarrell> commit -m
<iainfarrell> bzr commit -m "Added Design Team Blog to the Planet"
<iainfarrell> which is what I'm trying to do :)
<parthm> iainfarrell: do you have commit access to the branch on the server?
<caravel> hi folks
<iainfarrell> parthm: I _think_ so in that this is the adding to the planet and I'm an Ubuntu Member
<caravel> I get some weird flickering issue in explorer using 2.1.1 on XP (and tortoise I guess). Didn't find any info so far, besides a known overlay conflict with DropBox (which I don't feel is related, and I don'tuse anyway). Any tip anyone, please ?
<parthm> iainfarrell: i see some talk about this error message on bug #129701 ... seem to indicate that the user may not have write permissions to the branch.
<ubot5> Launchpad bug 129701 in Bazaar "UnlockableTransport error trying to commit in checkout of readonly branch (affected: 0, heat: 0)" [Medium,Fix released] https://launchpad.net/bugs/129701
<parthm> iainfarrell: what is the "checkout of branch:" shown by "bzr info"
<iainfarrell> ok parthm thanks, I guess I will have to find the right person to ask for access
<parthm> thats the branch you will need write access to.
<iainfarrell> checkout root: .
<iainfarrell>   checkout of branch: bzr+ssh://bazaar.launchpad.net/~planet-ubuntu/config/main
<parthm> iainfarrell: if you are a member of "planet-ubuntu" you should be able to write.
<iainfarrell> ahh ok, I think it's because I've not been added to the correct launchpad team
<iainfarrell> heh parthm - great minds :)
<parthm> iainfarrell: :)
<parthm> iainfarrell: i think the message is a bit cryptic. maybe it should be clearer. ... you could file a bug. someone would eventually look into it :)
<iainfarrell> So I need to be a member of Ubuntu Members which I didn't check at the start
<iainfarrell> I'll get myself added
<iainfarrell> you guys ROCK, thanks :)
<beuno> iainfarrell, being added to ubuntu members is a big process, as it is community-driven, I'd suggest you talk to someone from IS about it, or jcastro
<iainfarrell> thanks beuno I'm talking to Jcastro now :)
<iainfarrell> make sure we do this properly :)
<LeoNerd> Bah.. I dislike the new shelve plugin. shelve/unshelve/shelf was nice because all the options that weren't -obviously- shelve/unshelve, lived in shelf. shelf list, shelf view, shelf delete,...
<LeoNerd> Now they're seemingly-arbitrarily attached to one option or the other. bzr shelve --list, bzr unshelve --preview, bzr shelve --delete-only
<caravel> Could anyone enlighten me please ? Using bazaar 2.1.1/xp w/tortoisebzr (0.5.4 by default) -- since this version, explorer "blinks" when getting around to any bzr folder. Fresh reinstall of bazaar/win and reboot reproduce the issue. Any thought ?
<Mantrid> I'll take a really wild guess as I don't know, and suggest it may have something to do with icon caching in explorer.
<caravel> Mantrid: thanks - this is all I found, and I can't see it related: http://preview.tinyurl.com/2b8qclg
<caravel> Mantrid: the issue was occuring on a test repos, linked to an ftp server which is currently unavail. Could this be related ? Killing explorer mostly killed my windoz session, apps didn't come back when restarting explorer ^^ After restarting the issue still occured. I deleted the repos and created a new, local one: issue is gone.
<caravel> in other word: is there any process trying to figure "real time" whether the branch seen in explorer is up to date against its source ?
<Mantrid> hmm. Looks like you may have found the cause. I've not look at the tortoise code so I don't really know much about it. If it does re-occur then perhaps you can determine if it is related to the ftp server.
<Mantrid> Ah you should ask the totoise devs. I believe there are hooks in explorer that tell you something is happening and probably we hook into that.
<caravel> I've been using/setting up tortoise/cvs&svn an awful lot and never saw any similar issue. toirtoise was not 100% perfect but still the easiest for non-technical users ^^
<caravel> I've got a question cf. topology: two developers need to use bzr on their respective laptops, no server involved, just an ftp folder as a "relay" between both devs, one of them is the "gate keeper". Another ftp server should be used as an extra backup place. I guess it's a very common scenario on small projects ^^
<jelmer> caravel: right, that should work without issues
<caravel> None of the ftp servers are considered reliable. Should the main repos be created as independant on the gate keeper's laptop, then "pushed" onto the relay ftp ? To automate the ftp "waterfalls", should be use bzr client from the backup ftp to the relay ftp folder ?
<caravel> (backup ftp is a debian server we administrate, so we can setup bzr client here)
<caravel> Or... should the gate keeper define the main repos to be located on the relay ftp, then work on his local copy until remote commits ?
<caravel> Finally, is there any difference between both results ?
<Mantrid> Do you mean, should you use bzr to transfer the branches to the ftp server, or should you copy them up there?
<caravel> Mantrid: well, no: I hadn't consider NOT using bzr for replication, since I was assuming bzr would be more efficient than eg rsync for this (one of our criterias to chhose bzr actually, is that it's said to support folder renaming and files moving)
<caravel> but should I ? ;-)
<Mantrid> no I'd use bazaar to do everything. i.e. to push it up to the ftp server. That way it will lock the branch for you and prevent any accidental overwrites and so on.
<caravel> ok, so  dev A should make a "standalone" branch on his laptop, then "push" it on the relay ftp... which should be simply branced by dev B and the backup debian. Right ?
<Mantrid> yes I think so. But I don't quite understand, what is "backup debian" ? The ftp server is just to share the code isn't it between dev A and B right?
<Mantrid> I've no doubt seen this I assume: http://wiki.bazaar.canonical.com/Workflows
<Mantrid> sounds like this "Decentralized with human gatekeeper" except the gatekeeper is also developer B (or A) and you have some other debian server involved.
<caravel> Mantrid: Yes, I have seen this again and again ;-) dev A & B both travel quite extensively. "relay ftp" is a poor windo$ machine located at dev A home with unreliable connection (dev A is an independant consultant). dev B does internal QA and small contribs. "backup debian" is a modest server "on site" with unreliable connection, but we want a copy there, even if sometimes a little outdated. Purpose of the repo is a whole web site inclu
<caravel> Mantrid: sorry I guess this is almost flooding, did you receive this entirely ?
<Mantrid> missed the end :P But I think you say the debian box is where you would call the main repository where the code will have it's home.
<Mantrid> and the ftp at A is so that dev B can get A's work.
<Mantrid> You needent have a gatekeeper. It depends if you want the code reviewed or not before it goes to the debian server. I guess you DO want it reviewed yes?
<caravel> Mantrid: well... dev A need NOT to rely on debian. YES, dev A must review anything, he's the only one skilled with the code he's using
<caravel> here is the end of my prev msg ^^ "backup debian" is a modest server "on site" with unreliable connection, but we want a copy there, even if sometimes a little outdated. Purpose of the repo is a whole web site including many media files. Sync don't have to be very often (2 weeks), and will be scheduled ^^
<caravel> Mantrid: what we need really are mirrors of what dev A is doing + the ability for dev B to contribute (for exclusive approval by dev A)
<Mantrid> in which case dev B can put the code somewhere, anywhere in fact and tell dev A to review and merge. you can even use bzr send to send a bundle.
<Mantrid> dev A can then push up to a mirror and or release site.
<caravel> Mantrid: (bundles could be huge) ok, so the main branch should be located on dev A laptop -- then pushed up his home ftp. Is this correct, will bzr handle his subsequent pushes to let him update ?
<Mantrid> yes that will work. Unless someone else pushes and update to the same place on the ftp server first. In which case bzr will tell your the branches have diverged and dev A will have to merge. But. that should not happen as each developer will have his own place on the ftp server to put code, and so pushes will just "go up" - the differences (new revisions) will get pushed.
<Mantrid> In all cases, only the differences will get pushed up no matter which developer is pushing where.
<caravel> Mantrid: ok, so it seems perfect: actually, since the only purpose of the ftp is sharing a copy of the main branch (which sits on dev A laptop) then if dev B wants to contribute it is perfect: he could push also to the same space, forcing dev A to merge before re-pushing. Right ?
<Mantrid> so 1. You can't really break anything by accident, bzr will tell you. 2. It will be quick to push (after the first push of all the data)
<caravel> Mantrid: brilliant. thanks, I think I had not understood what was a bzr "push". cheers
<Mantrid> yes that's right.
<Mantrid> you can push the the same place. But if it's changed, he would have to merge back down first. But you said you want dev A to review the code first, so both the devs would use seperate places.
<Mantrid> I suggest you give it a little try out. You don't have to use an ftp server. You can pretend that /home/ftpserver or c:\ftpserver is your ftp server.
<Mantrid> What I do is the same for small projects. I push my work upto an sftp sever, so does my collegue. If I own the project, then I merge his work from the ftp server into mine and check it works, and then I push it back via sftp to what I call the mainline location which is seperate from both our branches.
<caravel> Mantrid: ok, but then do you use a shared repos for both branches, so the repo location is on the sftp server (and not on your workstation), right ? Then your mainline is a seperate bzr repo, even if it is 99% a duplicate of the dev area ?
<Mantrid> erm. you can do either. With two people it doesn't matter so much. But you can have a separate branch on the server called mainline if you want, that is if you like the "proper" stable code. That's separate from each of the developers branches. But you don't have to. If might be best though and then you can have a rule that says the mainline code must always at least be in working order. Whereas the developers branches don't have to be.
<Mantrid> So developer B will then refresh his branch "pull" or megre from either dev A's branch, or the mainline that that developer A manages.
<Mantrid> in any case. No matter what developer B does, whereever he gets the code from. bzr will pull it, or will tell him he needs to merge. There will be no problems of getting out of sync.
<caravel> Mantrid: I understand - in our case, dev A branch need to remain purely local to dev A laptop (yet it is a big effort for dev A to start using a VCS, can't push it too far). So he'll push "stable", dev B will update from "stable" and push to "B branch", from which dev A will merge ^^ OK, unless you need to correct me again I think it's all clear
<Mantrid> Yes that's it. And you can change your mind later if there is another way it's not a problem.
<Mantrid> dev B can pull or (update) from DEV a's branch directly if he wants to help dev A fix something toghther and then push his branch up. it will still merge correly, bzr will track all the changes no matter which branch they come from.
<Mantrid> but maybe I am confusing you now. Try it out, and you will see.
<Mantrid> also the bzr missing command can be helpful. it will give you a list of changes essentialy from what you have. You could say bzr sftp://server.com/projectx/trunk and it will tell you waht's changed, and what changed you have made that isn't up there already.
<caravel> Mantrid: sure ;-) again, dev A branch won't ever be accessible or published, only stable. Look: yet if I succeed to introduce the word "stable" itself as a concept in this little team, I think it will be a great victory!!  I already know that after this essential move (start using a VCS, finally), dev A won't have/take/accept to spend any time to reconsider anything, not even a sec ;-)
<caravel> Mantrid: thanks a lot for your clarifications. Bzr definitly sounds a lot more flexible than cvs/svn (or, well, then what I experienced with these).
<Mantrid> Yes. When you try it out a bit you will understand it better and it will make more sense to you.
 * caravel gives #bzr a break and is quite thankful to Mantrid
<Mantrid> :-)
<lifeless> mornin
<Mantrid> evening. Got to run.
<lifeless> this is going to be fun
<lifeless> "Note that when os.listdir() returns a list of strings, filenames that cannot be decoded properly are omitted rather than raising UnicodeError."
<maxb> urgh.
<maxb> Whoever thought *that* was a good idea
<lifeless> python3 has a bit of architecture-astronaut feel to it
<lifeless> in the whole unicode string thing
<jam> lifeless: so now they are omitted rather than returned as 8-bit strs? I thought there is a proposal to give them as private-plane code points, or something like that
<lifeless> 3.2 or something like that will do a surrogate escaping thing for non decodable filenames which is better
<lifeless> jam: no, thats the 3.0.1 docs
<maxb> I'm going to assume that architecture-astronaut means something like being designed from a viewpoint far too far away from the problem?
<lifeless> maxb: yes, one ignoring inconvenient realities ;)
<jam> lifeless: malformed files don't exist
<maxb> and if we all cross our fingers and believe that really hard, maybe it'll come true! :-)
<rubbs> wait. you mean Santa doesn't exist?
 * rubbs cries himself to sleep now.
<jam> rubbs: no no, santa *does* exist, malformed filenames don't
<rubbs> jam: oh, thank you for re-enforcing my irrational beliefs.
<jam> similarly the current discussion about why URLs are all Unicode strings in python 3
<james_w> malformed files are what you get for Christmas if you are on santa's naughty list
<jam> though from what lifeless has convinced me, you're not supposed to touch anything that you don't control
<lifeless> right
<lifeless> there is a large amount of close your eyes and ignore the world involved in browser address/location bars
<lifeless> and if you read that thread, to see the references to single urls that go
<lifeless> host/encodingA/encodingB
<lifeless> and then ask yourself how a user is possibly meant to create-guess a url for that server ;)
<rbriggsatuiowa> is it bad form to call the cmd_* classes from another python script?
<lifeless> rbriggsatuiowa: not at all, though I'd recommend using our factory facilities rather than constructing the objects directly.
<lifeless> e.g. bzrlib.commands.get_cmd_object('foo')
<rbriggsatuiowa> lifeless: thanks - also, when I try and merge one branch into another - the files show up - but the merge history does not (it does when I run bzr merge manually) # I'm passing cmd_merge().run(location=merging_location)
<rbriggsatuiowa> lifeless: (currently refactoring to use command factory)
<lifeless> rbriggsatuiowa: check bzr status
<lifeless> rbriggsatuiowa: I bet you haven't committed after the merge ;)
<rbriggsatuiowa> lifeless: reverting and trying with factory
<lifeless> rbriggsatuiowa: some commands override run_argv_aliases, but not all that many
<lifeless> rbriggsatuiowa: the factory change won't fix the issue, its merely to let you get plugin enhanced command objects and so on
<rbriggsatuiowa> lifeless: could you help me with this?  the merge history doesn't show up and the lockfile stays locked (if I run this manually it behaves normally)
<rbriggsatuiowa> lifeless: https://gist.github.com/d0ecf3eb46b7fbec71e0
<lifeless> 'lockfile' ?
<lifeless> oh right
<lifeless> you really want to be calling run_argv_aliases
<lifeless> as currently setup bzr command objects 'run' method is only really public if you are implementing a whole UI environment
<lifeless> you seem to just want to reuse the command as is, so you should reuse much or all of the UI environment too
<lifeless> what bzrlib version are you iusing?
<lifeless> rbriggsatuiowa: ^
<rbriggsatuiowa> 2.1.1 (I run apt off of the ppa)
<lifeless> righto
<lifeless> so I think I know what is happening
<lifeless> just chekcing
<lifeless> right
<lifeless> cmd_merge uses cleanups
<lifeless> in 2.1.x the run() method is not safe to call because only higher levels in the call stack ensure cleanups are run
<lifeless> so call run_argv_aliases
<lifeless> which is a little less python
<lifeless> and it will work
<lifeless> or grab 2.2b3
<rbriggsatuiowa> lifeless: trying it out
<mgz> lifeless: you've approved lp:~jspashett/bzr/missing_win32api_for_test but shouldn't it use Gordan's ExcutableRequired or whatever it was called instead?
<lifeless> mgz: it may want to use that as well
<lifeless> mgz: but his specific issue is his python doesn't have the win32api module
<rbriggsatuiowa> lifeless: bzrlib.commands.get_cmd_object('merge').run_argv_aliases([merging_location]) # worked - thanks a bunch
<mgz> ah, so it actually does require pywin32?
<mgz> in which case, ignore me, it's fine.
<lifeless> so he says, and my general thought on $notmyplatform things is - if they say it works and it looks plausible, land and fix later if needed.
<mgz> yup, it's correct.
<lifeless> thank you
<mgz> the actual function it's testing is horrible, but hey.
<TresEquis> mgz:  after all, where would we be without horrible code ;)
<lifeless> hahaha
<lifeless> TresEquis: a land of shinging light
<lifeless> rbriggsatuiowa: excellent
<mgz> re: his other branch, it's landable.
<mgz> I take Alexander's +1 as meaning Approve as well
<mgz> it's just a big confusing merge proposal discussion with lots of different threads of conversation going on
<lifeless> ok
<lifeless> has he pulled your stuff in ?
<lifeless> if not
<lifeless> can you please:
<mgz> he has
<lifeless> ok cool
<mgz> it's a little confusing as launchpad somehow has it listed above my comment
<lifeless> please file a bug
<mgz> perhaps because my commit timestamps predate the comment and it's not a merge?
<mgz> which is arguably correct
<lifeless> well
<lifeless> a timeline has a context
<lifeless> 'when it becomes visible in the context' is better than 'when it was created but still not visible'
<mgz> right, which would be "when did launchpad get this branch" I guess, rather than when the commit happened
<lifeless> embugginate!
<lifeless> mgz: right
<lifeless> in fact,
<lifeless> when did this branch, which is proposed, get this commit on its mainline
<lifeless> mgz: please try toggling https://code.edge.launchpad.net/~jspashett/bzr/587868_args_handling_cant_debug/+merge/28129 to approved
<mgz> I have no means of doing so.
<lifeless> mgz: didn't we give you pqm access ?
<mgz> oh, it can be done via pqm? I've not tried that.
<lifeless> no
<lifeless> separate related question
<lifeless> did we give you pqm access?
<lifeless> I thought we did
<mgz> yup, I have an open tab somewhere with john's pqm plugin that I mean to get round to working out
<lifeless> ignore that for a sec
<lifeless> please visit this page https://edge.launchpad.net/~bzr-core
<lifeless> (ignore the name, its misleading)
<lifeless> it will say somewhere near the middle
<lifeless> 'are a member' or 'are not a member'
<mgz> ah, yeah, I'm not member of any teams on launchpad
<lifeless> are you willing to be ?
<lifeless> joining either ~bzr (bzr and all plugins) or ~bzr-core (just bzr itself) will grant review control
<mgz> do I get a sticker?
<lifeless> which you have at the social level
<lifeless> heh :) - you got the tshirt instead
<mgz> yeah, I can join one of these, last time we looked at it there wasn't an obvious way
<mgz> but I now see a join button, so was perhaps just being blind before
<lifeless> mgz: no
<lifeless> tell me which one you'd like to join
<lifeless> core+plugins, or just core
<mgz> I've just hit join for bzr-core
<lifeless> the ~bzr team got lots of folk that weren't really interested in teh community, more just wanting help/cds/fanboy at one point
<lifeless> so its set to restricted, which I think has a bad UI in LP
<lifeless> because you can't *apply*, you have to be *added*
<lifeless> and there isn't even a 'but please sir' mechanism, which the slightly more open 'moderated' setting has.
<mgz> presumably you now have an approve button somewhere?
<lifeless> mgz: so, just-core is what you want ?
<lifeless> mgz: in moderated mode, yes.
<mgz> yup, core will do as I've only looked at a few bits of qbzr and so on
<lifeless> ok
<lifeless> I could add you to ~bzr, but martin is the owner of ~bzr-core and neither I nor a group I'm in are administrators in that team
<lifeless> so
<lifeless> when poolie gets up, you'll get review approval facilities
<mgz> cool.
<lifeless> have you looked at hydrazine ?
<lifeless> it needs the launchpad API stuff, but thats pure python and should be ok on windows.
<mgz> notyet, alexander expressed some fear of it.
<lifeless> Famous Last Words.
<lifeless> mgz: well the next step in getting you fully enabled here... is getting you running hydrazine
<lifeless> pqm-submit is a terrible weapon from a bygone age
<mgz> oh, the launchpad api things I tried to use when we were doing that stop-using-edge-thing
<lifeless> yeah
<lifeless> mgz: as I read the diff
<mgz> and it nearly worked, one of the (many, ugh, setuptools) bits had a recent 2.4 compat thing I submitted a merge proposal thing for
<lifeless> s is now unused ?
<lifeless> mgz: also, typo, line 106
<mgz> it's just an iterator, that we listify.
<lifeless> spit the command line
<mgz> yeah, the comments are a little suboptimal, and there are some existing and new >80 char lines
<mgz> roasting the commandline on a spit is about right though.
<lifeless> ok
<lifeless> so where I was going with all this
<lifeless> hydrazine has
<lifeless> $python feed-pqm bzr
<lifeless> it will, once sufficiently stabbed, land stuff and its the interface I'll be fixing up to use LP APIs for merge control in the future
<lifeless> I think it would be great if you had it working
<lifeless> and this patch seemed like a perfect worked-example
<lifeless> particularly as there are a few more quirks to get out
<lifeless> if its not too late, and you're interested in doing that, I'd love to work through it with you
<mgz> okay, so, you're kindly offering to walk me through landing this?
<mgz> letsdoit
<lifeless> yes
<lifeless> so firstly, lets assume this is perfect as is
<lifeless> to do the simple path through
<lifeless> (you can after we get it going land a trivial tidy up :))
<lifeless> I've 'approved' the patch
<lifeless> in principle you just do
<lifeless> python feed-pqm bzr
<lifeless> it should be the first patch up, so you'd hit e\n
<lifeless> and away it goes
<mgz> just reinstalling and patching the launchpadlib stuff
<mgz> okay, feed-pqm launches browser window pointing at edge
<lifeless> right
<lifeless> this is the login step
<lifeless> oauth style
<lifeless> feed-pqm will need to change any data
<mgz> anything, or non-private?
<lifeless> the permissions are very broad, but you get to see the code ;P
<lifeless> anything
<lifeless> if you were to have a private branch
<lifeless> you would want to be able to land it.
<lifeless> A major security fix might get that treatment, for instance.
<mgz> gotcha.
<mgz> where's it store the token locally?
<lifeless> it uses the freedesktop config path, or something
<lifeless> [god knows]
<mgz> I shall hunt later.
<mgz> Okay, so first up is the win32api dependency addition
<lifeless> ~/.local or .cache I suspect
<lifeless> right
<lifeless> now see the last comment
<mgz> recent comments is blank here, should it have something listed?
<lifeless> hmm
<mgz> ah, the next one lists the last comment
<lifeless> odd
<mgz> I think you marked that first one approved without actually adding an approval comment
<lifeless>  thought I sent it to pqm
<mgz> and it doesn't show the review submitter's comment
<lifeless> looking
<lifeless> oh right
<lifeless> it didn't have a commit message
<mgz> ah, it should say if you've already sent it/
<lifeless> so I set one and while it thought context switched.
<lifeless> anyhow
<lifeless> lets stay on track
<lifeless> you've used n and found the argv one right?
<mgz> yup.
<lifeless> e\n
<lifeless> (thats e-mail)
<mgz> complains about commit message
<lifeless> m\n
<mgz> my least favourite part ;)
<lifeless> feed-pqm will automatically add '(you)message(merge proposer)' when 'e' is done.
<lifeless> mgz: and thus why I ask submitters to set one :)
<mgz> so, I get a http 401 there, which I guess is expected
<lifeless> permission denied ?
<lifeless> you did login though
<lifeless> or were you not logged into edge at the time?
<mgz> right, but I'm not a member of bzr-core yet
<lifeless> oh
<lifeless> yeah
<lifeless> so - what did you put in
<mgz> for the commit message?
<mgz> "Allow use of Python arguments preceding bzr script in Windows command lines"
<lifeless> yes
<lifeless> ok I've set that for you
<mgz> okay, going back in
<mgz> okay, looking good, there an option to tell feed-pqm where to find gpg?
<mgz> (I'll just modify my path for now)
<lifeless> it uses the bzr config
<lifeless> so your ~.bazaar/bazaar.conf
<lifeless> [DEFAULT]
<mgz> and I need to set up gmail for smtp too.
<lifeless> gpg_signing_command = pathtogpg
<lifeless> right
<lifeless> I dunno how to do that
<mgz> I think I saw instructions on this for John's plugin, where's that tab...
<lifeless> mail_client = mapi
<lifeless> perhaps
<mgz> smtp_server = host:port
<mgz> smtp_username = smtp_password =
<lifeless> sorry, thats the default
<mgz> from there
<lifeless> mail_client=editor
<lifeless> too, perhaps
<lifeless> ENOTSURE
<mgz> willtry
<mgz> meh, thought I could get it to prompt me for email password, but get:
<mgz> NotImplementedError: <bound method SilentUIFactory.get_password of <bzrlib.ui.SilentUIFactory object at 0x01EDF5B0>>
<mgz> that might be nice to fix at some point
<lifeless> ha ha ha
<lifeless> yes
<lifeless> uhm
<lifeless> feed-pqm
<lifeless> should call bzrlib.initialize()
<lifeless> if it exists
<mgz> scary, it says "Sent!"
<lifeless> http://pqm.bazaar-vcs.org/
<lifeless> congrats
<lifeless> you might like to write it up for alexander and gordon and so on
<lifeless> or not - I don't mind :)
<mgz> yeah, wasn't nearly as bad as Alexander was fearing I think
<lifeless> while you're there
<lifeless> please hit e on the win32lib thingy
<mgz> donedonedone
<lifeless> now, the responsibility
<lifeless> its not a mechanical is-approved-queue
<lifeless> because needs fixing votes etc require verification
<lifeless> its just meant to make the mechanical part of 'send it in' easier
<mgz> is there anything particular that needs doing if pqm rejects it at the testing stage?
<lifeless> depends on how enthusiastic you are
<lifeless> heres what I do
<lifeless> if its my code, I dig deep, figure it out, fix etc.
<mgz> I take it I'd get email with the failures (now you've fixed that), and should write that in the merge proposal for feedback?
<lifeless> if its someelses code that I've committed to landing, same.
<lifeless> otherwise I'll grab the error from the mail and put it in the MP without the skips
<lifeless> and perhaps attach the stdout/stderr gz files if they look like there is going to be additional, useful data.
<lifeless> however they can't be attached because MP's are not 'things with attachments'
<lifeless> so instead you'd need to put them on a related bug or something
<lifeless> it also depends on how shallow it is
<lifeless> NEWS files conflicts I will generally JFDI
<lifeless> now - see my thread on bazaar@ about continuing work on someone elses proposal for some related stuff
<mgz> yeah, I nearly commented on your discussion with poolie the other evening but netsplit at the wrong moment
<lifeless> we took it to phone
<lifeless> irc wasn't quite getting the right intonation
<mgz> the superseeded workaround mentioned in the email thread seems like a reasonable workaround
<lifeless> yeah
<mgz> what I've done in the past it push up a copy of the branch with my changes and invite a pull
<lifeless> bzr lp-propose can set it all up for you
<lifeless> I think thats good too
<lifeless> case by case
<mgz> which is a softly-softly option for less straightforward changes
<mgz> ha, you've put up a py3 merge proposal!
<mgz> ...doesn't *quite* deliver on the name :)
<lifeless> mgz: softly softly catchee dragon
<cbz> monkey
<lifeless> cbz: not in this case, have you see python 3 ?
<cbz> heh
<fullermd> Dragons are easy to catch.  First, you smear yourself with ketchup...   I'll let somebody else pick up the planning from here.
<mgz> it's amusing how the email module thread has ballooned out into all kinds of doubt about the whole approach
<lifeless> well
<lifeless> folk have been skeptical from the start
<lifeless> as they were about .net's stance which AIUI is similar
<lifeless> I think part of the problem is that stringlike API's become less powerful when you make them more typed... and many web-sensitive things in python are expressed as pithy stringlike API's rather than (shock, horror) objects.
<lifeless> urlparse is terrible, for instance.
<mgz> yeah, as is like, all of wsgi
<lifeless> that reminds me
<lifeless> I saw a tweet about a comet ready wsgi server this morning
<lifeless> I must follow up on thsat
<lifeless> see how much evil its doing
<lifeless> mgz: where are we at in testtools
<mgz> well, there are probably still some things to debate, but if we're mostly happy with the current, could try landing tonight.
<lifeless> sure
<lifeless> gimme 10 minutes
<mgz> suggestion: I fix the problem the patch for Python 2.5.2 introduced, then merge trunk, resolve the _StringException bits, add NEWS, and we give it a shot?
<mgz> should take me about ten minutes to do the bits my side.
<lifeless> ok
<lifeless> ping me when ready
<mgz> okay, just writing NEWS now
<mgz> lifeless: pushed.
<mgz> I have kept your UTF-8 changes to _StringException, but haven't done anything about making piping to file output UTF-8 yet.
<lifeless> http://furiousfanboys.com/2010/04/luke-i-will-not-be-your-father/
<lifeless> totally offtopic, but lolol
<lifeless> bzr+ssh://bazaar.launchpad.net/~gz/testtools/unicode_tracebacks_501166/ still ?
<mgz> yup.
<mgz> I prefer the _StringException version with a type check in __init__ rather than in both __str__ and __unicode__ but you said subunit needs some changes there
<lifeless> subunit can be changed easily.
<mgz> let's do that now-ish as well then, and check it all works together
<lifeless> sure
<lifeless> first thing, does it work for me
<lifeless> make check PYTHON=python3.1 -> boom
<lifeless> hmm trunk goes boom too.
<lifeless> 4 vs 6
<lifeless> whats the diff
<mgz> dammit!
<lifeless> testtools.tests.test_testtools.TestDetailsProvided.test_multiple_addDetails_from_Mismatch
<mgz> I was checking like, six different pythons every step, and still manged to break py3k without noticing
<lifeless> testtools.tests.test_testtools.TestDetailsProvided.test_addDetails_with_same_name_as_key_from_get_details
<lifeless> testtools.tests.test_testtools.TestDetailsProvided.test_addDetails_from_Mismatch
<mgz> yeah, it's okay, I see it too.
<lifeless> testtools.tests.test_testtools.TestAssertions.test_assertThat_mismatch_raises_description
<lifeless> thats trunk
<lifeless> SEP (me)
<mgz> yeah, but I don't know how I missed testing py3k after the merge
<lifeless> testtools.tests.test_testresult.TestNonAsciiResultsWithUnittest.test_assertion_text_shift_jis
<lifeless> testtools.tests.test_testresult.TestNonAsciiResults.test_assertion_text_shift_jis
<lifeless> are the new ones for me
<lifeless> I'll pastebin the lot as thats easiest
<mgz> okay, that must be my fault, was sure I'd fixed it
<lifeless> http://pastebin.com/19SPiZEz
<lifeless> and I
<lifeless> will look at trunk now
<lifeless> actually, will finish my 'python2to3 is not sensible' mail first
<mgz> okay, my dumb, I understand that.
<mgz> ^I was going to ask that question in your thread, I really don't like the source compatible approach
<mgz> it might be the least worst, dunno, but I didn't have fun doing this with testtools
#bzr 2010-06-23
<lifeless> I'd like a python2to2and3
<lifeless> jam: ^
<lifeless> mgz: ok, I'm looking at trunk failures now
<lifeless> mgz: while you're fixing shiftjis
<lifeless> mgz: care to being in that __init__ guard I sketched, too ?
<mgz> yup, will do. want the straight up must-be-unicode version?
<lifeless> yeah
<jam> lifeless: /me is long overdue for leaving
<jam> Maybe i'll chat later
<lifeless> I think that that is what my analysis said would wokr
<lifeless> jam: ok, catch you around
<lifeless> oh, and don't get me started on what PQM is going to need to test 2.4 *and* 3
<lifeless> shudder
<lifeless> babune ftw
<lifeless> ok, the detailsProvided stuff is james_w's patch
<james_w> not py3k compatible?
<lifeless> james_w: nope, and I didn't even think to try, it looked like such a no-brainer
<lifeless> james_w: have a look at the pastebin, ignore the two shiftjis failures
<james_w> lifeless: did you see my testr MP? (I'm not sure whether MPs actually reach the people I want them to)
<lifeless> james_w: yes; uhm
<lifeless> I was tired
<lifeless> so, I don't want to block you; but there is a bug open about that command already
<james_w> np, just wanted to know it was in a queue somewhere
<lifeless> I'd like to fix both
<james_w> the bug opened by me?
<lifeless> the bug thats open is that default_test_id_list is handled oddl
<lifeless> by me
<lifeless> I want to be able to say, in .testr.conf for loom
<lifeless> I want to be able to describe the default tests to run
<lifeless> and IDOPTION to expand default_test_id_list via the normal IDOPTION expansion
<lifeless> or somethin
<lifeless> anyhow, that use case and yours are very tightly coupled
<james_w> ok
<lifeless> and I think your simply-bail approach conflicts with what I want which is kindof to filter more tightly
<lifeless> but still keep the original filter
<lifeless> actually, thats it - in english
<james_w> bug 531666 ?
<ubot5> Launchpad bug 531666 in Testrepository "IDOPTION needs exploring (affected: 1, heat: 2)" [Medium,Triaged] https://launchpad.net/bugs/531666
<lifeless> I want to be able to say, for a bzr plugin 'this is how you trigger the default set of tests for the plugin', 'this is how you run a human reduced set for the plugin', 'this is how you run a precise list' and (probably) 'this is how you turn off testr managing the list of tests'
<james_w> makes sense
<lifeless> -- foo bar baz
<lifeless> is already supported I think
<lifeless> which isn't enough to turn off supplied by default parameters.
<lifeless> anyhow - thats where I'm at, if you wanted to bring all that together that would be awesome
<lifeless> if not
<lifeless> I'll happily take something that fits clearly into that space, which I don't think your current patch does
<lifeless> james_w: ah iteritems
<mgz> lifeless: test fix and __init__ method pushed
<james_w> it's probably near impossible to come up with good names for the options in the config
<james_w> lifeless: it's gone in 3?
<lifeless> james_w: yes
<james_w> those tests have very poor failure modes, I found that when I was writing the code
<lifeless> james_w: just use items() in 2.x code everywhere
<lifeless> yeah
<lifeless> I noticed ;)
<james_w> natural given what they are doing, but...
<lifeless> ewll
<lifeless> can be improved
<james_w> ok, want an MP for that, or can you just JFDI, as I'm about to head to bed
<lifeless> some of the hook stuff added snice the core was written could make bits better already
<lifeless> james_w: for 3.1? JFDI'd already
<james_w> thanks
<lifeless> no prob
<lifeless> I should have caught that at merge time - mea culpa
<lifeless> sleep well
<james_w> thanks
<james_w> night all
<mgz> are well all passing happy now?
<james_w> lifeless: for testr, I don't get where my patch is different to the behaviour it has now for $IDOPTION. I think this is because I've never really understood the options for .testr.conf and just cargo-culted. I think it's a problem area as many people will struggle to understand it, but I don't have good ideas for fixing it right now.
<lifeless> james_w: I will look more closely; probably while at pycon I'll get some personal time
<lifeless> james_w: I have a backlog at the moment - subunit patches, this unicode stuff in testtools - so not obviously right-or-wrong stuff gets queued a little
<lifeless> mgz: yes, clean bill of health on 3.x
<lifeless> and on 2
<mkanat> jam: I'm on now, if you wanted to debug the meliae stuff.
<lifeless> mgz: btw testtools also sorts its NEWS file within sections
<mgz> ah, oh, hadn't noticed
<mgz> everything was beginning with T
<lifeless> and P and J :P
<mgz> and... J is before P!
<mgz> so it's already mis-sorted
<lifeless> yes, but thats me failing.
<lifeless> :>
<lifeless> mgz: so, you've changed the copyright on a file
<lifeless> mgz: which is ok - you're contributing this as MIT ?
<mgz> I did, it seems like the copyright assignment thing isn't happening to me, and the year needed updating anyway
<mgz> but I certainly submit as-per the licence
<lifeless> great
<lifeless> __all__ should be sorted too, just like imports
<lifeless> (I'm doing this as I note things)
<mgz> (with minor worries about Python licence derivation)
<lifeless> bah, it is, diff confused me
<mgz> ah, there might be one import line that's missorted I spotted the other day and forgot to fix
<lifeless> is ascii(foo) safe on arbitrart objects
<mgz> seems to be
<mgz> >>> ascii(object())
<mgz> '<object object at 0x00C39298>'
<lifeless> that is scary
<lifeless> scary scary scary
<lifeless> tell me about this hunk
<lifeless>      def _u(s):
<lifeless> -        return unicode(s, "latin-1")
<lifeless> +        """Use _u('\u1234') over u'\u1234' to avoid Python 3 syntax error"""
<lifeless> +        return (s.replace("\\", "\\\\").replace("\\\\u", "\\u")
<lifeless> +            .replace("\\\\U", "\\U").decode("unicode-escape"))
<mgz> ehehe, yeah
<mgz> this is where just using u"" would be soooo nice
<mgz> I reason that that code is correct as follows
<mgz> input is an arbitrary bytestring
<mgz> we double escape the escape character
<mgz> we then roll that back for the two kinds of unicode escape
<mgz> so, we now have a string with no escape sequences, except unicode ones
<lifeless> so this is the 'string is unicode==False' case
<lifeless> perhaps the docstring means 'to avoid Python 2 syntax errors' ?
<mgz> yeah, and it's only for testing-testing code
<mgz> no, the problem is you can't just use u"\u1234" in Python 3
<mgz> so the only 2+3 source compatible way to use unicode is... never to use unicode escapes in literals
<lifeless> your example seems to be a noop
<lifeless> which leave me horribly confused.
<mgz> _u('\u1234') -> u'\u1234' (2) or -> '\u1234' (3)
<mgz> it is horribly confusing, which I blame on the porting strategy
<lifeless> so the old _u didn't honour unicode escapes
<lifeless> it required a latin-1 [the file encoding] encoded unicode string
<mgz> nope, it basically didn't work for anything but the bottom 256 codepoints
<mgz> right.
<lifeless> so your doc string really means
<lifeless> 'manually handle unicode escapes provided in the string because we cannot use the 'u' prefix on python 3.
<lifeless> '
<mgz> It's test-instructional, "do this or you break Python 3"
<mgz> yeah.
<lifeless> well, we need _u() out side of tests
<lifeless> so it I think its worth having it be _good_
<mgz> well, it's not currently used outside tests, but if you can word the hack better go for it.
<mgz> most of testtools can rely on Python 2 upcasting ascii str to unicode
<mgz> and never use unicode literals
<lifeless>      def _u(s):
<lifeless> -        return unicode(s, "latin-1")
<lifeless> +        """Implement a function version of the 'u' prefix.
<lifeless> +
<lifeless> +        This is needed becayse the u prefix isn't usable in python3.
<lifeless> +
<lifeless> +        To migrate code that was written as u'\u1234' in Python 2 to 2+3 change
<lifeless> +        it to be _u('\u1234'). The Python 3 interpreter will decode it
<lifeless> +        appropriately and the no-op _u for Python 3 lets it through, in Python
<lifeless> +        2 we then call unicode-escape in the _u function.
<lifeless> +        """
<lifeless> +        # The double replace mangling going on prepares the string for
<lifeless> +        # unicode-escape - \foo is preserved, \u and \U are decoded.
<lifeless> +        return (s.replace("\\", "\\\\").replace("\\\\u", "\\u")
<lifeless> +            .replace("\\\\U", "\\U").decode("unicode-escape"))
<lifeless> mgz: we can't rely on upcasting, because it can go so horribly wrong.
<lifeless> I'm going to make that a __literal and use it for _u in both 2 and 3
<mgz> hehe, yeah, that docstring covers it. one of the reasons I didn't write it initally was because it would end up five times bigger than the code
<mgz> nitpick: you don't need 'Implement' at the start
<lifeless> true
<mgz> anyway, this is a poster child for where 2to3 works better than source-compat (there are cases in the reverse as well)
<lifeless> pep 257 needs a refresh for3
<mgz> XXX Mention docstrings of 2.2 properties <- if that's not done yet, might be a while coming
<lifeless> yeah
<lifeless> gutworth probably should see this changed version
<lifeless> what about
<lifeless> +        # GZ 2010-06-16: Python 3 StringIO ends up here, but probably needs
<lifeless> +        #                different handling as it doesn't want bytestrings
<mgz> no code is actually passing a StringIO object into that function (unless some testtools user has replaced sys.stdout with one prior to using the test runner), so it's a drawback, but not an exercised one
<lifeless> and I don't quite understand what the sys.version_info block that makes a new stream of the same class, actually does.
<lifeless> mgz: runner or result ?
<mgz> TestToolsTestRunner
<lifeless> mgz: so it doesn't matter right now, but when pqm does to 3
<lifeless> it uses subunit
<lifeless> which uses testtools
<lifeless> and it formats into a stringio for handing off to email
<lifeless> :>
<lifeless> Will you follow up later on this ?
<mgz> the new stream of the same class thing is in lieu of just doing `stream.errors = "replace"`
<mgz> ^yup, there are still some things to poke here, I've got some expectedfailures and a skipped test
<mgz> generally, # GZ comments are things that I intend to delete when I fix them
<lifeless> right
<lifeless> I was checking you were planning on continuing to scratch
<lifeless> that this was a stepping stone not a result
<lifeless> this worries me
<lifeless> +def _exception_to_text(evalue):
<lifeless> ,,,
<lifeless> +    except:
<lifeless> +        pass
<lifeless> why not be a little more precise ?
<mgz> it's bad, but it's what traceback._some_str does
<mgz> I have a shelve thingy which adds an `isbaseexception` function and reraises those
<mgz> but behaviour on Python 3 will still be, KeyboardInterrupt during Exception.__str__? eat it.
<lifeless>         list = ['Traceback (most recent call last):\n']
<lifeless> ->
<lifeless>         list = [_u('Traceback (most recent call last):\n')]
<mgz> gets upcast safely, it's fine.
<lifeless> I have two reasons for doing that
<lifeless> firstly, because if there *is* a bug that lets things go wrong, it won't help as it is
<lifeless> secondly, I want to be able to look at a string and go 'its not a function parameter to control behaviour' -> must have _b or _u
<lifeless> mgz: also, naughty
<lifeless> bytes is a classname
<mgz> ha. habit, I often use that.
<mgz> at least it wasn't added as a keyword in 3
<lifeless> me too, I'm trying to fix myself
<lifeless> list = [] is a bit weird too
<mgz> I do see the value in clearly documenting what should be a unicode object, but as we've just seen _u is not overhead-free
<lifeless> performance wise ?
<mgz> ^blame the traceback module, I'd love to have a less-weird way to write out all the logic in this function
<lifeless> oh, and 2 lines of VWS between functions please
<lifeless> PEP8
<mgz> wasn't that just classes?
<lifeless> top level 'things'
<lifeless> Separate top-level function and class definitions with two blank lines.
<lifeless> methods are single lines
<lifeless> look under "Blank Lines' in the pep
<mgz> so it does.
<mgz> I've been doing one line between related-but-not-class-method functions
<lifeless> its ok
<lifeless> I'm not terribly concerned, fixing where I notice, and signalling back to get better input in future ;)
<lifeless> I'm not convinced that:
<lifeless> +    else:
<lifeless> +        # For Python 2, need to decode components of traceback according to
<lifeless> ..
<lifeless> +        del __F, __M, __f, __g, __m
<lifeless> is shorter than copying the method.
<mgz> it's not.
<mgz> that import sorting thing I mentioned, testtools/content.py - changed TestResult to import from testtools not unittest, but didn't then sort it right
<lifeless> done
<mgz> ^one of the reasons I didn't copy the method was though we can doing MIT->Python to put testtools things in core, I was unsure how far we could do Python->MIT
<lifeless> it looks like its *just* shorter
<lifeless> than 2.7
<lifeless> oh, fairly safely I should think
<lifeless> I'll let it in
<mgz> well, I doubt anyone will actually care, but I didn't want to create problems
<lifeless> jml: ^ if you go blind, blame me and w'ell pull it out
<lifeless> mgz: very considerate.
<lifeless> (seriously)
<lifeless> uhm
<lifeless> your 3.1 _StringException has no __str__ now
<lifeless> is that deliberate?
<mgz> yup.
<lifeless> *blink* why ?
<mgz> the Exception.__str__ method does the right thing.
<mgz> unless we *intend* to pass extra arguments then ignore them
<lifeless> no, thats fine, citation needed ;)
<lifeless> I'll add
<lifeless> more style things
<lifeless> class foo
<lifeless> """docs"""
<lifeless> \n
<lifeless> def stuff
<mgz> where's that?
<lifeless> test_compat
<lifeless> should _disabled_test_string_exception be a skip ?
<mgz> ah yes, whoopsie.
<mgz> it's fine as a no-run, I intend to fix... whatever bug number that was... soonish
<lifeless> its a shame we need temp files
<lifeless> rather than just calling into compile()
<lifeless> I guess there are dragons there
<lifeless> but I can live with the slower test suite
<lifeless> landed
<mgz> temp files are a clean-ish way of doing this, and not too much of a slowdown
<lifeless> i absolute times, no, but relative it was shocking :)
<lifeless> now
<lifeless> -> #subunit
<mgz> heh, yes, perhaps I'm too used to bzr tests building whole working trees each test
<lifeless> also undesirable
<lifeless> but a little harder to fix comprehensively
<mgz> I'll add looking at making some of them just use compile to my list
<lifeless> idle priority
<lifeless> its not a functional issue
<mgz> the ones where it most needs a directory system are the filesystem encoding ones and now reading back for syntax errors, the rest might be avoidable without hurting coverage
<poolie> hi all
<mgz> hey poolie.
<lifeless> morning poolie
<poolie> hi lifeless
<lifeless> I think I started one of those long threads we dread this morning :) - sorry !  [python 3]
<poolie> mm, i've seen worse :)
<lifeless> its only just beginning :>
<mgz> it doesn't help that you started everyone off confused about what the goal was
<poolie> i actually looked at running with -3 a while ago when i added http://doc.bazaar.canonical.com/bzr.dev/developers/code-style.html#python-versions to the docs
<lifeless> mgz: if you're going to accidentally start a long confused thread, do it well!
<mgz> had you put "I think source-compatible is the way to go, not 2to3, because..." at the top, would have saved six or so messages
<lifeless> ah, thats where the python version is documented
<lifeless> I filed a bug that is mostly-fixed already; neat.
<lifeless> however we don't expose that to our users yet, I don't think.
<lifeless> mgz: well, hindsight
<mgz> indeed.
<mgz> blast, no more pending pqm patches with commit messages, can't test feed-pqm change lets me enter my email password on the terminal
<lifeless> mgz: pastebinit ?
<mgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<mgz> http://paste.ubuntu.com/453676/
<mgz> something along those lines?
<lifeless> hah, cute
<lifeless> yes
<jam> mgz: except you now also need to catch the returned object and call obj.__exit__()
<jam> hi lifeless
<lifeless> yea
<lifeless> per my mail to the list and the initialize docstring in trunk
<lifeless> poolie: I'm popping up to rangiora to drop stuff that needs to be looked after while we're in .au
<lifeless> poolie: I'll be 2-3mumble hours
<lifeless> poolie: if there is anything urgent, lets do it now, otherwise see you in a bit
<lifeless> mgz: you can play with ~lifeless/bzr/encoding-option/+merge/28126
<mgz> have to set a commit message on it?
<poolie> lifeless: ok np
<poolie> you could do some bug triage if you run out of patches
<mgz> okay, that seems to work.
<lifeless> poolie: sure thing, I wish I could do that via mail
<poolie> .. and you could if i finished the dkim thing and got it deployed?
<lifeless> poolie: I think its deeper than that
<lifeless> poolie: because I use google apps
<lifeless> not gmail per se
<poolie> oh and they don't sign it
<poolie> ok
<lifeless> so I need to also find out how to make them sign that
<poolie> you could gpg sign it
<lifeless> If I switch back to evo
<lifeless> using the google imap service
<lifeless> that will work
<lifeless> Or if I use firefox rather than chrome there is some magical gmail gpg extension I found but haven't used.
<lifeless> its all a bit of a mess
<lifeless> I have a deeper question
<lifeless> 'why do we care so much'
<lifeless> whats the risk
<lifeless> for setting a bit on an email
<lifeless> or the approved flag on an MP
<lifeless> the 'queue to PQM' one I would worry more
<lifeless> and 'do stuff with builders'
<poolie> i agree
<lifeless> if someone forges something
<lifeless> rollback the change - make *that* a secured, but possible operation.
<lifeless> and blacklist em
<poolie> adding pointless comments to bugs is roughly as disruptive as changing their state
<lifeless> *possibly* whitelist google/yahoo/msn email providers as being rasonably authoritative etc
<lifeless> anyhow, must go, and we're in complete agreement here I think ;)
<lifeless> sorry, got sucked into replying
<lifeless> *now I go*
<poolie> mgz, thanks for the hydrazine patch
<mgz> getting it setup and working wasn't as bad as Alexander was fearing the other day
<mgz> ...I really should be getting to bed though ;)
<poolie> mgz if i'd done it i probably would have just required 2.2
<poolie> it's a pretty nerdy tool
 * fullermd blinks.
<fullermd> Monkeypatch the compiler to twist the syntax on older interpreter versions?!
<fullermd> Did I miss the decision to rewrite in Perl?   :p
<lifeless_> back
<lifeless> mmm deep winter - totally dark here, now
<poolie> thanks to russel for the light relief :)
<lifeless> ;)
<lifeless> I'm going to get fully packed, taxi or whatever organised
<lifeless> then do some bugs for us
<lifeless> it looks like the hotel wifi is a 3g dongle
<poolie> hm
<lifeless> so I might visit you as much as you are comfy with
<poolie> as in, they give you a dongle
<lifeless> yeah
<poolie> or they have one thing shared for everyone
<lifeless> they give out a dongle
<poolie> i've seen worse
<lifeless> indeed
<lifeless> spiv: I get asked about python3 2-3 times a month, in various fora
<spiv> lifeless: interesting!
<lifeless> I think so
<lifeless> Its usually phrased as 'when do you think bzr will be python 3 ready'
<lifeless> and I usually say 'some years'
<lifeless> and explain the issues
<poolie> is this more of a question about py3 or about bzr? :)
<lifeless> I don't know
<lifeless> its a good question to ask
<lifeless> some of the folk are python-heads
<poolie> mine, or theirs?
<spiv> Why do they care, I wonder?  Are they interested in using bzrlib?
<spiv> Or do they routinely ask which version gcc was used to compile their kernel too? ;)
<lifeless> poolie: I think its a good question to ask about whether they are asking because of python 3 interests, or bzr interests.
<poolie> mm
<poolie> it reminds me a bit of ipv6
<poolie> it will probably happen  faster
<lifeless> poolie: and see, its been a smashing success!
<poolie> but my impression was that most people were doing it for the sake of doing it
<lifeless> there are, I think, broadly three groups
<lifeless> of questions, not people
<lifeless> mmm
<lifeless> motivations for questions
<lifeless> one set turns up when talking about performance
<lifeless> for instance, allison randall was one of the recent folk to ask about bzr python3 readiness
<lifeless> she of pynie, python-3-on-parrot fame
<lifeless> and she was saying that pynie is something like 10 times faster
<poolie> ?
<lifeless> another set is the pure ecosystem stuff
<poolie> nm, i didn't think it was that much  faster
<lifeless> folk interested in python3 readiness in a general sense, or in what we think of python3 - 'oh, you can't use it yet? why not? ...'
<poolie> perhaps on some microbenchmark
<lifeless> poolie: perhaps; I don't know.
<lifeless> poolie: can't really assess though at the moment ;)
<lifeless> and thirdly, yes there are folk querying whether they can use python3 to do their thing, and know thye want bzrlib (or vice versa, have python3 investment, want to know if bzrlib works for them)
<vila> hi all
<poolie> hi there vila
<poolie> lifeless: for me the deadline is when ubuntu decides to make 3 the only option, or the default
<poolie> i don't think they will remove 2 for a while
<lifeless> poolie: I'm sure they won't
<poolie> but it might become the default soon
<lifeless> if barry has anything to do with it :)
<lifeless> poolie: so, I'm going to land https://code.edge.launchpad.net/~lifeless/bzr/encoding-option/+merge/28126 - my tweaked version; ok ? [asking as per your please-dont-land-my-stuff request]
<poolie> yes, thanks
<lifeless> https://code.edge.launchpad.net/bzr/+merges really wants an 'any unmerged-unrejected' status option
<lifeless> or a set of checkboxes rather than a dropdown
<lifeless> what do you think ?
 * poolie looks
 * poolie used bzr builddeb in mild anger today
<lifeless> mgz: when you get up; if you could comment on https://code.edge.launchpad.net/~lovesyao/bzr/windows-utf8/+merge/1806 - that might be nice. If the approach is sensible it seems a small effort to put it in the right place.
<lifeless> poolie: mentioning it here because the audience is slightly smaller than the list
<poolie> which bit?
<lifeless> poolie: one thing you seem to be not acking in the py3 thread, is the 'fact|rumour|well established myth' that 2to3 is really '2.6to3'
<poolie> oh ok
<lifeless> If you have acked that, I'm sorry for mentioning it.
<poolie> no, i didn't specifically
<poolie> the only specific cases turned out not to be true
<poolie> otoh i'm quite prepared to believe there are some cases that are problematic
<lifeless> ok, cool
<lifeless> I mention this because it affects the range of options in a very significant way
<lifeless> but, enough said
<lifeless> we're in broad agreement on initial steps
<poolie> in looking at the changes that 2to3 makes
<poolie> i can't see anything where the 2.x version is both relevant to us and not available in 2.4
<poolie> i may very well be wrong
<poolie> if it turns out not to work, we'll have to try something else
<lifeless> I filed this - https://bugs.edge.launchpad.net/launchpad-code/+bug/597431
<ubot5> Launchpad bug 597431 in Launchpad Bazaar Integration "cannot set/remove prerequisite branch after creation of merge proposal (dup-of: 596796)" [Undecided,New]
<ubot5> Launchpad bug 596796 in Launchpad Bazaar Integration "Can't add an pre-req branch to an existing MP (affected: 2, heat: 95)" [Undecided,Invalid]
<lifeless> which was apparently a dup of an invalid bug
<lifeless> which was filed separately
<lifeless> I'm a bit concerned that good intentions are leading to a pretty crufty UI
<lifeless> so I'm calling this to your attention to get another opinion
<lifeless> another case of the 'drop 2.5 and below' meme as related to py3 compat - I'm trying to hunt it down. http://lucumr.pocoo.org/2008/12/7/porting-to-python-3:-dos-and-donts
<poolie> mm there's another one "python3 is a ghetto"
<poolie> that the recommended way of using 2to3 is going to encourage people to stay there
<lifeless> Terry Reedy claims on http://www.pubbs.net/200901/python/13302-2to3-help.html that his understanding is that 2to3 can convert 2.5->3.0 but not in a way that keeps working on 2.5, but it can do that if you start with 2.6.
<lifeless> which seems confused.
<lifeless> anyway
<lifeless> enough of this
<lifeless> poolie: if you had a comment about that bug, that would be nice.
<poolie> that might be part of the confusion
<poolie> i don't intend to feed the output into py2.4
<poolie> heh
<poolie> that transcript is pretty funny
<lifeless> yeah
<lifeless> I was about to close it up top
<lifeless> but didn't
<spiv> I'd be amazed if people thought a "2to3" tool is intended to produce output suitable for 2!  But I could just be easily amazed :)
<poolie> > If you want to do a one-time conversion, then 2.5 to 3.0 is fine.
<poolie> that's my understanding too
<poolie> uh, considering he starts out by typing shell commands into the python prompt, the bar is pretty low
<poolie> what a time sync
<poolie> *sink
<lifeless> yes. I blame guido.
<poolie> actually i meant the profusion of misguided advice
<poolie> re https://code.edge.launchpad.net/~lovesyao/bzr/windows-utf8/+merge/1806
<poolie> i can believe there's a bug there
<poolie> the patch itself is a bit weird
<poolie> it would be nice to see some reproduction instructions
<lifeless> yeah
<lifeless> I hope mgz can shed light on it
<lifeless> as he has all the equipment
<lifeless> and I know his shiftjis encoding works :)
<poolie> re prerequisite branches
<poolie> there is a difference between "this builds on X" and "this supersedes X"
<poolie> i think prereqs are meant to express the first
<poolie> people might of course forget to add the prereq when they create the mp
<poolie> so it would be nice to be forgiving and let them change it later
<poolie> aaron seems to have the approach that mps should be locked after creation
<poolie> which seems a bit weird
<lifeless> right, adding a prereq for our use case discussed recently is a hack
<lifeless> -but-
<lifeless> you may realise that you have two things after the fact
<lifeless> and split them up
<lifeless> or as you say just make a mistake
<poolie> right
<lifeless> Aaron links through to a bug that says precisely that things should be locked, citing an unexplained security concern.
<poolie> istm that there is a rule "mps should not change drastically while they're under consideration"
<spiv> Well, I guess changing the pre-req should also change the diff to review.
<poolie> and "you should be clear what the vote applies to"
<lifeless> spiv: so does 'push' :>
<poolie> but the first should be enforced by humans more than code
<lifeless> spiv: and neither email the reviewers.
<poolie> and perhaps they should only be locked at the moment they're queued
<lifeless> poolie: yes, thats my stance
<spiv> Specifically, you could have a pre-req that hides some revisions that add bad code.
<spiv> But, you can do that already
<lifeless> poolie: thank you for the second opinion
<spiv> So I don't quite follow abentley's concern either.
<lifeless> spiv: right; in fact with a prereq you would say 'cannot queue, pre-req X is not approved to queue'
<spiv> Right.
<spiv> Hmm, so a scenario that is sort of plausible is initially having a pre-req on a MP that hides some bad revisions.  Then reviewers review the good parts and approve, then the MP is modified to remove the pre-req and stays apparently approved.
<spiv> But if you take a "once overall status is approved the MP is locked" approach then changing the pre-req like that would at worst knock it out of approved.
<lifeless> whats the weather like in sdyney atm
<lifeless> spiv: agreed
<spiv> Weather applet says 14C, rain showers ;)
<lifeless> so please do subscribe to the bug
<spiv> Which sounds about right to me.
<lifeless> and help me tease this apart
<poolie> accurate
<poolie> quite wet here
<lifeless> I'd hate for us to have a lot of machinery and complexity driving an odd user experience
<spiv> Well, I'll let abentley explain his concern first, rather than distract the bug itself with my speculation about his concern.
<lifeless> urls changing
<lifeless> etc
<lifeless> spiv: sure
<poolie> i suspect we need some use cases or something at a higher level than bugs
<poolie> changing user model is hard to negotiate through bugs
 * spiv makes sure he is subscribed to that bug
<vila> lifeless: loom test failure, reno 115 for loom and bzr.dev revno 5317: AttributeError: 'RemoteBranch' object has no attribute '_set_last_loom'
<lifeless> vila: what test ?
<vila> lifeless: paste coming just a sec
<vila> lifeless: http://paste.ubuntu.com/453808/
<vila> argh, forget the noise at the beginning, look at the last run
<lifeless> I see it too
<lifeless> is it new ?
<vila> lifeless: starting at line 65 with BZR_PLUGIN_PATH=-site BZR_PLUGINS_AT=loom@${HOME}/.bazaar/plugins/loom ./bzr selftest -s bt.per_branch -s bt.per_interbranch
<vila> bzr selftest: /home/vila/src/bzr/trunk/bzr
<lifeless> vila: happy to fix it tomorrow
<vila> lifeless: I encounter it yesterday but I thought I was out of date, so pretty new finally (after your patch for interbranch anyway)
<vila> lifeless: ok, want a bug ?
<lifeless> meh
<lifeless> no need
<vila> cool
<mgz> poolie: ha! press ganged to hydrazine. sorry I went to bed before I could do the push.
<vila> not ablocker but pretty annoying as working *in* a loom requires that the plugin is active or the test suite fails (for 'bzr version' tests or something that needs to use the current bzr src branch)
<mgz> poolie: I know it's a dev tool, but as my main bzr is still pre-2.2 and lifeless has only *just* changed the init mechanism again, I had motivation to cover all angles
<vila> lifeless: so whether or not I activate the plugin I can't get clean runs :-/
<poolie> mgz no problem at all
<poolie> if someone's using it with pre-2.2 i'm quite happy to add the support
<mgz> lifeless: I'd forgotten about that branch, but was thinking of that sort of approach just the other day when doing bzr-grep stuff for parthm
<mgz> doing colour for windows, and doing the kind of console size change detection that vila nearly killed us all with means you need a console handle
<mgz> so was going to find some time to investigate doing a custon ui object based on the win console stuff
<vila> mgz: thanks for the credit !!! :-P
<mgz> :D
<mgz> would be something like having a curses of TextUIFactory
<lifeless> vila: its important to me that loom work
<lifeless> vila: this week is pp week, so a different focus
<lifeless> vila: but that will be very shallow
<lifeless> vila: there will be a missing unwrap_branch or similar
<vila> lifeless: sure, no worries, I've got a workaround: http://paste.ubuntu.com/453812/
<vila> lifeless: may be not the right solution but unblocks me
<lifeless> vila: loom side of the fix pushed.
<lifeless> vila: you get to fix the bzr test :P
<vila> Ha ! I hadn't thought about that one: paramiko use threads internally, exceptions can occur there but *can't* be caught...
<poolie> wow, "Mojibake" leads into a world of distraction :)
<vila> lifeless: you rock ! ... let me look
<lifeless> poolie: distractapedia ?
<poolie> mm
<mgz> lifeless: so, the basic idea of the lovesyao/ branch seems reasonable to me, but the duplicating bits from ctypes.wintypes, not checking for errors, replacing std streams, and putting it in the bzr script are all wrong
<lifeless> mgz: ok, thats progress - thanks.
<mgz> for instance, apply that patch, then try and redirect bzr output to file, get nothing
<Mez> hmmles...
<Mez> bzr packaging is dodgy in lucid.
<Mez> I've installed under ubuntu-minimal - and it's throwing errors about missing _md5 in hashlib
<Mez> ah, actually, this is hardy :(
<lifeless> Mez: python-minimal isn't supported by anything - the package description says so :)
<poolie> mgz: i agree
<Mez> lifeless: *shrugs* then maybe ubuntu-minimal shouldnt use it.
<lifeless> I agree
<Mez> I can't even do-release-upgrade with it
<mgz> if there's another surge of interest about getting colour in core, I'll bump trying out a winconsole based ui factory up my list of fun things to try
<Mez> what's the correct package for python?
<lifeless> mgz: I was just trawling stale patches
<lifeless> Mez: python
<Mez> which is apparently already installed...
<mgz> it was a timely reminder, I punted on looking at it a few weeks back on bzr-grep
<lifeless> or python2.5 / python2.6 etc
<lifeless> Mez: thats interesting
<Mez> ImportError: no module named _md5
<jpds> 1/11
<vila> lifeless: meh, your fix is even more work for me than my workaround and looks suspicously hard to fix :-) So I think I'll stay with my workaround :)
<poolie> vila, re configs
<poolie> i think the thing to do is to lock for the whole transaction but not make it too long
<poolie> we might need to look into what bzr-svn is writing into those files
<vila> for context: bug #525571
<ubot5> Launchpad bug 525571 in Launchpad Bazaar Integration "No locking when updating files in ~/.bazaar (affected: 6, heat: 45)" [High,Triaged] https://launchpad.net/bugs/525571
<lifeless> vila: your workaround fails to write a loom file
<lifeless> vila: it creates corrupt looms and will really hurt you
<lifeless> vila: so I recommend you don't.
<lifeless> vila: to fix it, the bzr test just needs to relax a little.
<vila> lifeless: only if there are no threads right ?
<lifeless> vila: no, your workaround simply fails to write it.
<lifeless> vila: possibly it writes it in some cases, I'm tired.
<lifeless> vila: anyhow, definitely not mergable, because an empty loom is still meant to have a valid loom file.
<vila> lifeless: sure, but I can't afford a failing test suite *right now* and for a couple of hours, so I'll stick with that, I'll check the loom state very thoroughly meanwhile
<spiv> I think the right fix is to add a _ensure_real helper to the Inter object for _set_loom_state, like it does for other things already.
<spiv> Although that may trip some HPSS call count assertions.
<lifeless> spiv: thats what unwrap branch is and does
<spiv> lifeless: yeah, that's the one
<lifeless> spiv: and the failure vila references is the extra get
<spiv> Ah, good.  For some values of "good" :)
<lifeless> 'yes we have no bananas'
<poolie> heh, i just had a cute failure in lp code
<poolie> or bug, rather
<poolie>         self.assertTrue(principal.person.preferredemail.email, 'foo.bar@canonical.com')
<poolie> obvious once you see it
<poolie> not so great that it passes
<mgz> should be assertEqual?
<poolie> it should
<exarkun> bzr: ERROR: [Error 145] The directory is not empty: u'C:/Users/exarkun/twistedbot/windows7-64-py2.6-select/Twisted/.bzr/checkout/limbo/new-7/words'
<exarkun> When running "bzr checkout svn://...."
<spiv> exarkun: ooh, wacky
<spiv> exarkun: bug report, please :/
<spiv> exarkun: often problems with temporary files on Windows are related to virus scanners keeping files open at inconvenient moments, interfering with attempts to delete or even rename them... possibly that's involved here?
<exarkun> Maybe if there's something that comes with Windows 7, I don't know
<exarkun> I don't think there's anything extra installed
<spiv> (.bzr/checkout/limbo is a temporary directory for assembling files for the checkout)
<spiv> That's what I feared :/
<spiv> Make sure to include the traceback from the .bzr.log, hopefully it will provide an extra clue.
<exarkun> That would involve being able to get files off of a Windows machine... I have no idea how to do that.
<spiv> :(
<spiv> Perhaps add -Derror to the command line the build slave runs?
<spiv> That will cause bzr to always dump a traceback if it exits with an error code.\
<exarkun> Can't add arbitrary arguments to bzr command lines without modifying buildbot slave code
<spiv> vila: remember that paramiko bug?  https://code.edge.launchpad.net/~spiv/+archive/packaging-test
<spiv> exarkun: oh right, it's all software.  Everything is terrible :(
<spiv> vila: please install that on your lucid build slave
<spiv> vila: and undo whatever hack you did to hide the corresponding test failure
<vila> spiv: will look into it !
<vila> spiv: the hack was just to blacklist the test with -x :-)
<vila> spiv: so I can just add this ppa to my /etc/apt/sources.list right ?  Would a newer version packaged for lucid override that in due time ?
<spiv> vila: apt-add-repository ppa:spiv/packaging-test
<vila> yeah, better, it adds the key too right ?
<spiv> vila: a newer version in lucid should override it if I didn't screw up the version on my package, yes :)
<spiv> Right.
 * vila boots the slave
<vila> spiv: it gets flagged as not authenticated :-/
<vila> spiv: not a problem for me but you may want to investigate
<spiv> oh boo.
<maxb> spiv: Likely just Launchpad taking a bit of time to generate the key
<vila> spiv: test suite passing on lucid, test whitelisted again :) Well done
<spiv> vila: suite, I mean, sweet!  Thanks :)
<spiv> maxb: well, luckily I'm unlikely to care about it tonight
<maxb> spiv: It has fixed itself already
<spiv> maxb: so if the problem fixes itself by magic then that's great :)
<vila> spiv: if you're bored, on hadry, we know have repeated failure for http://babune.ladeuil.net:24842/job/selftest-hardy/lastFailedBuild/testReport/bzrlib.tests.test_sftp_transport/SSHVendorBadConnection/test_bad_connection_ssh/ :-P
<spiv> maxb: excellent :)
<vila> hardly hadry, most probably hardy
<spiv> vila: bored?  Unlikely :)
<vila> :-D
<spiv> vila: but in case *you* are... https://bugs.edge.launchpad.net/bzr/+bug/522637
<ubot5> Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 10, heat: 54)" [High,Confirmed]
<vila> spiv: I thought you were so happy to reproduce that one locally ?
<spiv> vila: I'm happy, but also haven't yet had the time to dig into it at all
<vila> but bored, me ? I wish :)
<rbriggsatuiowa> will a successful pull look the same as a merge + commit in the bzr history?
<spiv> rbriggsatuiowa: not quite
<spiv> merge + commit makes a new revision, with two parent revisions: your prev revision, the merged revision.
<spiv> Whereas with a successful pull your local branch is simply updated to have its latest revision be the same as the latest revision as you are pulling from.  No new revisions are created that didn't already exist.
<rbriggsatuiowa> spiv: so pull revision history will be slightly more readable?
<spiv> In either case, the full history that you had previously and that the other branch will both be present.
<spiv> Depends on what you think makes a history readable :)
<spiv> And perhaps on which tools you use to look at the history.
<spiv> By default "bzr log" will only show "mainline" revisions, so a revision that merged 10 revs from another branch only takes up one entry.
<spiv> Or maybe you'd rather look at history with a GUI like "bzr qlog"...
<rbriggsatuiowa> spiv: looking at what --include-merges looks like for both ...
<spiv> There's not one right answer, it's a matter of what works for you :)
<spiv> If you have time to experiment a little, then I recommend doing that and see what you like.
<rbriggsatuiowa> spiv: I like the idea of pull slightly better - I'm trying to script some stuff out and pull seems nice in that if they haven't diverged I can just pull in - otherwise I'll bring the two branches up manually
<spiv> Otherwise, "pull when you can and merge when you can't" is likely to be a good default for you.
<rbriggsatuiowa> spiv: sweet - thanks for your help
<spiv> You're welcome.
<exarkun> I'm not sure I understand what this is showing me, <http://pastebin.com/h3cb0fyL>, particularly wrt _zippath.py
<exarkun> I think that should be a rename from zippath.py, not an add
<exarkun> Hm.  It seems to be because when I did "bzr up-thread" I ended up with a pending merge for some reason.
<exarkun> But I didn't do anything that should require merging, I just added a new file
<spiv> If the thread you are in has revisions not in the next thread, and you do up-thread, then it does that merge
<exarkun> I wish it were more visible :(
<spiv> The behaviour of up-thread in bzr-loom trunk has changed recently to make this a little more automatic, and I think more improvements are planned to cut down unnecessary merges.
<spiv> File a bug, lifeless has been spending some time polishing looms recently.
<exarkun> everything else related to looms is really awesome, though
<jam> spiv: what are you still doing up? :)
<jam> morning vila
<vila> morning jam !
<vila> exarkun: you may want to look at --auto or even upgrade to the loom trunk (which requires bzr.dev currently though) where --auto is now the default
<vila> exarkun: with the latests version I intensively use 'bzr switch' and 'bzr up-thread [thread]' to work on the right thread when needed
<vila> latest versionS
<exarkun> Hmm 'bzr switch'
<vila> jam: did you read the IRC logs from a couple of days ago (I think it was this week) where we discussed the update_copyright bug that update the copyright line without checking if the current committer is really the one doing the change ?
<jam> vila: I did not, but I don't really care :)
<vila> jam: which is the case I encounter when using looms and pulling new changes from bzr.dev and merging via up-thread
<jam> the point is to get the copyright lines correct
<jam> it doesn't matter if *vila* changed the file
<jam> it still needs an updated copyright line
<jam> vila: that behavior is ~ intentional
<vila> jam: right, you need to read the logs for different points of view :)
<jam> vila: so... the only reason I don't update every file from the beginning, is because a file that is not otherwise modified, shouldn't end up modified just to update the copyright
<jam> otherwise
<jam> if the person had set the right copyright date
<jam> *when they modified the file*
<jam> then my plugin would be a no-op
<jam> otherwise, the copyright line is *currently wrong and should be fixed*
<vila> by who ?
<jam> now, there are cases where somebody did the modification in 2005, and you are just now merging it
<jam> vila: does it matter who updates it?
<jam> as long as the line is corret
<jam> correct
<spiv> jam: I'm not really awake
<jam> spiv: kisses to little Vincent
<jam> spiv: and sleep well
<vila> lifeless argued that pqm shouldn't be the one hence update_copyright shouldn't be installed there
<spiv> jam: but if I were, I'd say "but what about someone that makes a commit when their system clock is in the wrong year?" :P
<jam> spiv: it would still get recorded in bzr with the wrong year
<vila> by extension, someone *merging* a change shouldn't update the copyright line either
<jam> and update-copyright will then spit out the wrong year at a later time anyway
<jam> having the wrong year is going to give wrong info for all sorts of reasons
<spiv> jam: other idea I had recently:
<jam> vila: so... if you merge bzr.dev, the code is currently wrong (because some copyright headers haven't been updated)
<jam> it is certainly possible that we should just spin on bzr.dev and get it right
<spiv> jam: it would be cute to keep copyright out of the files in the repo, and use content filters to add it to trees.
<jam> rather than having your merges do it
<jam> however
<jam> you should still get *convergence*
<vila> jam: I'm already sold on convergence you know :)
<spiv> jam: thanks for the kind wishes
<spiv> g'night all!
<vila> I'd just mention the discussion about making the plugin less eager which will only *slow* down the convergence :)
<jam> spiv: content filters would be interesting, I don't fully understand why you're required to have Copyright header in every file, etc.
<jam> vila: I disagree
<jam> the plugin shouldn't be touching much if someone has already run it
<vila> jam: but if you want to review https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28306, convergence will happen faster :-P
<jam> if you really want it, write a patch that includes an iter_changes() against all parents but the first, and omit files that seem changed in the first, are not actually according to the latter.
<vila> jam: well, fixing that bug could certainly rally more users and converge faster then :)
<jam> vila: meh
<jam> I think the current semantics are correct
<jam> I can't force an update in the branch you merged *from*
<jam> so I might as well do it in the one you merged *to*
<jam> vila: your diff is not ready yet
<vila> jam: you can start by reading the commit messages :)
<vila> teasing you :)
<jam> vila: *way* to verbose
<jam> your commit comments are 4 screens
<jam> (and poorly wrapped for some reason)
<vila> urgh, damn lp
<jam> ahh, if I make my screen full-width
<jam> it gets slightly better
<jam> it seems there is a column forcing early wrapping
<jam> which is pretty ugly.
<vila> indeed, 80 columns ftw !
<jam> vila: tbh, I find your style of log messages to be overly verbose.
<jam> and hard to read
<jam> I would rather more of a summary, and less of a line-by-line what changed
<jam> maybe that's just me
<jam> (having the filenames also makes it harder to read, because I have to mentally filter out stuff)
<jam> Then again, if I ever go back years later, maybe I'd rather the extra detail
<vila> that's the gnu ChangLog style and we are a GNU project :-) Just focus of the first paragraph which is generally a summary
<vila> It's part of my workflow and help verify my commits and it often helped catch typos or errors,
<jam> vila: well, if launchpad formatted the page correctly, it might be easier. I assume things are indented, etc, appropriately?
<vila> it also triggers some last minute fixes which were wrong though :)
<vila> they are wrapped to fit the 80 (surely less) on word boundaries which isn't always ideal when long identifiers are present.
<vila> But overall since we have a hierarchical history in bzr.dev you rarely encounter them unless you dig for a specific point, and in this case *I* am happy to find the details ;)
<jam> sure
<jam> but I do try to read your logs sometimes, and am often put off from doing so
<jam> just letting you know
<jam> you certainly don't have to change
<jam> *more* commits with terser info might work better :)
<vila> yup, I keep trying :)
<jam> it certainly is an argument for per-file commit messages
<JoshBrown> When branching, where do you normally put the new branch relative to the main branch?
<vila> JoshBrown: it depends of your workflow, but I never put a branch *inside* another branch,
<vila> JoshBrown: if you intend to work on many branches for the same project, you want to use a shared repository,
<vila> JoshBrown: from there, you're free to define any hierarchy *under* the shared repo,
<vila> JoshBrown: if you have a few branches, just put them there, if you have more, group them into some topic folder (bugs, experimental, cleanup, whatever),
<vila> JoshBrown: when a branch use a shared repo, bzr will walk up the file system hierarchy to find the repo, so use any intermediate level you see fit
<JoshBrown> Thanks, I wondered what a repo was, and that answers my question perfectly :)
<vila> JoshBrown: a repo is where all the revisions are stored, a branch is merely a pointer to the tip (the most recent revision)
<jam> vila: I don't know what you did, but the diff *still* isn't available
<vila> JoshBrown: a so-called "stand alone" branch has its own private repo, you can use 'bzr reconfigure' to change
<vila> jam: *I* did as usual, blame lp :) I've noticed the diff wasn't still there but really nothing different from my side I can think of, I even exported my loom to ensure I'm dealing with regular branches
<vila> jam: just clicked the resubmit button...
<vila> I just...
<JoshBrown> vila: Ahh, I thought bazaar was 'distributed' as in every branch was completely separate. Now you've explained it, it makes way more sense. Thanks!
<jam> vila: well, now you're *really* going to piss lp off :)
<vila> jam: :)
<vila> JoshBrown: being distributed doesn't forbid sharing locally :)
<JoshBrown> vila: Yeah, I see that now - I'm glad bazaar isn't as wasteful as I thought.
<Phoenixz> I have an open source project on launchpad. I use this project as a framework for another project at the company where I work for. Now, I don't want to mix the stuff from this company in the open source project, but every now and then, this implementation here makes me find bugs in the open source framework. I fix them in this project, and I want to merge the fixes back to the open source project, but WITHOUT the company specific implementation..
<Phoenixz> I figured I'd just do a merge from the company project to the open source project, remove the company specific stuff, and commit, push back.. I did that and it looks okay to me
<Phoenixz> but now when I do a push to launchpad, it starts sending megabytes of data to launchpad (the company project has various large images).. What went wrong here?
<Phoenixz> The WT looks good, has only the framework + its fixes.. when using bzr ls, I also only see the correct files, even in older revisions..
<Phoenixz> So where do these megabytes of data come from if I can't find them in my repo, and AFAIK, they never got in there in the first place?
<jam> vila: quick question, is GnuChangeLog specific that everything is left aligned? It seems to me that you should be indenting
<jam> I'll also note that "bzr log --gnu-changelog" puts the file content *before* the summary
<vila> jam: I'm unclear on that since bzr log indent again so I de-dent before committing...
<jam> not sure who is wrong
<vila> wow, I'll need to have a look at that...
<jam> vila: http://paste.ubuntu.com/454019/
<jam> as an example of what would be nicer *to me*
<vila> hmm, so --gnu-changelog outputs exactly what I have in my ChangeLog files (which I use as buffers before committing)
<jam> vila: 'bzr log --gnu-changelog -v'
<jam> the --verbose is necessary to get the list of files
<jam> look more at bzr.dev than your log
<jam> since you already format specifically
<jam> http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs
<jam> shows pretty clearly that you *don't* indent a subsection
<jam> shame
<vila> I see, no, it's different, hmm, interesting issue, -gnu-changelog try to simulate the fact that someone have entered a single comment for *all* files, which indeed totally fail in my case since I entered comments for each file
<vila> jam: no shame, that's because it's colorized in all good editors so you don't need indentations :-P
<jam> of course, the overall ChangeLog design is very lisp-ish with its choice of () on *everything*
<vila> but there seem to be far too may empty lines there
<jam> vila: 'bzr log | vim' isn't colorized at all
<jam> I *can* end up doing "set ft=changelog" which does help a fair bit
<jam> though basically by allowing me to ignore everything that I mentioned is too verbose
<jam> (it shows in blue, and I can just skip over all of it easily)
<vila> bzr log --gnu-changelog -n0 -l18 -v > ChangeLog-2 C-x C-f ChangeLog-2 ... colorized :)
<jam> sure, but C-x C-f ...
<jam> and/or explicit naming of the content
<vila> available in all good editors I said... oh come on, I just did the simplest here, let see...
<jam> I'll also note that it borks all the other entries
<jam> (mbp) test that kerberos isn't loaded (Martin Pool) shows up as all-blue
<jam> (note no --gnu-changelog)
<vila> C-SPC M-| bzr log --gnu-changelog -n0 -l18 -v M-x change-log-mode
<jam> anyway, I can do something like that to make it easier to read your stuff
<vila> cool :)
<jam> I don't really feel that I *like* it
<jam> but at least I don't just auto-skip everything you've writetn
<jam> written
<vila> ha, some perl motto applies here: be strict in what you produce but tolerant in what you accept,
<vila> let's both medidate on that :-)
<vila> (i.e. I'll try to to more commits and less verbose ones :)
<vila> yeah toto my dear friend, NOT, to do
<jam> vila: I've found that being tolerant in what you accept leads to people being loose in what they generate. Witness HTML non-strictness and 'bug-compatible' behavior :)
<vila> hehe
<vila> yeah GIGO: Garbage In Garbage Out
<vila> I found the above a bit derogatory and lately I'm more inclined to call it: Better Input Means Better Output
<vila> dunno, the acronym sounds sexier...
<jam> :)
<jam> vila: also note our failure to roundtrip revisions with '\r' in them which broke some mysql revs, etc.
<jam> anyway
<jam> I mostly wanted to let you know that I do find your log messages hard to read, and they don't really play nicely with other tools (like launchpad).
<jam> I think there is a reasonable request to make per-file commit messages more fully supported
<jam> in which case you can do the formatting such that --gnu-changelog output gives you what you really want
<jam> and we could do something like a commit --file importer
<jam> that could convert ChangeLog formatting into the appropriate bzr internal structure
<jam> vila: oh, and 2+hrs later, still no dif
<jam> diff
<jam> definitely something broken
<vila> yup, I had a vague plan for that
<vila> yes, I raised the issue in #launchpad-code but no answer :-/
<vila> and that's the same for my other threads too,
<vila> but lp seems to suffer from some problems too so that may just be a transient issue...
<jam> vila: you shouldn't be working now anyway, thanks for at least putting up with my gripes :)
<vila> noted, I'll finish submitting my threads hoping for lp to finally update the diffs... (only 2 left)
<jam> so, I don't think your changes to osutils are really correct
<jam> in that we just do "foo = ntpath.foo" anyway
<jam> and I *think* you might have regressed some of the shutil stuff
<jam> where we could have lazily imported rmtree
<jam> and not triggered an import of shutil until someone actually calls rmtree
<jam> (that might not be in lazy form, though)
<jam> I remember working on that, I don't know what the current state is
<vila> jam: hmm, then we'll need to define proper wrappers to delay the import instead of relying on symbol aliasing
<vila> or finally cleanup osutils....
<jam> vila: what is wrong with lazy_import as a wrapper here, given that it... works
<jam> just comment that specific one with why we do it
<jam> you *can* add a "def rmtree(*args, **kwargs): return shutil.rmtree(*args, **kwargs)"
<jam> but it seems a bit pessimistic
<jam> if it makes you feel better, you can do it, though
<jam> certainly in that file, lazy-importing something whose attribute you access is certainly a loss
<jam> for readability, and probably even runtime (as you have at least 1 indirection that you always pay)
<vila> I don't remember why I fixed that one this way, probably because I didn't understood the intent, I can revert that as well adding a 'lazily' in the comment to clarify
<jam> vila: so most of the "from transport import get_transport" changes to "transport.get_transport" changes seem fine (though monkey-patching a function in the test suite at that level is a bit ugly.)
<jam> I don't fully understand the http protocol stuff
<jam> and especially why it is mixed in with these other changes
<vila> because it cleans up some bugs in the parametrisation without really changing anything else
<vila> well, bugs about not respecting the parametrisation will be more correct
<vila> the http protocol is the parameter that decides which server should be used
<vila> 1.0 no threads for requests, 1.1 a thread by request (well really a connection)
<jam> vila: I find test_http.load_tests() very hard to read. It is often unclear to me what tests are being multiplexed
<jam> (x, y = split_suite_by_condition() is x or y the one that matched)
<jam> and why are we splitting and multiplexing these one way, and these another
<jam> a comment is probably warranted
<jam> # TestHTTPTransportRegistration should be tested against all transports, but all other tests should only be parameterized by protocol
<jam> or something like that
<jam> or maybe just clarifying
<jam> # some tests test the transport implementation, so we multiply for urllib and pycurl
<jam> # other tests only parameterize on HTTP 1.0 vs 1.1
<jam> maybe it is just me, but doing it all via isinstance checks seems bad form
<jam> versus, say creating a per_http_transport and per_http_protocol files
<jam> you don't have to do it
<jam> just observations about my confusion trying to read (and in the future support) this code
<exarkun> I made a loom, and then I pushed, and then I recorded, and then I pushed again and nothing happened.
<vila> isinstance() makes load_tests() simpler since many test classes can inherit from a base with common parameters
<exarkun> So now my loom is permanently available only in my one working copy?
<jam> exarkun: I don't know the specifics, but possibly doing one more commit + record + push will make a difference
<vila> exarkun: a related bug has been fixed really recently about that
<jam> vila: so it would probably take at least 1hr for me to actually understand load_tests
<jam> if not longer
<jam> I don't know if we could do better
<jam> but as it stands, it is pretty bad
<jam> That doesn't even count understanding *why* the tests are split as such, just to figure out "ok, *these* tests are parameterized *this* way"
<jam> I *think* splitting it such that all tests in a single file are parameterized identically would help
<jam> but I know there is a fair amount of 'chaining' (some get X, some get X & Y, some get XYZ, etc)
<jam> at least the tests are reasonably fast :)
<jam> (without pycurl, 414 tests in 14s)
<vila> nah, split extract the relevant tests for each kind of parametrization, there are several layers but roughly that's pycurl/urllib http-1.0/1.1 then there are the various auth ones... hmm, yeah 2.000 lines already, wow I didn't realize that...
<vila> jam: hehe, and there are some TODO at the top of the file :)
<jam> well at a minimum it should have a 'per_' in the name
<jam> since that is how we identify interface testing
<vila> yup
<vila> I'm about to finish, can you copy/paste all of that in the review or should I search my log tomorrow ?
<jam> vila: anyway, looks fine to land
<jam> you didn't introduce the test_http bogosity (in this patch at least :)
<jam> I'll file a bug
<vila> hehe not in this patch, but I'm certainly responsible for load_tests() there :-)
<jam> *dammit*
<vila> and I keep using it as the most complex parametrization function to copy from :-)
<jam> hit ^L to go to the URL bar in Firefox, but was in Pidgin so it destroyed my backlog
<vila> AAArgh
<jam> *me* really doesn't like ^L in pidgin
<jam> (used to bite me a lot more when I had to hit ^L in gvim to refresh because of display bugs)
<vila> remind me of C-w closing windows instead of cutting the selection :-/
<jam> vila: do you know how often irclogs.ubuntu.com updates?
<vila> no, but I'd say hourly
<jam> http://irclogs.ubuntu.com/2010/06/23/%23bzr.txt is missing the last hour or 2
<exarkun> I did another commit, then a record, then a push.  But it made no difference. :/
<vila> jam: http://paste.ubuntu.com/454047/ is that enough ?
<jam> I think bug 597791 is a reasonable summary without it
<ubot5> Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 6)" [Wishlist,Confirmed] https://launchpad.net/bugs/597791
<jam> I don't really like the summary line, but meh
<jam> vila: what is your merge proposal page
<vila> which one  ? >-/
<jam> found it
<jam> https://code.edge.launchpad.net/~vila/bzr/cleanup/+merge/28315
<jam> anyway,
<jam> BB:tweak
<jam> needs osutils fixed, but everything else looks ok
<jam> vila: so reading through http://irclogs.ubuntu.com/2010/06/18/%23bzr.html
<jam> there is, indeed, a small whole that lifeless is correct about
<jam> however
<jam> it is a fairly small edge case, in that the chance of landing something that requires no actual changes years after it was originally done is small (but not 0)
<jam> a bigger issue
<jam> is that he seems to feel that if he didn't get the copyright line correct, then I shouldn't make it correct
<jam> and I disagree
<jam> and changing that line requires *someone* to commit a change
<jam> which affects that line
<jam> (if you base it purely on the history of the content changes)
<jam> so unless you update the plugin to say "only include copyright years for file content that is not in a comment"
<jam> or some other such thing, I think it is a rather good approximation of correctness
<jam> which is *far* better than what we have done manually
<jam> (so yes, it may get some edge cases wrong, we currently get the *bulk* of cases wrong doing it manually)
<jam> ugh, lifeless is not logged in to read this in his backlog
<vila> right, I think the issue was about me asking to install it on pqm which was a bit too much :)
<jam> vila: I disagree, and I'm posting to the mailing list about it
<vila> I'm off now, it's way too late and family is waiting, see you
<vila> jam: cool
<jam> Peng: any chance you could help me a bit with bug #441125?
<ubot5> Launchpad bug 441125 in Bazaar "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq') (affected: 1, heat: 15)" [High,Confirmed] https://launchpad.net/bugs/441125
<maxb> What could possibly cause a pack to be in obsolete_packs but still listed in pack-names?
<jelmer> maxb: XFS?
<jelmer> maxb: (just guessing)
<maxb> ... on launchpad
<jelmer> no idea in that case
<jam> maxb: there were some bugs about concurrent updates and autopacking, etc. The ones I know of were fixed, and I didn't think they included that failure
<jelmer> 'evening jam
<jam> maxb: http://tinyurl.com/27nb3jj
<jam> is a search on Launchpad that might help
<poolie> good morning
 * jelmer waves
#bzr 2010-06-24
<jam> morning poolie
<jam> so much for showing up extra early :)
<poolie> hi jam
<poolie> heh, well, before 9 :)
<poolie> i'll try to push that back to a bit eariler
<poolie> i guess lifeless is away travelling?
<poolie> so jam how are things for you?
<jam> poolie: things are going fine. I dug into one of the bugs a bit. Basically reconcile on stacked branches is just broken
<poolie> mm i saw your mail
<poolie> that sounds good to fix
<poolie> is that already pointing at 2.2.0? if not you could target it
<jam> yes it is pointing at 2.2.0 (hence why I found it)
<jam> I'm actually targeting the 2.0 series for the fix
<jam> I think it is reasonable to do there, and reasonable to consider it worthy of a backport
<jam> poolie: I had an idea about python compatibility. What if we made 2.0-2.2 be compat back to py2.4, but then expected bzr2.3+ to have a higher cutoff. RHEL 6 is in beta now, so it is likely to come out soon and support python 2.6. Then the bzr versions that are available for RHEL5 will still be compat with py2.4
<jam> but we will be able to have newer ones have a bit more freedom
<poolie> that could work
<poolie> so we'd skip 2.5 entirely?
<jam> maybe
<jam> I wasn't sure about going to 2.5 vs 2.6
<jam> 2.6 would make it easier to support 3.0
<poolie> mm
<jam> at a cost of having our code more wildly diverge
<poolie> i'd care a bit more about using 2.6 features than 3.0 at the moment
<jam> poolie: any specific features?
<jam> Context objects would be nice, but I think that is 2.5
<poolie> that's the only one that comes to mind
<poolie> 'except Foo as e' is a bit less error prone
<jam> true
<jam> though we've already gotten it right for now :)
<spiv> I nearly got that wrong just the other day, but I caught myself :)
<lifeless> poolie: hai
<lifeless> I has 3g gsm goodness
<lifeless> or something
<poolie> hi there
<poolie> and is it good?
<poolie> want some lunch?
<lifeless> poolie: sorry
<lifeless> key doesn't work to the room, locksmith showed up
<lifeless> uhm yes, lunch could be good
<mkanat> jam: If you're around, I can debug the loggerjam^H^H^Hhead stuff with you.
<lifeless> poolie: hi
<lifeless> poolie: I'd like to treat production relation issues as high/critical
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/585126 prompts me to mention this; I want to move it out of 'new'
<poolie> uh ok
<ubot5> Launchpad bug 585126 in Launchpad Bazaar Integration "sendbranchmail is eating memory (affected: 1, heat: 9)" [High,Triaged]
<lifeless> it seems like 'incomplete' for bzr, for now
<lifeless> but thats the status, not the importance field.
<lifeless> What do you think?
<poolie> i think i set it to incomplete before the additional data was attached
<poolie> if this is causing persistent pain to LOSAs and there's enough data to progress it, let's do something
<lifeless> its bzr task status hadn't been set.
<poolie> are you asking how to triage it, or that you're actually planning to work on it?
<lifeless> I've just made it incomplete; I was proposing to set the importance too, to something other than medium.
<lifeless> the former
<lifeless> I think we would allocate engineer resources promptly to it, if it were actionable
<lifeless> and that high or critical is reflective of that.
<lifeless> I think I'm asking for high, not critical, on reflection.
<poolie> ok
<lifeless> its not severe enough to block a bzr release, whatever it is.
<poolie> i don't think it's critical unless a losa is actively complaining about it
<lifeless> I'd really like a 'user error' rather than 'invalid' bug status
<lifeless> because it might be very interesting to do data searches on em
<lifeless> and it might feel kinder
<lifeless> mmm, could be argued to be ui issues anyhow, I guess.
<vila> hi all
<lifeless> hi vila
<spiv> lifeless: you could add a tag, I guess.
<lifeless> yes; little unsatisfactory
<lifeless> \o/ 1 bug to go
<lifeless> or is there... I might be done on this pass
<lifeless> spiv: is there a webnumbr for 'new' bzr bugs ?
<lifeless> cause its 0
<lifeless> :>
<poolie> hi vila
<vila> lifeless: yeah !
<poolie> lifeless:  there's an lpstats graph
<vila> hey poolie
<poolie> hey
<lifeless> poolie: yeah, but thats all like 80's UI and so on
<poolie> those are some epic test suite patches
<vila> poolie: nice catch for the 2004 copyright
<poolie> spiv, still here?
<poolie> spiv, do you have any qualms about me merging the hpss flush() patch?
<spiv> poolie: No qualms
<vila> poolie: hehe, yeah, epic ;) And I didn't even take some suggestions from spiv and lifeless into account yet (and I realized in the middle of the night that some minor changes haven't committed for windows (hackish workflow involving a babune slave))
<spiv> lifeless: not yet, feel free to make one.
<poolie> vila are we there yet?
<vila> where ?
<vila> the proposed patches are a definitive step^W staircase to make the tests pass on windows
<poolie> k
<vila> the proposed patches are a definitive step^W staircase to make the tests pass on windows
<poolie> i guess that would be nice
<vila> grr
<poolie> it would be nice to lock it in
<vila> the missing bits can come later or during review
<poolie> it's not really a high priority goal for us atm though
<vila> I realized that, but on the other hand there are several demands for more features on babune which are not reasonable to implement if the test suite does not pass for windows
<vila> (python-2.4, plugins, installers, etc)
<poolie> true
<poolie> if it's not totally green it will slip back
<poolie> thus my wondering how much more we'd have to do
<vila> yup, and the leaks were a total blocker
<poolie> mm
<vila> with my patch we're down to 4/5 failures
<poolie> i've seen them trying to run under tribunal too
<poolie> on linux
<poolie> i'm not sure why, but i suspect it causes different concurrency patterns between threads
<poolie> if the main thread often blocks
<poolie> lifeless: after that thread about python3 i think we should reject your merge <https://code.edge.launchpad.net/~lifeless/bzr/py3/+merge/28237>
<vila> I've fixed so many different possible hangs that I can't even guess which one you're encountering :)
<poolie> on the grounds that getting to a single codebase from 2.4 through to 3.1 probably won't work
<poolie> is that ok with you?
<poolie> :)
<lifeless> poolie: I'm ok with it being rejected given the wait and see approach that we seem to have settled on in the thread.
<poolie> well
<lifeless> I disagree about 'probably' and 'won't'
<lifeless> :)
<poolie> you think we certainly can get a single tree that works on 2.4 and 3.1?
<lifeless> 'would be fugly'
<lifeless> poolie: I'm quite certain its doable, I'm not certain its desirable.
<poolie> 'single non-gross codebase'
<vila> poolie: :)
<poolie> so i wasn't exactly proposing wait and see
<poolie> but rather, get 'python -3' clean, and then try using 2to3
<lifeless> poolie: It may be the lesser of two evils, all things considered, but I don't have enough info or practical experiments run with 2to3 to make an assertion about that.
<poolie> as a though experiment
<poolie> there is no syntax for octal ints that works on both
<lifeless> poolie: yes, thats the wait and see approach I referenced, and because of that I'm happy to reject that patch.
<poolie> we can either rewrite them all to decimal
<poolie> or, we can keep them in 0666 syntax and use 2to3 with only the octal syntax rewriter turned on
<lifeless> poolie: we need 2 octal ints I think; consolidate to osutils.USER_RWX and USER_RX, or something.
<poolie> obviously this is a pretty tiny example
<poolie> but my point is that the second seems at least possibly as good
<lifeless> poolie: or even use the constants in the os module, or wherever they are
<poolie> sure
<poolie> it's just an example
<lifeless> poolie: right
<lifeless> poolie: we lack data
<lifeless> poolie: all concerns aside, we have a plan to get more data. So lets do that.
<poolie> great
<lifeless> poolie: We have different opinions about what the data is likely to tell us.
<lifeless> poolie: which is fine :)
<spiv> int('666', 8) works in both 2.4 and 3.1
<vila> evil...
<poolie> heh
<lifeless> spiv: \o/
<spiv> I wouldn't want to put that in an inner loop :)
<lifeless> no
<lifeless> but when we're that much into tuning we get into function params etc anyhow
<lifeless> so we could do it there
<vila> but perfectly fine as osutils.o666
<lifeless> sure
<poolie> sheesh _example_
<lifeless> though I'd name it better
<vila> _bike shedding_ !
<poolie> perhaps 'except Foo as e' is a better example
<lifeless> poolie: we're a fun company of non pedantic individuals
<poolie> it's a purely mechanical transform
<lifeless> Hmm
<lifeless> I suspect you could write a
<lifeless> except:\ncatch(Foo, 'e')
<lifeless> that would work on all python versions.
<lifeless> and make folk cry if they ever read its internals.
<poolie> probably
<lifeless> (not suggesting it!)
<poolie> might be a bit messy if you needed multiple catch branches
<vila> so as far as automating code translation, my vote would be to target 2to3 while we support 2.4 and target 3to2 when we switch to support mainly 3.x
<lifeless> vila: I think that this is too early to talk about
<lifeless> we don't know if 2to3 will work well yet; we're going to gather data
<vila> sure, my bet is that we'll end up carrying our own 2to3 if only to take our idiosyncrasies into account
<vila> but I'll shut up now ;)
<lifeless> vila: I mean *even doing that* - pretty much every has to add fixers, its part of the design of 2to3 (to be an 80% solution, local knowledge fixes local gaps)
<vila> just wanted to mention I've done my share of automated conversions from os1 to os2, langugae1 to language2, db1 to db2, and so on
<vila> yup, the workload is always split across: fix the translator, fix the input
<vila> we have a big advantage here with our test suite...
<vila> make that BIG
<lifeless> poolie: oslocks
<lifeless> poolie: and dirstate
<vila> ob: must die
<lifeless> I've just been doing bug stuff :) - but I was reminded that while we *could* fix the concurrent use of st and diff with commit by moving to a separate stat cache - so we don't write to the dirstate when we run iter_changes
<lifeless> that wouldn't remove the os locks and the locks themselves are a cause of bugs with corrupt dirstates not being written to disk, bad out of space behaviour, and AFS/NFS issues.
<mgz> morning all
<lifeless> poolie: so its rather solidified my opinion that we really do want the complexit of a pack-like structure for the dirstate, and the separate stat cache *at most* reduces the writer concurrency requirements on that structure.
<lifeless> vila: well yes, but its more nuanced than that ;)
<vila> hehe
<lifeless> it has a cost, we need to know what we're buying :)
<poolie> i think i agree with that
<poolie> not sure what you mean by "at most" though
<poolie> lifeless, vila, https://code.edge.launchpad.net/~mbp/bzr/deprecation/+merge/27582 is updated per your comments about using overrideAttr
<lifeless> thanks
<lifeless> looking
<lifeless> poolie: I mean that if split out the stat cache again, it doesn't fix the os locks or make the pack-like structure on disk for dirstate much simpler; it only removes one of 3 or so requirements
<poolie> right
<poolie> i don't think just splitting it out would be worth a format bump
<poolie> i'm sending the hpss flush patch to pqm
<lifeless> kk
<lifeless> I'm 'waiting for bugs.edge.launchpad.net'
<lifeless> oh, foo, parthm is gone again
<lifeless> poolie: rereviewed
<lifeless> spiv: ping
<lifeless> spiv: I know its EOD, but hpss effort tests + foreign formats, could use some airtime
<vila> poolie: approved, oh lifeless reviewed it too
<vila> so, yeah, see https://bugs.edge.launchpad.net/bzr/+bug/597791/comments/1
<ubot5> Launchpad bug 597791 in Bazaar "test_http load_tests is overly complex and hard to understand (affected: 1, heat: 6)" [Wishlist,Confirmed]
<vila> the tests pass, I've just checked, TestActivityMixin.setUp() calls TestCase.setUp() so the code is right but ugly
<lifeless> losa ping; what version of testtools is installed in the balleny bzr pqm chroot please
<lifeless> I want to know what features are available :)
<mthaddon> lifeless: 0.9.2-1~0.CAT.8.04
<lifeless> thanks heaps
<vila> poolie: this patch will certainly conflict with my cleanup patch so it will be simpler for both of us if you land yours first and I'll address the conflicts with mine
<spiv> lifeless: like the loom issue?
<lifeless> precisely and
<lifeless> I can solve that one easily
<lifeless> its rather specific
<lifeless> just convert to a matcher and provide an Or test in there
<spiv> Perhaps related, it would be good to start thinking about extending the smart protocol in the loom plugin
<lifeless> spiv: I have been :)
<spiv> e.g. maybe add a verb for set_loom_state?
<spiv> Oh, great! :)
<lifeless> spiv: ignoring questions about what level to operate at, it raises questions about how to add the client side
<lifeless> the server is nicely extensible
<lifeless> the client side proxy rather less so
<spiv> Right.
<lifeless> and I'm thinking perhaps the _real_format could add methods
<lifeless> make RemoteBranch more of a composite
<lifeless> anyhow, neither of those things would make the test better, because plugins will want to call different verbs
<lifeless> and we trace verbs
<lifeless> spiv: for loom it happens to be easy, but what about e.g. bzr-svn
<lifeless> spiv: if you have an svn repo
<lifeless> and access it via bzr push bzr+ssh://host/svn/repo/branch
<lifeless> >
<spiv> Yes, what indeed.
<lifeless> I don't have answers
<spiv> I suppose one answer would be to allow the plugin to set its own call-count requirements.
<lifeless> the test isn't structured quite that way, but we could rephrase it.
<lifeless> Another would be to say that this test is format specific
<lifeless> but that adds a burden if/when we rev formats
<spiv> Or something like "here's the call trace core bzr expects, and core bzr will match that specific trace.  Plugins can override that trace and/or matcher."
<lifeless> yeah that too
<spiv> You could have extreme corner cases with e.g. inter-branch tests from one plugin format to another plugin's format.
<lifeless> definitely
<lifeless> so
<spiv> I don't have any great ideas.  I'd be very happy to start with whatever is needed for looms tests to pass without feeling too ugly.
<lifeless> I'm inclined to lowbrow it right now
<spiv> +1
<lifeless> and hard code in 'get is ok'
<lifeless> [a single get]
<spiv> That's ok with me.  For now the main concern is "confident the core is not regressing", followed by "loom can pass tests", I think.  I think you can hard code and meet those goals.
<lifeless> spiv: what do you think:
<lifeless> http://pastebin.com/4XLwfMdJ
<vila> ...or merge loom into bzr-core
<lifeless> vila: that wouldn't help
<lifeless> vila: because the loom format would still behave differently.
<spiv> lifeless: looking now
<spiv> lifeless: I worry about the risk that the core could regress with that patch
<vila> lifeless: sure, but the issues will be easier to address, anyway, I don't think it's the right time for this, just mentioning it as middle term goal
<spiv> other than that, it looks reasonable.
<vila> I think it's one more case where we want the parametrization to be more pluggable for plugins
<lifeless> vila: I really don't see it being easier
<lifeless> vila: different maybe.
<lifeless> spiv: anything I can do to mitigate your concern ?
<lifeless> spiv: scratch that. Anything *you want me to do to get +1* on the patch :P
<vila> core mentioning loom (an external plugin) is wrong, if it was in core it would be right
<spiv> lifeless: perhaps some sort of "if purely_core_scenaro" guard?  Not sure.
<spiv> lifeless: for this specific case I'd probably accept an convincing argument that the practical risk of the core regressing in exactly that way is low :)
<lifeless> its very low.
<lifeless> vila: if it was in core, in a per_interbranch parameterised test, its still wrong.
<lifeless> vila: abstraction leak; we're being pragmatic about time and goals here is all :P
<lifeless> spiv: concretely
<lifeless> spiv: the test claims that it tests for get_parent_map missing
<lifeless> spiv: so its overly sensitive in using an exact list
<vila> the test is about: "he client has no reason to query the remote graph any further" does loom cares here ?
<vila> hehe, we agree :)
<lifeless> spiv: this test change does not open the door for get_parent_map
<lifeless> vila: loom in general - yes. In specific , no.
<lifeless> in general yes because it does push-per-thread
<vila> yup, may be the test is too high-level
<lifeless> spiv: I'm going to propose it as a merge; vila may +1 it :>
<vila> lifeless: as long as it includes a comment explaining the constraints here, sure ;-)
<lifeless> vila: well, its the patch I put up.
<lifeless> vila: you wanted a passing test suite; its up to you :)
<vila> which patch ? The one you pasted ?
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/28375
<lifeless> yes
<vila> weird, it didn't appear in the active review page until you mentioned it here :)
<vila> lifeless: approved, please land
<lifeless> vila: can you toggle the merge bit too in future, please
<vila> grrrr
<vila> sorry
<vila> done
<vila> Am I the only one who keep forgetting that merge bit ?
<lifeless> no
<lifeless> I want a cron job
<lifeless> that assesses the votes and sets it
<vila> ha cool
<vila> oh, and thanks for that fix, I will get rid of my workaround as soon as it lands
<lifeless> poolie: another thing I find annoying about gmail - the use of first names only
<lifeless> I know many Martins, and many Johns.
<lifeless> vila: btw
<lifeless> vila: threads in paramiko: teach paramiko to accept a thread factory replacement parameter.
<vila> lifeless: yes, that's probably the way to go but I felt too weak to go there and there may be a different way to run the paramiko code into the threads we already have (the way the test server implementation without ssh support works is an hint)
<vila> but overall since the paramiko daemonic threads appear to die naturally I punted :->
<lifeless> vila: for sftp it makes its own ones, I think
<vila> it makes its own ones as soon as it needs a wrapper for ssh
<vila> at least they are the only ones I left
<vila> and it uses timeouts there which... re-open the same can of worms I was getting away from, so, as long as it works... I prefer to left it as is as I know it will be a nightmare to debug and probably hardly fixable without fixing paramiko which in turn will make it harder to keep it as an external dependency
<vila> huge effort, small reward :-/
<lifeless> vila: timeouts are fairly good for defensive programming
<lifeless> vila: I wouldn't want to get rid of them
<lifeless> mgz: you'll be glad to know we broke subunit trunk with our patch
<lifeless> mgz: 58 errors :)
<lifeless> mgz: some of which are testtools bugs
<jml> how do I stop getting bzr bug mail
<lifeless> I think you have two choices
<lifeless> you can either leave the relevant control team
<lifeless> or you may be able to individually explicitly subscribe to all the bugs in the same place the team is subscribed
<lifeless> with a subscription of 'I'm not subscribed'
<lifeless> its the same conflation of 'power/access/interest' pattern we have in LP
<lifeless> jml: oh, and I'm sorry if I tripped your 'zomg' threshold with bug spam today.
<jml> lifeless, not at all. it's been bugging me for a while.
<jml> lifeless, I like bzr a lot, but I never ever read the bug or MP mail any more
<gustavonarea> Hello. Does anyone know how to migrate multiple related Mercurial branches to Bazaar? I know I have to use --marks/--import-marks/--export-marks, but it doesn't seem obvious to me how to do it and I cannot find anything in docs or the Web. All I find is documents explaining how to migrate from bazaar to git using marks.
<lifeless> gustavonarea: can't you just install bzr-hg ?
<gustavonarea> lifeless: it hangs the computer and then gets killed by the OS
<lifeless> oh, thats a little undesirable
<gustavonarea> And that happens on a high spec server; I wouldn't try it on my laptop
<gustavonarea> any idea how to do it with fast-import/export?
<lifeless> not personally sorry; maybe the bzr list, or the bugtracker, will know more.
<gustavonarea> thanks lifeless! I'll stay around just in case :)
<lifeless> mgz: I've pushed a one-character fix; so small I'm not even going to ask jml for a review.
<jml> lifeless, don't you care about quality?!?!!!!1!!??!?
<lifeless> jml: no, not at all.
<lifeless> mgz: jml: anyhow, trunk of both play nice together once more.
<jml> \o/
<vila> lifeless: timeouts lead to hard to track bugs with threads and sockets in our case, they *are* good for defensive programming but they shouldn't be used to work around synchronisations issues (which was the case here)
<lifeless> vila: agreed
<vila> lifeless: I think I don't understand what you're after in the smart-server-leaks threads, I just posted a comment but discussing it here may be more effective (if you're still available)
<vila> s/threads/merge proposal/
<lifeless> vila: you appear to have done the following:
<lifeless>  - rearranged some code
<lifeless>  - added a new, strange, public method which users would not expect to have to call
<lifeless> I am neutral on the first and against the second
<lifeless> vila: I don't understand why the second is needed
<lifeless> if I understood why, I would stop being against it :)
<lifeless> I would like to see internal behaviours kept internal
<vila> because I want to reuse most of the code there but *not* creating the server socket as part of building the object
<lifeless> I may have it wrong; it may still be internal and the diff is confusing me
<lifeless> vila: I don't mind if the creation is separate to building the object, thats orthogonal to my concerns
<vila> well, the actual code does too much in __init__ for my needs so the socket creation has to be done outside of it
<lifeless> sure
<vila> I can create a base class to address that but that sounded too bug a hammer
<vila> big
<lifeless> I repeat, I'm fine with the separate method.
<lifeless> I'm not fine with who has to call it
<vila> now, I don't think users *have* to call it as it's now called by the smart server factory,
<lifeless> if it was called start() I would be fine
<vila> ha, ok, so public and a better name ?
<lifeless> vila: the smart server factory is a user of the class the method is on
<lifeless> the connection between the two should be clear, or the factory shouldn't exist.
<lifeless> by which I mean, if we have two components, we should have *two* components, not one-and-a-half
<vila> hmm, there is already start_background_thread/stop_background_thread but no start/stop >-/
<lifeless> why isn't it part of one of those methods, for instance?
<vila> cause I'm lazy ? :)
<lifeless> heh
<lifeless> I'm lazy too
<lifeless> I think I'd have tried to find a way where i didn't change callers.
<vila> kidding, because I was unclear about how this class was used and wanted to just pick the good bits
<vila> my overall feeling (backed by some discussion with spiv) is that the actual design is *good enough* and I think we may want to improve it but I didn't want to do that as part of my patch
<vila> not a good reason to make it worse though
<lifeless> right
<lifeless> I fully agree with that
<vila> hmm, the server factory has a set_up/tear_down but don't use  start_background_thread/stop_background_thread... that's part of the friction I think
<vila> hmm, and start_background_thread/stop_background_thread is, in fact, used by TestSmartTCPServer for a single test and overlap with TestingTCPServerInAThread too >-/
<gustavonarea> How can I add an alias to my branches, like "lp" for launchpad.net? I've check the docs and searched for this on the Web but I didn't find anything
<lifeless> bzr-bookmarks plugin
<lifeless> I think
<gustavonarea> I'd like to something like "bzr branch foo:trunk" where "foo:trunk" gets translated to "bzr+ssh://example.org/path/to/trunk"
<gustavonarea> ah ok, thanks lifeless
<maxb> gustavonarea: See http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html, I think for the style of prefix you want, you might need to write a tiny plugin of your own
<gustavonarea> cool, thanks maxb
<gustavonarea> maxb: any pointers on how to write a plugin like that?
<vila> the bookmarks plugin :)
<gustavonarea> ok, thanks vile
<gustavonarea> * vila
<maxb> Or the built in launchpad plugin
<vila> yup, as maxb said, but the lp plugin do more than that so may be harder to grasp
<maxb> The bzr feature that you need to interact with is called directories
<gustavonarea> thanks maxb!
<rbriggsatuiowa> when working with feature branches and a trunk - if I am merging feature branches into trunk - which is a better workflow?  merging trunk into feature, then feature into trunk or just try and merge feature into trunk (ran into a case where it wasn't pulling all the changes from a feature until I merged trunk into due to weirdness with reverse and forward merges)
<rbriggsatuiowa> (my problem is resolved - I was just wondering for future reference what the preferred workflow is)
<fullermd> I normally go by a gut feeling of "are there going to be non-trivial conflicts to resolve?"
<fullermd> If it'll land easy, JFDI.  If not, do the merge in the branch and deal with the fallout, then land it.
<fullermd> And then kick yourself for not pre-emptively merging trunk into feature on a regular ongoing basis in the first place   :p
<rbriggsatuiowa> fullermd: cool - thanks (or yell at the people working on the feature for not pulling in :)
<rubbs> fullermd: fwiw, that's the way I do it too.
<lifeless> good morning
<jelmer> hello
<mgz> <lifeless> mgz: you'll be glad to know we broke subunit trunk with our patch
<mgz> urk?
<lifeless> mgz: for starters pull testtools trunk
<lifeless> and diff -c -1
<mgz> subunit hits a path not in the testtools testsuite at all?
<lifeless> then slap self on forehead (I did this) and mutter 'coverage dagnammit'
<mgz> right, done that
<mgz> but for dammit-ness
<mgz> -    return ''.join(chars)
<mgz> +    return u''.join(chars)
<lifeless> yes
<lifeless> as I said, 1-character fix.
<mgz> Python 3 SyntaxError
<lifeless> hahaha
<mgz> need a _ and a ( and a )
<lifeless> 4 character fix coming up
<lifeless> I'll uncommit that one
<mgz> I'm a little perpelexed that this isn't tested but testtools itself though
<lifeless> I was tirrrred last night
<lifeless> so am I
<lifeless> it has done a sneaky I think
<mgz> I take it the issue is with details objects with no textual components
<lifeless> TestResult isn't getting exercise
<mgz> which then means we get a str object on Python 2, which we're now throwing a TypeError over
<lifeless> mgz: thats probably it
<lifeless> yes to the str object
<lifeless> probably to the proximate cause
<lifeless> subunit had a bunch of literals I 'u'ified
<lifeless> as its not py3 ready anyway its no great loss
<lifeless> need to migrate them to _u()
<lifeless> or py2to3, though like bzr, subunit supports much older pythons
<mgz> alternative spelling, str().join
<lifeless> mgz: for what?
<mgz> u"".join
<lifeless> how does that work on 2.x?
<mgz> doh.
<lifeless> lol
<jam> lifeless: you mentioned the idea of "refreshing the pack index" to try and get things to behave correctly. Is that Repository._refresh_data() ?
<lifeless> jam: sounds like
 * lifeless noses around
<jam> lifeless: k, that doesn't work :)
<lifeless> oh! thats very interesting.
<lifeless> and yes, thats what it is
<lifeless> the base class docstring says it all.
<jam> I'll also note that I got weird behavior wrt stacking fetch based on ordering
<jam> if I created the stacked repo before I populated the base
<jam> then the base revision would always get fetched
<jam> I think spiv mentioned something like that
<lifeless> spiv just fixed a bug there
<jam> (now there, _refresh_data *might* do something, though)
<lifeless> pull his patch
<jam> well, I'm working in 2.0, and I can workaround it in the test by create_base() fetch_base(), create_stacked()
<lifeless> he says his patch is a candidate for 2.x+
<lifeless> and I agree
<jam> same here
<jam> but it was just an observation, not something blocking me
<lifeless> ok
<jelmer> lifeless: do you know what the time planning is for 2.2 ?
<lifeless> no
<lifeless> it should happen
<jam> lifeless: repo.bzrdir.open_repository() doesn't set fallback repositories?
<lifeless> jam: thats right
<jam> lifeless: Bazaar/Calendar/2010 says b4 on July1st, and 2.2.0 on July 29th
<lifeless> jam: branches define the fallbacks
<jam> lifeless: that seems to be why one succeeds and one fails
<lifeless> policy in branch, implementation in repo
<lifeless> jam: ah!
<jam> RepoReconciler calls repo.all_revision_ids()
<jam> and gets different results when a repo is stacked
<lifeless> yeah, reconcile is meant to work with a no-fallbacks repo
<lifeless> you might like to add an assertion-like-check to the reconciler objects
<jam> lifeless: there isn't a "remove_fallback_repo" command, is there?
<lifeless> they'll misbehave terribly otherwise
<lifeless> jam: not offhand; it would need to flush all cached graph objects and so on that had been opened from it
<lifeless> jam: so it would be pretty awfully complex
<lifeless>  / prone to misused
<jam> so Reconciler does take a bzrdir and directly opens the repo
<jam> but repo.reconcile() just uses self
<lifeless> jam: https://code.edge.launchpad.net/~jameinel/bzr/2.0.5-switch-unicode-317778/+merge/19121
<lifeless> is that abandonware :) ?
<jam> lifeless: well, not *my* code at least
<jam> mostly proposing the patch that was in the bug
<jelmer> jam, lifeless: Ah, so I guess I have less than a wek left to get the final API changes for colocated branches in place?
<jam> jelmer: I'm pretty sure we decided to API freeze for 2.2b4
<jam> to give plugins time to stabilize
<lifeless> jelmer: no last minute stuff
<lifeless> jelmer: you have layer inversions still, last Isaw
<lifeless> jelmer: I really think we should say colocated is still unsupported, and work on it in 2.3
<lifeless> make it as clean as possible, its going to be the underpinnings for apis for years
<jam> lifeless: so for the mp, I would reject the code as-is, and I don't think philyoon is going to work on it
<jam> It sort of depends how high we want to prioritize it for us
<jam> *I* don't need it
<lifeless> well
<lifeless> I'm reviewing bugs-with-patches
<jam> bialix and others may
<lifeless> found quite a few closed
<jam> lifeless: ValueError reasonable for "_fallback_repository is not empty" ?
<jam> or just a generic BzrError?
<lifeless> either is fine for me
<lifeless> we expect API users only to encounter it.
<jam> right
<jam> lifeless: so Pack format repos fail reconcile because the target pack already exists.
<jam> do you think it is reasonable to catch FileExists in _reconcile_pack
<jam> or should I catch and skip in the test.
<lifeless> sure
<lifeless> uhm
<lifeless> my dream
<jam> Today it is a bit annoying that 'bzr reconcile' fails on pristine repos.
<lifeless> implement catch, byte-compare
<jam> I know we'd like to have the consistency check
<jam> but that is a bit out-of-scope
<lifeless> offhand I think catching it in reconcile is ok
<lifeless> after all reconcile isn't adding data to the repo
<lifeless> its like pack()
<jam> lifeless: the alternative is to have NewPack.finish() do something special to indicate it shouldn't be used after all
<jam> we've already done "self._use_pack(new_pack)" which checked to see if data was inserted
<jam> until we call finish_content() we don't know the final name of the pack file, to know if it will collide
<jam> lifeless: and that is called from NewPack.finish()
<lifeless> sure
<lifeless> I'm ok with catching it; no real opinion :_
<lifeless> :)
<jam> the only other problem is that we can get a collision on disk and the file *isn't* in pack-names
<jam> (if someone ^C's during autopack, and then runs it again, I think)
<jam> note also that this doesn't really affect Linux users, since transport.rename() will overwrite the existing file (I believe)
<jam> it affects sftp, though
<lifeless> did you see the question on lp about a case of that?
<jam> https://code.launchpad.net/~geoff.bache/bzr/trunk/+merge/28463 has a serious issue about NEWS
<lifeless> yeah
<jam> lifeless: I saw a question about a file being in pack-names but having been renamed to obsolete_packs, which is a different thing
<lifeless> jam: thats the one I was thinking of
<lifeless> I was wondering how we could gather more data on that
<lifeless> in an acceptably safe manner
<lifeless> there is also some redundancy with other work in that patch
<jelmer> lifeless: for when is 2.3 planned?
<jam> jelmer: approx 6months from the release of 2.2
<jelmer> jam: ah, thanks
<jam> by the 'standard' calendar
<spiv> jam, lifeless: thinking of SFTP rename, I see that OpenSSH has an extension to the SFTP protocol for a POSIX rename.
<jam> spiv: is that sort of like having sftp v7 implemented?
<spiv> It's described in http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=HEAD
<lifeless> I'd like to:
<lifeless>  - define a standard protocol for moving files with a known/predictable temp name; that will catch that file existing first and error so that calling code can rollback partial things/whatever
<lifeless>  - use that around everything that replaces single files
<lifeless> because we can never be sure that someone isn't sitting on the local disk on windows.
#bzr 2010-06-25
<poolie> hi spiv
<lifeless> ok, losa ping - again, sorry for the noisiness of this; there is something odd/wrong
<spiv> Morning poolie.
<poolie> thanks for the stacking fix
<poolie> there are some more similar ones if you're keen
<poolie> probably currently untargeted but i would not object to fixing them
<spiv> Any specific ones in mind?  There are quite a few with the 'stacking' tag!
<poolie> nothing specific sorry
<poolie> what did you have in mind to chase next?
<lifeless> poolie: shout when you have a minute (loom-diff topic)
<spiv> poolie: submitting my bzr and bzr-builder branches to support the 'take just debian/ dir from a parallel import' case.  I have complete patches for both, but based on discussion on the list I think I'll leave out any CLI for it in the initial bzr patch.
<spiv> poolie: that said, one of the other High stacking bugs looks fairly straightforward, so I'll queue that up to tackle too
<spiv> (https://bugs.edge.launchpad.net/bzr/+bug/551525)
<ubot5> Launchpad bug 551525 in Bazaar "reconfigure --unstacked doesn't quite work for lp branches (affected: 1, heat: 3)" [High,Confirmed]
<poolie> spiv that would be nice, you could target that
<bendj> I'm building 2.2b3.  On x86m builds & installs just fine.  On a similarly configured x86_64 box, however, it reports an "internal error": http://pastebin.com/8UK28NnA
<bendj> Before I report a bug -- does that, in fact, look like a bazaar issue, or likely something in my env?
<bendj> I ask cuz of the different behavior on different arch ...
<lifeless> its a bit hard to tell
<lifeless> that means that trace._bzr_log_filename is None
<lifeless> do you have logging disabled or something, perhaps ?
<bendj> lifeless: Nope.  Was working ... at least before this build attempt.
<bendj> nothing _should_ be significantly different abt this x86_64 box :-/
<bendj> lifeless: aha.  well, sort of ... if I manually "rm /usr/local/bin/bzr" the previously installed bzr, then re- "python setup.py install", no more error.
<bendj> shouldn't an install overwrite a preexisting bin?
<lifeless> bendj: only if its installing to the same place
<bendj> lifeless: it is ...
<bendj> interesting tried it on 3 x86_64 boxes, same behavior.  on x86 boxes, no req't to PRE-delete the nimady
<lifeless> e
<bendj> aghh! binary
<bendj> (nimady? jeesh ...)
<lifeless> nomstu surely ?
<bendj> heh ... smart___ ;-)
<bendj> easy enuf -- added to my notes.  thx!
<AfC> If I want to get the branch of an Ubuntu package [presumably from Launchpad] (as opposed to an upstream hosted on Launchpad), is there a special command or URL to use?
<spiv> IIRC, lp:ubuntu/src-package-name (or e.g. lp:ubuntu/maverick/src-package-name to explicitly get the maverick version)
 * AfC tries that
<AfC> spiv: yes,
<AfC> $ bzr branch lp:ubuntu/bc
<AfC> spiv: worked.
<AfC> Kind of a shame that all the revisions show as being made by Bazaar Package Importer <james.westby@ubuntu.com> instead of whomever the original committer in Debian or Ubuntu was.
<poolie> hi afc
<AfC> poolie: hello Martin, nice to see you
<poolie> you too
<lifeless> AfC: I think it sets author now
<lifeless> AfC: so log can show it
<AfC> oh.
<AfC> so does that mean those branches will be superseded with new ones?
<AfC> lifeless: ^
<lifeless> maybe someday
<lifeless> magic 8 ball says 'drink some beer'
<AfC> lifeless: cool!
<AfC> No, that was "cool that the bzr branches will be fixed", not "cool that you're drinking and we
<AfC> are not" :)
<lifeless> AfC: actually I'm working @ poolies today
<AfC> lifeless: still, though, all in all the "go drink beer" meme is a good one. I think we might take your advice.
<lifeless> AfC: be my guest :)
<mgz> <bendj> I'm building 2.2b3.  On x86m builds & installs just fine.  On a similarly configured x86_64 box, however, it reports an "internal error": http://pastebin.com/8UK28NnA
<mgz> ^I actually get some test failures like that in my setup, because I don't init logging
<mgz> really that line shouldn't assume that trace._bzr_log_filename is a string
<poolie> spiv, lifeless, did one of you mention an updated network delay simulator?
<parthm> looks like an interesting ssl bug got fixed upstream in python http://bugs.python.org/issue9075 ... was posted on reddit.
<spiv> poolie: I don't think that would have been me.
<lifeless> mgz: I'm in that area now, I'll do something to it (stabby stabby)
<poolie> i'm trying to reproduce bug 590638 between here and chinstrap
<ubot5> Launchpad bug 590638 in Bazaar "hpss protocol buffers too much outgoing data (affected: 1, heat: 11)" [High,In progress] https://launchpad.net/bugs/590638
<poolie> as another machine on a similar network
<poolie> unfortunately it's only sending fairly large stream parts
<poolie> so the effect is not very obvious
<mgz> lifeless: cool
<mgz> now I need to stop playing and pack my things
<spiv> poolie: IIRC, igc saw a variety of large and small stream parts when fetching lp:launchpad, perhaps try using that as the data?
<vila> poolie: There is SocketDelay in stub_sftp..
 * vila not fully here yet
<vila> poolie: but a vm sounds like an easier way to truly simulate that (ymmv, etc)
<poolie> spiv, i think when i branched from lp to chinstrap it probably got repacked into something less fragmented?
<lifeless> yes
<lifeless> it will be optimus prime now
<vila> hi all
<spiv> poolie: hmm, I guess you could grab the files via sftp.
<sebi_`> I accidently added .git/ to my branch with "bzr add .", but after "bzr remove .git", bzr actually erased the *physical* location.. what's the deal with that?
<sebi_`> er, bzr rm .git
<spiv> 'bzr revert .git; bzr rm --keep .git'
<sebi_`> I just wanted to remove it from my branch ):
<sebi_`> bzr revert .git brought at least .git back, thanks
<spiv> 'bzr rm FOO' will automatically delete FOO if it is safe to do so, i.e. if the file(s) to delete were committed and unchanged, because when people 'rm' things they usually want them removed completely :)
<spiv> If you'd never committed the .git directory, then 'bzr rm' would have defaulted to 'bzr rm --keep'
<sebi_`> true, but git rmtree $path only removes the data from the branch, if it has been accidently pushed
<sebi_`> I didn't commit yet
<sebi_`> okay, well, time to study the docs again, I guess :P
<sebi_`> also, are comments allowed in the .bzrignore?
<spiv> 'bzr revert' reverts to the last committed state... so if 'bzr revert' brought it back, you must have committed it.
<sebi_`> errr yeah. commited, but not pushed
<spiv> Leading #, I think.
<sebi_`> okay
<spiv> Depending on how recently you accidentally committed that directory, you might find 'bzr uncommit' helpful.
<sebi_`> it looks like no sensitive data has been added, so I guess it's fine
<poolie> hi there vila
<vila> hey poolie
<poolie> hi spiv, vila
<poolie> for reasons i'm about to post to bug 582157, i couldn't prove that flushing the hpss stream more often makes things faster
<ubot5> Launchpad bug 582157 in Bazaar "pull from launchpad is slow (affected: 1, heat: 8)" [High,In progress] https://launchpad.net/bugs/582157
<poolie> but i'm still pretty sure it will help in some cases
<vila> :)
<poolie> so i think i'll send it up anyhow
<vila> when have no scientific proof, trust the experts :)
<vila> s/have/you have/, typos....
<poolie> :)
<spiv> poolie: My suspicion is it will help a small amount.  I certainly don't expect it to hurt, at least not for the uses we currently use body streams for.
<spiv> poolie: so, your inconclusive results match my expectations :)
<poolie> me too
<poolie> i had to adjust or cut a couple of tests about how many flushes there were
<poolie> i hit https://bugs.edge.launchpad.net/tribunal/+bug/598348
<ubot5> Launchpad bug 598348 in Tribunal "poor handling of wide error messages (affected: 1, heat: 6)" [Medium,Confirmed]
<poolie> when they fail they print the whole 1.5MB stream :)
<spiv> Heh.
<poolie> though it is nice the test is there
<GaryvdM> Hi all
<vila> hey GaryvdM !
<GaryvdM> Hi vila
<GaryvdM> Does use of ctypes reduce portability?
<poolie> GaryvdM: it depends what you do with it :)
<poolie> not necessarily
<GaryvdM> Hi poolie!
<GaryvdM> poolie: http://code.activestate.com/recipes/496960-thread2-killable-threads/
<poolie> wow
<poolie> ok, good night all
<lifeless> gnight
<lifeless> btw
<lifeless> paste
<lifeless> loggerheads web engine
<lifeless> has that code already
<GaryvdM> night poolie
<poolie> lifeless: which bit? thread killing?
<lifeless> yes
<GaryvdM> Ok - I feel better about using it then.
<poolie> in qbzr?
<GaryvdM> Yes
<C-Keen> Hi! I am comming from darcs and hg/git and I was wondering if I am expecting the wrong thing here: if I do a merge from a remote branch to my own, should I see the other branche's commits in history?
<poolie> C-Keen: yes, use 'log -n0'
<C-Keen> poolie: that's cool! thanks!
<C-Keen> I like how bazaar handles history!
<C-Keen> poolie: another question. Can I tell bzr to commit merges if my tip does not diverge?
<jelmer> C-Keen: you would probably want to use 'bzr pull' in that case rather than merge
<C-Keen> ah ok
<GaryvdM> C-Keen:  bzr merge --pull . That will pull if the branches have not merged, and will merge if they have.
<GaryvdM> *have not diverged
<C-Keen> ah!
<GaryvdM> Offtopic question, but it is for qbzr dev:
<GaryvdM> Is there a way to tell grep to use single line mode.
<GaryvdM> i.e. "." should include \n
<GaryvdM> I've read man grep about 3 times and I can't see anything.
<Kinnison> grep explicitly operates on lines
<GaryvdM> I want to find:  lazy_import.*'''.*bzrlib\.plugins\.qbzr\.lib\.trace.*'''
<Kinnison> you can tell by the "...for lines containing a match..." in the first paragraph of the description.
<GaryvdM> Is there maybe an alternative to grep that can do that?
 * GaryvdM looks if he can use ack...
<spiv> Kinnison: I think by "single line" GaryvdM means "as if entire file were a single line", perhaps, so he can search for patterns that span \n.  I'd probably call that "multi-line matching" myself.
<spiv> GaryvdM: i.e. you're looking for the equivalent of re.DOTALL in Python's re module?
<Kinnison> spiv: yeah, grep doesn't do that
<GaryvdM> spiv: yes - re.DOTALL is what I need
<GaryvdM> spiv: and that is the same as re.S which in refered to as single line mode in some places.
<GaryvdM> http://blog.stevenlevithan.com/archives/singleline-multiline-confusing
<GaryvdM> So confusing...
<vila> jelmer: ping
<vila> jelmer: Ping
<jelmer> vila: pong
<vila> losa: regarding bug #525571, do you still have some corrupted subversion.conf file around ?
<ubot5> Launchpad bug 525571 in Bazaar "No locking when updating files in ~/.bazaar (affected: 6, heat: 52)" [High,In progress] https://launchpad.net/bugs/525571
<mthaddon> vila: not that I'm aware of
<exarkun> doesn't the ticket description describe how to produce one?
<exarkun> (and also include one?)
<vila> exarkun: there is one mentioned in the bug description but I wonder if it is complete...
<exarkun> vila: I'm the reporter.  It is.
<vila> exarkun: good to know !
<vila> that's very weird that configobj created an *empty* section with the name of an existing one...
<vila> I can't imagine  scenario (even with two processes writing to the same file) that could give such a result,
<exarkun> Hm yea, that's interesting.
<vila> the whole section duplicated, I can, with some efforts :), imagine that both were trying to create the same content, but an empty one...
<evanton> is there a tool that would allow me to import revisions from a bzr repo into a subdirectory of another bzr repo? My final goal is to join a lot of small bzr repos into one, where each small repo will be a directory in the big repo
<evanton> basically I want to give as arguments small repo location, new big repo location, directory name and let the tool pull revisions one by one and add them to the custom directory in the big repo
<beuno> evanton, so, the opposite of that would be to use "bzr split", which I think is in bzrtools
<beuno> I'd expect there to be an equivalent
<fullermd> It's in base, not bzrtools.
<fullermd> And the command is 'join'.
<fullermd> It's essential the equivalent of merge + move the root of the merged tree.
<beuno> I am so outdated...
<jmlxx> Hi All!
<jmlxx> anybody have any info/insight as to why Bazaar Explorer wont launch on Win7 x86 platform?
<jmlxx> using the default settings during install, i get an error when trying to launch the program "Unable to execute file: BZR - Create Process failed; code 2, The system cannot find the specified file"
<jmlxx> anyone??
<VSpike> heya. bzr just threw and exception on me during a push by sftp.  The last line (more or less) was SSHException: Server connection dropped:
<VSpike> It asks me to file a bug report, but it seems to me that this is probably normal?
<VSpike> ALso, what's the best way to recover? Just bzr break-lock and repeat the push?
<lifeless> VSpike: yes
<lifeless> VSpike: uhm sounds like an error case we aren't explicitly handling yet - could you please file that bug, we'll make it prettier when it happens.
<VSpike> okie doke
<VSpike> does that answer still apply if I mention I'm running the cygwin version? ;)
<lifeless> yes
<VSpike> Looks like Bug #386036 to me
<ubot5> Launchpad bug 386036 in Bazaar "SSHException causes bzr to crash (affected: 1, heat: 2)" [Medium,Confirmed] https://launchpad.net/bugs/386036
<lifeless> wah yes
<lifeless> you could me-too it
<VSpike> Done :)
<VSpike> http://pastebin.com/Zm9D0Umg
<VSpike> Any ideas what to do about this error?
<VSpike> Hmm keep getting same error (apart from file names) when I repeat the attempt
<maxb> VSpike: about the only thing I can think to check is file permissions on the repository
<VSpike> maxb: the permissions look ok.  I can see the files in /.bzr/repository/upload that are still there.  Interestingly, the destination file that it wants to rename to in ../packs/ already exists
<VSpike> perhaps that's why it cant rename the file?
<maxb> sounds entirely plausible
<VSpike> Aha. Bug 516179
<ubot5> Launchpad bug 516179 in Bazaar "bzr push confused by existing pack file (affected: 1, heat: 1)" [Medium,Confirmed] https://launchpad.net/bugs/516179
#bzr 2010-06-26
<VSpike> problem solved. tar'd the tree, scp'd it to the remote, ssh in, unpack, push
<johnf> Is there an easy way to run some bzr command to return a non-zero exist status when there are uncommited files?
<spiv> johnf: 'bzr diff > /dev/null', I guess.
<johnf> spiv: ended up going with  test `bzr status | wc -l` != 0
<lifeless> johnf: stf ?
<johnf> lifeless: do you perhaps mean wtf?
<spiv> lifeless: "shoot the fridge"?
<lifeless> whats the context for this
<spiv> johnf: lifeless has just told me it's a bug that 'bzr st', or at least 'bzr st -q', doesn't do that.  I'm filing a bug.
<johnf> lifeless: I want bzr st -q to return non-zero if there are modified, added, removed or unknown files.
<johnf> or some similar command
<spiv> Or maybe the PyCon network is a bit crummy and I'll be filing that later...
<__monty__> Hi, I'm trying to fix a bug and I don't really know what to do. I did a very  naÃ¯ve code change and here: https://code.launchpad.net/~toonn/bzr/no-repo-error-message/+merge/17039 Robert Collins suggested to do something, but I need some help with it. Does anyone have some time to help me?
<lightpriest> came in to ask something, noticed the url to "bzr answers", found what i needed... bzr is simply great ;p thanks
<__monty__> Hi, I'm trying to fix a bug and I don't really know what to do. I did a very  naÃ¯ve code change and here: https://code.launchpad.net/~toonn/bzr/no-repo-error-message/+merge/17039 Robert Collins suggested to do something, but I need some help with it. Does anyone have some time to help me?
<beuno> 101mb!  I haven't pulled bzr.dev in a little while...
<__monty__> Could anyone help  with this bug: https://bugs.launchpad.net/bzr/+bug/45599 ?
<ubot5> Launchpad bug 45599 in Bazaar ""no repository present" error should suggest using bzr branch (affected: 2, heat: 2)" [Wishlist,In progress]
<lifeless> \o/ connected
#bzr 2010-06-27
<glyph> Hey
<glyph> I've been using bzr-svn
<glyph> on the SVN repository on svn.twistedmatrix.com
<glyph> any time I do a 'pull' on any branch where I've done a 'push' though, I get a
<glyph> Conflicting tags:
<glyph>     release-2.0.0+win32installer
<glyph> can anyone help me out with an explanation of why that particular tag is always conflicting, and/or what I can do to fix it?  I don't really care about tags at all, I'm just using bzr-svn for offline commits.
<lifeless> glyph: pull --overwrite
<micahg> how do I include the changelogs of the merged revisions into the new branch?
<glyph> micahg: changelogs?
<micahg> glyph: sorry, commit messages :) (packaging on the brain)
<glyph> micahg: that's just what happens when you branch in bzr
<glyph> micahg: have you done 'bzr visualize' or 'bzr qlog'?
<micahg> glyph: no\
<micahg> glyph: I wanted them merged for the merge commit message
<glyph> micahg: you want all of the commit messages in the branch to show up as one *giant* commit message for the merge revision?
<micahg> glyph: no, just the revisions that are being merged in
 * micahg thought there was a flag
<glyph> I don't know if there's a flag
<glyph> but there's no reason to do that
<glyph> since you can always access the earlier commit messages in the revision log
<samgee> I have a branch foo to which I added subtree bar. Then I did some commits on foo/bar (and nothing on the rest of the tree). Now I want to put bar into its own branch, keeping just the history starting from when it was added.
<samgee> bzr split seems to copy the whole history. I found https://answers.launchpad.net/bzr/+question/106791, but it looks like bzr-rewrite hasn't been updated in a while and doesn't work with bzr 2.x. Any solution for this?
<lifeless> moin moin
<mneptok> lifeless: ahoyhoy
#bzr 2011-06-20
<spiv> Good morning folks.
<jelmer> hi spiv!
<spiv> Hey jelmer
<vila> hi girls and guys !
<jam> morning all
<lifeless> jam: I'd love to talk parser performance in go with you at some point
<jam> lifeless: sure
<jam> I'm currently waiting for rm -rf 's to run on my machine
<lifeless> have you seen lmirror ?
<jam> I just got a 240GB SSD, and I'm cleaning stuff up
<jam> before I switch
<lifeless> nice
<jam> lifeless: I have not specifically, link?
<lifeless> I'm considering an upgrade, my 120GB is sooo full
<lifeless> http://launchpad.net/lmirror
<lifeless> https://codespeak.net/issue/pypy-dev/issue718 has some context and a piece of sample data
<lifeless> basically I have a dirstate like file format (done precisely because its easy to write a reasonably fast parser in plain python), but my attempts to write a go parser have been unwhelming on performance
<lifeless> I'm *considering* a rewrite to go rather than a C module for the python implementation (or even a C implementation)
<jam> lifeless: apparently the 200+ ones also give better performance, essentially RAID0 in the device
<jam> (interleaving reads/writes between chips)
<lifeless> jam: like they need better performance :>
<jam> that's a shame, you can go to "https://code.launchpad.net/~jameinel/bzr" but not ".../+junk"
<jam> lifeless: https://code.launchpad.net/~jameinel/+junk/godirstate
<jam> was my dirstate parser in go
<lifeless> jam: so I know this is a micro benchmark, but my basic attempts at getting even the tokenization in go felt very slow
<jam> lifeless: the #1 thing for single-threaded code is to try to use gccgo
<jam> since it has all of gcc's optimization abilities (inlining code, etc)
<jam> which is not present in 6l
<jam> the downside is that it explicitly spawns an OS thread for a goroutine
<jam> rather than the lightweight routines
<jam> lifeless: Do you have code where I can look at it?
<jam> I know when I wrote the Dirstate parser, I accidentally used bytes.IndexBytes instead of bytes.IndexByte
<jam> the former being pure Go, and the latter being ASM that uses SSE instructions, etc.
<lifeless>  http://pastebin.com/KUYS6aji was my last attempt
<jam> lifeless: your code is doing "bytes.Split()" which I believe uses IndexBytes. Using a loop around IndexByte is likely to be a lot faster
<jam> (IME)
<lifeless> interesting
<jam> I'm poking around with it now
<jam> It seems to take 1.1s on my machine with your 1.bz2 file from pypy
<lifeless> yeah, thats about right
<lifeless> real    0m0.842s
<lifeless> user    0m0.650s
<lifeless> sys     0m0.180s
<lifeless> CPython stringsplit is 0.25 or some such
<jam> so I'm wrong about the loop, at least offhand. http://pastebin.com/LPCHWYPB
<jam> takes 5s
<jam> instead of 1.1s
<jam> lifeless: you also have a small bug in your code. You pre-allocated the buffer, so it is full of '\x00' at the end. But you don't parse just up to "length"
<lifeless> ah, good catch
<jam> this one is down to 1s: http://pastebin.com/bWP7fSM2
<lifeless> I didn't see a 'read giving me the buffer' function for bytes
<jam> lifeless: ioutil.ReadAll()
<jam> I ran into that one by accident
<lifeless> real    0m0.544s
<lifeless> user    0m0.340s
<lifeless> sys     0m0.200s
<lifeless> so quite a bit better
<jam> lifeless: your original version was creating 10445784 strings, the new one is creating just: 3331175
<jam> so that is ~1/3rd the total strings
<lifeless> yeah
<lifeless> good catch
<jam> still about 2x slower than s.split('\x00')
<jam> If I use the IndexByte loop, and I pre-allocate enough space in the content, I get about the same performance
<jam> so it isn't particularly better
<jam> lifeless: so a nice bit, is that it is fairly easy to write a tokenize function that runs asyncronously: http://pastebin.com/ZUUPsNY8
<jam> it reads through the file, and spools the tokens to  the user
<jam> the downside, is that it runs 3.5x slower...
<jam> parsing the raw string in a goroutine is only 2.6x slower http://pastebin.com/1McKLdM4
<jam> so some of it is the overhead of repeated read calls
<jam> however, there is still a fair amount of time that is being spent in the goroutine synchronization overhead
<jam> lifeless: as I've roughly mentioned in my thread, I haven't really found a case where real-world go is faster than real-world python. If only because people have written extensions already. Also, I think memory management is faster in python
<jam> refcounting is usually quite fast as long as you don't have to run the cycle detector :)
<lifeless> jam: well, refcounting single-threaded sure, but multithreaded it just cache busts all over the place
<jam> sure
<jam> though stop-the-world-and-follow pointers seems to cache bust, too
<jam> I suppose if it was generational it would do ok
<lifeless> jam: runtime detection of 'used' seems to be the problem ;)
<jam> lifeless: clearly we would all be better off writing assembly
<jam> I've been poking at that the last few days... hard to get my head around it.
<jam> Especially when some operations work with some registers but not others
<jam> ROLQ BX, SI vs ROLQ CX, SI
<jam> one worked, but I couldn't tell you which one offhand
<lifeless> jam: iX86 assembler is one of the least regular around
<jam> yeah, and GAS is swapped order to other code, and ...
<lifeless> hmm, why does initialize call __enter__ ?
<jam> lifeless: because it is called "initialize()" not "give_me_something_to_initialize()"
<lifeless> doesn't that make it had to use as a context manager, or are folk expected to use the underlying class directly now ?
<jam> lifeless: poolie felt that it was very easy to forget to enter as a context manager
<jam> so he made it start the context by default
<jam> you can still use it as a context if you want
<lifeless> that will double enter though won't it ?
<jam> I think it is ok with that
<jam> I haven't looked specifically recently
<lifeless> hmmm, I expect __exit__ will not restore things correctly.
<lifeless> (because its saved state will be overridden by the second __enter__)
<lifeless> fortunately lp only has one use of bzrlib.initialize
<jam> lifeless: "if not self.started: self._start()
<lifeless> ah cool
<lifeless> thanks
<lifeless> this seems a little wierd to me, like __init__ having side effects;
<lifeless> anyhow, I'm perilously close to second guessing here
<lifeless> :)
<jam> lifeless: basically, the function is called "initialize()" which sounds like it is done
<jam> not "initializer()" or some other hint that you still have to call __enter__
<jam> we talked about it at the time
<lifeless> did you consider renaming it?
<jam> I think we felt that it wasn't worth an api break just for that
<jam> I suppose you could have "bzrlib.get_context()" and then have "bzrlib.initialize()" call that one
<vila> jelmer: thanks for the reviews !
<jelmer> vila: anytime :)
<jam> hey guys, just re-installing my system on a shiny new 240GB SSD! Just checking that IRC is working
<jelmer> ooh
<jam> now, of course, I have the problem that laptops only take 1 HD at a time
<jam> so I have to figure out how to connect the old one to get everything off of it
<jam> I have an esata port, I'm hoping I can use that
<jelmer> jam: should we be worried that perhaps now you won't have any reason for optimizing bzr anymore ? :P
<jam> jelmer: network is just as slow as it has always been
<jelmer> heh, ok :)
<guru3> I'm trying to merge into a branch with uncomitted changes that I want to remain uncommitted...
<guru3> I used --force to get the changes in, but now I can't commit only the merge.
<poolie> hi jelmer, jam, guru3
<glyph> hey guys
<jelmer> hi poolie, glyph
<jelmer> poolie: how's the data sprint?
<glyph> jelmer: So, I just encountered this: https://bugs.launchpad.net/bzr/+bug/799876
<ubot5> Ubuntu bug 799876 in Bazaar "dpush blew up again; CachingBzrRevisionMetadata mismatch" [Undecided,New]
<glyph> and, thanks to the fact that this isn't fixed
<glyph> https://bugs.launchpad.net/bzr/+bug/673884
<ubot5> Ubuntu bug 673884 in Bazaar "dpush ends up in a broken state if it encounters a network problem" [High,Confirmed]
<glyph> I need to go and hand-apply a hundred changes
<glyph> can you give me a clean way to rebase these?
<glyph> I promise, after this time, I'll just switch to git and stop expecting bzr to work properly. :-P
<poolie> very good
<jelmer> glyph: that looks like an old bug that's already been fixed :-(
<glyph> jelmer: I just installed 2.3.1 like a month ago
<glyph> it was the latest on bazaar.canonical.com
<glyph> jelmer: anyway, quick, while these patches still apply clean, how do I grab a specific N revisions and just apply them as patches to a local branch?
<jelmer> glyph: it looks like the mac installer is shipping an older bzr-svn
<jelmer> glyph: there is bzr replay, but that uses bzr metadata so it might not work
<glyph> jelmer: 1.0.5dev?
<jelmer> glyph: how many revisions did it push?
<glyph> 24 out of 31
<glyph> oh wait a second... maybe rebase -r?
<jelmer> glyph: my guess is that what will work best is to graph a clean copy of trunk and to try to run bzr replay for each of the 7 missing revisions
<glyph> jelmer: I'm playing the changes onto an svn branches so I can preserve the merge without getting all the bzr property crud into the repo
<jelmer> glyph: rebase -r might work too (but like replay, it also will break if e.g. new files were added in between)
<jelmer> glyph: Are revision properties really such a big problem?
<jelmer> poolie: cool :)
<jelmer> glyph: we really should fix that dpush continuation thing though :-/
<glyph> jelmer: yes
<glyph> jelmer: yes you should
<glyph> jelmer: the revprops are a problem because bzr's format is in flux, and my upstream svn repository is no joke
<glyph> jelmer: Twisted and CalendarServer's repos are both somewhat screwed because washort pushed a couple of revisions with v3 versions
<glyph> I *have* had our respective trac admins quash the property display though, so that once my experiences with bzr-svn have quieted down a bit, and I stop having tracebacks with every third branch I push, we can start using them
<jelmer> glyph: those are file properties though, the format bzr-svn uses for revision properties hasn't changed since it was introduced and has been present for the last two days
<jelmer> s/days/years/
<glyph> jelmer: there are still bugs related to that transition
<glyph> jelmer: wait, what?  v3 revision identifiers and v4 revision identifiers are definitely revprops
<glyph> I can dig around in the repository and find the problematic commits if you want
<glyph> but there are already bugs filed
<jelmer> glyph: I'd be interested to hear about the problematic commits, there appears to be one bug report about about v3 properties at the moment, but that's in a private repository so it's hard to debug.
<jelmer> poolie: Did you see my email about bfbia?
<glyph> jelmer: OK.  Maybe in a bit :).  first, I need to get these commits fixed
<glyph> jelmer: rebase -r isn't working
<glyph> If I have my upstream branch and my downstream branch
<jelmer> glyph: have you tried replay?
<glyph> jelmer: what's the difference?
<glyph> I mean I'll gladly try it, I just want to know what it's doing :)
<jelmer> glyph: replay just does one revision, and is a fancy form of "bzr merge -c + bzr commit"
<poolie> jelmer: no, but i can look
<glyph> jelmer: the help for '-r' on replay is incredibly unhelpful.  Should I just try it with no args, and it will figure out where to start?
<jelmer> poolie: I'd like to send a request for feedback to launchpad-dev@ but I just wanted to give you the chance to object, if you think it's a bad idea to split it up or to look at it at this point.
<poolie> i have 900 unread at the moment
<glyph> ah, it's undocumented _and_ mandatory
<poolie> :/
<poolie> that's great, thanks jelmer
<jelmer> poolie: thanks :)
<jelmer> glyph: it just takes the revision number of the source branch to replay
<glyph> woah
<glyph> it looks like that worked flawlessly
<jelmer> I have no idea if it will work, since the branches have diverging history and replay relies on matching fileids, etc
<glyph> and did exactly what I _thought_ rebase -r would do (although with src and dst reversed, obviously)
<glyph> jelmer: no added files, thank goodness
<jelmer> glyph: I'm as surprised as you are :)
<glyph> jelmer: well now I want to know why rebase didn't work :)
<jelmer> glyph: rebase rebases revisions in the current branch on top of an upstream branch
<glyph> jelmer: http://trac.calendarserver.org/changeset/7630 is the commit I just pushed
<glyph> Oh
<glyph> oh my goodness
<glyph> that is super weird
<glyph> This is arguably actually user error
<glyph> There really *are* no changes in this revision, so bzr has no idea how to associate it with the branch!
<amdahlj> I'm trying to initialize set up a workflow where code is stored in central repository and people working on it check out from that repository.  After I run init however, it seems like there are no branches to check out from
<jelmer> glyph: :-(
<glyph> jelmer: well, it makes _me_ feel a little better
<glyph> I'll note it on the bug
<glyph> If I don't make this dumb mistake in the future, I won't have this error
<amdahlj> Hi everyone, I'm having quite a bit of trouble getting init, checkout and commit to get the kind of system I would like
<poolie> ok, tell us more
<amdahlj> What I'm trying to do is organize a central repository where code is checked out by multiple people, edited, and then changes are committed back to the central location
<amdahlj> When I try to do this, I start by running init pointing towards where I want the central location
<amdahlj> Then I check that out to the local location, add the starting files of the project and then commit it back to the central location
<amdahlj> When I do that, none of the code in the local directory ends up in the central directory, which confuses me
<poolie> ok
<poolie> do you mean, not in the repositoyr, or just not in the central working tree?
<poolie> the working tree won't be automatically updated
<poolie> so if you want to see it ther, you need to go to the server and just say 'bzr update'
<amdahlj> I don't mean specifically in the working directory.  I don't see a working directory in there.  I mean there is nothing at all in the central directory
<amdahlj> even after succesfully commiting to that location, it is still empty
<amdahlj> Ah, now I understand the working tree distinction
<amdahlj> apparently by default the repository is hidden
<amdahlj> Now I understand that it's not going to actually assemble a working copy unless I update manually.
<poolie> right
<amdahlj> Hmmm, any idea what the command is to bring up the gui version of checkout?  The usual pattern seems to be q + commandline command but qcheckout doesn't work
<maxb> amdahlj: I have no idea why, but it appears to be qgetnew
<amdahlj> thanks max
<maxb> vila: Hi. Have you had a chance to think about https://code.launchpad.net/~vila/udd/795703-fix-tags/+merge/64952 ? I'm hoping that they will get to deploy LP tomorrow
<poolie> amdahlj: you could file a bug against qbzr
<poolie> pad.lv/fb/qbzr
#bzr 2011-06-21
<Riddell> bonjour
<vila> Riddell: hello !
<maxb> vila: Hello. Now that fixit.sh is merged, shall I translate my existing commands from the bugreport to use it?
<vila> maxb: for extra clarity, it would be nice, but you don't have to
<vila> maxb: did you have confirmation of the deployment ?
<vila> err, off the lp side of things
<vila> s/off/of/
<maxb> Still waiting on that
<vila> ok
<maxb> it will be easy enough to translate the commands - I will just rewrite my version of the shell functions to ones which echo code in the new format
<vila> maxb: I'll wait for your ping then
<vila> :)
<vila> maxb: oh, by the way, I did a launchpad-login on jubany and this seems to work
<vila> maxb: just one more thing to keep an eye open for for a few days (in case this triggers something (not that I can think of any though))
<vila> s/any/&thing/
<jelmer> hah, hello for real
<Riddell> jamesh: did you see my request about https://code.launchpad.net/~jr/bzr/bzr-gpgme/+merge/64859 ?
<poolie> hi all
<poolie> thanks for that riddell
<Riddell> for the gpg stuff?  you're welcome :)
<vila> hey poolie
<poolie> hi vila
<maxb> Riddell: One thing which occurred to me looking at your examples.... OK, 1 commit not valid..... which commit? :-)
<vila> the invalid one ;-P
<Riddell> maxb: you use -v to show you the invalid author and bzr log --signatures to find the commit
<Riddell> I did think of having  bzr verify -vv  or something for very verbose which showed each commit but then why not just use bzr log
<vila> Riddell: convenience
<vila> why use 3 commands if one is enough ?
<poolie> in the log perhaps it would be good to show the key id
<poolie> vila, i was wondering if you could share your todo list or plan for babune
<poolie> or summarize it, if the current one is too cryptic or detailed
<vila> http://paste.ubuntu.com/630417/
<poolie> thanks
<poolie> that looks good
<poolie> i think it would be good to get it off your own personal hardware, for a couple of reasons
<vila> yes ! bug #688101 is almost dead ;)
<ubot5> Launchpad bug 688101 in Bazaar "Failing to bzr resolve multiple conflicts bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]" [High,In progress] https://launchpad.net/bugs/688101
<poolie> hooray
<poolie> one being so it's not down if you're away
<vila> and it may be the last case where we have multiple conflicts for the same file...
<poolie> also so we can run more builders
<poolie> and, also, so other people can co-admin it
<poolie> i'm setting up usertest again and it would be nice if that was actually driven by jenkins not cron
<poolie> (perhaps)
<poolie> oh, also i was remembering that thing at our recent sprint of "i have to wait until i get home to do this"
<vila> sure, as long we keep the ability to admin it
<vila> ha, that would be mostly addressed if the sources were public
<Riddell> what is baboun?
<poolie> i think probably our own machine, but on a server somewhere else
<vila> Riddell: http://babune.ladeuil.net:24842/
<poolie> Riddell: it re-tests bzr on other operating systems than that run by pqm
<maxb> abentley: Hi, would you be able to offer some comments on bug 796748 when you have a moment?
<ubot5> Launchpad bug 796748 in Bazaar "TreeTransform canonicalises symlink-containing paths wrongly" [High,Confirmed] https://launchpad.net/bugs/796748
<abentley> maxb: what kind of comment are you looking for?
<maxb> To start with, a quick sanity check - and maybe an explanation why treetransform is canonicalizing symlinked paths at all
<abentley> maxb: paths are canonicalized so that you cannot get two trans_ids for the same path.
<maxb> It makes sense to me to canonicalize /./, /../, // etc. - but I'm less convinced about expanding symlinks to their underlying path
<abentley> maxb: symlinks themselves should not be transformed to the path they point at.  Files under those symlinks should.
<maxb> Why should they?
<abentley> maxb: otherwise, you wind up with two references to the same file, and that will break TT.
<maxb> In that bug, I've found a situation where the current canonicalization gives the same trans_id to two paths which are actually distinct, and that breaks it too
<abentley> maxb: Another way to fix it would be to forbid traversal through symlinks, and perhaps that's what I should have done.
<maxb> That sounds like a practical option for fixing this
<abentley> maxb: I don't think you've found a situation where the same trans_id has been given to two different paths.
<maxb> No, I really have. I hacked in some print statements and observed it
<abentley> maxb: A trans-id can only refer to one path in the source tree.
<maxb> Well, it's *supposed* to, yes. But that got violated
<abentley> maxb: It cannot, unless you change the source tree while the TT is active.
<abentley> maxb: Which is against the rules.
<abentley> maxb: Maybe "paths" is incorrect.  I don't think you've found a situation where the same trans_id has been given to two different files.
<maxb> OK, that's partially true. There was one trans_id, assigned to two paths, which both led to the same file in the source tree
<abentley> maxb: Right.
<maxb> But, the intent was to drive the TT to remove the symlink involved, and put two distinct files at the two paths concerned
<abentley> maxb: How are you driving it?
<maxb> via "bzr import-dsc"
<abentley> maxb: without looking at the code, it sounds like a bug in bzr import-dsc.
<maxb> I'm not really convinced
<maxb> If I have this tree:
<maxb> lenny/
<abentley> maxb: I'm not either.  But since I don't know what the code is trying to do, I don't know what the bug is.
<maxb> lenny/some-file
<maxb> squeeze -> lenny
<maxb> Can you describe a valid way to drive TT to remove the squeeze symlink, create a squeeze directory, and a file squeeze/some-file ?
<abentley> maxb: sure.  This will take a sec.
<abentley> maxb: Now, what do you want to do about the original some-file?
<maxb> for the sake of this example, let's say we want to update its text content, only
<abentley> maxb: so you want to create a new some-file at squeeze/some-file, and update the contents of lenny/some-file?
<maxb> yes
<abentley> maxb: http://pastebin.ubuntu.com/630431/
<maxb> abentley: OK.... is it considered technically invalid to attempt to create squeeze/some-file in a way involving a call to tt.trans_id_tree_path('squeeze/some-file'), before the squeeze directory is real on disk?
<maxb> If so, import-dsc is running afoul of that
<abentley> maxb: no.  You can do tree transform operations in any order.  That's part of the design.
<maxb> Ah.
<abentley> maxb: However, You cannot create squeeze/some-file at all using trans_id_tree_path.
<maxb> Right... *that* is the violation going on here, then
<abentley> maxb: Because in the tree, squeeze/some-file was lenny/some-file
<abentley> maxb: Since you're replacing squeeze with a directory, squeeze/some-file must be a new file, or you must move lenny/some-file.
<maxb> I'm unclear what you mean by "must be a new file"
<maxb> Or why moving lenny/some-file should matter
<abentley> maxb: by "must be a new file" I mean it must be a file with a new trans-id.
<maxb> Well, quite. I want it to be. And it would be if trans_id_tree_path didn't follow symlinks
<abentley> maxb: No, it would be an existing id in that case, too.  You'd just have two existing ids for trans_id_tree_path, one for squeeze/some-file and one for lenny/some-file.
<maxb> hmm
<abentley> maxb: I think you may not realize that trans_id_tree_path refers to paths in the source tree.
<maxb> OK, so it sounds like import-dsc is being lazy in how it constructs the TT
<abentley> maxb: and therefore nothing you do in the transform should change its output.
<abentley> maxb: that seems possible.
<maxb> Alright, this conversation has clarified that the code in import-dsc was written cutting some corners in how to properly drive TT, and needs an overhaul - thanks.
<abentley> maxb: np.
<maxb> (the same code is present in bzrtools, ftr)
<abentley> maxb: Yes, I think I didn't anticipate the problems with replacing a symlink with a file.  Aside from that, using the tree paths seems fine.
<abentley> maxb: have you filed a bug on import-dsc or bzrtools?
<maxb> No, only the one on bzr, at present
<abentley> maxb: what's the project for import-dsc?
<maxb> builddeb
<abentley> maxb: I've filed bug #800270
<ubot5> Launchpad bug 800270 in BzrTools "import-tar incorrectly handles symlinks turned into directories" [Medium,Triaged] https://launchpad.net/bugs/800270
<ccxCZ> is there bzr webinterface that can generate static files as on-push hook, that could be then simply served via webserver?
<jelmer> ccxCZ, there was a bzr-html plugin that did that, though very rudimentary
<ccxCZ> hmm, nicehtml is 404 and htmllog is just commit message log
<jelmer> ccxCZ, what sort of information are you looking for?
<ccxCZ> well, mostly what loggerhead does, altough it doesn't have to be so fancy-ajaxy
<jelmer> I don't think there is anything like that (or even close to that).
<jelmer> More than just dumping the current contents to disk would also require an insane amount of disk space for any project with a nontrivial amount of history or a non-trivial tree.
<jelmer> loggerhead IIRC has one page per revision of each file (including markup), and then some
<ccxCZ> hmm, when I do bzr log -n 0 -p on my projects it doesn't go over few megs
<ccxCZ> I think it should be reasonably doable for smaller projects
<jelmer> ccxCZ: That shows the diffs though, not the full file contents (like loggerhead)
<ccxCZ> yes. I expect it would be significantly larger than that, but it gives some estimate
<maxb> Hurrah, LP fix is deployed. vila / james_w / spiv : If you happen to be around, requeue_package.py --all-of-type bzr please?
#bzr 2011-06-22
<Kamping_Kaiser> can i use bzr-buildpackage with only debian/ in revision control, or do i need to have upstream source there too?
<lifeless> it can work either way
<Kamping_Kaiser> perfect. i'll just keep debian/ around then.
<Kamping_Kaiser> thanks :)
<AfC> Say I've previously I did a
<AfC> $ bzr branch lp:ubuntu/empathy natty
<AfC> It was "natty" at the time. Now I pull and suddenly it's "oneiric". I guess it did what I told it to, but I surely didn't get what I wanted; I thought I had a branch with natty's version in it
<AfC> Is there a modification to the lp:ubuntu/package syntax to bind it to a specific release series?
<mwhudson_> AfC: i think lp:ubuntu/natty/package works
 * AfC tries `bzr missing` with that
<AfC> Grr. Why oh why is it transferring megs and megs of data to give `missing --line` when I already have the revisions present!
<AfC> Anyway
<AfC> mwhudson_: yes, that works. Thanks
<Kamping_Kaiser> related to my last question, is it possble to copy the debian/ dir between repositories keeping history? i'd like to move it from packagename/debian into shared/packagename/debian so i don't have to carry all the source too
<AfC> If I would like `bzr builddeb` to build both a source package and a .deb binary package, what options would I do?
<AfC> $ bzr builddeb -S -- ...
<AfC> seems not to build the .deb
<AfC> (ok, fine)
<AfC> but what is the complimentary option?
<AfC> Or should we not use `-S --` and instead be doing `-- -S -sa` or so?
<Kamping_Kaiser> -S == source only
<AfC> [the other problem I ran into is about 1 of 15 packages I've done lately didn't have the .orig.tar.gz available in target distro, so uploading to PPA bombed, whereas the rest of the time it all Just Workedâ¢ leaving me quite gunshy]
<AfC> [and thinking for good measure I should always be passing `-- sa`
<thumper> hi bzr people
<thumper> I have some code right now that works on working trees
<thumper> handling things like adding or editing files
<thumper> I want to write some other code that does the same work, but works on a branch instead
<thumper> how do I get a tree representation of a branch that I can use like a working tree?
<thumper> is a revision tree the way to go?
<lifeless> yyou can use a revision tree + a transform
<lifeless> the lp translations export code does this, if you want to cargo cult
<thumper> hmm...
<thumper> lifeless: ta
<vila> maxb: about to restart the package importer, anything I should know ?
<maxb> vila: for anything in particular?
<vila> maxb: well, no, that's the trick :) Anything that crosses your mind !
<maxb> I was wondering if I need to fix my change to the path to lp_creds.txt first
<vila> maxb: p-i stopped
<vila> maxb: argh, landed ?
<maxb> yes
<vila> maxb: wait, no need, your change is ok for jubany right ?
<vila> so you can do that later
<maxb> I thought it was ok, but now I think I may have miscalculated the number of dirname calls
<vila> maxb: depends on local setups if I read it correctly it works for udd/branch but not for udd/bugs/branch and anyway you can't have both
<vila> maxb: the real solution is to have it in pkgimport.conf anyway
<maxb> I am somewhat unconvinced about pkgimport.conf, unless it supports relative paths
<vila> maxb: waiting for GSA to update the script and then start the pi again
<vila> maxb: relative to what ?
<vila> to the file itself ?
<maxb> Possibly
<vila> wow, 'somewhat' 'possible', you make it hard to satisfy :)
<maxb> Anyway, I think jubany is now going to be looking for lp_creds.txt in the wrong place - /srv/package-import.canonical.com/new/scripts/ rather than /srv/package-import.canonical.com/new/ :-/
<vila> what's wrong with conf file ?
<vila> maxb: are you sure about that ? losa is ready to start it again, should I hold him ?
<maxb> Yes, sure :-(  Probably best to just put in a symlink for now, to not block on admin actions
<maxb> i.e. cd /srv/package-import.canonical.com/new/scripts/ && ln -s ../lp_creds.txt
<vila> maxb: confirmed
<vila> maxb: done
<vila> maxb: re-started
<maxb> thanks
<maxb> can you requeue --all-of-type bzr ?
<vila> maxb: and stopped
<maxb> oh
<vila> maxb: and started again
<maxb> ?
<vila> mass-import is bogus for 'restart' it doesn't delete STOPFILE, I'll file a bug and fix
<maxb> oh, heh
<vila> maxb: requeue done
<maxb> I have also filed a MP to minimally undo my path thinko
<vila> maxb: cool, could you mention that we need to delete the symlink when this lands ?
<maxb> s/need to/can/, but yes
 * vila nods
<vila> maxb: just making sure someone don't run into it and spend time wondering why it's there
<maxb> Hmm, there are a bunch of spurious failures - I suggest requeue_package.py --auto linux-restricted-modules haskell-utf8-string language-pack-kn language-pack-sq-base
<vila> maxb: old spurious or new spurious ?
<vila> maxb: wow, nice to the failure split !
<vila> maxb: requeue done
<vila> rhaaa lovely... finally I can type just 'categorise_failures.py'
<maxb> oh?
<vila> yeah, fixit.sh set the right env vars....
<maxb> So, 465 failures... now we just wait to see how many of the currently retrying ones succeed :-)
<vila> maxb: should we proceed with bug #795703 then ?  :D
<ubot5> Launchpad bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check)" [Undecided,New] https://launchpad.net/bugs/795703
<maxb> Yes - shall I sort the instructions for the new fixit syntax now?
<vila> maxb: as you will, I'm doing it right now, we can compare notes (I don't mind a double-check there ;)
<vila> s/will/wish/
<vila> s/as you wish/yes, please do/
<vila> or something ;)
<vila> hmm, right, UI mistake, the package should come first, that's what we are acting upon (a GUI could display the relevant packaging branches or even tags, allow selection then action)
<vila> we'll see to it later
<maxb> done, posted to the bug.
<maxb> And I wish launchpad could be asked not to line-wrap for displa
<maxb> y
<maxb> it all comes out right in copy/paste, though
<vila> at least copy/pastin works...
<vila> hehe
<maxb> awesome, the failure count is going to settle at at most 469 already
<maxb> which is a nice step down from the 485 we were at when all this LP mess started
<vila> maxb: yeah, well done
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | UDD failures: 465
<vila> maxb: http://paste.ubuntu.com/630689/ ok ?
<maxb> ah, oops. yes
<vila> no problem, I had one too :) double checks are good :)
<vila> maxb: procedding
<vila> a bit slow
<vila> of course establishing ssh connection for each command doesn't help
<maxb> Right, so that's A through E.
<maxb> I should have a look at the rest of the alphabet :-)
<vila> owww
<vila> done
<vila> maxb: and report posted on comment
<maxb> Hmm, I need to revisit bug 494481 one of these days
<ubot5> Launchpad bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged] https://launchpad.net/bugs/494481
<vila> maxb: pfew, that took long overall (sorry for that) but I think it's a nice step in the right direction
<vila> maxb: feel free to update the topic ;)
<maxb> I'll be waiting on that to check that they *actually* succeed :-)[5~
<vila> shouldnt' be long now, 0 outstanding jobs
<vila> jam, Riddel: jelmer being sick, spiv offline, poolie sleeping, sprint next week, should we drop the standup ?
<jam> vila: I'm fine either way
<Riddell> I don't mind
<maxb> Hmm, it's looking quite achievable to drive the Ubuntu main UDD failure count below 100 in the next fortnight
<Riddell> was going to try and convince people to review my gpg stuff
<Riddell> do we know what we're doing at the sprint next week?
<vila> maxb: what about bug #796751, should it be marked invalid ?
<ubot5> Launchpad bug 796751 in Bazaar "TreeTransform _override_conflicts checking is not sensitive to symlinks" [Medium,New] https://launchpad.net/bugs/796751
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | UDD failures: 455
<vila> \o/
<maxb> Yes, I think it should
<maxb> done
<vila> hehe, done too :)
<vila> maxb: boom http://webnumbr.com/ubuntu-package-import-failures.from%282011-06-16%29 :)
<vila> maxb: setting bug #795703 on the assumption that you'll post more there
<ubot5> Launchpad bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check) [package names A through E]" [Undecided,In progress] https://launchpad.net/bugs/795703
<vila> maxb: setting it 'im progress' that is...
<maxb> hah, nice graph
<maxb> vila: I've landed the lp_creds.txt path change, if you want to deploy and then remove the symlink
<vila> maxb: done, waiting a bit to delete the symlink (just because)
<vila> maxb: ha right, just got your mails about the symlink, good, we're on the same page
<Kamping_Kaiser> is there a way to make bzr only show files below `pwd` that have been modified? (like svn would). i keep trying to copy+paste the paths it tells me are modified and realsing i'm not in the repo root
<vila> Kamping_Kaiser: not that I know of but I'm pretty sure there is a bug about that
<Kamping_Kaiser> vila: i'll have a look on lP, cheer
<Kamping_Kaiser> s
<Kamping_Kaiser> can i do something in bzr if i want to redirect http attempts to access foo/packages/ so its foo/packges-version instead? would i have to do it using the webservers rewriting, or can i use bzr somehow?
<a7ndrew> There's an incomplete sentence at http://doc.bazaar.canonical.com/latest/en/mini-tutorial/#starting-a-new-project where would be the best place to report that?
<Riddell> a7ndrew: bugs.launchpad.net/bzr  or if you can work out how to fix it we can just commit the fix
<Riddell> well I know how to fix it, just need to think about what text
<a7ndrew> I'm not quite sure what the author meant to say to finish off that sentence.
<Riddell> a7ndrew: well report a bug and we'll get to it
<johnf> How would it be possible for me to have a shared respository which also seems to have revisions in it? i.e. it has shared sub branches but if I run bzr log I also have revisions
<johnf> This repo was originally created in 2006 so it is quite old
<briandealwis> johnf: you can have a branch coexist with a repository.  In fact a standalone branch is exactly that
<briandealwis> I remember being puzzled by this too
<poolie> hi all
<poolie> johnf, i think we now warn if you try to create that but it may have been possible in the past
<poolie> or, obviously, yo ucould just move the branch directory
<Riddell> good $timeOfDay poolie
<Riddell> poolie: I don't notice any warning if i run init-repo then init
<poolie> hello there
<poolie> hm
 * maxb marves at bug 800771
<ubot5> Launchpad bug 800771 in Bazaar "pull -overwrite overwrites not only files but all information about commits" [Undecided,New] https://launchpad.net/bugs/800771
<maxb> *marvels
<fullermd> Impressive.
<ScottK> Nice.
<pommeverte> hello
<pommeverte> I have a question (that may sound a little stupid). But I have a project that is going to be setup for a few clients. Each client will have specific (personal) code implementations. I was thinking of branching my project for each client but then how would I go about correcting, say.. a bug accross all branches?
<pommeverte> or am I not going the right way with this?
<pommeverte> I'm kind of looking for a way to make patches
<pommeverte> is there maybe a way to shelve changes and then share them with another diverging branch? Or is there maybe a way of merging a single commit and dealing with conflicts?
<pommeverte> Any help would be appreciated I couldn't seem to find anything about this in the documentation
<jelmer> pommeverte: do you mean like "bzr merge -c" ?
<pommeverte> hmmm what does the -c do?
<pommeverte> (looking through man)
<jelmer> merges just the changes in one particular revision
<pommeverte> hmm well yes that sounds exactly like it. Completely overlooked it since I checked the (outdated) man online
<pommeverte> thanks
<pommeverte> do you think this is the best way of going about it?
<jelmer> I think so
<pommeverte> ok perfect. Thank you very much
<poolie> hi jelmer
<jelmer> hi poolie
<poolie> how's your week?
<jelmer> apart from the sick day, pretty good
<jelmer> I did some more Launchpad work this week, and had a look at adding support for multiple upstream tarballs in the package importer.
<poolie> oh, right
<poolie> i hope you're feeling better
<jelmer> I am, thanks :)
<etenil> Hey there
<maxb> Hello
<etenil> I've made a small bzr repo on my server. My workflow is to create branches for each feature I work on and then merge them into trunk and delete the now useless branch. I've discovered I can easily push new branches up to my small server, but I haven't found yet how to delete them.
<etenil> Could you give me a hand?
<maxb> There is not a command within bzr itself for deleting branches. People usually just rm -rf them
<etenil> ah
<etenil> :/
<etenil> the thing is, I'm not working alone, and I'm restricting the ssh access of the other devs to running bzr
<etenil> is there really no way to accomplish this but rm -rf?
<maxb> bzrtools provides "bzr zap --branch" - i've never used it though, so I don't know if it works remotely
<etenil> well that's a start anyway. I'll give it a try
<etenil> thanks maxb
<etenil> mmh
<etenil> that doesn't seem like the right thing.
<etenil> I guess I'm good for posting a feature request :)
<__yhvh__> hey I built in a recently downloaded repo, did make clean and make distclean, bzr status shows loads of files changed
<__yhvh__> I also rm'ed the whole thing and d/led again fresh but the modified still show up,
<__yhvh__> is this info stored outside the repo dir?
#bzr 2011-06-23
<jam> morning all
<jelmer> hi jam
<jam> hi jelmer, feeling better?
<jelmer> yeah, much better
<jam> I still mean to have you come out and visit us in Eindhoven sometime. Maybe after we settle from the sprint?
<vila> hi jam, jelmer
<jam> hi vila
<vila> jelmer: glad you're feeling better !
<fullermd> Well, I guess if .eu is here, it must be time for me to go...
<jam> fullermd: I didn't think you ever left
<fullermd> Well, I'm almost always right, but I'm occasionally left.
<vila> fullermd: careful, you may end up falling asleep
<jelmer> jam: Yeah, me too
<fullermd> Sleep?  I just did that _last_ week...
<jelmer> 'morning vila, fullermd
<vila> maxb: wrong revid used in bug #795703 (but the tags have been deleted nevertheless)
<ubot5> Launchpad bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check)" [Undecided,In progress] https://launchpad.net/bugs/795703
<vila> maxb: I won't apply the other ones until you give feedback
<maxb> vila: Oh dear, do I fail at copy paste?
<maxb> gnome-mousetrap, right?
<vila> maxb: That's my fear :-/ (I know I often fail there because of my unusual setup where the clipboard content can randomly (really ? :-/) be wrong so some copies are lost and I end up pasting an old value...
<vila> well, often is exaggerated but that's not rare enough to be really annoying
<maxb> Oh,yes. The revid I put for gnome-mousetrap is the same as the one from git-buildpackage above
<maxb> I think the I and K commands should all be safe, since I was wise to the problem by then - but apparently I missed one instance near the beginning
<vila> maxb: yes, I saw the duplicate but had of course no idea what the right one could be
<maxb> I've updated the bug now
<vila> cool
<maxb> For some reason, qbzr seems particularly prone to copy / paste weirdness
<maxb> Maybe that's what I get for using one Qt app in a Gnome desktop
<maxb> oh. I failed, with the same revid, for gphoto2 and gst-plugins-base-0.10 too
 * maxb sorts
<maxb> and apparently I fixed gnumeric on breezy, but now it's failing on hoary-security
<maxb> Whilst you're on jubany, could you also requeue --full ubuntu-defaults-builder ?
<vila> maxb: done
<vila> maxb: +1 for requeue in fixit.sh, it even allow c/p from IRC... :-p
<vila> maxb: almost a natural language UI (for some geek value of natural ;)
<maxb> I was just thinking something like that :-)
<maxb> vila: You saw my updated commands for gst-plugins-base0.10 gphoto2 gnome-mousetrap?
<maxb> (Just wanting to be sure since they partially interleaved with your comments on the bug)
<vila> maxb: gphoto2 and gst-plugins-base done
<vila> maxb: that's an interesting experiment, let's keep posting there if only to capture what happened (errors included)
<vila> and *of course* no offense intended, I hope that's clear
<vila> I *expect* errors
<vila> that's why I wanted to capture recipes in fixit.sh
<vila> I know no better way to design UI...
<vila> maxb: also, any error should end up in some trace at http://package-import.ubuntu.com/status/ right ?
<vila> or can there be some fallouts for users with local branches ?
<maxb> Thanks, that's looking better - but, did you miss my comment #16 for gnome-mousetrap?
<vila> ha crap, yeah, it seems
<maxb> oh,
<maxb> maybe not
<vila> err
 * vila blinks
<maxb> ah, you did the tags, but not the requeue
<vila> my comment appears *after* yours ?
<maxb> Right - sorry.
<maxb> I was attempting to match up the failures page and the bug
 * vila notes to use two pages: one to copy/ one to paste
<maxb> So, you did in fact do my second fixup to gnome-mousetrap's tags, but did you requeue it again?
<vila> yeah, a real UI involving a single user would probably address these cases
<vila> maxb: yup, I just requeued it
<maxb> great!
<maxb> so
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | UDD failures: 444
<maxb> :-)
<vila> nice number, let's stop there ! :D
<maxb> hmm
<vila> magcius: ha, just found your comment on #714622
<vila> gha
<vila> magcius: sorry
<vila> maxb: ha, just found your comment on #714622
 * magcius looks up bug #714622
<ubot5> Launchpad bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
<vila> double gha
<vila> magcius: wrong nick completion, sorry for the noise
<vila> rhaa, what's the bug # for selftest not using python provided definition for number of available processors/threads ?
<jelmer> vila: are you sure we have one? IIRC we only use the python provided one in some cases
<vila> oh, may be a fix has landed, let me check the annotations
<jelmer> I landed a fix for the number of processors on *BSD earlier
<vila> ha right, no bug, but that's revno 5683 by... you :)
<vila> yup, I thought that was still pending
<vila> could be cleanup up now that we require py26
<vila> hmm, the python impl slightly diverge from our fallback... (sunos5 and even darwin)
<vila> ok, forget about it
<lifeless> poolie: bzr: failed to report crash using apport:
<lifeless>      OSError(17, 'File exists')
<lifeless> poolie: have you seen that before?
<jelmer> lifeless: I've seen it before on occasion, but I'm not sure what causes it
<jdobrien> lifeless, he's here in orlando AFAIK
<lifeless> jdobrien: yes, he is
<briandealwis> git users: is there a git equivalent of bzr's append_revisions_only?
<jelmer> briandealwis, I'm not sure how it works exactly, but I think the term you're looking for is "fast forward only"
<briandealwis> jelmer: thx for the pointer
<RobOakes> Good morning. Is anyone aware of a tutorial that describes how to keep packaging information and the source code of a project in separate branches?
<RobOakes> I am trying to set up a launchpad recipe similar to the one shown here: http://www.youtube.com/watch?v=_bG-SXNX9Ww
<RobOakes> My biggest problem is that my packaging branch and my code branch don't share a common ancestor. Is there any way around this? (I don't want all of my source history as part of the packaging branch, just the debian folder.)
<jelmer> RobOakes: you can use the nest command if you don't want them to have shared history
<RobOakes> What would be the best way to do this? Do I need to create a new branch with the nesting command?
<RobOakes> Sorry, my knowledge of bzr is pretty basic. I basically use it like SVN, and you can't do fancy stuff in SVN.
<jelmer> RobOakes, the nest command would be in the recipe
<jelmer> RobOakes: I usually just merge the source history into the packaging branch, is there any reason you don't want to do that?
<RobOakes> Yes, it's due to size.  The program I'm packaging, LyX, has 20 years of development history and some 300,000 commits.
<RobOakes> I'm actually curious if I can do a lightweight checkout with the source so I don't have to wait for the entire source history to download. (On my local machine.)
<RobOakes> Would the nest line look something like this: merge packaging nest lp:~...
<jelmer> no, it would be nest rather than merge
<RobOakes> Okay. Is there a difference between nest-part and nest?
<RobOakes> (bzr help is being less than helpful and Bug report which discusses them doesn't delve into the differences.)
<maxb> You'd use nest if the debian/ directory *was* the packaging branch, nest-part if the debian/ directory was contained within the packaging branch
<maxb> i.e. whether you need to nest a whole branch or just a subtree of one
<RobOakes> Okay, so something like this: nest packaging lp:~lyx-outline-devel/+junk/lyx-debian debian?
<RobOakes> If I wanted to place the entire contents of lyx-debian into a folder called debian?
<poolie> lifeless: hi, it's vaguely familiar, the thing would be to work out which file or line is raising it
<jelmer> 'morning poolie
<poolie> hi there jelmer
<jamdahl> Hi everyone, I'm having some difficulty with bazaar allowing out of date checkouts to make commits
<maxb> Can you elaborate on what you mean?
<jamdahl> Ok, so I have a project initialized to a central location
<jamdahl> and 2 separate checkouts of that
<jamdahl> Checkout 1 makes an edit and commits
<jamdahl> Checkout 2 makes a conflicting edit and commits
<jamdahl> My problem is that checkout 2 got no warning and was allowed to commit
<jamdahl> any ideas?
<jelmer> jamdahl, how were the checkouts created?
<jamdahl> bzr checkout remotedirectory localdirectory
<LarstiQ> evening
<lamalex> hi, does bzr grep search history? is there a plugin that will grep a projects history for some pattern/lines of code?
<jelmer> jamdahl: that's odd - what happened to the contents of the remote branch?
<maxb> jamdahl: Are you sure no one used "bzr branch", "bzr unbind" or "bzr commit --local" anywhere in this?
<jamdahl> I'm testing this so I did it all myself.  None of those commands were used
<jamdahl> bzr checkout was used for checkout, bzr qcommit was used for commit
<LarstiQ> lamalex: afaik that is exactly what bzr-grep does
<lamalex> LarstiQ, i guess i just need to give it revs to search
<lamalex> expected it to just automatically search backwards through history
<LarstiQ> lamalex: doesn't `bzr help grep` say?
 * LarstiQ installs it
<LarstiQ> lamalex: if you don't specify a revision, and also not a filename, it seems to grep through history
<LarstiQ> or maybe the help can use some rewording
<jamdahl> I think I have narrowed down the problem actually
<jamdahl> or at least part of it
<jamdahl> apparently when I am calling commit, diff, and some of the other commands it isn't doing it on the entire checkout
<jamdahl> The project I'm version controlling is a spreadsheet with the VBA code exported.  The spreadsheet is in the main directory  and the vba code is in subfolders
<lamalex> LarstiQ, hm.. I mean it just outputs (for me) what's in the current rev without any rev numbers or anything
<lamalex> unclear if it goes through branches that were merged and so on
<jamdahl> It seems like much of the time when I call for a commit or try to check diff, it doesn't notice the change to the spreadsheet
<LarstiQ> lamalex: ok, needs some rewording then. -r to the rescue!
 * LarstiQ heads for dinner
<lamalex> thanks
<poolie> hullo all
<lifeless> hi
<poolie> hi there
<LarstiQ> hi poolie, lifeless
<lifeless> hi LarstiQ
<jelmer> nÃ¥vond
<LarstiQ> hey jelmer :)
<maxb> jelmer: FYI bzr-builddeb r571 "Merge cleanup of DistributionBranch upstream attributes." causes problems for the udd importer - I guess that needs a related update. What were your intentions re compatibility there?
<jelmer> maxb, I hadn't realized I had broken the udd importer - will have a look now.
<milleja46> hi
<maxb> jelmer: If you look in the importer's make_db_set, there's a construction of DistributionBranch with a None second argument - I think the blame is there
<maxb> milleja46: hello
<milleja46> i need to pull some updates for a project but i don't know how to set the bzr_ssh variable...what would the bzr_ssh variable be?
 * milleja46 remembers he has to have pagent loaded XD
<maxb> jelmer: "./import_package.py --no-existing --no-push python-oauth" is a relatively quick reproducer
<maxb> milleja46: Oh. Windows. I don't know about that stuff :-)
<LarstiQ> milleja46: iirc it doesn't always need to be set
<LarstiQ> milleja46: but one option is "plink"
<milleja46> LarstiQ: i know but i think i'd forgotten that i needed to have pagent running XD
<LarstiQ> milleja46: ah right
<milleja46> LarstiQ: is there a way to add plink to environment variables so that i don't have to set it again?
<LarstiQ> milleja46: iirc there is an "Environment Variables" setting somewhere in System
<LarstiQ> milleja46: you can add BZR_SSH=plink there
<milleja46> so in the value part put bzr_ssh=plink?
<milleja46> or just plink?
<jelmer> maxb, fixed
<jelmer> maxb, thanks for the reminder
<maxb> awesome, thanks
<maxb> bleh
<maxb> I've found the bug which results in all these misplaced tags w.r.t the importer's meta
<james_w> oooh
<james_w> tell me
<maxb> The importer is quite capable of moving tags.... but it only sends them back to launchpad using merge_tags_if_possible, mostly
<james_w> ah
<james_w> not sure it should be moving tags normally though should it?
<maxb> an example is the iscsitarget import I'm trying to repair
<maxb> It collided in maverick, so it push --overwrote that.
<james_w> ah
<james_w> collisions, of course
<maxb> But, natty and oneiric were just straight pulls from what went before, so they kept the old tag
<zyga> I'm trying to implement something equivalent to `bzr pull` using bzrlib
<zyga> my simple code seems to work but it prints "unknown command commit"
<systemclient> how can I tell bzr that I want to run astyle *.java before every commit?
<zyga> am I missing something obvious?
<zyga> here is my code: http://paste.ubuntu.com/631467/
<lifeless> systemclient: a start_commit hook
<zyga> lifeless, could you please have a look at my code and tell me if I'm missing something obvious (or there is an easier method of doing that apart from shelling out to bzr)
<systemclient> lifeless: so I basically write a little python script that calls a shell command?
<lifeless> zyga: I don't see where you are committing to trigger that error
<lifeless> zyga: unknown command will be because you haven't loaded the bzr built in command classes (see bzrlib/command.py)
<zyga> lifeless, I have no idea either, I'm running on daily bzr
<lifeless> systemclient: yes, - can be very tiny
<zyga> lifeless, let me reinstall bzr just in case
<lifeless> systemclient: there are folk that have written generic call-shell-command implementations of the core hooks
<lifeless> systemclient: I don't recall where they are offhand
<zyga> lifeless, could I be initializing bzrlib incorrectly somehow?
<poolie> we should really merge that
<lifeless> well, you're definitely doing it a bit oddly
<lifeless> poolie: it had security issues
<zyga> lifeless, ah, it must have been coming from one of my plugins, sorry for the noise
<zyga> lifeless, I wish I could do it easier but there is a bug in the way normal initialization works (I posted about this to the mailing list recently)
<lifeless> zyga: you probably want to use bzrlib.initialize
<lifeless> ah yes
<zyga> lifeless, then fix it :>
<lifeless> that surprised me
<lifeless> zyga: you are as capable of that as me :>
<zyga> lifeless, would you accept a simple fix without unit tests? I don't feel skilled in bzr internals enough to test this
<poolie> zyga: if you want it to do what 'bzr pull' does' it would be easiest to just run run_bzr(['pull', ...])
<zyga> poolie, run_bzr, I never saw that before, let me have a look
<lifeless> zyga: you probably want to call bzrlib.commands.install_bzr_command_hooksI()
<lifeless> zyga: that will register commit etc
<lifeless> zyga: do that before you call load_plugins
<zyga> lifeless, thanks, applied
<zyga> lifeless, is there a way to initialize just the launchpad plugin?
<zyga> lifeless, I would like to shield the system from random plugins users may have (and speed up oprations)
<lifeless> bzrlib.plugin.set_plugin_path(); import bzrlib.plugins.launchpad
<zyga> lifeless, awesome!
<lifeless> (something like that)
#bzr 2011-06-24
<zyga> lifeless, can I call bzrlib.log.get_history_change(old_revision_id=None) to get a history since beginning?
<lifeless> I haven't looked at the log code in over a year
<zyga> reading it quickly it seems that I have to
<zyga> how can I get the revision_id of the first revision in a branch?
<lifeless> well you'd travese the mainline to the start
<lifeless> but
<lifeless> I suspect you're using the wrong entry point
<zyga> lifeless, I just want to have the same objects to work with (to tell the user how many things changed) regardless of doing pull vs update internally
<lifeless> you'd normally use revisions
<mwhudson> what the heck?  meld is running 'bzr check' for me
<mwhudson> on my launchpad repository
 * mwhudson objects
<mwhudson> whisky tango foxtrot!! http://mail.gnome.org/archives/commits-list/2011-February/msg01667.html
<lifeless> AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<lifeless> I presume you will express mail the nuclear cluebat?
<mwhudson> well
<mwhudson> i'm trying to remember how bugzilla works
<bob2> bwahahaha
<mwhudson> so yes, running bzr check --tree --branch _is_ faster than running bzr check
<bob2> from the "better to ask for a large stable of ponies and a yacht, than forgiveness" style of error handling
<fullermd> If they just want to check that it's a branch, couldn't they just make a few commits and then roll them back?  I should suggest that...
<mwhudson> os.path.isdir('.bzr/checkout') seems about right to me
<mwhudson> of course there's no documentation so i don't quite know what the method is for
<mwhudson> https://bugzilla.gnome.org/post_bug.cgi
<mwhudson> ah haha, nice one bugzilla
<mwhudson> https://bugzilla.gnome.org/show_bug.cgi?id=653302
<ubot5> Gnome bug 653302 in version "bzr check is completely inappropriate for testing the presence of a bzr-managed tree" [Major,Unconfirmed]
<mwhudson> well, that was a distraction
<mwhudson> "This patch attempts to add a quick sanity check
<mwhudson>   to most version control systems.  The checks are meant to be
<mwhudson>   as quick as possible to reduce startup time."
 * mwhudson giggles
<jtv> lifeless, quick Q: are non-ASCII svn usernames supposed to work when checking out a svn repository into a bzr branch?
<jtv> oh, looks like the traceback may be apport crashing while it tries to report the problem.
<jtv> Nope, the traceback is bzr.
<jtv> I'm filing.
<jelmer> hmm, anybody seen John today?
<jam> vila: ping
<jelmer> hi jam
<vila> jam: hi and pong
<vila> jelmer: hi
<jelmer> hey vila
<maxb> If someone has a moment, UDD iscsitarget is ready for repair in bug 794574
<ubot5> Launchpad bug 794574 in Ubuntu Distributed Development "Import repair: iscsitarget" [Undecided,In progress] https://launchpad.net/bugs/794574
<vila> maxb: this requires updating the jubany scripts from lp:udd right ? (Which also requires restarting mass_import since udd.paths has been introduced (not strictly required but..)))
<vila> maxb: jubany is at revno 470 right now
<Riddell> jelmer: you said we have --directory for most commands but many just take a [Location] argument, is there a reason to use one over the other?
<jelmer> Riddell: -d is usually where we don't have a location to work from as the first argument, but want a way to specify it
<Riddell> I think for verify-signatures it makes sense just to have a [Location] option then
<Riddell> since it doesn't take any other options
<jelmer> Riddell: e.g. bzr push takes a -d option to override the source location, bzr tag already takes a tag name argument so you can override the branch to work in with -d, etc.
<jelmer> Riddell: presuming you mean s/options/arguments, I agree
<Riddell> I do
<maxb> vila: There's no requirement to restart mass_import here. I think we should skip doing so. (Or, we should migrate to doing so in a LOSAless fashion, or decide to hold off future refactorings that would affect it)
<vila> maxb: (I went that route...For now, we have a losa and have to bear with it) Now, I know we don't *need* to restart mass_import, it's just that I'd feel safer doing so. But more importantly I wanted to check with you I understood what changes were pending and didn't miss some
<vila> especially with 2 revisions fixing previous ones, nothing pending ?
<vila> maxb: and keep in mind that the initial plan was to migrate from jubany and lose shell access... so we're "lucky"
<maxb> :-/
<mbp_> hi maxb, vila
<mbp_> i think a agood step for the losas is to start having them do jobs for max that we currently do ourselves
<poolie> why 'lucky'?
<vila> no shell access would have been worse :)
<vila> poolie, maxb : I think giving access to jubany would me pragmatic given the recent requests
<vila> s/me/be more/
<vila> funny tyop
<poolie> to whom?
<vila> to us
<vila> bah
<vila> to maxb
<poolie> i see your point
<maxb> That would be convenient, but would probably need to go via the Ubuntu Developer Membership Board for signoff, given the level of access that implies
<poolie> right, it's pretty high
<poolie> and it's a step in the wrong direction
<poolie> routing through the losas seems like a good step
<maxb> I disagree on both counts
<poolie> oh?
<vila> except the losas don't have the required knowledge as of today and the long term plan is to not need them for such operations
<vila> maxb: lp:udd pulled & fixit done , by the way
<maxb> Applying to give me access to the branches directly is roughly similar to me applying to be a core-dev - not a wrong direction, but potentially awkward because I've jumped directly to contributing to matters cutting across all of Ubuntu
<maxb> Involving the LOSAs simply adds more "please run this" repetetive work to an already overworked team
<vila> oh, we aren't giving you access to the branches, we give you the ability to impersonate james_w :D
<vila> poolie: by the way, what's the status of the bug about not using james_w credentials anymore ?
<maxb> None of the work involved in managing the importer necessarily requires administrative rights - all it requires is enough privileges on Launchpad plus a computer to run the importer on
<poolie> maxb, that's true about it creating more manual work
<poolie> or, spreading it around
<poolie> vila, i have an email alias for it
<vila> poolie: and a lp account ?
<poolie> not yet
<poolie> that's the next thing i need to do
<poolie> oh, also to test whether the address works :)
<maxb> vila: Can you check if something's broken, the web pages don't seem to be updating, as if categorize_failures.py was not running
<vila> NameError: global name 'explanations_file' is not defined :-(
<vila> tests tests tests :D
<james_w> <bigcalm> davmor2: don't you wish you could do that?
<james_w> * em has quit (Read error: Connection reset by peer)
<james_w> <bigcalm> Not that I would want to touch the floor in a men's bog
<james_w> * em (~em@unaffiliated/emma) has joined #ubuntu-uk
<james_w> <BigRedS> anyone know what the premissions openssh actually wants for a chrooted sftp are? It's doing that wonderful thing of saying I've got them wrong, but not what they should be
<james_w> <MartijnVdS> BigRedS: http://www.debian-administration.org/articles/590 ?
<james_w> * em has quit (Ping timeout: 260 seconds)
<james_w> <BigRedS> yeah, it wants more than just owned-by-root it seems
<james_w> * Guest96855 has quit (Quit: Ex-Chat)
<james_w> * em (~em@unaffiliated/emma) has joined #ubuntu-uk
<maxb> oh for goodness sake. I suck, evidently, though I grepped really really carefully after the first problems.
<james_w> <BigRedS> It's happy with the user being unable to write to the chroot dir
<james_w> <BigRedS> which seems normal, except I'm sure the user used to be able to write there...
 * maxb fixes
<james_w> <MartijnVdS> BigRedS: yes, so the user can't drop a .ssh/authorized_keys
<james_w> <BigRedS> I *thought* it used the user's ~ for ssh bits and bobs for precisely that reason?
<james_w> <BigRedS> docs seem either to be scarce or to be hiding from me though
<james_w> * marxjohnson (~mark@2.102.242.119) has joined #ubuntu-uk
<james_w> <MartijnVdS> apt-get source... :)
<james_w> oops, sorry
<vila> who is impersonating james_w now ?
<vila> maxb: you don't suck, really
<maxb> pushed
<vila> AttributeError: 'set' object has no attribute 'web_status_dir' :-}
<maxb> what?!
<vila>     paths = set()
<vila>     path = os.path.join(paths.web_status_dir, "index.html")
<maxb> yes :-/
<vila> I really think overriding symbols should be banned from all languages :)
<jelmer> james_w: is it correct that RepackTarballAdaptor isn't used anywhere in bzr-builddeb?
<james_w> jelmer, I'm not sure. I don't remember the class, so if grep says no then it likely isn't
<poolie> hi jam
<maxb> pushed, again
<vila> maxb: watch out for the same pattern in write_main_page or did you fix both ?
<james_w> ah
<maxb> yes, I fixed all three
<james_w> from the test multiplication code
<vila> maxb: by removing them ? (They don't seem to be needed, it's a set for a single add)
<maxb> I didn't want to change that much for a quick-fix
<vila> maxb: anyway, it ran
<jelmer> james_w: ah, hmm. is this replaced by the scenarios now perhaps?
<maxb> Besides, I think it's so that all of the writing functions have the same interface
<vila> maxb: ok, will you or should I ?
<maxb> do what?
<vila> maxb: sure same interface but that doesn't mean the implementation has to do useless stuff
<maxb> I'm happy with the code as it currently is.
<vila> ha right, just re-read get_info, it has to be a set, so nm
<james_w> jelmer, I can't remember if it uses multiplication any more
<jelmer> james_w: I'll browse a bit further
<james_w> yeah, looks to be scenarios now
<poolie> maxb, i'll see if we can do that
<poolie> s/that/giv eyou access
<jam> hey poolie, just on my way out
<jelmer> hey jam
<maxb> poolie: That would be useful. I suppose I should file a per-package uploader application for bzr, so that I can be an Ubuntu developer of some kind.
<poolie> that'd be good
<poolie> hi jam
<poolie> and jelmer
<poolie> maxb, so perhaps we should ask the tb if you can have access to ubany
<poolie> maxb, i think it would be worth you doing a ppa
<maxb> PPU ?
<poolie> you can find my application in the techboard archive
<poolie> yes, ppu
<jelmer> hi poolie, maxb
<poolie> you can crib from that if you want
<jelmer> wait, what?
<jelmer> clearly there are some meanings of the word "crib" I'm not familiar with :)
<poolie> copy
<poolie> as in cheat on an exam
<jelmer> ah, thanks
<poolie> also 'a brothel', 'a wicker basket', ' a packed lunch taken to work'
<poolie> i have nevert heard of those
<poolie> actually maybe the first, but it's very archaic
<jelmer> yeah, the only two places I remember seeing it are in bible references and on MTV ("MTV Cribs")
<vila> ha, I found surprising you never heard of a brothel :)
<vila> jelmer: what ? The bible is talking about brothels ???
<vila> oops, that may be offensive, sorry
<poolie> these are obscure meanings of the word 'crib'
<jelmer> vila: a crib is also an infant bed
 * vila notes to never ever use this word
<vila> Just in case I try to say I put one of my daughter in a crib....
<jelmer> :)
<vila> jelmer: is it still time to remember you about bike leds ?
<jelmer> vila: I haven't forgotten :)
<vila> great !
<maxb> Oh. Hah.
<maxb> jubany gets different results to me because lucid's and natty's dpkg behave differently
<poolie> hm
<poolie> i wonder if i should just ask on the tb list
<poolie> maxb it may be better f you start your developer application first
<poolie> then that can describe your credentials etc
<maxb> ok
<poolie> i would be delighted to endorse you
<vila> maxb: can't you test it in chroot ?
<poolie> i expect james, jelmer, and others would too
<vila> poolie: by the way, could we discuss with losas to get a read-access to some ppa so we can precisely (and cheaply) setup jubany replicas ?
<vila> poolie: that is, not *now* but next week ;)
<maxb> PPA? To contain their patched packages?
<vila> maxb: yeah, *these* packages
<poolie> the CAT packages?
<vila> maxb: or share one with them, whatever
<poolie> sure
<poolie> just ask
<vila> poolie: could be. The ones that are installed on jubany.
<vila> creat
<poolie> vila, the URL is visible on jubany ;)
 * vila blinks
 * vila blinks twice
<vila> yummy
<vila> what a beautiful idea to end the week...
<poolie> cheerio
<Prodi> i'm having some issues with bzr throwing an error when I try to do a push
<Prodi> tried a search, but nothing seems to be relevant/help
<Prodi> the last part I see working is the fetching revisions, it sends a few megs to the server, and then throws the following error
<Prodi> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Prodi> my network appears to be fine though
<maxb> Hmm. Please check your ~/.bzr.log, see if there is additional debugging information there
<Prodi> i'm running this on windows
<Prodi> do you know where that file is located?
<maxb> No :-)
 * Prodi googles
<maxb> Ah. "bzr version" should tell you where the log file is
<Prodi> oh ok
<Prodi> got it
<Prodi> there's some message about adding something to LRUSizeCache failed, but I assume that's just a warning
<maxb> Yes
 * maxb wonders which flavour of UDD failure to attack next
<maxb> The remaining NoSuchTag ones that I semi-diagnosed at Millbank, I think
 * Prodi wonders what UDD is
<maxb> UDD is Ubuntu Distributed Development, the use of Bazaar to maintain Ubuntu packages
<Prodi> ah
<maxb> UDD is also the Ultimate Debian Database, just to confuse everyone :-)
<Prodi> TooManyConcurrentRequests: The medium 'SmartSSHClientMedium
<Prodi> )' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<maxb> Hmm. Usually that means a ssh connection has broken and bazaar has kept trying to use it
<Prodi> hmmm
<maxb> Perhaps you could pastebin a larger chunk of the log?
<vila> Prodi: bzr version ?
<Prodi> Fri 2011-06-24 14:30:55 -0400
<Prodi> 0.062 bazaar version: 2.3.1
<Prodi> 0.063 bzr arguments: [u'qsubprocess', u'--bencode', u'l4:pushe']
 * jelmer is making progress on multiple upstream tarballs
<vila> Prodi: 2.3.3 is out, not sure if the fixes are relevant though. Depending on your OS there is also betas for 2.4
<Prodi> i went with the windows MSI
<Prodi> taht contains all the pieces
<vila> right, windows it is then. So you can (and probably should) upgrade to either 2.3.3 or 2.3b4
<vila> meh
<vila> 2.3.3 or 2.4b4
<vila> if you still encounter the issue, file a bug please at http://pad.lv/fb/bzr
<Prodi> I went for the stable release provided at http://wiki.bazaar.canonical.com/WindowsDownloads
<Prodi> http://pastebin.com/3rEHqZU6
<Prodi> actually, this may be server permissions related
<Prodi> it never seems to set the right permissions when I branch on the server
<Prodi> well, that didn't help
<Prodi> is there a server side log I can look at?
<Prodi> ]for the smart server?
<james_w> maxb, $ requeue lash
<james_w> Traceback (most recent call last):
<james_w>   File "/srv/package-import.canonical.com/new/scripts/requeue_package.py", line 33, in <module>
<james_w>     opts.zap_revids = filter(None, opts.zap_revids.split(','))
<james_w> AttributeError: 'NoneType' object has no attribute 'split'
<james_w> that's because there's no --zap-revids given I think?
<maxb> Argh
<maxb> I seem destined to break udd scripts in silly ways at the moment
<james_w> maxb, want me to fix it?
<maxb> I'm happy to do so, but you can likely to it just as quickly :-)
<maxb> *do
<maxb> (I'd just add default="" to the option definition)
<maxb> Maybe I should just turn it into a standard append-type optparse option
<maxb> The current uses I'm coming up with for it tend to only involve zapping a few series
<james_w> done
<maxb> thanks
<maxb> by the way, don't update bzr-builddeb on jubany, it breaks current udd :-/
<james_w> ok
<james_w> that was the fix jelmer proposed, or something else?
<maxb> Apparently jelmer's fix didn't go far enough
<james_w> ah, ok
<maxb> bug 801726 filed for now to preserve my mental state on that
<ubot5> Launchpad bug 801726 in Ubuntu Distributed Development "UDD still breaking with tip of lp:bzr-builddeb" [Undecided,New] https://launchpad.net/bugs/801726
<maxb> Right.
<maxb> I'm done compiling work for people to run on jubany now :-)
<maxb> Ooh, and I've *very nearly* knocked AssertionError:<module>:main:find_unimported_versions:check off the top spot in the rankings
<Prod[a]> is there a way I can work around having to push to the server remotely?
<Prod[a]> like package the change into a file and do the commit from the server or something?
<Prod[a]> or rather package the commit, and push it from the server
<maxb> Bazaar has a concept called a "bundle"
<maxb> Try bzr send --no-patch -o foo.bundle destination-branch
<Prod[a]> k, will try it out
<Prod[a]> thnx
<Prod[a]> should I also open a bug report for this?
<Prod[a]> considering I don't really know where or what the issue is?
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | UDD failures: 401
<maxb> (assuming no more of the in-progress ones fail :-) )
<KombuchaKip> EasyTAG has just been resurrected. Please vote on your preferred revision control management we should use: http://www.easypolls.net/poll.html?p=4e04d772a34eb0e4f6954f91
 * maxb wonders how spamming that message in #bzr can possibly make sense
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | UDD failures: 400
<Prod[a]> i opened a bug for it
<Prod[a]> https://bugs.launchpad.net/bzr/+bug/801769
<ubot5> Ubuntu bug 801769 in Bazaar "Connection closed error on push" [Undecided,New]
<Prod[a]> oh, there it is :)
<maxb> requeue --auto qbittorrent if someone has a moment?
<timrc> does anyone have an example of how to push a local branch to a remote location using bzrlib?
#bzr 2011-06-25
<Noldorin> can bzr edit past commit messages?
<Noldorin> i remember this being discussed some time ago, but haven't heard much about it recently.
<maxb> Not really
<maxb> Only by uncommit/commit, so only for the top commit in history, without pain
<Noldorin> maxb, that's what i thought yeah
<Noldorin> is it under consideration for the future?
<Noldorin> some ideas on how to do it were discussed on the mailign list some time ago i think
<maxb> err..
<maxb> since when did "bzr ci" in a debian package commit without prompted for a log message?!
<lifeless> sounds like a bug
<lifeless> the commit template facility is meant to generate a default, not an actual
<jimis> hello, can you point me to some documentation for using bzr like git? That is with full branch downloaded in a directory, and switching between local feature-branches in that same directory?
<jimis> the reason is that when you have huge repositories, it's often prohibitive to keep 10-20 branches in separate directories
<LarstiQ> jimis: bzr-colo
<jimis> LarstiQ: I was aware of that but somebody had told me that it is possible without plugins
<jimis> Plus it would be nice if I could find some section in the documentation about that workflow, bzr-colo isn't much documented
<LarstiQ> jimis: depending on what that person meant, yes
<LarstiQ> jimis: you still need to have separate directories around for your branches, but they can be without working trees
<LarstiQ> jimis: and then you just use the regular `bzr switch` between them
<LarstiQ> jimis: if that is enough for you, then good :) But it's not the "full" git workflow from a purist standpoint.
<jimis> LarstiQ: how can I have multiple dirs, but not consuming multiple-times the disk space?
<LarstiQ> jimis: for example, `bzr init-repo --no-trees ~/src/project; cd ~/src/project; bzr branch somewhere-trunk; bzr branch trunk feature1; bzr co --lightweight feature1 work;`
<LarstiQ> jimis: only the 'work' dir will have a working tree
<LarstiQ> jimis: the key thing there is --no-trees
<LarstiQ> jimis: if you already have a repository you can use `bzr reconfigure` to toggle that on or off
<jimis> LarstiQ: thanks, that is good enough
<jimis> I'll try it and if it works well I'll make a request to document that workflow in bzr's user guide
#bzr 2011-06-26
<sagaci> hey, I've just tried using the command bzr launchpad-login - usually it works but on this new ubuntu 11.04 natty install, I've come across a few weird errors
<sagaci> http://paste.ubuntu.com/632867/
<sagaci> now I'd usually file a bug about this kind of thing but I'm not particularly well-versed with what's gone wrong so I was just wondering if it is a known-bug and/or if there's a workaround
<lifeless> looks like the pycurl timeout bug
<sagaci> so, keep trying?
<lifeless> sagaci: there is a patch for pycurl
<lifeless> I think its in natty-proposed now
<sagaci> righteo, thanks
<lifeless> jelmer: I'm getting this when I commit now :
<lifeless> modified versions.cfg
<lifeless> bzr: ERROR: Revision {robertc@robertcollins.net-20110626084349-sa7ry4ihy3afdo6o} not present in "Graph(CachingParentsProvider(CHKInventoryRepository('file:///home/robertc/source/launchpad/gpgverify/.bzr/repository/')))".
<lifeless> jelmer: where that rev is the rev being committed
<lifeless> I'm guessing its a plugin issue
<sagaci> thanks, updated to the -proposed version and it processed without error
<lifeless> \o/
<lifeless> zyga: you should add a url/homepage to your lava-dev-ool setup.py
<zyga> lifeless, :-)
<lifeless> (http://pypi.python.org/pypi/lava-dev-tool/0.1 has no link to launchpad/your homepage)
<zyga> lifeless, how did you find about it :-)
<zyga> (and thanks, fixing now)
<lifeless> I'm subscribed to the pypi twitter feed
<zyga> ah, good one
<zyga> fixed
<zyga> thanks
<zyga> lifeless, in dublin yet?
<lifeless> zyga: I won't be there
<zyga> aw, too bad
<lifeless> zyga: got something more important :) - we're expecting in 8 weeks
<zyga> congratulations
<zyga> boy or girl?
<lifeless> la chica
<zyga> great :-)
<lifeless> jelmer: branchfeed plugin (if you want to reproduce) was seeing an incomplete cached graph from the repository
<lifeless> jelmer: actually, happens w/o that plugin too :<
<lifeless> jamesh: gpgme 0.2 should probably get released :)
<jelmer> 'evening lifeless
<jelmer> lifeless: I'm about to head off to Dublin, but I'll try to remember to have a look
<lifeless> have a good flight
<lifeless> I should probably pull trunk in
<lifeless> I may be running a weird combo of stuff
<LarstiQ> morning
<poolie> hi all
<lifeless> hi poolie
 * jelmer waves
<lifeless> hi jelmer
<lifeless> jamesh: happens to bzr-dbus too
<lifeless> bah
<lifeless> jelmer: ^
<jelmer> lifeless, the graph issue from this morning you mean?
<lifeless> yes
#bzr 2012-06-18
<gour> morning
<gour> i've few programs for which i keep their config files under dvcs...now we are going to switch to bzr and wonder whether you recommend to use lightweight checkouts for 'working trees' and keep repos separately with --no-trees ?
<mgz> morning
<jelmer> hi
 * jelmer is having fun fighting with pbuilder chroots
<mgz> and I thought you had debian packaging entirely tamed jelmer... are the chroots defeated yet?
<jelmer> ish
<jelmer> the fact I'm running quantal seems to be breaking me up :)
<jelmer> mgz: what mischief are you up to?
<jelmer> also, we still seem to have a fair number of issues with encodings in 2.6 :(
<mgz> the usual silliness, and seeing what hacks need fixing or documenting before I can post the mp I promised last week
<mgz> jelmer: just need to merge all our branches up I think
<jelmer> mgz: from where?
<mgz> 2.2->2.3 and 2.5->2.6 and some of the ones inbetween
<jelmer> k
<gour>   /q
<mgz> jelmer: I see you've started the merge up, but 2.3 doesn't seem to have landed and you've got 2.3->2.4 up?
<abentley> jam, is anyone patch-piloting?  I have a couple MPs I'd like reviewed.
<jam> abentley: I think we're watching the queue, but nobody is specifically focused on it. You're welcome to request reviews.
<gour> i just played a bit with bzr's lightweight co-s emulating "Switching a lightweight checkout" section (http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/reusing_a_checkout.html) and i had a feeling that this feature should enable me to create sandboxed directory wich is goingto be populatd by different working trees based on the 'switch' command
<gour> now i see that it works this way :-)
<gour> but i must say that the code example was (is) a bit misleading to me...so i propose the following one...
<gour> http://pastebin.com/cRi6vYgB
<gour> conclusion: treeless branches in (no-tree) shared repo, feature branches, lightweight checkouts...easy switching between them...great stuff and we love bzr's simplicity & power :-)
<mgz> gour: note also `bzr switch -b NAME` to create sibling feature branches is handy
<gour> mgz: hmm, does it mean, if i'm e.g. on master branch, that bzr switch -b feature1 branch will 'clone' a master branch into feature1 and switch on it?
<mgz> yup.
<gour> very handy...thumbs up
<gour> it seems to me that bzr is really nicely designed despite changing its format (too) often in the past, so understanding why so many people are enamored  by git is well beyond me :-}
<LeoNerd> Format changes should have been prettymuch invisible to users, though
<gour> LeoNerd: well, it was a bit irritating in the past
<LeoNerd> Eh.. it was a mild inconvenience at times but I don't recall ever being actually uspet by it
<jelmer> gour: the last format change is more than three years ago at this point
<gour> i know that 2a is stable and do not complain...just sayign that
<gour> foramt changes in the past created a feeling that bzr is not stable...that's all
<gour> otherwise i wouldn't be here today ;)
<mgz> jelmer: bug 1014626 / 1014627 should still be dupes of bug 966934 I think, were they from after you did the 2.5 merge to dev?
<ubot5> Launchpad bug 1014626 in Bazaar "UnicodeEncodeError formatting translated message during merge" [Medium,Triaged] https://launchpad.net/bugs/1014626
<ubot5> Launchpad bug 966934 in Bazaar "[i18n] bzr commands affected working tree crashed with unicode error in non-english locale" [High,In progress] https://launchpad.net/bugs/966934
<JordiGH> How do you checkout/update to a past revision?
<mgz> use -r, see `bzr help update`
<JordiGH> I did see it, but I couldn't figure out what -r meant.
<JordiGH> Am I using the right word?
<mgz> depending on exactly what you're trying to do, you may want revert instead.
<JordiGH> I want my working tree to be at a specified revision.
<mgz> did you try it?
<JordiGH> Yeah, but I don't know if it worked.
<JordiGH> How do I know at what revision I'm currently in?
<mgz> `bzr revno --tree`
<JordiGH> Okay, is that done with revert or update? I did both.
<mgz> revert changes the state of the tree (files on disk), but not the branch, update changes both
<mgz> so, after a revert, `bzr st` will tell you stuff has changed from the current branch state
<JordiGH> But update seems to try to merge changes...
<JordiGH> I ended up with merge conflict markers.
<JordiGH> I don't want that.
<mgz> did you have local changes?
<mgz> changing the tree always means you may get conflicts
<mgz> if you're sure there's nothing in the current state you want keep, a plain bzr revert will throw everything out
<JordiGH> I didn't make any, but I don't know if bzr decided I had changes because there's been updates and reverts.
<mgz> perhaps, if you're not sure, you can always look at your .bzr.log to see exactly what happened
<mgz> `bzr version` will tell you where to find it.
<JordiGH> Ooh, nice feature.
<mgz> and you can always get a copy of an older revision cleanly by creating a new tree, `bzr checkout --lightweight -r-6 . ../old_rev` for instance
<JordiGH> So, just to make sure I have the right terminology...
<JordiGH> if I do "bzr update -r foo" that means change the state of the current directory to whatever is stored in that branch?
<JordiGH> What happens if you commit there? Do you just painlessly branch off?
<JordiGH> Wait, what is a "branch" in bzr?
<JordiGH> It's not a path in the DAG, is it?
<JordiGH> It's also a working directory?
<mgz> see <http://doc.bazaar.canonical.com/beta/en/user-guide/core_concepts.html>
<mgz> if you try to commit it will prevent you from doing so by default
<mgz> what you probably want is two branches, but just work in the one directory
<mgz> as that's what I imagine you're used to with other tools
<mgz> if you describe the actual task you're trying to do, rather than just the step, that might help
<JordiGH> No, what I'm used to with hg is to commit wherever I want and for things to branch off naturally.
<JordiGH> "branch" in bzr also seems to mean "working tree".
<JordiGH> Or directory.
<jelmer> JordiGH: a branch is a line of history
<JordiGH> Does "branch" also mean "clone" in bzr? You even use the branch command when you want to clone a repo.
<jelmer> JordiGH: a branch and a clone are the same thing at the moment
<jelmer> JordiGH: since each control directory usually holds a single branch, and not multiple like in git or hg
<JordiGH> Alright.
<JordiGH> So how do you branch off at a past revision?
<JordiGH> You update to a past revision, and you do a special kind of commit?
<jelmer> JordiGH: update the branch to a past revision or update the working tree state to the same state as in a past revision?
<jelmer> "bzr up -rREV" for the first, "bzr revert -rREV" for the latter
<JordiGH> So "update the branch" means... what?
<jelmer> JordiGH: resetting the branch to an older revision
<jelmer> I guess the equivalent in git would be "git reset COMMITTISH"
<JordiGH> And "the branch" means the working directory?
<JordiGH> I don't do git.
<jelmer> JordiGH: no, the branch is the history
<JordiGH> So reset the history?
<jelmer> JordiGH: so "bzr up -rREV" would make the branch look like the history ended at REV
<JordiGH> How do I see the DAG?
<jelmer> JordiGH: bzr log
<JordiGH> That's just the log entries.
<JordiGH> How do I see what's an ancestor of what?
<jelmer> or for a more graphical one, "bzr qlog" or "bzr viz"
<JordiGH> bzr: ERROR: unknown command "viz"
<JordiGH> But qlog seems to be doing something...
<jelmer> JordiGH: the log will show that (right hand side ancestors are shown indented)
<JordiGH> Starting Qt?
<jelmer> JordiGH: viz is part of the bzr-gtk plugin, qlog is part of the qbzr plugin
<JordiGH> So it's like git that when you update to an earlier revision, it looks like later revisions disappear?
<jelmer> JordiGH: well, that's if you use "bzr up -rREV"
<jelmer> if you just want to reset the working tree to the same state as in a previous revision, use "bzr revert -rREV"
<JordiGH> But then bzr st thinks I modified all files.
<jelmer> JordiGH: right, because the last revision didn't have those changes
<jelmer> JordiGH: and bzr st by default shows the changes between the working tree and the last revision
<jelmer> if you just want to create a new revision that resets the state of the tree, just commit chose changes
<jelmer> e.g. bzr commit -m "Revert back to rREV."
<JordiGH> How does bzr keep revisions centralised?
<JordiGH> heh, idgi
<jelmer> JordiGH: they're in the control directory (.bzr/repository)
<santagada> I want to see a graph of two branches, what they have in common and what differs in terms of commits, how can I do that with bzr?
<jelmer> santagada: bzr missing
<santagada> jelmer: thanks
<santagada> :)
<santagada> jelmer: docs don't mention missing... or I didn't find it
<santagada> but thanks a lot if really did solve my problem
<santagada> now I will slowly merge revisions that are missing
<JordiGH> A pull also updates, right?
<JordiGH> And an update also merges, right?
<jelmer> JordiGH: in the hg terminology, pull indeed also updates the working tree
<JordiGH> How can you pull revisions without touching the working directory?
<MvG> Hi! IWe've got a Windows machine here with TortoiseBzr which reports a lot of x-bit changes for a working tree. I'm a bit confused about this, as I didn't think Windows NTFS had such a thing. I guess most regular Windows users would be even more confused. Can someone around here tell me what could give bzrlib the idea of such changes?
<mwhudson> is there some cute way i can suppress this message:
<mwhudson> <doanac> I also finished the conversation with some advice I told him I realized he didn't have to pay attention to.
<mwhudson> <doanac> i said - if i were you, I'd focus on making zach happy (even in spare time), because that's the best thing you could do for your career right now
<mwhudson> <doanac> he said he understood, but I don't think he can resist this urge.
<mwhudson> <mwhudson> heh
<mwhudson> <mwhudson> he really is a strange guy
<mwhudson> <doanac> I think he's wanting to create an entirely new community that's a "fork" of LAVA
<mwhudson> <doanac> I asked "fork"? he said - well, a rewrite is a kind of fork
<mwhudson> <doanac> i found that part a bit amusing
<mwhudson> <doanac> its not like anybody can stop him, but I had to be clear he can't use "lava" in the branding of what he does
<mwhudson> <mwhudson> good idea
<mwhudson> <doanac> and maybe we'll come crawling back to him some day. as he said, finishing up the rest of porting stuff to lava-core was easy :)
<mwhudson> oh ffs
<mwhudson> !
<mwhudson> You have not informed bzr of your Launchpad ID, and you must do this to
<mwhudson> write to Launchpad or access private data.  See "bzr help launchpad-login".
<lifeless> mwhudson: which message :P
<mwhudson> lifeless: the one about launchpad :(
<lifeless> bzr launchpad-login mwhudson, I think.
<mwhudson> lifeless: without doing that
<lifeless> don't use lp: urls.
<mwhudson> lifeless: i have been using bzr and launchpad for a /little/ while after all...
<mwhudson> yeah, that might be easiest
<lifeless> or use bzr's library
<lifeless> whats the use case ?
<mwhudson> lifeless: just avoiding spam when running a script
<mwhudson> lifeless: just half a thought that there might be some config option i could set
<Guest12454> mwhudson: you can set launchpad_username ?
<mwhudson> Guest12454: i want to use the http transport, but don't want to be nagged about it
<Guest12454> ah
<Guest12454> we discussed having a lp+http:// URL scheme at some point
<Guest12454> but that never emerged
<mwhudson> jelmer: ok
<mwhudson> jelmer: i guess if that itch strikes again i know what to do...
#bzr 2012-06-19
<zyga> mwhudson, ?
<zyga> mwhudson, some paste
<gour> morning
<gour> co-located branches doc (http://doc.bazaar.canonical.com/developers/colocated-branches.html) lists few 'use cases' (http://doc.bazaar.canonical.com/developers/colocated-branches.html#use-cases) and i'm not sure whether co-located branches are real need in bzr (yesterday i played with --lightweight checkouts used for feature branches based on shared repo) or is it more of filling the gap to hg/git's features?
<spiv> gour: they are more convenient than lightweight checkouts + branchless repo, and just as good for many cases, so that's a pretty valuable improvement
<gour> spiv: i see...thanks...are they going to be ready for 2.6?
<spiv> They're already ready in 2.5: http://doc.bazaar.canonical.com/bzr.2.5/en/whats-new/whats-new-in-2.5.html#basic-colocated-branch-support
<spiv> No doubt they'll be even better in 2.6 :)
<gour> iirc, jelmer or someone else was speaking something about UI not polished (yet)...otoh, i was not aware they're already in...does it mean we should (try) to adopt 'em instead of lightweight co-s & branchless repos?
<spiv> I'd give it go, yes.
<gour> ok
<spiv> If you don't like them for some reason you can always change your mind later and use lightweight checkouts and boring old branches in treeless repo, etc :)
<gour> :-)
<gour> in some use cases, i like treeless repo and lw co-s...eg. i'm using weechat irc client and my ~/.weechat is lightweight co keeping track of weechat's config files, while the treeless repo is in ~/repos
<gour> hmm, colocated branches need new format...we just talked about bzr's formats yesterday :-)
<gour> 2.6 docs when speaking about colocated branches uses future tense, so wondering what's avaialable today...
<bob2> suspect once you get used to them you'll want to use colocated all the time
<spiv> bob2: well, it's not especially well-suited for the .dotfiles use case mentioned above.
<spiv> But for general code hacking, yeha.
<jelmer> gour: huh?
<jelmer> gour: colocated branches need a new format?
<gour> jelmer: bzr init -h ==> --development-colo  The 2a format with experimental support for colocated
<gour> branches.
<gour> or it means something else i'm not aware of?
<jelmer> gour: the development-colo format isn't  necessary for colocated branches anymore
<jelmer> gour: you can just use them with 2a these days
<gour> jelmer: hmm, it seems that docs needs some love then ;)
<jelmer> gour: which docs?
<gour> jelmer: bzr-2.5.1 help text for 'init' command
<mgz> morning!
<jelmer> hey mgz
<jelmer> gour: ah, but I guess it's listed under the development formats still?
<gour> jelmer: well, it's listed under branch format section along with --2a etc., iow. valid option for 'init' in 2.5.1
<jelmer> gour: sure, but there's lots of other uninteresting formats there too
<jelmer> *development
<jelmer> though we should probably hide development-colo
 * gour nods
<anddam> do I need to register a launchpad account in order to just clone (branch?) a repository?
<jelmer> anddam: no, you can clone a branch (as long as it's not private) without an account
<anddam> jelmer: do I need to init a repo before running bzr branch?
<jelmer> anddam: no, see the mini tutorial
<jelmer> http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
<anddam> I tried both, "bzr branch lp:foo" and "mkdir foo; cd foo; bzr init; bzr branch lp:foo"
<anddam> k
<anddam> I just read that
<anddam> it shows how to init-repo and init but it doesn't says it that's *mandatory* or not
<anddam> with git a "git clone" would create the local repository as well
<jelmer> anddam: in bzr the repository is created if a shared one doesn't exist too
<anddam> I'm trying cloning lp:groundhog
<anddam> I get    bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~juanjux/groundhog/groundhog-juanjo/"
<anddam> when running "bzr branch lp:groundhog", is that an issue on my side or not?
<jelmer> anddam: that branch doesn't really exist - it's never been pushed to according to the web page
<anddam> sounds like it isn't
<anddam> I see
<anddam> Recent revisions
<anddam> This branch has not been pushed to yet.
<anddam> so the launchpad repository for the project is empty, isn't it?
<jelmer> it doesn't actually have a control directory I think
<jelmer> so it's not even empty
<anddam> I apologize but I'm really new to bzr
<anddam> idk what a control directory is
<anddam> the point is that lp:groundhog has no code, is this correct?
<jelmer> it's the same thing as ".git" in git
<jelmer> I mean, in git the control directory is named ".git"
<jelmer> anddam: yes, lp:groundhog doesn't have any code
<anddam> I see lp:~juanjux/groundhog/trunk is listed as branch and that has code
<anddam> is there any difference between a subdir in user space or a root level project?
<anddam> I mean is that just a convention, a matter of taste or so?
<anddam> (fetching)
<jelmer> anddam: I'm not sure I follow
<jelmer> anddam: subdir in user space?
<anddam> jelmer: yes, ~juanjux/groundhog rather than groundhog
<jelmer> anddam: ah, that's just convention
<anddam> thx
<anddam> bye
<abentley> vila: Could you please review https://code.launchpad.net/~abentley/bzr/config-branchname/+merge/110825 ?
<abentley> jam: Changing branchname to fall back to basename is a 1-line change, and I'm happy to do that.  Maybe rename to "shortname".  But you're not proposing we remove "basename", right?  So we'd still be introducing a new variable.
<jam> abentley: I'm fine with a new var, what I want is to have 1 var that can just be used, without needing to think "do I need X or Y in this case"
<abentley> jam: Okay.  Does "shortname" work?  ("branchshortname" seems...long)
<jam> branchname is fine for me
<jam> I think I prefer that
<abentley> jam: "branchname" was meant to refer to the colocated branch terminology.  jelmer, is it cool if I introduce a config var called "branchname" that is ",branch=$NAME" but falls back to "parent/$NAME"?
<mgz> Have we got a bug for `bzr config --remove launchpad_username` not working on 2.5.1?
<mgz> needs --scope=bazaar
<gour>     /q
#bzr 2012-06-20
<zyga> hi, is there a way to rebase a tree on top of nothing, just to change all the internal file IDs
 * gour is, in principle, against rebase, but well...
<zyga> gour, I'm trying to work around a bug in bzr
<zyga> gour, that prevents me to bzr join two trees that have some common ancestry
<gour> zyga: ahh, ok...good luck
<gour> we're considering to keep our /etc under bzr, possibly with etckeeper...anyone using it (possibly on archlinux)?
<bob2> definitely need etckeeper
<bob2> works quite well with git for me
<gour> the point is that, afaik, there is no support for archlinux's pacman, so wonder if it is worth without it?
<bob2> yes
<bob2> and integrating it should be trivial assuming pacman isn't totally crap and has no hook support at all
<gour> heh
<gour> i'd use it with bzr (treeless repo and lightweight checkout)
<bob2> erk
<mgz> morning
<mgz> is there a shorter equivalent of -c rev in git than SHA^..SHA?
<LeoNerd> I'm not aware of one. It's one of my standard ways to wind up the git fans :)
<LeoNerd> Especially  bzr di -c-1
 * gour considers that git is simply not human...that's all
<gour> i'm considering one linux distro which uses git for contribution and wonder if bzr-git can be used...the answer is "yes...as long as the output is a patch that can be read by 'git am'". are we on the right track with bzr-git here?
<jelmer> gour: sort of
<jelmer> gour: bzr-git adds custom formatters to 'bzr send' and 'bzr diff'
 * gour is confused a bit
<jelmer> gour: 'bzr send --formt=git' will attempt to generate 'git am' compatible patches
<gour> jelmer: ohh, that's good :-)
<jelmer> gour: in practice, there's still some issues with that though
<gour> jelmer: may we count on bugging you about in stumbling upon some obstacles?
<gour> *it when stumbling...
<kbulgrien> heh, can they count on you for patches?
<kbulgrien> :-)
<gour> he he
<jelmer> gour: I'm happy to comment or review changes
 * kbulgrien avoids git like the plague
<gour> they just have their policy and we are anticipating need to contribute some missing packages (without being involved with git)
<jelmer> gour: but I'm not really doing a lot of activce work on this code anymore
<gour> jelmer: so, if git changes something in the future, there js de
<gour> *is dead-end?
<jelmer> gour: even before then, there may be minor issues that you will want to see fixed
<jelmer> i.e. it generating output that is not compatible with git-am in some situations
<jelmer> (I don't know if it does, but I can imagine there are some situations where that is the case)
<gour> ok, we'll (re-)consider it
<gour> jelmer: how does plain patch differs from what 'git am' requires? i assume that's always possible to produce
<jelmer> gour: git am has metadata for the commit, and e.g. a diffstat
<jelmer> so things like th ecommit message, committer name, author, etc
<gour> ahh, ok
<jelmer> gour: don't get me wrong, I still use bzr-git (mostly with dpush) and do the occasional fix to it when I hit a bug or there's a severe regression
<jelmer> gour: but I'm not working on it as actively asI was before, and don't want to give you the impression I am
<gour> jelmer: ok. let me try installing taht distro 1st...
 * gour appreciates jelmer's honesty
<jelmer> which distro is it, out of curiosity?
<gour> frugalware...i use archlinux atm
<jelmer> ah
<jazon> Hello I have a little problem with bzr, I pastebin it
<jazon> http://pastebin.com/63NXhvjE
<jazon> can you help me please?
<vila> jazon: try 'ssh -vv jazon@192.168.1.228'
<mgz> jazon: and I'm guessing there's no directory /optimhome/portugal/ on that server
<jazon> it's work
<mgz> the path is not relative to your home dir, it's absolute.
<jazon> when I try bzr with http://my.IP.adress/optimhome/portugal it's work...
<mgz> right, because the http server does it's own url->path mapping that works differently
<mgz> and is relative to a srv directory presuambly
<mgz> pass the full path to ssh and it should be fine (if you enter your password correctly)
<jazon> what is the way to pass the full path? I don't know.
<jazon> It's the first time I do my own bzr server
<mgz> if you ssh into the server, where is the optimhome directory located?
<mgz> under /var/www maybe?
<jazon> yes
<mgz> then use bzr+ssh://192.168.1.228/var/www/optimhome/portugal/ as the branch location
<jazon> http://pastebin.com/Kwq9vYNm
<mgz> fix the permissions so your user has write access to all of /var/www/optimhome
<jazon> thx mgz it's work fine :)
<mgz> jazon: great!
<ramsforums> hello
<ramsforums> anyone there
<ramsforums> i need a help with bzr
<wgz> it's generally best to just ask your question, rather than asking to ask.
<ramsforums> Thanks
<ramsforums> I have downloaded repositories on my development PC from launch pad using the following command
<ramsforums>    bzr branch lp:openobject-server/6.1 server
<ramsforums> It worked and all latest source files on my PC
<ramsforums> Last week I did an merge using the following command
<ramsforums>    bzr merge
<ramsforums> It worked well.
<ramsforums> I am not making any changes to my working code. I typically use them that's all
<ramsforums> Today I want to get the all latest changes from the repository I run the following command
<ramsforums>  bzr merge
<ramsforums> I have encountered the following err
<ramsforums>  bzr: ERROR: Working tree [Actual tree here ] has uncommitted changes (See bzr status)
<ramsforums> Is it a buy or I am making mistake?
<ramsforums> Thank you
<wgz> you want to use `bzr pull` not `bzr merge` to just get the latest changes
<ramsforums> oo ok thanks
<ramsforums> appreciate your help
<wgz> merge is only for the case where you have two diverged branches with a common ancestor that you want to recombine into one
<ramsforums> what does bzr update do?
<wgz> modifies the files in the branch and the revision that the branch stands at
<wgz> see <http://doc.bazaar.canonical.com/beta/en/user-guide/core_concepts.html>
<ramsforums> ok thanks wgz for the help and giving direction
#bzr 2012-06-21
<jnl> hi, when i pipe bzr log --line to a pager the lines gets chopped off to 78 with (with a "..." at the end), can i avoid this?
<mgz> morning
<bialix> hi all
<bialix> hi jelmer
<jnl> n/m, looks like bug in old version (2.0)
<matttbe> Hello
<matttbe> Recently, I wanted to update the version of Cairo-Dock in Ubuntu.
<matttbe> I updated my branch to be synced with the main branch (bzr uncommit -r 25; bzr revert; bzr pull # => now on rev 26) and used merge-upstream option (bzr mu --version "3.0.2" --distribution=quantal).
<matttbe> On Launchpad, I can see that the previous rev (26) has the same rev ID on my new branch (lp:~cairo-dock-team/ubuntu/quantal/cairo-dock/3.0.2) and on the main branch (lp:ubuntu/cairo-dock).
<matttbe> But if someone tries to merge my new branch into the ubuntu branch, it seems there is a conflict. => https://code.launchpad.net/~cairo-dock-team/ubuntu/quantal/cairo-dock/3.0.2/+merge/111020
<matttbe> Note that on rev 26, there is a patch (in debian/patches) which was applied but the diff (available in LP)  seems correct except that if you have a look to the conflict, it seems the previous patched was unapplied before merging:
<matttbe> This is what I can find in src/gldit/cairo-dock-callbacks.c:
<matttbe> <<<<<<< TREE
<matttbe> 		if (pDock->iSidTestMouseOutside == 0 && pEvent)  //(...)
<matttbe> =======
<matttbe> 		if (pDock->iSidTestMouseOutside == 0 && pEvent && ! pDock->bHasModalWindow)  // (...)
<matttbe> >>>>>>> MERGE-SOURCE
<matttbe> But we can find this diff on rev 26:
<matttbe> -  if (pDock->iSidTestMouseOutside == 0 && pEvent)  // (...)
<matttbe> + if (pDock->iSidTestMouseOutside == 0 && pEvent && ! pDock->bMenuVisible)  // (...)
<matttbe> Should I have to remove my previous patches, commit and then use bzr merge-upstream?
<mgz> matttbe: have you had any luck getting an answer?
<matttbe> mgz: no
<matttbe> mgz: but if we use 'bzr pull' instead of 'bzr merge', we don't have this bug because  it seems patches are unapplied just before:
<matttbe>   > Unapplying quilt patches to prevent spurious conflicts
<mgz> right, my guess would be one branch was done with the quilt plugin enabled and the other wasn't
<mgz> but I don't understand from yuor description if your branch or lp:ubuntu/cairo-dock has the quilt patches applied in tree
<matttbe> yes, lp:ubuntu/cairo-dock has quilt patches applied in tree
<matttbe> and these patches are removed in the new one
<mgz> in the diff I see the patches are completely removed, right?
<matttbe> yes
<mgz> were they merged upstream?
<mgz> or just dropped?
<matttbe> merged upstream
<mgz> okay
 * mgz ponders
<matttbe> but it seems the problem is that they are merge upstream but the same line has been modified too
<mgz> so, either you can play with the quilt options in bzr-builddeb and see if one of them helps,
<mgz> or just do the merge locally, resolve the conflict and push it?
<mgz> jelmer may have better ideas.
<matttbe> note that in lp:ubuntu/cairo-dock, there is a patch (which is applied in tree) to remove one line in: src/gldit/cairo-dock-keybinder.h
<matttbe> Now this patch is no longer needed (merged upstream) but if we use 'bzr merge', the line is still there
<matttbe> yes, I merge it locally, resolve conflict, revert the wrong change in src/gldit/cairo-dock-keybinder.h and  push it on another branch
 * jelmer reads up on the last few minutes of converstaion..
<matttbe> but if we use 'bzr pull' we don't have any problem (but if the sponsor want to merge this branch just to modify the ubuntu version in debian/changelog and push only one rev, it's not so easy and he has to check that all files are corrects)
<matttbe> maybe it can be interesting to unapply patches just before merging (if it's possible)
<jelmer> matttbe: bzr-builddeb can do that
<matttbe> jelmer: but who has to do that? the sponsor?
<jelmer> matttbe: matttbe whoever does the merge
<matttbe> ok, thank you!
<jelmer> matttbe: the bzr-builddeb has some documentation; you'll need a newer version of bzr-builddeb
<matttbe> jelmer: I've the version 2.8.4 from Ubuntu Quantal repos
<jelmer> that should be new enough
<matttbe> jelmer: but what should the sponsor has to use? I used 'bzr merge-upstream' and everything was ok for me (but not for the sponsor)
<matttbe> I see that now 'bzr mu' unapplied patches and it's great but then, the sponsor has to use 'bzr pull', or is there another solution?
<jelmer> matttbe: if you've done the merge then the sponsor shouldn't have to do it again
<matttbe> jelmer: except if he want to do modifications, no? e.g. the current Ubuntu version in debian/changelog is set as UNRELEASED (or should I've to set modify it but I thought that it had to be done by the sponsor)
<jelmer> matttbe: sure, but he shouldn't get conflicts that you (or bzr-builddeb for you) resolved earlier
<matttbe> yes but he doesn't have this conflicts if he uses 'bzr pull' because 'quilt pop -a' command is automatically launched. This is why I wonder why patches are not automatically unapplied if we use 'bzr merge'.
<matttbe> But if you say that the sponsor has to use 'bzr pull' and not 'bzr merge', I can understand. Now I know what the sponsor has to do with my branch ;)
<jelmer> matttbe: I'm not sure I follow - 'bzr merge' already should be automatically unapplying patches for '3.0 (quilt)' during a merge
<matttbe> jelmer: yes, you're right, sorry. But if it removes patches, it will not see that patches have been removed and then the diff is wrong.
<matttbe> jelmer: Or is it maybe simply because patches shouldn't be applied in tree?
<jelmer> matttbe: What do you mean with "But if it removes patches, it will not see that patches have been removed and then the diff is wrong" ?
<jml> I'm using 'bzr branch lp:foo' in an automated environment. Is there any way to shut up the warning about launchpad-login?
<jml> I guess I can just specify the http url.
<jelmer> jml: specifying the http URL is probably easiest
<jelmer> there might me some warning suppressing config option too, though I'm not sure about the name..
<jelmer> jml: no, doesn't look like we have a way to silence that message~
<jml> jelmer: thanks.
<matttbe> jelmer: on lp:ubuntu/cairo-dock, there is a patch (applied in tree) which removes one line in one file. With the new version, we can remove this patch (merged upstream). On my branch, 'bzr mu' has unapplied this patch and I've removed it (with 'quilt delete -r').
<matttbe> But if the sponsor merge my branch, the line has not been removed.
<matttbe> It's maybe because if this patch is unapplied just before merging, the line is still in the tree (ok) and then, if we merge this branch with no applied patches with my new branch, this line will remain because on my branch, I don't have changed this file (if we have a look to the diff file, we don't see any modification about this line because I don't modify between the two revisions)
<matttbe> Sorry, I'm not sure that it's understandable :)
<matttbe> (and I don't know how bzr works to do the merge)
<jelmer> matttbe: is the change also gone from the working tree, and from the .pc directory (quilt should take care of that)
<matttbe> after the merge (my new branch => lp:ubuntu/cairo-dock), the '.pc' directory is empty and debian/patches only contain 'series' (which is empty)
<matttbe> in fact, I guess I'll have the same result if I do that:
<matttbe> quilt pop -a ## Now the line is reverted back in the corresponding file
<matttbe> bzr commit ## just to do the merge or I have to use bzr merge --force
<matttbe> bzr merge my_new_branch ## the line is still there
<matttbe> (yes, I confirm I've the same problem if I launch these commands)
<alf_> james_w: jelmer_: Hi! I am trying to merge a new version of a package with merge-upstream, but it complains that "bzr: ERROR: Upstream version 2012.06 has already been merged." . I had previously merged 2012.06 and commited, but then reverted/uncommitted the changes.
<james_w> alf_, run bzr tags and you will see an upstream-2012.06 tag?
<james_w> "bzr tag --delete upstream-2012.06" and you should be good to merge again
<alf_> james_w: Right, "upstream-2012.06     ?" . I did that and now I am getting: bzr: ERROR: Unable to find the tag for the previous upstream version, 2012.06, in the branch: upstream-2012.06
<james_w> alf_, hmm
<james_w> alf_, do you have a 2012.06 tag hanging around as well?
<alf_> james_w: no
<james_w> alf_, hmm
<james_w> alf_, and I guess debian/changelog has no mention of 2012.06 any more?
<alf_> james_w: aha, I made an intermediate commit to update the debian/ dir and have a 2012.06 entry in the debian changelog as UNRELEASED.
<james_w> alf_, that will be it then
<alf_> james_w: ok, so how do I get around that? Do I have to uncommit?
<james_w> alf_, if you remove that entry from the changelog and commit then it should work
<alf_> james_w: so 1. remove that entry, commit, then 2. merge-upstream ?
<james_w> alf_, I think so
<alf_> james_w: it worked, thanks!
<jam1> james_w: I replied to jml's message about upgrading jubany. I imagine we'll want both you and vila around if/when we deploy to Jubany.
<jam1> What time do you usually start in the AM?
<jam1> (utc)
<james_w> jam, 1300
<jam> james_w, so about 1hr ago, right?
<james_w> jam, yeah
<vila> jam: huh ?
<jam> vila: see the thread about upgrading udd
<jam> I think it is reasonable to try to roll out storm again, and if it fails, just roll it back.
<jam> But we don't have to be afraid of that step, as long as we can catch it and roll it back quickly if it starts failing.
 * vila blinks
<jam> and if we get it working, then we can think more sanely about a next step.
<jam> vila: why do you think it is unsafe to *try* a storm rollout?
<vila> because it failed at last attempt ?
<vila> corrupting the db ?
<vila> maxb knows the details, I've just read his emails
<jam> vila, james_w: did it actually corrupt the db? I realize some bits got deadlocked.
<jam> and it wouldn't be rolling out the exact code, it would be with an update to avoid the increased isolation level.
<jam> I don't see a point to rolling out the exact thing we know was failing.
<james_w> it did write some bad data due to the db due to storms behaviour regarding str/unicode
<jam> james_w: was that part of the fixes from max?
<james_w> but I plan to fix the instance Max found and do another pass looking for other cases
<jam> (fixes unrelated to locking to quote you)
<james_w> jam, we haven't yet fixed the last instance he found
<james_w> but we fixed some other things before rolling back
<jam> so that would be a blocker, certainly.
<james_w> yep
<jam> james_w: so another possible transition plan would be to wait until we get some sort of staging system setup.
<vila> +1e6
<jam> I feel like the timeline on that is a bit... unbounded
<vila> I thought a basic test was conducted on ec2 ?
<jam> if it isn't, then it 'races' with finishing the unicode/str fixes
<jam> if we can get a staging set up first, or close to the same time, then doi t
<jam> it
<vila> not to mention the pristine-tar failures ?
<jam> vila: isn't pristine-tar 100% orthogonal to this?
<vila> when it comes to deployment, no
<james_w> a staging system that would do everything except push the branches back?
<jam> james_w: something like that
<jam> I would have some concern that 'doing work but throwing it away' might thrash (if say the primary is stopped for a while)
<jam> james_w: but we really need a place we can test things that isn't prod
<james_w> yes
<vila> james_w: as long as you start with a copy of the dbs
<vila> james_w: pushing does some more db updates but.. well, if the rest is ok, you'll know what to expect
<jam> james_w: do you have any idea of a timeline for the unicode fixes? I imagine if you felt there was no way to get the code deployed, it wasn't worked on as a priority. :)
<jam> vila, james_w: So if we feel there is a reasonable recovery step (snapshot the dbs first, know exactly what to roll back to), it feels like we can at least start to get forward momentum. And if we can get things moving, then we can *improve* stuff.
<jam> jelmer_: are you still doing up-merges?
<james_w> vila, what bd operations does the push do?
<james_w> db
<jelmer_> jam: nope, I'm done
<james_w> it won't test things like filing merge proposals, or the push code
<jam> jelmer_: how are the lp branches coming?
<james_w> and makes the bookeeping a bit off
<james_w> is that an issue?
<vila> james_w: I thought the revids were recorded after pushing ? (That's a gut feeling not from reading the code)
<jelmer_> jam: I was struggling with some tests yesterday, am currently reviewing
<jam> jelmer_: as in doing reviews for others? Or getting the branches reviewe
<jam> d?
<james_w> vila, ah yes, sorry, I was reading the wrong bit
<vila> james_w: at least when I test locally, doing the same import without pushing seems to redo the same steps
<james_w> yeah
<james_w> I see what jam means about thrashing now
<james_w> jam, indeed, I hadn't done the fixes because it wasn't clear what the plan was
<jelmer_> jam: reviewing for others
<james_w> jam, they are just a couple of hours work though
<jam> anyway, I'm at EOD (have to go take my son to swimming), but I'd like us to hash out a quick 'next steps' and see what can get the ball moving again.
<james_w> I'll followup on the mailing list
<LeoNerd> FSCKING REBASE!
<LeoNerd> Can anyone tell me why I have to 'bzr unbind' before it'll actually work? I hate having to do this
<LeoNerd> Otherwise it immediately claims that bzr: ERROR: Bound branch BzrBranch6(file:///home/leo/src/perl/IO-Async.TASKS/) is out of date with master branch RemoteBranch(bzr+ssh://cel/var/bzr/leo/perl/IO-Async.TASKS/).
<jelmer_> LeoNerd: why would you want to use rebase with a checkout?
<LeoNerd> Because I never do anything that isn't in a checkout
<LeoNerd> I don't trust my ability not to lose my laptop or crash its disk, so everything is backed up on my server
<LeoNerd> Currently I  bzr unbind;  bzr rebase ..... bzr bind :bound; bzr push --overwrite :bound
<jelmer_> LeoNerd: generally you would make a checkout of the master branch
<jelmer_> LeoNerd: and it's pretty uncommon to rewrite branches in the main project branch
<LeoNerd> Hrm? It's not the main branch. It's a feature branch
<jelmer_> anyway, what you're trying to do isn't really wrong but it's not very common either
<LeoNerd> I rebase it after every main release
<CodeNinjaSD> Does bazaar support E-mail messages to one or more addresses should be generated when a change is committed. Format of e-mail may change (e.g., doc committer committing to src tree)
<CodeNinjaSD> What about sthe ability to attach searchable/annotated tags, other than revision number to code artifacts
<gour>  /c
<psusi> I have noticed that I made a slight error a few commits back.  With git, I would fix the error, commit it, then rebase -i to sqash that commit back into the previous one.  How can I do this with bzr?
<psusi> or maybe pop the last few commits off the branch into patch files, fix the errored commit, then reapply the patches
#bzr 2012-06-22
<psusi> how can I go back and correct a commit after adding a few more on top of it?  With git I would just commit the fix, then use rebase -i to squash the fix into the original.
<bob2> you can rebase if you want
<bob2> or just fix it
<psusi> how would I rebase it?  I'd prefer to not clutter the history with the fix commit
<bob2> by rebasing it?
<bob2> http://wiki.bazaar.canonical.com/Rewrite
<bob2> depends how much you care
<psusi> do I have to branch into another directory first, then uncommit back to the problem commit, fix, recommit, then rebase the original branch onto this one?
<psusi> or is there a way to do it in the current directory?
<spiv> psusi: use the rebase command (from the bzr-rewrite plugin)
<psusi> spiv, yea... how exactly?
<spiv> Although maybe I'm wrong, and it still needs you to do it in another directory.
<spiv> I'm sorry, my memory on using it is hazy :(
<mwhudson> psusi: one of the reasons people don't care so much about this sort of thing in bzr is that most of the time one is working a branch that's going to be combined with trunk by "bzr merge"
<lifeless> you'll need to branch the rev you want to fix to  a new branch, uncommit once and commit with the fixed message, then replay from the other branch
<lifeless> mwhudson: I think they do care, often, but we've filtered them out of the community; see my manifesto for my analysis about it ;)
<mwhudson> psusi: and when people run "bzr log" in trunk, they only see the message that the branch was merged with by default
<mwhudson> lifeless: well yes
<psusi> mwhudson, that not only does not avoid cluttering the history with minor fixup commits, but clutters it even more with useless merges
<mwhudson> psusi: you see, i don't think of them as 'useless merges' -- quite the opposite, they are actually the most important thing
<mwhudson> psusi: not trying to convert you or say you are wrong, but different tools tend to be used in different ways
<psusi> a merge that just fast forwards rather than actually merges concurrent development lines is a useless line in the history at best, and at worst, hides the actual development
<spiv> It depends on what you value (and what the owners of the other branches value).
<psusi> well, there aren't other branches
<psusi> hence, why I don't want to add extra commits
<spiv> I tend to value having a single, clear commit on my branch when a merge happens summarising the thing that landed (and then if I want to see details of how that got developed I dig into the history on that side).
<spiv> But I understand other folks work differently or value different properties more.
<psusi> that makes sense... if I branched and made several commits that all are part of one new feature... but I didn't... just several unrelated commits
<jam> morning all
<mgz> morning
<jml> hello
<lifeless> hawdee
<Wiz_KeeD> hey guys!!
<mgz> hey
<Wiz_KeeD> mgz i have some question about bzr think you can help out?
<Wiz_KeeD> :D
<mgz> Wiz_KeeD: don't ask to ask, just ask.
<psusi> when I want to ammend the previous commit, if I uncommit, fix it, then recommit, I have to retype the log message.  Is there a way to avoid that?
<jelmer_> psusi: the commit message is saved in .bzr/branch/branch.conf if you have bzr-gtk or qbzr instaled
<jelmer_> they will also suggest the old commit messages if you commit using 'bzr qcommit' or 'bzr gcommit'
<jelmer_> 'bzr commit' doesn't have this functionality (yet)
<psusi> doh
<mgz> I just keep it on the clipboard generally...
<psusi> problem with that is that if I look at the log, copy, and paste it back in, I have to manually delete the indentation from each line
<psusi> which gets annoying
<Wiz_KeeD> how can i browse bzr revisions?
<jelmer_> Wiz_KeeD: bzr viz or bzr qlog
<Wiz_KeeD> none work
<Wiz_KeeD> wait
<Wiz_KeeD> nop, neither work
<jelmer_> Wiz_KeeD: you'll have to have either bzr-gtk or qbzr installed
<Wiz_KeeD> unknwon command
 * gour uses fish shell and it usually guess correct log message
<Wiz_KeeD> it has installed olive bazzar gui
<psusi> I did a bzr rebase and it shows up in the log as a merge.. what gives?
<Wiz_KeeD> what does rebase do?
<psusi> rewrites history to make commits appear as being based on a different starting point
<Wiz_KeeD> being based on a different startying point?
<psusi> instead of rev X, then A and B, it's rev Y, then A and B
<Wiz_KeeD> ah...
<Wiz_KeeD> littel wierd
 * psusi beats bzr with a rubber hose... a rebase is NOT a merge!
<jelmer_> psusi: hmm?
<psusi> jelmer_: a few commits back, I fixed something wrong.  So I branched, uncommitted back there, fixed it, committed it again, and am now trying to rebase the subsequent commits on top of the new fixed old commit so it looks like I got it right the first time
<psusi> and when I bzr rebase -r 33.. fixed, rev 33 shows up as a MERGE
<jelmer_> psusi: presumably because the old rev 33 was a merge commit?
<psusi> nope
<psusi> no merges anywhere
<psusi> until after I try to rebase
<psusi> err, actually it was rev 33 where the error was so I rebase -r 34.. to get all of the commits above there onto the new, corrected 33
<psusi> but after the rebase, r34 shows as a merge that has the description of the old r34, but merges the new, corrected r33
<jelmer_> ah, bzr-rebase probably doesn't handle the same revision being in the branch multiple times very well
<psusi> argh... this is so easy in git
<psusi> this is really broken... the history apparently was correctly rebased... it shows r34 following the new, corrected r33... it r34 also says it merged in the OLD r33
<psusi> which makes no sense at all
<psusi> well, I guess it's back to my old method of uncommit, shelve, repeat, edit, recommit, unshelve, commit, repeat
<fullermd> Well, it's a parent of the old 34, so in that sense it could be part of the stuff to be brought over, given a certain interpretation.
<psusi> the whole point of rebasing is to discard the old history
<fullermd> 'd probably have to poke around in the helpfile for the details; I don't know (or have it around to check myself)
<psusi> and make 34+ as if they were originally done on top of the new 33
<fullermd> A matter of interpretation.  It would be just as valid to say the point is to take (history on that side that's not here) and stick it on the end of here.
<psusi> and you obviously did not merge the old 33, since the state of the files reflects the contents of the new 33, but the log makes it look that way
<psusi> no, that's what a merge is
<fullermd> Not really.  Merge couldn't put them on the end.
<psusi> merge always puts them on the end.... under a merge commit
<fullermd> new-33 isn't a parent of old-34, so merge couldn't make that happen; only a rebase could.
<fullermd> It has to create a new-34 to cause that.
<fullermd> Merge can only put them off to the side, then put something new on the end that connects the two.
<psusi> right... rebase changes new-34 so it says its parent is new-33.. and that's all it should do
<psusi> instead it seems to make new-34's parent new-33, AND merge in old-33
<psusi> you can't have both old and new 33, they conflict
<fullermd> Anyway.  This is bootless.  My point is that it's not immediately obvious to me whether the existing parent of 34 is part of what should be preserved or not in a rebase, and so I'd consider either behavior a sensible answer to the question.  It would take digging into the details of what rebase does and what args it takes to know for sure, and I don't have any of that at my fingertips.
<fullermd> Semantically, yes; that's what you intend.  The question is, is the command you're running expressing that as bzr expects.
<fullermd> It could be a bug "the default choices aren't what I expect", or a bug "the default choices aren't working as designed"; I don't know which.
<psusi> how is it not obvious?  the whole point of a rebase is to eliminate the existing parent and replace it with a new one
<fullermd> If the former, there's probably some arg you can find in help that will get you where you want to be.
 * fullermd shrugs.
<fullermd> To me, in isolation, it's not obvious that one of the choices is obviously right and the other obviously wrong, so I couldn't express an opinion as to which way things are failing.
<psusi> one of the choices follows the definition of rebase, the other does not
<fullermd> There is no "definition of rebase".
<psusi> sure there is... to change the base revision on which a set of history started from
<fullermd> There's a "what _git_ does when you run rebase with -xyz", and a "what _bzr_ does when you run rebase with -xyz".  Presumably they're _close_, but I don't see any reason to assume they're identical.
<abentley> vila: I'd like to discuss bug #1015614 .  Do you have a minute?
<ubot5> Launchpad bug 1015614 in Bazaar "Configuring local colocated branches matches too broadly" [Undecided,New] https://launchpad.net/bugs/1015614
<fullermd> Wow, LP got into the millions there.
<abentley> fullermd: Yep, about a month ago: http://blog.launchpad.net/general/one-in-a-million
<fullermd> The downside is that I'm really going to have to knuckle down and write some terrible code if we're going to hit the billion mark in my lifetime.  Sigh.  Back to the salt mines...
<mgz> it's not enough just to be bad fullermd, you also have to be popular
<fullermd> Oh, I take _that_ part for granted.  I mean, _look_ at me!
<abentley> mgz: like nvidia? :-)
<jml> hey, someone just asked me why submit: and push: locations are two different things
<jml> and I don't know the answer
<jml> what's the answer?
<jelmer_> jml: submit is what you want to submit merge proposals against
<jelmer_> jml: e.g. in the case of bzr
<jelmer_> you push your feature branch to lp:~jml/bzr/feature-branch
<jelmer_> whereas the submit location is lp:bzr
#bzr 2012-06-24
<KombuchaKip> I have a bundle file someone sent me of their changes to my branch. I'd like to apply their changes, but selectively. Is there a GUI manual merge technique?
<luke-jr> I got disconnected during a long branch (from a remote branch); is there a way to use the already-downloaded data when I try again?
<jave> hello
<jelmer> hi
<jave> I'm playing with fastimport/export. For example, the emacs bzr repo. A conversion takes: Exported 121365 revisions in 1:36:59
<jave> (I use a gitbzr script for convenience)
<jave> wheres the bottleneck? I dont think the server used is super slow at least
<rawr> profile it and find out.
<jelmer> jave: are you fastexporting directly from the server?
<jelmer> jave: that won't be very fast, it'll be trying to manually extract all full texts
<jave> jelmer: no theres a local bzr emacs checkout I convert from
<wgz> do you mean checkout? because that's just the tree state, you need the whole repository locally#
<jave> sorry im not too good with the bzr terminology. I meant an entire copy of the emacs repository.
<jave> can I, say, convert the repo disk format to something that is space-inefficient but fast?
<qaghan> Guys, I have a problem. I cannot push files onto Launchpad. I created an SSH key, copied and registered it on Launchpad, have the files in my /.ssh folder and the trunk of my project that I want to push
<qaghan> but I still keep getting the permission denied(publickey) error
<qaghan> I did do $ bzr launchpad-id thingie also
<xuedi> hello there, this might be a stupid question, i installed bzr-gtk on debian ... Does someone know the name of the binary to start the gtk frontend? bzr-gtk does not exist
<kbulgrien> dpkg -L <package_name>
<kbulgrien> Why do people ask questions and leave only minutes later...
<SteveA> good evening!
<SteveA> I'm introducing bzr to a team that is using Eclipse on Ubuntu, and looking for a recommendation of whether to suggest QBrzEclipse or BzrEclipse.
<SteveA> hi beuno, BjornT, bob2, elmo, jamesh, james_w, herb, jelmer, kirkland, lamont, lifeless, mthaddon, mwhudson, Ng, spiv, verterok! Look me up if you're in London.
<SteveA> hi jam too
<lifeless> SteveA: hi :)
<lifeless> uhm
<lifeless> I think qbzreclipse has more cycles being put into it
<lifeless> bzreclipse is a little unmaintained at the moment I think, verterok is flat out with $otherstuff
<SteveA> thanks lifeless
<SteveA> any recommendations on what the best svn integration is right now?
<lifeless> bzr to svn, or eclipse to svn ?
<lifeless> bzr-svn if you mean the former.
<SteveA> svn to bzr and back, although for the back journey, we'll most likely produce hand-crafted patches and manually commit to svn
<SteveA> so, mainly taking an svn branch at a particular revision, and want to make a bzr branch of that
<SteveA> and be able to pull updates from that svn branch over time
<lifeless> bzr-svn
<SteveA> ta
<lifeless> 'bzr branch svn:///.... '.... wait, bzr pull at later date
<SteveA> nice!
<lifeless> it will do some fairly extensive number crunching if the repo is big, on first execution.
<lifeless> This maps out the whole history etc. It stores it in a db in ~/.bazaar/svn/ IIRC. So its fast on second and third etc
#bzr 2013-06-17
<mwhudson> if i C-\ and bt it appears to be in accept()
<mwhudson> which (a) makes sense and (b) surely should be interruptable
<mwhudson> hmm
<mwhudson> works on this other machine
<mwhudson> hey guess what, i can C-c bzr --no-plugins serve ...
<mwhudson> maybe bzr-git?
<lifeless> maybe
<lifeless> or maybe bzr-svn
<SamB> it's too bad about bzr-svn
<jelmer> lifeless: bzr-svn I suspect, subvertpy
<jelmer> SamB: what is?
<SamB> jelmer: I heard it's going the way of the dodo ...
<jelmer> SamB: nobody is actively killing it :)
<jelmer> but yeah, I understand what you mean
<SamB> Oh, were dodos killed by man? I forgot about that.
<mwhudson> jelmer: $ bzr plugins | grep -c svn
<mwhudson> 0
<jelmer> IIRC they were supposedly quite tasty.
<mwhudson> so if it's bzr-svn that's pretty magic action at a distance...
<jelmer> mwhudson: I guess there are more things in the world that break python's brittle SIGINT handling
<jelmer> but I'm glad it's not certain I'm responsible for this one ;-)
<SamB> Python's SIGINT handling is broken out-of-the-box
<jelmer> batteries included?
<SamB> and you can't really unbreak it properly without writing a stub in C ...
<SamB> since SIGINT can easily arrive before you've had a chance to override it
 * SamB would be a lot happier if there was a flag you could put in your shebang that would make Python follow the usual SIGINT rules
<mwhudson> uhh
<mwhudson> it's the dbus plugin
 * mwhudson boggles gently
<spiv> SamB: A sufficiently creative LD_PRELOAD would probably do the trickâ¦
<spiv> mwhudson: sweet baby dbus!
#bzr 2013-06-18
<Noldorin> is it possible to pull in bzr without updating the working tree?
<bob2> yes
<bob2> but in practice you want a shared repo, then
<Noldorin> bob2, what's the command?
<bob2> as above
<bob2> you want a shared repo and bzr pull
<Noldorin> and yeah, ot's just a hypothetical question
<Noldorin> :)
<Noldorin> oh
<Noldorin> bob2, so with a single working directory & branch it's not possible eh?
<bob2> didn't say that
<bob2> but it hardly seems worth explaining for a hypothetical
<Noldorin> bob2, is it complicated heh?
<bob2> ok!
<Noldorin> bob2, hmm i think you misread one or more of my messages
<jelmer> Noldorin: Repository.fetch()
<jelmer> Noldorin: not sure if we expose that on the command-line directly anywhere
<jelmer> Noldorin: (or why we should)
<Limit_> HI, I am getting this error: can anybody help??
<Limit_> Connection error: Couldn't resolve host 'xmlrpc.launchpad.net' [Errno -2] Name or service not known
<Noldorin> jelmer, ah right, i see
<Noldorin> fair enough then
<LarstiQ> Noldorin: you can also do `bzr remove-tree` first ;)
<Noldorin> LarstiQ: 'first'?
<tuvwx> bzr is taking hours to branch a ~1GB repo on a machine with 512MB ram :(
<tuvwx> it appears to be swapping constantly (physical memory is full)
<lifeless> tuvwx: if you're cloning over http from LP, don't :)
<tuvwx> lifeless: i'm using the launchpad-suggested command at the top of the 'code' tab: bzr branch lp:...
<jelmer> tuvwx: are you logged in? that makes a significant difference since that will make it switch from http to ssh
<tuvwx> no, i'm not logged in. does bzr use ssh differently from http?
<jelmer> tuvwx: yes, significantly. bzr uses a custom (bzr-specific/optimized) protocol over ssh. over http it just does regular file access
<tuvwx> but why would "regular file access" consume that much memory?
<jelmer> tuvwx: what version of bzr are you running?
<tuvwx> jelmer: 2.6.0dev2 from debian wheezy
<jelmer> okay, that should have all the performance improvements
<lifeless> tuvwx: because if you thrash the internal page cache, it regets content over http
<lifeless> tuvwx: and each retrieval has approx 2x overhead in RAM, and unlike the os page cache isn't shared.
<lifeless> tuvwx: I suspect you're branching something like mysql
<lifeless> tuvwx: or java, and some of these have very large btrees which result in inventory cache thrashing
<lifeless> tuvwx: there is a bug on it I believe.
#bzr 2013-06-19
<tuv> i aborted the http branch after 3 hours, and started a new one after login. it cloned in 10 minutes twice what it did in 3 hours!
<tuv> and did not eat up all my memory. ~80%
<tuv> well.. it did get to consume all my memory eventually, but waaay later than http did
<tuv> >512MB for cloning a repository does not sound right
<tuv> and it's done in 20 minutes.. WOW
<jam> vila: how do you get stuff like 'bzr merge' and 'bzr switch' to move ignored files to the lost-and-found instead of conflicting? I don't remember the syntax and my quick greps didn't find it.
<spiv> jam: there's a bzr config option
<jam> spiv: right, but *what* is it :)
<spiv> jam: bzr.transform.orphan_policy ?
<spiv> (Thank you release notes)
<jam> spiv: I wasn't looking all the way back to 2.3, wow
<jam> spiv: thanks for helpnig
<jam> I was looking for "lost" and "ignore" when it is "orphan" and "move"
#bzr 2013-06-22
<maxiaojun> Is bzr dead?
<maxiaojun> jelmer, is bzr dead?
<tuv> maxiaojun: what would you think so?
<maxiaojun> stuck in a beta release, bad smell
<tuv> maxiaojun: you're obviously better informed than me. i'm just a casual user
<tuv> i'll wait for an answer next to you
<jelmer> maxiaojun: hi
<maxiaojun> hi
<jelmer> maxiaojun: I don't think Bazaar is "dead", whatever that means. There have been commits in the last couple of weeks.
<maxiaojun> ok, cool
#bzr 2013-06-23
<beniwtv> Hi all... I've upgraded to Ubuntu 13.04, now bzr 2.6.0dev3, and on all commands (from a previous working repo) I get: bzr: ERROR: No such file: u'.bzr/repository/pack-names': [Errno 2] No such file or directory
<beniwtv> Google doesn't seem to find any references to this :(
<fullermd> Is the file there?
<beniwtv> fullermd: nope
<fullermd> What all IS under repository/ ?
<beniwtv> fullermd: repository doesn't even exist only branch/ branch-format branch-lock/ checkout/ README
<fullermd> You'll have to look in the .bzr dir for the repository.
<beniwtv> fullermd: Also, this has been working before upgrading to 13.04
<fullermd> bzr version shouldn't matter; none of that stuff has changed in ages.
<beniwtv> fullermd: Yep, that's what I got in .bzr
<fullermd> Right, but not the .bzr for the repository; that's just the tree.  What's 'bzr info' say?
<beniwtv> beniwtv: Same error msg, I suspect something is broken, so maybe I should just check out everything again?
<fullermd> If you don't have any local stuff to lose, that's simpler.  Still would be nice to get some idea of what happened though...
<fullermd> Try walking up the FS manually to find the repo.
<beniwtv> fullermd: Yeah, I tried that, but no repository directory is there
<beniwtv> fullermd: Looks like it got wiped out or something...
<fullermd> I wonder if we're talking past each other.
<fullermd> I'm not saying "find the repository" as in ".bzr/repository/", but as in "find the shared repository this branch is using"
<fullermd> Unless you're doing a --light checkout from somewhere remote, but...
<beniwtv> fullermd: Ah! Sorry, my mistake.
<fullermd> So /some/path/xyz/.bzr/ may not have a repository/ in it, but maybe /some/path/.bzr/ or /some/.bzr/ does.
<beniwtv> fullermd: You're right, it does
<fullermd> Or /.bzr/, assuming you're insane   :)
<beniwtv> fullermd: Ok, so it's got packs/, but no file pack-names
<beniwtv> fullermd: No wait, it's got one renamed to .tmp
<beniwtv> fullermd: pack-names.3699.*.tmp
<fullermd> OK, that implies (I think) that it was writing a new one and got interrupted partway through.  Badly timed system shutdown or crash or ^C or the like.
<fullermd> e.g., it writes foo.tmp, then removes foo, then moves foo.tmp in place, to make sure things are atomicish.
<fullermd> Which means that file MAY only be partly written.  Blech.
<fullermd> But, if the main file has gotten as far as being removed, maybe we can assume it's complete.
<fullermd> And in any case, it's all you got.
<fullermd> So all that's just a long-winded way of saying "Try moving it in place".
<beniwtv> fullermd: Well, I cold try renaming it
<beniwtv> fullermd: Yep
<fullermd> A poke at 'log' or the like afterward will probably serve as a quick smoke test.
<fullermd> If that works, it's probably worth doing a full 'check' just to be sure.
<beniwtv> fullermd: Nope, another error, and it's got a lot more to commit (bzr status) that I changed, so...
<fullermd> Well, that file IS just a listing of files and stuff from the packs dir.  So it should be possible to recreate manually.
<fullermd> It's not plaintext though, but some binarish internal format.  So...
<beniwtv> fullermd: Ok, so it's propably easier to just check it out again and replace the changed ifles manually...
<fullermd> A little grep'ery suggests that there IS a method that seems to generate them itself, which may be easy to call...
<fullermd> But it may require have a repo object to get to calling it, which is a nice stupid chicken-and-egg position.
<beniwtv> fullermd: ok, no worries, I'll just check it out again...
<beniwtv> fullermd: thanks anyway tough :)
<maxb> The binary format can be inspected via '$ bzr dump-btree .bzr/repository/pack-names
<maxb> Though I forget exactly what the series of numbers stored for each pack are
<fullermd> Unfortunately, that doesn't help with the lack of restore-btree   :)
<maxb> If you can somehow recover the data, you can write out a new one with bzrlib.btree_index.BTreeBuilder
<fullermd> It's 11 in the morning.  The sun is up.  You shouldn't be able to give me nightmares...
<maxb> Well, it seems the extra data stored in the pack-names file is the size in bytes of each of the related index files for that pack
<maxb> Though I'm a little unclear why that info is stored separately
<maxb> Which means in theory it ought to be trivial to rewrite a pack-names for any repository that is otherwise uncorrupted
#bzr 2014-06-19
<mark06> is there any bug for the fact that qlog doesn't show merge tags?
<fullermd> "merge tags"?
<mark06> tags applied to merged branches, sorry
<mark06> I see them here for example, bzr qlog lp:ubuntu/utopic/pidgin
<mark06> but not in my branch, *why*?
<fullermd> You mean tags off on non-LHS revs?  They're there, if you expand it.
<mark06> I expand the node but they don't show up... will try recreating the branch from ubuntu... maybe a bug with windows which is on old version
<mark06> it worked on ubuntu... I guess windows version needs an update :(
<fullermd> I wouldn't think the branch would be squirrely; pretty sure that's worked like that as long as we've had tags.  Maybe just the qlog is old and not showing them right?  That seems odd too though...
<mark06> forgot to check log... maybe it's just qlog...
<fullermd> Can just check 'tags' too.
<mark06> the windows branches are gone
<fullermd> Oh, if only it were really that easy   ;-}
#bzr 2014-06-20
<mbruzek> Hello #bzr.
<mbruzek> Have a question for you.  I am getting a branches diverged error and I do not know how to resolve.
<mbruzek> http://pastebin.ubuntu.com/7674915/
<mbruzek> I read the help on bzr help diverged-branches
<mbruzek> Can someone please advise?
<jelmer> mbruzek: try "bzr missing lp:~mbruzek/charms/precise/ntp/amulet"
<jelmer> "bzr missing" is using a different remote URL than "bzr push" is
<jelmer> (since you're specifying one explicitly)
<mbruzek> jelmer I tried to do "bzr missing" with no result, I did not know to add the branch
<mbruzek> I got it sorted with my teammates.  Thank you for responding.
<jelmer> mbruzek: see its first line of output, it runs against a different branch
<mbruzek> jelmer, what does bzr merge default to?
<jelmer> mbruzek: parent branch I think
#bzr 2015-06-16
<CoyoteLE> ÐÑÐµÐ¼ Ð¿ÑÐ¸Ð²ÐµÑ, Hi all)
<CoyoteLE> nya)
 * CoyoteLE ^_^
#bzr 2015-06-17
<CoyoteLE> Hi all!
<barry> jelmer, or anyone else: does anybody still know how `bzr merge-upstream` works and can help with a problem i'm having?
#bzr 2015-06-18
<sidi> Is anyone aware of a Chinese tutorial for Bazaar? I have a Chinese student who's struggling to understand the basics and I'm under the impression a native resource would help
<fullermd> Can't say that I've ever heard of one...
<LeoNerd> The basic concepts of any modern DVCS are all basically the same; it might be easy to pick up the basics from anything that happens to be locally-translated, then the specifics of any particular one will make more sense afterwards
<dr_iil> Hi there.
<dr_iil> Probably google blindness but I've been looking for documentation on using bzr with composer but not coming up with much.
<dr_iil> If anyone could point me at some appropriate reading that would be very welcome.
<dr_iil> Thanks
<LeoNerd> composer?
<dr_iil> For managing dependencies.
<LeoNerd> Hmm.. not heard of it myself
<dr_iil> Works really well for managing versions into packages. e.g. package uses a different version of a data object. Versions are in the same repository etc. Works with GIT SVN and Mercurial. Can't find anything in the Composer docs about Bazaar. Can't find anything in Bazaar docs about Composer
<dr_iil> Nevermind. Probably they've just not gotten round to it yet.
<dr_iil> Sure it will be straight forward to work out.
<dr_iil> It's turned out to be very straightforward, It's just not supported. Oh well that solves that one.
<fullermd> It _is_ always nice when problems have simple and straightforward resolutions.  Sorta.
<fullermd> I think Composer is one of those things floating around the same crowd of people who use Docker and such things.
<fullermd> And as such, presumably makes sense once you internalize the couple dozen other components of that world, but is completely impossible to describe or comprehend otherwise...
<dr_iil> It's the kind of tool that's invaluable if you development isn't absolutely linear or you have to progressively update a component across multiple projects that have shared components.
<dr_iil> Or if you manage components in separated projects.
#bzr 2018-06-18
<jelmer> Prodi: hi
#bzr 2018-06-21
<mgz> jelmer: okay, finished here, will womble over to the office to meet you?
<jelmer> mgz: cool, meet you in the lobby in a couple of minutes?
<mgz> yeah, will be ~5
<mgz> see you soon!
