#bzr 2008-06-09
<beuno> mwhudson, I'm looking at bugs I can easily close for loggerhead, and I bumped into bug #121715, but I don't understand what that means  :)
<ubottu> Launchpad bug 121715 in loggerhead "should have annotation info on diff view" [Undecided,New] https://launchpad.net/bugs/121715
<mwhudson> i don't think i understood what that one meant either
<beuno> lol
<mwhudson> oh hang on, i filed it
<beuno> yeah, that's why I asked
<mwhudson> i think the idea was that you could mouse-over the line numbers and get annotation info
<mwhudson> but feel free to ignore it
<mwhudson> (especially now annotation isn't so very cheap with packs)
<beuno> mwhudson, alright, I'll mark it as incomplete, and aim for a cleaner list of pending bugs to fix  :)
<jelmer> mwhudson: sorry, don;t have experience with pysvn
<mwhudson> jelmer: oh ok
<mwhudson> in other pysvn news, pysvn.Client.update appears to ignore the ignore_externals code
<jelmer> mwhudson: only with python-subversion
<beuno> ah, I can't change bug importances
<chandlerc> jelmer: please let me know if you need me to re-work my patch. i'm more than happy to bang on it until its up to par
<jelmer> which patch is that? The one for dealing with "branches" being missing?
<chandlerc> yea
<jelmer> chandlerc: it would be nice to have a unit test that ensures that bug is fixed
<chandlerc> k, i'll dig into the testing framework...
<jelmer> chandlerc: Never mind
<jelmer> chandlerc: This is a webdav-specific error, so it's hard to create a test for it
<jelmer> chandlerc: I'll merge your patch
<chandlerc> ok
<chandlerc> =] it would have taken me a while to get comfortable with the test framework anyways
<chandlerc> i got lucky with the patch, was much simpler than I had originally thought
<jelmer> chandlerc
<jelmer> : committed, thanks!
<chandlerc> jelmer: thanks for the help debugging it yesterday! the fix was quite easy
<lifeless> sweet!
<lifeless> :!bzr search search
<lifeless> Revision id 'robertc@robertcollins.net-20080608221948-66c28r366alynula'.
<lifeless> Revision id 'robertc@robertcollins.net-20080608055724-c6tjpycts2476brf'.
<lifeless> :!bzr search indices
<lifeless> Revision id 'robertc@robertcollins.net-20080608133638-j5yazpedr3mlixju'.
<lifeless> Revision id 'robertc@robertcollins.net-20080608114120-2gjfj34t8xuqp2qt'.
<lifeless> Revision id 'robertc@robertcollins.net-20080608143716-0eq1vm6b2zj8mx2t'.
<lifeless> :!bzr search indices run
<lifeless> Revision id 'robertc@robertcollins.net-20080608143716-0eq1vm6b2zj8mx2t'.
<lifeless> beuno: ^ searching now works
<lifeless> (and I've pushed)
<beuno> lifeless, if I hadn't met you in person, I'd be sure you're not human. Pulling now  :)
<lifeless> there is a bug in the bzrlib index layer that makes it fall over and cry when indexing all of bzr
<lifeless> the second-stage index layout will avoid this and actually have some chance of scaling too :P
<lifeless> -> breakfast, then I might teach this to use slightly better apis so it doesn't load the entire index to search
<beuno> lifeless, beuno@beuno-laptop:~/bzr_devel/bzr-search$ bzr index .
<beuno> bzr: ERROR: Failed index creation. Internal error: mismatched output length and expected length: 12509112 3127278
<lifeless> 09:44 < lifeless> there is a bug in the bzrlib index layer that makes it fall over and cry when indexing all of bzr
<lifeless> oh
<beuno> well, it's not on bzr.dev  :)
<lifeless> you have a shared repository
<lifeless> it *is* on bzr.dev :P
<beuno> I do
<beuno> ah
<beuno> heh
<lifeless> if you were to tighten up index.index_url
<lifeless> then it would restrict itself to the plugin, and work
<lifeless> get it working, make it correct, make it fast
<lifeless> stage 1) done.
<lifeless> if you branch the plugin to a standalone area it will be happier
 * beuno sets aside loggerhead bug triaging and fires up VIM
<beuno> works as a standalone branch  :)
<lifeless> hmm, we want hit summaries soon as well
<lifeless> just printing the rev id is not that helpful :P
<lifeless> should pass branch to search, then it can pass to the hit objects
<lifeless> dammit. BREAKFAST I AM COMING
<lifeless> :P
<beuno> lifeless, so, playing around with it, I replaced all_revision_ids() with get_graph and turned it into a dict, and it seems to not explode now :)
<beuno> it's very hackish, as I just wanted to see if it worked
<beuno> I'll try and cleanup enough to send a quick patch
<lifeless> awesome
<beuno> lifeless, ah, Verterok, which is working here today, has a simpler solution. Replace branch.repository.all_revision_ids() with branch.revision_history()
<beuno> works fine here
<lifeless> its wrong though
<lifeless> your one was better
<lifeless> revision_history is left-hand-side only
<beuno> ah, I see
<lifeless> ideally its actually find-the-new-revisions task
<lifeless> but indexing the lot as a starting point isn't a problem
<beuno> lifeless, this is what I have now: http://paste.ubuntu.com/18618/
<beuno> it returns a dict, which, of course, isn't what it's expecting
<beuno> and I suspect that will get repeated revids as parents, which we don't want to re-index
<lifeless> try
<lifeless> searcher = graph._make_breadth_first_searcher()
<lifeless> for parents, ghosts in searcher.next_with_ghosts()
<lifeless> revs_to_index.update(parents)
<lifeless> revs_to_index.remove(NULL_REVISION)
<beuno> lifeless, beuno@beuno-laptop:~/bzr_devel/search.beuno$ bzr index .
<beuno> bzr: ERROR: Failed index creation. Internal error: mismatched output length and expected length: 12509112 3127278
<lifeless> pass [_last_rev_id] to the searcher constructor
<beuno> lifeless,     for parents, ghosts in searcher.next_with_ghosts():
<beuno> ValueError: need more than 0 values to unpack
<beuno> :/
<toyto1> hello guys, using http like this 'bzr checkout http://www.example.com/myproject-as-repo' where the "myproject-as-repo" has the .bzr directory will require special configuration in the server?
<lifeless> beuno:     def next_with_ghosts(self):
<lifeless> ...
<lifeless>         return self._current_present, self._current_ghosts
<beuno> I didn't know about the searcher, it may be useful for loggerhead too (if I can get it to work)
<toyto1> when i tried 'bzr checkout http://www.example.com/myproject-as-repo' I have error '... couldn't resolve host ..'
<lifeless> toyto1: no special configuration needed, just have to serve the directory
<lifeless> toyto1: if you want to allow writing, then you need special configuration
<lifeless> beuno: next_with_ghosts does not return an iterator
<toyto1> lifeless: yeah my purpose is writing is thru sftp, while checkout or read is thru http
<lifeless> beuno: I was doing pseudocode
<lifeless> toyto1: will work fine
<beuno> lifeless, alrighty, let's see if I can figure this thing out...
<toyto1> lifeless: but when I tried that it says 'couldn't resolve host'... error that looks like that :(
<lifeless> toyto1: sounds like it can't figure out the host :)
<toyto1> lifeless: nvm, I type a wrong path sorrry :) thanks for that
<toyto1> lifeless: yeah hehe sorry, thanks lifeless :)
<lifeless> no probs
<lifeless> beuno: that work better?
<beuno> lifeless, it seems a little trickier than that, but I got it not exploding now. Just need it to actually index  :)
<beuno> meh, no, not working
<beuno> I'm trying to iterate similar to repository.InterRepository._walk_to_common_revisions
<beuno> leaving aside the logic that compares
<lifeless> well, I would start with just the full graph collection
<lifeless> as size(branch) better than size(repo)
<beuno> including duplicate parents and such?
<lifeless> searcher eliminates those
<beuno> right
<beuno> lifeless, http://paste.ubuntu.com/18624/
<beuno> I must be something fundamentally wrong, as it gets StopIteration on the first loop
<lifeless> [_last_revid]
<beuno> argh, thanks
<beuno> lifeless, some progress :)    have to cleanup a bit
<lifeless> cool
<beuno> lifeless, seems to work: http://paste.ubuntu.com/18625/   (delete the bzr-search index first)
<beuno> seems to, as in, it works on a shared repo, and returns the search results expected
<lifeless> two things
<lifeless> there are two branches
<lifeless> if you index twince on a shared repo you will blow up
<lifeless> secondly, you don't need to filter the next revs, just update
<lifeless> *outside* the loop, remove the NULL revision
<beuno> lifeless, fixed the null filter, but I don't understand what you mean by "there are two branches"
<lifeless> in the function
<lifeless> new index
<lifeless> update index
<lifeless> you've made new index perform better
<beuno> ah, yes, copy the logic
<bpeterson> if I have a branch with bzr-email enabled on it and I reconfigure it to a checkout, will the bzr-email hook still run?
<lifeless> yes
<lifeless> though you may need to update your locations.conf depending on what rule you put in
<bpeterson> I put it in .bzr/branch/branch.conf
<bpeterson> because I couldn't get the wildcards right
<lifeless> yah that should fire
<lifeless> easy way to test :P
<bpeterson> thanks again
<bpeterson> It's even easier to ask here, though!
<beuno> lifeless, something like this?  http://paste.ubuntu.com/18626/
<beuno> mwhudson_, the searcher seems like it could help with the loggerhead needs-full-history problem. It's not straightforward to use right now, but with some refactoring...
<lifeless> beuno: good; don't need the set() cast around next revs AFAIK, but otherwise should be good
<beuno> lifeless, ah, I don't  :)
<beuno> want a bundle for that, or will you just copy off paste.u.c?
<lifeless> commit, bundle me up
<beuno> lifeless, sent
<lifeless> thanks
<tro> "ERROR: Cannot switch a branch, only a checkout." why is this the case? why can't branches be switched (using bzrtools' "switch")?
<jamesh> tro: a checkout is connected to some branch located elsewhere
<jamesh> "bzr switch" connects the checkout to some other branch
<jamesh> on the other hand, a branch doesn't have such a relationship to switch
<tro> and you can't have both the branch and the checkout be in the same directory?
<jamesh> what do you want to do exactly?
<jamesh> if I know that, I'll be able to give better advice
<tro> i've been playing with git a little bit, and i like that it could manage many branches in the same directory. i could switch between then without "cd"ing into a different directory. this is neat, because then i won't need to setup my IDE environment again for a different branch
<tro> i've been trying to have something similar work with bzr
<jamesh> okay.  So what do you want to happen to the existing work in your branch?
<tro> well, if i had any local changes, i'd "stash" them or something. but i don't care much about that. i would commit my changes before switching to a different branch
<jamesh> commit them to where?
<jamesh> if you have a standalone branch and run "bzr commit", they'll be committed to that location
<jamesh> if you overwrite the branch with another, then you won't have those changes
<tro> i'd like to be able to create a new branch from the current branch, switch to the new one, work a bit there committing my changes, then maybe switch back to the original, work a bit there, and so forth
<tro> at some point maybe merge them. i know you can do all of this, but i'd like ot be able to get all this done without changing directories
<jamesh> so, you'll need to have some place to store the branches, and another for the working tree
<tro> right. that's pretty much what i figured. ok, thanks.
<jamesh> you can store the branches without working tree files, so it won't use more disk space
<jamesh> and the bzrtools "bzr cbranch" command can help with the "create a new branch from this one and switch to it" workflow
<tro> o neat. i'll try it out. thanks.
<jamesh> as your branches are local, you'll get best performance by creating your working tree with "bzr checkout --lightweight"
<jamesh> a non-lightweight checkout caches more information, which is good if the branch is on the other end of a slow network link, but is just overhead for local branches
<tro> makes sense :)
<jamesh> tro: it'd make sense to create a no-trees repository to store your branches in (bzr init-repo --no-trees)
<jamesh> and then create your branches under that directroy
<tro> if i ever need to move the entire repository to a different machine, will i be able to just move the repo files there?
<jamesh> yep
<tro> nice
<beuno> mwhudson_, so, I seem to have gotten navigation with revnos working
<beuno> URLs look nicer  :)
<mwhudson_> great
<beuno> still need to make it work everywhere, but it works for changelog well enough
<beuno> anything else you'd rather I invest my time in?
<mwhudson_> the whole area of url generation is a mess
<mwhudson_> so cleaning that up just anyway sounds like a good idea
<beuno> that would be even better than working around the current way  :)
<beuno> from what I can see, it doesn't really make any sense to have automatic URL generator, but, instead, on function that generates it based on what values you want to pass on
<beuno> would that seem ok?
<mwhudson_> well, that's sort of what there is now
<mwhudson_> but there's all this crazy **util.get_context(**kwargs) nonsense
<beuno> yeah, that's what I was referring to
<mwhudson_> also, please do this in a separate branch :)
<beuno> alright, let's give it a try
<toyto1> guys have you tried commiting a file(s) or directory(ies) but the internet is suddently gone?
<toyto1> I am having a testing then internet is disconnected but it's now locked and can't commit.
<beuno> toyto1, you can use --local to commit locally until you get access to your branch again
<toyto1> beuno: i mean when I commit to the server, the branch is transferring it to the main branch (which is the server)
<toyto1> beauno: while transferring, the internet was gone and I stopped it
<beuno> ah, you may have to break the lock and commit again
<toyto1> beuno: then I try to commit it again but it says Will continue to try until HH:MM:SS and i waited but after I wait, it shows an error
<toyto1> beuno: how to do that?
<beuno> toyto1, bzr break-lock LOCATION
<toyto1> beuno: trying...
<toyto1> beuno: thanks a lot brother! It works great ;)
<beuno> toyto1, I'm glad
<Peng> It would be neat if nosmart+http used If-Modified-Since/If-None-Match.
<lifeless> how so
<Peng> I dunno.
<Peng> Well, how would it be neat, or how would it be done?
<lifeless> both really; consider that bzr tries not to download the same thing twice anyway
<vila> Peng: are you referring to bug #120697 ?
<ubottu> Launchpad bug 120697 in bzr "bzr shouldn't bypass http caches" [Unknown,Fix released] https://launchpad.net/bugs/120697
<Peng> vila: I guess so, indirectly.
<Peng> I'm just looking at my web server logs, and noticing that when Launchpad using several hundred KB of bandwidth pulling a branch daily when it hasn't changed in months, being able to return 304 Not Modified would save a lot of bandwidth.
<Peng> Not that it matters.
<lifeless> well, it should hit about 10 files:
<lifeless> format, format, last-revision
<lifeless> sorry, format, format, format, last-revision
<lifeless> 4
<lifeless> and possibly a check that the tip is there
<Peng> Launchpad uses bzr 1.3. It also reads a bunch of one .rix.
<Peng> Err, all of the .rixes.
<Peng> By "a bunch of", I mean "the whole thing, using a Range request", of course.
<lifeless> that will be the check for the existence of the tip revision (to detect corruption). Or possibly a bug.
<Peng> lifeless: IIRC, whatever it was, more recent versions don't do it.
<beuno> mwhudson, pushed to where I got to: lp:~beuno/loggerhead/zpt.cleaner_urls
<beuno> stopped using get_context, switched from revids to revnos almost everywhere and cleaned up here and there
<beuno> found a few bugs while I was at it
<beuno> and that's it for me today
<mwhudson> beuno: sweet
<lifeless> needs to be faster
<lifeless>  time bzr search workaround
<lifeless> Revision id 'jelmer@samba.org-20080511215646-kxxs86xvurf96nuq'.
<lifeless> real    0m0.658s
<lifeless> user    0m0.476s
<lifeless> sys     0m0.104s
<lifeless> (still doing full index loading)
<lifeless> real    0m3.863s
<lifeless> user    0m3.036s
<lifeless> sys     0m0.124s
<lifeless> to do the same search on bzr.dev
<lifeless> beuno: new index format, closer to stage-2
<lifeless> beuno: and I've merged your patch
<lifeless> beuno: you should give this a spin :P - it can index bzr.dev now
<lifeless> (which takes it 15 seconds)
<mwhudson_> heh heh heh
<mwhudson_> that's 'slightly better' than loggerhead's index
<lifeless> it doesn't index file texts yet
<mwhudson_> what does it index?
<lifeless> commit messages
<lifeless> but very extensible
<lifeless> I needed enough going on that I could write the infrastructure and engine
<visik7> how can I use lp: over http is it possible (for checkout)?
<mwhudson_> commit messages is all loggerhead indexes :-p
<lifeless> so I haven't spent time working on getting term lists for texts, inventories, or author etc in commits
<lifeless> mwhudson_: grab, play :)
<mwhudson_> lifeless: i'll see if i can trick beuno into doing that first :)
<lifeless> he already has
<lifeless> and sent me a patch even
<mwhudson_> cool
<Peng> visik7: If you haven't run bzr launchpad-login, it will use http.
<Peng> visik7: Why do you want to use http?
<lifeless> mwhudson_: so next objection :P
<thumper> visik7: just go bzr branch lp:whatever and it should use http if you haven't done a "bzr launchpad-login"
<mwhudson_> lifeless: it's 1948
<lifeless> mwhudson_: ah yeah fair enough
<visik7> Peng: 'couse I'm firewalled
<lifeless> this is me time, for me
<lifeless> something lightweight and entertaining to tweak while I play WoW :P
<visik7> Peng: and the only protocol allowed here is http on port 80
<mwhudson_> yeah, i realize
<mwhudson_> something to do with some old english person's birthday
<lifeless> or so they claim
<Peng> visik7: Oh. That sucks. No ssh?
<visik7> Peng: ssh yes but I just want to checkout some branch
<Peng> visik7: bzr+ssh uses ssh, so your firewall is not a problem.
<lifeless> visik7: you can checkout over ssh, but you can also checkout over http; you just can't commit back to the branch over http (with launchpad)
<visik7> with anything afaik 'couse http has not write methods
<visik7> isn't it ?
<Peng> What?
<Peng> http does not allow writes.
<lifeless> james_w: you might find bazaar.launchpad.net/~lifeless/+junk/bzr-search fun
<james_w> hi lifeless
<lifeless> -> dinner
<Peng> I should probably RTFM, but how do you check the current revision of a checkout?
<Peng> When upstream has new revisions?
<thumper> does bzr support non-ascii filenames?
<Peng> thumper: Sure.
<Peng> I think.
<Peng> Wasn't there a recent mailing list post about something being passed around as str instead of unicode?
<thumper> I don't follow the mailing list closely
<uws> Peng: bzr revno
<uws> Peng: 'bzr missing' is also useful
<james_w> thumper: yes, but not all filenames can be versioned. There are some banned characters for a start.
<jamesh> '\n' for instance
<mwhudson> also \
<Peng> \ is banned?
<thumper> james_w: what about u'\xf8'?
<mwhudson> as periodically found out by ~vcs-imports
<thumper> Peng: I think because of windows
<james_w> thumper: not sure, sorry.
<Peng> thumper: Yeah,
<jamesh> thumper: it seems to
<Peng> thumper: Yeah, Windows bans \, but does bzr?
<Peng> uws: This is a checkout. Those just use the master branch, which does not help.
<jamesh> thumper: you sure you aren't talking about the byte '\xf8' on its own?
<jamesh> as opposed to the UTF-8 sequence '\xc3\xb8'
<thumper> jamesh: Not sure
<thumper> GroÃ¸vy
<thumper> the non ascii value above
<uws> Peng: Hmmm. dunno then. "bzr unbind; bzr revno; bzr bind" perhaps? :)
<jamesh> thumper: okay.  Because '\xf8' as a byte value is not a whole character
<thumper> jamesh: but is u'\xf8' valid?
<jamesh> thumper: it is
<thumper> jamesh: urllib.quote is choking on it
<jamesh> I just tried committing a file with that name to a dummy branch with no problem
<jamesh> thumper: if the function you are using expects a URL, you probably need to UTF-8 encode it then url encode that
<jamesh> >>> urllib.quote(u'\xf8'.encode('UTF-8'))
<jamesh> '8'
<jamesh> bah
<thumper> jamesh: :( it is in the guts of the svn bindings we are using for importing to bzr
<uws> >>> urllib.quote(u'\xf8'.encode('utf-8'))
<uws> '%C3%B8'
<Peng> uws: Did I mention it's a lightweight checkout?
<uws> Peng: Sorry, can't help you ;)
<uws> jamesh: What you did works here
<jamesh> thumper: well, if the function expects a (relative) URL, then it probably doesn't expect a unicode string
<jamesh> since URLs are ascii
<thumper> jamesh: yeah, however I'm not entirely sure what the original intent was
<Peng> Shouldn't bzr have special url-handling routines?
<jamesh> that's a point.  One of the bzrlib.urlutils functions might be what you need
<thumper> hmm, normalize_url looks promising
<lifeless> Peng: update?
<Peng> lifeless: What?
<lifeless> nevermind, brain fart
<Peng> ok
<scorpioxy> hey guys, first off, excellent work on bzr-fast-import...much appreciated. My question is that i used it to transform a git-svn repo that i was using, so how can i go on using it to update it from the main svn repo?
<awilkins> scorpioxy: I'm not sure that is a supported use-case... it would have to have the same revision-id values as bzr-svn and I'm not sure that is the case
<awilkins> scorpioxy: AFAIK the various SVN interop units do not share a common SVN-BZR mapping, and putting git in the middle probably doesn't help either.
<lifeless> scorpioxy: I would say you need to keep doing git-svn, the bzr-fast-import, if that has an incremental mode
<lifeless> scorpioxy: or, if you had no significant local edits, use bzr-svn from scratch
<scorpioxy_> Sorry about the report(disconnected and don't know if anybody answered). So my question was, i used bzr-fast-import to convert a git-svn repo. How can i go on using this new repo by using bzr-svn? Is changing the repo format all that's needed?
<Jc2k> lo scorpioxy_
<Jc2k> a few people answered
<scorpioxy_> Jc2k: oh sorry, can i see those on the irc log?
<Jc2k> i'll summarise
<Peng> scorpioxy: IRC log: http://paste.pocoo.org/show/65615/
<Jc2k> ahh
<Jc2k> i wont ;D
<scorpioxy_> Peng: aha thanks
<Peng> Or, http://paste.pocoo.org/show/65616/ has nicer syntax highlighting.
<Peng> But it's the same thing.
<Peng> Anyway.
<scorpioxy_> they're both have a messed up layout due to long msgs, but yeah, i read it
<scorpioxy_> ok well thanks all, i guess i'll just have to use bzr-svn directly although its a big repo
<Peng> scorpioxy_: Oh, you're right. I didn't notice that.
<Jc2k> scorpioxy_: i have converted a 2gb repository with bzr-svn
<Jc2k> scorpioxy_: 23,000 revision
<Jc2k> scorpioxy_: and i am aware of bigger ones
<Jc2k> scorpioxy_: what distro are you using?
<scorpioxy_> Jc2k: oh yeah, the problem is my internet connection, not bzr-svn...i've been using that for quite a while now...and it works very well
<scorpioxy_> Jc2k: ubuntu hardy
<Peng> If you have leaky svn bindings (which I think Hardy does), you should incrementally convert about 1,000 revisions at a time.
<Jc2k> hmm
<Jc2k> hardy has OK bindings
<Peng> It does?
<Jc2k> the fix i backported from hardy to etch meant i was able to convert the whole of GNOME SVN without it dieing
<Jc2k> BUT some reallllly big repos can still leak
<Jc2k> hardy is about as good as you can get without running subversion 1.5, or using jelmers bindings
<scorpioxy_> In my case, the repo just has about 1500 revs but some big change sets...the original svn repo was badly setup and badly used so i have to live with that.
<lifeless> james_w: did you give bzr-search a spin ?
<james_w> lifeless: I've branched it, still doing email etc. currently.
<lifeless> do a pull
<lifeless> just landed proper partial read support
<lifeless> 1/2 sec to query bzr.dev for a single term
<lifeless> (though it doesn't handle bzr.dev fully correctly, because the document lists are too long)
<james_w> what indexing package did you go for in the end?
<lifeless> but, you can search for some terms - like workaround :)
<lifeless> 'bzrlib'
<lifeless> this is just a spike, for fun, in my weekend :)
<james_w> works well.
<lifeless> cool
<fredreichbier> hi ;)
<fredreichbier> is there a way to enable a hook only for a specific branch? put it somewhere in ./.bzr or something else?
<lifeless> fredreichbier: depends on the hook - most have some config options
<fredreichbier> lifeless: are there docs to that config options?
<lifeless> depends on the plugin :)
<fredreichbier> hehe
<fredreichbier> ah sorry i misunderstood you
<fredreichbier> i thought you meant the hook classes. what about a hook i wrote myself? ;)
<lifeless> oh, hooks fire for every branch, but you can easily look for some option to enable/disable
<lifeless> for an example, the email plugin looks for an email address to send the email to
<fredreichbier> ok, i will read the code. thanks you :)
<lifeless> k, moved the branch to lp:~lifeless/bzr-search/trunk
<cjwatson> Hi, I'm trying to get bzr-git to work, and having no luck at all. Can anyone help out?
<cjwatson> 'bzr get git://git.debian.org/git/tasksel/tasksel.git' says 'bzr: ERROR: Unsupported protocol for url "git://git.debian.org/git/tasksel/tasksel.git"'
<cjwatson> 'bzr get http://git.debian.org/git/tasksel/tasksel.git' says 'bzr: ERROR: Not a branch: "http://git.debian.org/git/tasksel/tasksel.git/".'
<lifeless> cjwatson: you will need to write quite some code to make that work
<james_w> hi cjwatson
<cjwatson> lifeless: what is bzr-git good for?
<lifeless> ddaa did a branch that can clone locally I believe
<lifeless> its still in development
<lifeless> call it pre-alpha, not feature compelte
<cjwatson> ah, I see; I mistakenly assumed that "enough support for bzrk to operate" would be enough to clone
<lifeless> hell no
<cjwatson> perhaps some indication could be added to its Launchpad project page so that more people don't get misled?
<lifeless> indeed
<mpt> I have a branch where "bzr diff" works, but "bzr log" returns an error
<mpt> http://bzr.pastebin.com/m68ff744a
<james_w> mpt: that's a bug with ghost handling
<james_w> I think there is a patch for it, it may even be in bzr.dev, is that what you are using?
<mpt> james_w, I'm using bzr.dev as of about last Thursday
<james_w> maybe it's not made it yet then.
<mpt> james_w, do you mean bug 235055?
<ubottu> Launchpad bug 235055 in bzr "bzr log fails with KeyError if there is a ghost in the mainline history" [Undecided,Confirmed] https://launchpad.net/bugs/235055
<james_w> yup, I think that's it
<james_w> ah, so no patch yet.
<mpt> james_w, so is it safe to continue working with the branch in the meantime?
<james_w> yep, it's a bug specifically in the log code I believe
<mpt> ok, thanks
<lamont> is there a bzrtools to go with the bzr 1.6 beta?
<uws> lamont: yes.
<uws> lamont: http://launchpad.net/bzrtools/stable/1.6.0/+download/bzrtools-1.6.0.tar.gz
<uws> lamont: linked from http://bazaar-vcs.org/BzrTools
<lamont> any chance of that landing in the bzr beta ppa?
<mpt> james_w, but now the branch won't push
<lamont> uws: so bzrtools is non-beta 1.6?
<lamont> interesting
<uws> lamont: Well, I think the API is finalized, so bzrtools knows what to expect ;)
<lamont> true enough
<lifeless> this will be interesting when versionedfiles lands
<lifeless> and deletes about 3000 lines of api
<lifeless> we'll see
<mpt> How can I get around this error with push? http://bzr.pastebin.com/m6244a2b1
<mathrick> what is the bzr approach to integration with !python languages?
<mathrick> mpt: that is just generic poking around, but is the remote repo consistent?
<mathrick> then, what is the revno of your source repo?
<mathrick> and last, run bzr with BZR_PDB=1, that will break into the debugger on errors
<mpt> mathrick, by "consistent" do you mean it passes bzr check, or what?
<mathrick> yeah
<mathrick> not corrupted
<mpt> I'll try that
<mpt> mathrick, the revno of my local branch is "1", because of bug 235055
<ubottu> Launchpad bug 235055 in bzr "bzr log fails with KeyError if there is a ghost in the mainline history" [Undecided,Confirmed] https://launchpad.net/bugs/235055
<mpt> In reality it's 6416
<mpt> (which seems to be what the traceback is complaining about)
<mathrick> mpt: so it seems, I have no idea if you can do anything about it short of getting the bug fixed
<mpt> ok, thanks for your time anyway :-)
<mathrick> mpt: not much to thank for, I'm mostly a lurker/asker myself :)
<tethridge> anybody know of a clear case plugin for bzr?
<mtaylor> hey lovely folks...
<mtaylor> if I wanted to add some print statements to merge so I could tell what file it's working on... where would be a good place to start?
<ricardokirkner> hi folks. I am having this strange issue here. I configure bzr as a smart server with http authentication (using the bzr-smart.py handler). The strange thing is this. I have two projects set up to use different bzr repositories. When I hit the first project (for a log, status, info, etc.) everything works out ok, but when I try to access the second repository, I get an error 'Not a branch'. If I restart apache and try to access this last repository
<ricardokirkner> everything works out ok, but now the first project's repository throws the 'Not a branch' error. Somehow it seems I can only have one repository working this way. Any ideas?
<enquest> how do I revert one file to an older state... Without that some other files would come along?
<tethridge> enquest, specifiy the name of the file bzr rever /path/to/the/file
<tethridge> that should be "bzr revert"
<enquest> something like : bzr revert -r 32 foo/bar.html
<tethridge> yes
<tethridge> enquest, I'm reading through this now.  Thought I would share.  http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<enquest> ok thanxs... And if I want to go back to 33
<tethridge> I'm a new user too
<mathrick> enquest: revert -r 33
<tethridge> it's an easy read
<mathrick> enquest: revert only operates on the working tree, it never touches the repo
<enquest> The docs are a big beef...
<tethridge> can somebody tell me what the main benefit to "init-repo" is?
<tethridge> the user guide doesn't really go into a lot of detail
<tethridge> what is it doing, saving space?
<mathrick> (therefore you should be careful not to confuse uncommit and revert, and there's a catch that after a revert bzr revno will not necessarily reflect the working tree's state)
<Kinnison> repositories help when you have lots of related branches
<tethridge> help how?
<Kinnison> they can be used to save space by sharing the revisions between the branches
<mathrick> tethridge: repo is a collection of branches
<mathrick> they are able to share data
<Kinnison> E.g. I have a repo for my project 'libgfshare'
<Kinnison> which has branches 'devel' 'release-1.0' 'add-fs' etc
<mathrick> the two benefits of repos as less space used and (much) faster branching
<mathrick> both of which come from the fact revisions are shared
<tethridge> ok, thanks
<enquest> thxs that worked
<mathrick> eg. bzr branch bzr.dev/ bzr.copy/ takes about 1m on standalone trees, and about 2s on a repo branch
<tethridge> so if I already have a my-projects-branches directory with branches below
<enquest> thxs that worked
<mathrick> because there's 90m of data to shuffle around
<tethridge> can I init-repo the my-projects-branches after the fact and have it work?
<mathrick> tethridge: not directly, you need to bzr reconfigure --use-repo the branches
<mathrick> after init-repo
<tethridge> ok
<mathrick> err, --use-shared
<enquest> are there places where you can use bzr without having to install it your self. Auto backup and correct security and private?
<fredreichbier> enquest: ehm... you can use any shared hoster with ftp access for bazaar hosting, if i understood you correctly
<enquest> yeah but I don't want to setup anything... Just some commercial service?
<doctormo> hey all
<mathrick> enquest: all bzr needs is ftp or similar write access to use a remote location as a repo
<tethridge> mathrick, can you give me the full command for --use-shared?
<doctormo> trying to push something to launchpad as an inital push, looks like I've gotten a broken .bzr it says: you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again.
<mathrick> tethridge: bzr help reconfigure
<tethridge> thanks
<kiko> kiko@gasolinux:~/devel/fix-rdf-icon-queries$ get-lp-branch bzr+ssh://devpad.canonical.com/code/tom.berger/launchpad/actionmenuless-bug-page-hold-off
<kiko> bzr: ERROR: exceptions.AssertionError: unexpected response code ('error', "'launchpad@pqm.canonical.com-20080417230844-njz750l4kkk38m3c'")
<kiko> mmmm!
<kiko> wow, bzr 1.3.1
<kiko> let me upgrade.
<mathrick> humm, shouldn't 1.3 understand the new smart protocol already?
<tethridge> mathrick, is that a new argument?  It doesn't show up when I do a bzr help reconfigure
<mathrick> it sounds like something that would result from the confusion of old bzr caused by the new protocol
<tethridge> I'm using gutsy
<kiko> it does, but I think it does
<mathrick> tethridge: bzr --version?
<kiko> I think it dies in some corner cases
<tethridge> 1.3.1rc1
<fullermd> Doesn't seem likely.  You wouldn't get new version responses unless you made a new version request.
<mathrick> tethridge: then it should have that, paste the result you get into http://pastebin.com
<tethridge> mathrick, http://pastebin.com/d54445ad1
<mathrick> hmm
<mathrick> tethridge: oh, right, it's new in 1.4
<mathrick> I think you can work around that, tho
<mathrick> tethridge: move your existing branches somewhere, and try that: bzr branch /temp/branch /path/to/repo/
<mathrick> bah
<mathrick> bzr branch /temp/branch /path/to/repo/branch1
<tethridge> mathrick, how can I tell if the branch under the repo is using the repo?
<mathrick> bzr info
<mathrick> it will tell you if it's standalone or not
<doctormo> did my question apear? or did I get ignored?
<tethridge> mathrick, that works
<tethridge> can I delete the old branches once I create the new branches under the repo?
<spiv> kiko: Try "bzr -Dhpss ...", and check the ~/.bzr.log on both sides.
<Jc2k> doctormo: i dare say "accidentally not seen" rather than ignored ;)
<spiv> kiko: (but do try upgrading the client to 1.5 first)
<kiko> spiv, yeah, upgrading first
<tethridge> mathrick, did you see my question about deleting the original branches?
<doctormo> Jc2k: would you like me to retype?
<Jc2k> doctormo: i can see your q, not that i know enough about bzr to help you
<doctormo> Ah I see.. damn it, should I remove the code from launchpad and try again?
<kiko> kiko@gasolinux:~/devel$ get-lp-branch bzr+ssh://devpad.canonical.com/code/tom.berger/launchpad/actionmenuless-bug-page-hold-off
<kiko> bzr: ERROR: Generic bzr smart protocol error: unexpected response code (('error', "'launchpad@pqm.canonical.com-20080417230844-njz750l4kkk38m3c'"), <bzrlib.smart.protocol.SmartClientRequestProtocolTwo object at 0x89a656c>)
<kiko> spiv, interesting, eh?
<kiko> spiv, this is local to devpad
<kiko> spiv, can you reproduce it?
<doctormo> Jc2k: nope, recreating didn't work :-(
<kiko> I'm just doing bzr branch
<spiv> kiko: the ~/.bzr.log once you use -Dhpss would be much more interesting
<Jc2k> doctormo: where are you pushing to?
<kiko> spiv, can you try and reproduce? less chinese whispers that way
<Jc2k> doctormo: and what version of bzr?
<spiv> kiko: I'm about to sleep
<doctormo> Jc2k: launchpad
<doctormo> Bazaar (bzr) 1.3.1
<kiko> spiv, so you can leave it running overnight
<spiv> (It's past my bedtime on a public holiday)
<Jc2k> doctormo: ys, but are you pushing to lp:somefoo/blah or sftp://some.launchpad.url.i.cant.remember ?
<doctormo> I use bzr push https://code.launchpad.net/~ubuntu-us-ma/us-ma-loco-site/trunk, because lp doesn't work
<spiv> kiko: you probably have a traceback in your ~/.bzr.log on the server side that would be helpful
 * spiv -> zzz
<kiko> spiv, um, yeah, and you can see it too -- and I won't be the one fixing that bug so..
<Jc2k> doctormo: apparently you can also push to bzr+ssh://john.doe@bazaar.launchpad.net/~john.doe/+junk/myproject
<Jc2k> doctormo: but i've only ever used the form bzr push sftp://uberperson@bazaar.launchpad.net/~uber-dev-team/ubuntu/development myself
<doctormo> Jc2k: ah I think that is what I used for other projects
<doctormo> thanks Jc2k
<Pieter> haha
<Pieter>   File "/opt/local/lib/python2.5/site-packages/bzrlib/index.py", line 834, in _parse_segment
<Pieter>     raise AssertionError('no \n was present')
<Pieter> AssertionError: no
<Pieter>  was present
<Jc2k> lol
<tethridge> is there a skeleton plugin somewhere?
<fredreichbier> hi. i have developed a plugin named nicehtml, as a "more flexible htmllog". it generates a html information page for a branch, example page: http://bzr.reichbier.de/pywmctrl-main/ - and I'd like to know what you think about ;) code available here: http://bzr.reichbier.de/nicehtml/ :)
<Dauerbaustelle> now, actually, we have developed :P
<fredreichbier> ah, sorry, dependencies are python-jinja and python-pygments :x
<akojima> is there a way to ignore line end styles (\r\n vs \n) when merging/diffing?
<Odd_Bloke> fredreichbier: I recommend sending an email to the list letting people know about it (if you haven't already done that; I'm a few days behind on list traffic).
<victorng> hi all
<fredreichbier> Odd_Bloke: thanks, I'll do ;)
<victorng> has anyone had luck gettin bzr-svn working in osx 10.5?  the instructions @  http://bazaar-vcs.org/BzrForeignBranches/Subversion don't seem to work for me
<victorng> i get the following error messages: bzr branch https://svn.collab.net/repos/svn/trunk test
<victorng> bzr: ERROR: Not a branch: "https://svn.collab.net/repos/svn/trunk/".
<Jc2k> victorng: what about if you try bzr branch svn+https://svn.collab.net/repos/svn/trunk ?
<victorng> jc2k: uh... weird... i'm just trying with the svn binary i built as per the instructions on the bazaar-vcs page and the svn client doesn't seem to speak http
<victorng> plain "svn co" doesn't seem to work with that custom svn binary
<Jc2k> http or https?
<victorng> both
<victorng> :(
<victorng> weird
<victorng> i had to add a --without-gssapi --disable-gssapi when compiling svn
<Jc2k> that might explain what is wrong with https, but i wouldnt have expected http to break
<victorng> i kept getting errors in neon yelling about GSS_C_NT_HOSTBASED_SERVICE
<victorng> so i tried to explicitly disable the GSS stuff
<victorng> hmm
<mpt> jam, good morning, do you have time to help me with a broken branch or two?
<jam> mpt: morning mpt
<jam> I think so
<mpt> jam, so I have a branch that suffers from 235055. I can't bzr log, but I can still bzr st, diff, and commit
<jam> bug #235055
<ubottu> Launchpad bug 235055 in bzr "bzr log fails with KeyError if there is a ghost in the mainline history" [Undecided,Confirmed] https://launchpad.net/bugs/235055
<mpt> jam, but when I try to push: http://bzr.pastebin.com/m6244a2b1
<jam> mpt: that certainly sounds like the ghost problem
<jam> the "revno' in the second case is so short because there is a ghost
<mpt> jam, yes, bzr revno returns "1" when it should be 6416
<mpt> I don't mind not being able to log, but I really do need to be able to push :-)
<jam> mpt: I have a script around that copies revisions from other repos to fill in ghosts like this
<jam> I attached it to a bug, but it wasn't *that* bug :(
<jam> mpt: I'll paste bin it
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<jam> mpt: http://paste.ubuntu.com/18789/
<jam> Basically, you'll run it as "python copy_all_revisions.py remote_repo local_repo"
<jam> It will probably copy more than you need, but if we can get it all done right away, so much the better
<mpt> jam, should I uncommit to get a sensible revno in the branch before I run the script? or doesn't it matter?
<jam> mpt: I don't think it will batter
<jam> matter
<jam> as long as the pointers are still there, which they should be
<beuno> lifeless, plugin is looking very good. Maybe I should try and trick mwhudson into making me work on this as part of Loggerhead...  ;)
<mpt> jam, thanks, trying it now
<jam> mpt: we *might* need to go cheat and fix the revno, but we'll cross that when we get there
<mpt> Target is missing 417 revisions
<jam> mpt: some of those will be other heads, and some will be ghosts you want to fill. but it shouldn't take long with only 400 missing
<mpt> It's halfway there
<jam> mpt: and the first half is the "slow" half
<jam> I sort topologically, and start fetching from the one that is likely to fetch the most ancestors
<mpt> ok
<mpt> Just out of interest, what's a "head"?
<jamesh> mpt: each revision has a pointer to its parent(s)
<jamesh> mpt: a head has no other revision pointing to it as a parent
<mpt> ok
<mpt> so as soon as I make a commit in a branch, that's a head
<jamesh> and it'll stay a head until you commit a subsequent revision
<mpt> but as soon as I make another commit, that previous one stops being a head
<jamesh> if you "bzr uncommit", the head stays in the repository though
<jam> mpt: mostly it is likely to be stuff from other branches, or someone doing 'bzr uncommit", etc.
<mpt> ok, finished
<mpt> jam, "bzr log" no longer returns an error, but it returns only one revision, my most recent one, r6416
<jam> mpt: right, probably because of the 'revno = 1' stuff
<mpt> yeah
<jam> you *know* it is 6416, right?
<jam> edit .bzr/branch/last-revision
<jam> and fudge that number in
<jam> if it doesn't say '1' then stop
<mpt> My copy of the same branch in the remote repo doesn't have that revision, but it has 6415, 6414, 6413, etc
<jam> mpt: sounds close enough :)
<jam> mpt: we can always work out it if it is wrong again, but I'd like to get it right the first time
<mpt> jam, .bzr/branch/last-revision doesn't exist
<jam> mpt: is there a .bzr/branch/revision_history then?
<mpt> should I create it?
<jam> you might have an older branch format
<mpt> yes, there's revision_history
<jam> :(
<jam> oh wait, you should be able to "bzr reconcile" the branch
<jam> I added that in a recent release
<mpt> wait
<mpt> sorry
<mpt> I was still looking at the copy in the remote repo
<mpt> ... oh, the local copy doesn't have .bzr/branch/revision_history either
<mpt> ok, I'll try reconcile
<mpt> "Fixing last revision info 1 => 6416" - yay
<jam> sometimes things work out well :)
<korpios> Having a hard time finding an answer to this via the Bazaar website or Google: how would I cleanly delete a branch within a shared repository?  If I simply rm -rf'd the dir, wouldn't that leave old, now-unused data in the shared repo?
<akojima> is there a way to revert a merge?
<LarstiQ> korpios: yes, but that doesn't need to be a problem. Is it for you?
<korpios> LarstiQ: Well, if I make lots-and-lots of feature branches and kill them once I'm done with them ...
<jam> korpios: well if they are merged into the other branch, then you need the info anyway
<jam> and otherwise when you copy stuff out of this repo, if they aren't referenced, they won't be transmitted
<korpios> jam: True, but I'm thinking more failed ideas, screwups, and the like
<jam> korpios: sure, but they rarely take up much space
<jam> versus the size of everything else
<jam> and it doesn't propagate
<jam> I believe Jelmer has a plugin which will garbage collect your repo, but you have to be careful that there aren't any branches you forgot about
<korpios> Somewhat related question that this brings to mind: would a new shared repo created by branching from a few branches of an old shared repo lose the benefits of a shared repo?
<korpios> (at least for those branches, not new ones going forward)
<jam> korpios: the branches in the new shared repo will still share between eachother
<jam> but it will copy the data from the old to the new repo
<korpios> right, that part is fine
<korpios> but if I have shared repos A and B, I could branch A/* to B, and the new B/* would still be sharing data amongst each of the B's?
<korpios> (I'm thinking "poor man's garbage collection")  :p
<jam> korpios: branching from A/* => B/* will share stuff in B/*
<jam> korpios: and that is exactly what Jelmer's plugin does for you
<korpios> Ah ^_^
<LarstiQ> korpios: yes, that is indeed the poor man's garbage collection approach
<jam> it just replaces the repo in place at th eend
<jam> korpios: the one thing it loses is parent pointers (where the branch was branched *from*) which is one of the benefits or the plugin
<jam> since it doesn't actually create new branches
<korpios> Nice ... I was worried that the B/* wouldn't share since they weren't created "together", but I'm guessing this has to do with the shared repo just seeing "hey, these two have the same object, let's share" regardless of source?
<jam> korpios: correct
 * korpios feels better :)
<korpios> thanks!
<rammel> Hi all. A team member is trying to commit to his branch over bzr+ssh on windows using bzr 1.5. After some seconds the console screen stalls and nothing happens any more. If the guy breaks with ctrl-c and trys to break the lock, bzr stalls again. If he ssh's to the server and enters bzr break-lock, it works. But the next try to commit fails again. What could it be?  Thank you!
<victorng> hey - when i try to use bzr-svn and branch a svn repository over HTTPS - i get this: Assertion failed: (g->gc.gc_refs != _PyGC_REFS_UNTRACKED), function instancemethod_dealloc, file Objects/classobject.c, line 2285
<victorng> when i branch a svn repo over plain HTTP, it seems to hang forever
<mpt> mathrick, the "bzr check" you suggested just finished with a KnitCorrupt error :-)
<korpios> Hmm ... I have a branch in my shared-repo that's just for mirroring a launchpad repo.  That works, pulls fine, etc.  I created a second empty branch as my "local dev mainline", and tried to merge in the mirror branch; it seems to merge okay, but on update it gives: "bzr: ERROR: Reserved revision-id {null:}"
<korpios> (I'm using merge so I can avoid seeing the history on bzr log --short)
<korpios> I've tried this with 1.5 and 1.6b1, same result
<mathrick> mpt: heh, that was fast :)
<korpios> I can't find any bugs in bazaar's launchpad tracker that seem directly related
<emilis_info> hi, I have a question: will bzr autodetect moved files or do I have to use `bzr move src dest`?
<gour> hard to believe...svn needs 10 rcs to release :-/
<cr3> what does this mean: bzr: ERROR: Unknown bzrdir format: ''
<korpios> Gah, even with bzr.dev (the "bzr: ERROR: Reserved revision-id {null:}" error)
<cr3> wtf! bzr: ERROR: Revision {email-20080417161838-a2tfnk26kx1q7vjf} not present in "revisions.kndx".
<gour> emilis_info: afaik, bzr does proper tracking for renames
<emilis_info> gour, so, it should detect automaticly if I move a file?
<cr3> googling for that error returns a message from irclog asked by myself, unanswered, and bug #232270, also unanswered :)
<ubottu> Launchpad bug 232270 in bzr "Cannot checkout -- KnitCorrupt: attempt to add line-delta in non-delta knit" [Undecided,New] https://launchpad.net/bugs/232270
<gour> emilis_info: i'd say - yes. but bear in mind i'm quite new with bzr coming from darcs and, iirc, bzr does the same thing. try on some test-case or wait for some bzr dev to get definite answer
<emilis_info> gour, thx
<emilis_info> gour, how is bzr compared to darcs? :)
<gour> emilis_info: i LIKE it. it's not much complicated, or let's say quite easy with nice interface, simple-enough model so you can understand what's going on (unlike that kernel-VCS) and it is quite safe
<emilis_info> :)
<gour> emilis_info: good win32 support (it will be useful for my win32-dev-friends) and nice gui-tools (bzr-gtk) for my gui-friend-lovers (i'm satisfied with cli)
 * emilis_info too
<gour> regular release, active community, friendly #bzr...
<gour> i'm not so much concerned with performance, but this is also improving...
<gour> all in all...bzr is for me, without competition ;)
<cr3> are there bzr commands to fix a bzr repository?
<gour> cr3: bzr reconcile ?
<Pilky> emilis_info: you need to use bzr mv for bzr to pick up you've renamed/moved a file
<Pilky> otherwise it will think you've removed it and added a new file
<beuno> cr3, try: bzr reconcile LOCATION
<emilis_info> Pilky, thanks
<emilis_info> that answered my question
<beuno> jam, btw, happy birthday  :)
<dvheumen> I've been looking at the site and documentation, but I couldn't find the answer to my question exactly, so I'm asking here... When I do a lightweight checkout, what is the bandwidth cost when a commit changes? (since it seemed to me that no original files are stored in the lightweight checkout)
<fbond> Hi, I have a source tree that contains an svn repository.  I need to add the svn repository to my bzr branch.
<fbond> bzr add refuses because I have bzr-svn installed and it refuses to see that directory as a simple directory.
<fbond> I.e., it wants to treat it as a repo.
<fbond> Any way around this (besides uninstall bzr-svn)?
<Stavros> hello
<Stavros> can someone tell me what update does exactly/
<Stavros> does it get the changes from the branch to your working copy?
<beuno> Stavros, yes, it updates the working tree, and, if it's a checkout, it also updates to the latest revisions
<Stavros> hmm, checkout is a subcategory of update you mean?
<Stavros> i don't understand that
<Stavros> if it updates the WC, shouldn't it also update to the latest revision?
<beuno> Stavros, well, if it's not a checkout, than you may not want the latest revision
<Stavros> you mean latest revision in general?
<Stavros> not just in my repository?
<beuno> in the case of a checkout, it updates to the last revision the branch you're bind to has
<Stavros> ah
<Stavros> and what if the branches have diverged?
<beuno> Stavros, well, when you commit to a checkout
<beuno> it doesn't let you unless you're up to date
<beuno> because it commits to the bound branch
<Stavros> well no, i mean if you pull and you have local changes and the other branch has changes as well
<Stavros> what do you do in that case?
<beuno> Stavros, if you pull, you're not using a checkout
<Stavros> well yes, i didn't say i was, you did :P
<beuno> in that case, update just updates the working tree, which would be up to date if it's local
<Stavros> a checkout is just a pull/update, isn't it?
<beuno> a checkout is bound to a branch
<beuno> so it may be a bit more complicated than pull/update, since you commit *to* the bound branch
<beuno> if you're pulling changes locally, than you don't need update
<Stavros> ah
<Stavros> i see, thanks
<beuno> when you push remotely, like, for example, via sftp, the remote branch WT is not updated
<beuno> it has the latest revisions
<beuno> but you have to explicetly run update on it
<Stavros> ah, yes
<Stavros> i'm a bit unclear still on how you resolve collisions
<Stavros> conflicts
<Stavros> you merge manually and then you commit?
<beuno> basically, you edit the file that has the conflicts to how you really want it to look, and remove all herring markers
<beuno> than, bzr resolve FILE
<beuno> commit
<beuno> you're set
<Stavros> ah
<Stavros> i tried that once and it turned all the other commits into one with my name on it
<beuno> well, yes and no
<Stavros> so i wasn't sure if that was the right thing to do
<beuno> they are sub-commits
<Stavros> ah
<beuno> you will see them as merges into your commit
<beuno> with subrevnos like 13.1.1
<Stavros> ah yes
<Stavros> interesting, thanks
<Stavros> that clears it up
<beuno> I'm glad  :)
<Stavros> thanks :)
<beuno> my pleasure
<aantn> hello
<aantn> I'm having some trouble pushing a revision to a new branch I just branched
<aantn> I get the following error
<aantn> http://rafb.net/p/vvGXf170.html
<beuno> aantn, try:  bzr launchpad-login your_username && bzr push --use-existing-dir
<aantn> I tried running bzr launchpad-login aantny, but it didn't help
<beuno> ah, well, it should  :)
<aantn> beuno: it doesn't
<beuno> aantn, that error message is *after* you ran launchpad-login?
<aantn> beuno: that's correct
<beuno> aantn, try:  bzr push lp:~screenlets-extras-team/screenlets/screenlets-extras
<aantn> beuno: thanks, that works
<aantn> the url I was using shouldn't have began with http://
<beuno> aantn, you should do that again, and add a --remember
<beuno> so it doesn't happen again
<beuno> aantn, exactly, http is read-only
<aantn> beuno: I know; thanks
<beuno> aantn, np  :)
<LaserJock> with bzr-svn are svn tags and branches just normal bzr branches?
<Peng> LaserJock: Yes.
<jelmer> fbond: bzr --no-plugins add ...
<beuno> vila, around?   I have a tests question  :)
<beuno> vila, anyway, when you are, I added a --dry-run command to bzr-upload, and I wanted to add tests for the new switch, but I'm not sure duplicating all tests is the right way to go  :)
<jml> abentley, lifeless: what did we end up deciding with the bzrdir.clone changes for stacking?
<abentley> jml: I applied your patch and then made the behavior optional.
<jml> abentley: ok. thanks.
<abentley> jml: And then regaled you with tales of how clone isn't really clone.
<Kinnison> thus jml blocked the episode from his mind.
<jml> long weekend had more to do with it, I think :)
<Kinnison> :-)
#bzr 2008-06-10
<Leonidas> I have branched off some line of development with my own changes, now I'd like to get a complete, clean patch of my changes to the trunk revision. How to do that?
<Leonidas> I tried with merge --preview, but it does not work, since I'm working treeless. And I don't really plean to do a merge anyway.
<Leonidas> s/plean/plan/
<Peng> Leonidas: bzr send?
<Leonidas> Furthermore, I'd like to merge in the latest trunk changes since branching, but they should not appear in my patch.
<Peng> Leonidas: bzr send?
<Leonidas> Peng: thanks. I'll see whether this is what I want.
<james_w> Leonidas: there is also "bzr diff -r ancestor:URL"
<Peng> Leonidas: 'bzr send' produces a bundle file, which by default includes a diff and the (base64-encoded) meta data.
<lifeless> poolie: did you ring?
<Leonidas> Peng: bzr send sounds good, but I'd need to get the patch only, since it's only me who is using bzr. The other people have no use for bundles.
<Leonidas> bzr send --output=- is nice, now compine it with no-bundle
<Leonidas> huh? Am I missing something? bzr send --no-patch --output=- works
<Leonidas> bzr send --no-bundle --output=- does not.
<Leonidas> bzr send --output=- does work and produces both patch & bundle.
<spiv> Leonidas: I'm guessing "bzr send --no-bundle" is failing due to a lack of a public location for your branch.
<spiv> Leonidas: if you just want a diff, you're better off using "bzr diff" directly, as james_w suggested.
<Leonidas> spiv: right, it fails because there is no public location. But I don't see why it does not work like bzr send just without the bundle. I could use sed, though ;)
<spiv> Leonidas: bzr send tries fairly hard to make sure that all the history is available to the recipient, either in the included bundle, or in a publically accessible branch if there is no bundle.
<Leonidas> ah, that explains a lot!
<poolie> lifeless: no
<spiv> i.e. bzr send is designed as a way to send merge directives for branches, not as a way to generate diffs.  Generating diffs is what "bzr diff" is for :)
<Leonidas> spiv: ok, bzr diff -r ancestor:... works properly. Fine.
<Leonidas> Thanks, also to james_w
<Leonidas> I wonder what happens if I merge trunk :)
<Leonidas> ok, works. Fine
<igc> lifeless: I'm planning to tweak stacked branches today
<igc> 1. move branch-location into branch.conf
<igc> 2. rename shallow options and messages to stacked
<igc> 3. ????
<igc> lifeless: is that ok?
<poolie> igc, is the name really just branch-location? it needs a less ambiguous name...
<igc> poolie: no. I was being lazy because I knew that lifeless knew what I meant
<poolie> ok :)
<abentley> jelmer: around?
<jelmer> abentley, hi
<jelmer> igc: 4. profit ? ;-)
<abentley> jelmer: Can I ask some questions about samba?
<jelmer> abentley: sure
<Peng> jelmer: How stable is bzr-svn's 0.4 branch at the moment?
<jelmer> Peng: stable
<Peng> jelmer: So it's okay to use instead of 0.4.10?
<abentley> jelmer: The main question is, is Samba suitable for sharing to linux clients?  I.e. can it preserve users, modes, etc?
<jelmer> Peng, at the moment, yes
<abentley> I've only used it when the primary clients were win32.
<Peng> jelmer: Are you planning to break it before the next release? :P
<jelmer> abentley: Yes, when you're using a recent version of Samba and CIFS VFS (mount -t cifs rather than mount -t smbfs)
<jelmer> Peng: no plans :-) but not guarantees either..
<abentley> jelmer: cool, thanks.
<jelmer> abentley: It's more POSIX compliant than NFS3 and even more compliant than NFS4 in a lot of cases
<Peng> Maybe I'll keep using 0.4.10 as long as it works with bzr.dev. If it still does.
<abentley> jelmer: great.
<Peng> Yeah, it does.
<jelmer> Peng: 0.4.10 is broken with bzr.dev (push for example)
<Peng> Oh.
<Peng> Broken as in traceback or corruption?
<jelmer> traceback
<jelmer> corruption never happens because of mismatching versions
<lifeless> poolie: found the plugin ? :P
<lifeless> abentley: is branch.conf meant to be human edited or bzr edited?
<abentley> lifeless: Yes.
<lifeless> hmm
<abentley> Same as bazaar.conf.
<lifeless> what settings from it are copied on clone/sprout?
<abentley> I can't think of any values that are copied.
<lifeless> ok
<lifeless> igc: go ahead
<abentley> lifeless: It contains values like parent location, push location, bind location.
<igc> lifeless: thanks
<igc> lifeless: summary email on its way now too fwiw
<lifeless> igc: thanks
<lifeless> poolie: call?
<mwhudson> beuno: are you still up?
<ricardokirkner> hi everyone. I just wanted to know. Is olive-gtk currently the best available option for a gui interface to bzr? Or are there any better options? (I would prefer gtk over qt, but it' s entirely a matter of (visual) taste)
<ricardokirkner> what I was looking for is some app that makes viewing change history easy (something like trac, but as a client app, instead of requiring a webserver)
<beuno> mwhudson, yeap
<mwhudson> beuno: cool
<mwhudson> beuno: so my understanding, roughly speaking is that you have done four things to loggerhead recently:
<mwhudson> 1) remove the use of deprecated methods
<mwhudson> 2) switched to using zpts
<mwhudson> 3) some ajax-y stuff for revision views
<mwhudson> 4) use cleaner urls
<mwhudson> beuno: would that be a fair summary?
<beuno> mwhudson, generally, yes. Although 3) required generating a new controller from scratch for diff, and changing how the revision view is generated
<mwhudson> ok
<mwhudson> so what i would _like_ is to have one branch for each of these things :)
<mwhudson> (they don't all have to be brances off trunk, i'd expect the branch for 3) to be a branch off that for 2), for example)
<beuno> ah, good, was about to say that  :)
<beuno> and, well, 4) off 2) also, since it's mostly templating work
<mwhudson> sure
<beuno> ok, I can do that, now, where could I find a good VCS to help me with that...
<mwhudson> heh heh
<mwhudson> beuno: i'd like to review the branches for 1 and 2 today if i can
<beuno> mwhudson, oh, sure. I'll get right on it.   1) would be with KID than?
<beuno> *then
<mwhudson> beuno: yeah, i think so, the changes are entirely independent of the templating stuff
<mwhudson> and this branch is more urgent
<beuno> yes, I see where you're going. I'll push em to LP and ping you
<mwhudson> thanks a lot
<mwhudson> you could even send merge requests to the bazaar list :)
<beuno> sure, whatever is better. Will BB get confused if I send with [MERGE]?
<mwhudson> yeah, i guess [loggerhead/MERGE]
<mwhudson> hmm, is there anyway of running bzr viz in a repository?
<mwhudson> (i.e. with multiple heads)
<mwhudson> beuno: any idea how long this is going to take?  i.e. a few minutes, an hour, tomorrow?
<mwhudson> beuno: don't want to pressure, just want to know
<beuno> mwhudson, I'll send 1) in a few minutes
<mwhudson> cool
<beuno> and 2) by the end of the day
<beuno> as I see it, 3) and 4) stack up on top of 1) and 2)
<fullermd> You can run viz on multiple branches...
<mwhudson> fullermd: you can?
<mwhudson> beuno: isn't it rather late for you already? :)
<mwhudson> beuno: but sounds good
 * mwhudson heads out to buy some chocolate to fuel the review
<beuno> mwhudson, I've seemed to moved to new zeland time zone these past weeks  :)
<mwhudson> beuno: heh
<fullermd> Yah, just hand it a couple on the command line.
<fullermd> (I haven't really used it, but I've done it)
<mwhudson> fullermd: maybe my bzr-gtk is too old, it doesn't work for me
<fullermd> NEWS says it was on 0.94.0
<mwhudson> 0.93.0
<mwhudson> oh well
<lifeless> beuno: glad you like it
<beuno> lifeless, I may even attempt to get it working within loggerhead, when I run into some free time
<beuno> a pre-alpha version of it will be *way* better than what there is today  :)
<lifeless> :P
<lifeless> surely not ?
<beuno> mwhudson, we sould really disable full text indexing by default
<beuno> it makes my core2duo 1.5gb of ram cry for a good hour on bzr.dev
<lifeless> holy crap
<lifeless> are you sure it only indexes the commit messages?
<beuno> I promise  :)
<lifeless> how the hell can you spend more than a few seconds indexing bzr.dev's commit messages.
<lifeless> I reckon you are missing a lock_read() or something similarly inane
<beuno> I'd rather invest time in getting it to work with something new (bzr-search, for example) than fixing the horrid current sqlite thingie
<lifeless> k
<lifeless> (I'm sure the underpinnings are not that different though)
<lifeless> poolie: bzrlib.tests.test_lockdir.TestLockDir.test_35_wait_lock_changing is failing sporadically for me. I mention this because I thought it was fixed?
<mwhudson> lifeless: i think i already explained that loggerhead's text indexer is worse than you can possibly imagine, didn't i?
<mwhudson> i wasn't kidding
 * igc lunch
<beuno> mwhudson, patch for 1) sent off to the list
<lifeless> mwhudson: I thought my imagination had more power
<beuno> mwhudson, I'm off for ~2 hours, and I'll be back to send 2) with 1) merged into it, and other tweaks it needs to work properly
<mwhudson> beuno: ok, have fun
<beuno> lifeless, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/launchpad%40pqm.canonical.com-20080418101647-2k1lv1l0edudd191?file_id=textindex.py-20061219035715-norgqx0pl0hxdax8-1
<beuno> for your amusement  :)
<beuno> mwhudson, oh, and I just remembered, not sure what that list is for, but I also tried genshi as a templating engine, which failed miserably  :)
<mwhudson> beuno: right, i'm not expecting to merge that one :)
<fbond> jelmer: thanks
 * beuno is off
<lifeless> beuno: bye
<lifeless> holy cow
<lifeless> thats scary shit
<lifeless> I mean, might want to tweak the term generator in bzr-search to combine robert's -> roberts rather than robert's -> robert, s
<lifeless> but thats stemming which I punted on
<synic> is there an IRC bot out there that'll watch bzr repos for changes?
<lifeless> I believe so
<mwhudson> so bookmarks and lp: urls don't really get on
<bob2> yay for stacking
<poolie> lifeless: re that test - i have a patch that addresses it but there was some nontrivial review pushback, i need to revisit it
<poolie> uh
<poolie> i tried doing an incremental patch towards it, introducing a different error for "waiting for lock timed out" from "lock is not available at this instant"
<poolie> which i think will make those tests clearer and not timing dependent
<poolie> but the increment was not compelling by itself
<lifeless> poolie: k
<beuno> back
<beuno> mwhudson_, so, 2) then?
<mwhudson_> beuno: yes please :)
<beuno> on it
<jml> hey guys
<jml> when someone deletes a directory in bazaar and the directory has pyc files, I get conflicst
<lifeless> yes
<lifeless> known issue, no good answer so far
<jml> lifeless: ok. cool.
<lifeless> (you need a way to separate 'my-bank-details.txt' which I ignored so it wouldn't be added from 'foo.pyc' wchich I ignored so it would not be added
<bob2> need to somehow consider the former to be...precious ;)
<lifeless> or the latter to be junk
<lifeless> but this has complexity impact
<beuno> mwhudson_, do you want the 2) patch relative to 1) or trunk?
<mwhudson_> relative to 1) please
<mwhudson_> beuno: i
<beuno> coming up
<mwhudson_> 'm not going to be working for much longer today, btw
<mwhudson_> i'll look at it first thing tomorrow
<beuno> oh, but it's only 3k lines...  :p
<mwhudson_> :)
<mwhudson> i know, i'm lame
<beuno> mwhudson, sent
<beuno> I'll prepare the other 2 tomorrow
<poolie> beuno, hi
<beuno> hey there poolie
<poolie> beuno: what a circus :-}
<beuno> poolie, heh, the past weeks have been pretty active  :)
<lifeless> abentley: lol, I have this image of bb running around going 'I'm freaking out mAAAAAAN'
<beuno> hahha, I was just thinking that. With ian's patch in it's hand
<abentley> lifeless: hehe
<fdv> Hi. Anybody know what 'KnitCorrupt: Knit <bzrlib.knit._PackAccess object at 0x870fc6c> corrupt: incorrect number of lines 221 != 152 for version {svn-v3-single1-dHJ1bmsvbWFpbg..:6226825f-cf0a-0410-9073-f4040cba8958:trunk%2Fmain:116353}' means?
<beuno> I'm off to bed. G'night everyone
<igc> night beuno
<lifeless> fdv: my first thought would be a symlink with newlines in it in the source svn repo
<fdv> lifeless: ah
<lifeless> because I *think* bzr-svn generates its own knit hunks or something like that
<fdv> that revision had broken symlinks, but I tried removing those nodes
<lifeless> jelmer: ^ any thoughts
<fdv> what are knit hunks, really?
<spiv> fdv: records containing the lines added in a revision, basically.
<fdv> ok..
<spiv> Usually just the new lines, and a record of the lines removed.  Sometimes a full copy of a file is stored rather than just a delta, depending on various conditions.
<fdv> right
<spiv> Basically, low-level guts :)
<fdv> I removed all the nodes containing these symlink edits from the dump file and repopulated the repo
<fdv> and then tried pulling it again
<abentley> igc: Do you have a clear idea what you need to do to generate a mergeable directive?
<lifeless> fdv: did you clear the output repository?
<lifeless> fdv: or remove the corrupt revisions copied into it?
<fdv> lifeless: absolutely :)
<igc> abentley: use bzr.dev as the submit_branch
<fdv> lifeless: I couldn't remove the whole revisions
<fdv> only the nodes affected
<igc> abentley: I don't get hope to get the right preview diff though ...
<abentley> igc: And you can use -r to specify the cherrypick you want
<igc> so -rancestor:../foo.bar?
<lifeless> igc: bzr send -r thread:..-1
<lifeless> igc: you should never need to touch -rancestor with send and a loom
<igc> lifeless: I've exported the loom
<lifeless> igc: oh, don't
<lifeless> igc: :)
<lifeless> igc: I send all my patches for loom-branches direct from the loom
<igc> lifeless: I didn't know better and smart people told me to :-)
<lifeless> AIUI export-loom exists solely for use with launchpads internal review system which is not loom aware
<lifeless> BB doesn't have the same flaws
<abentley> lifeless: Not true, also for dealing with PQM
<lifeless> abentley: oh, I guess. I do all my merges via an integration branch, so it never occured to me
<lifeless> abentley: (bzr pull $source --overwrite && push --overwrite && pqm-submit -m '...')
<abentley> igc: Anyhow, are you able to get a reasonable preview diff?
<igc> just trying now
<igc> abentley: in the case of StackableBranch, not by using -rancestor:../Development1 :-(
<igc> I guess the preview is the least important bit
<igc> but it annoys people reviewing in the mailer
<abentley> igc: The preview reflects the merge you are requesting.
<abentley> If it's wrong, your request is wrong.
<igc> abentley: the preview contains the right changes vs bzr.dev
<igc> but it's more than I wanted in the preview because it includes the changes from 'threads' below
<lifeless> igc: honestly, do the BB submissions direct from the loom
<lifeless> igc: with 'bzr send -r thread:..-1' from within each thread.
<lifeless> igc: it will JustWork
<lifeless> (I mean, this is the sort of scut work that loom is _meant_ to manage for you)
 * abentley has send -r thread: aliased as tsend
<igc> lifeless: understood. Why the ..-1 ?
<lifeless> exactly
<lifeless> current tip
<abentley> igc: a -r spec generally specifies the tip.
<lifeless> igc: you want from the thread below (thread:) to the last commit (-1). But giving send one revision says 'from bzr.dev to that revision)
<abentley> So -r thread: specifies the tip to be the tip of the previous thread, which is wrong.
<igc> ok
<abentley> You can probably specify "-r thread:.." but I haven't tried that.
<igc> I try sending from the loom now
<abentley> Alternatively, you can specify the revision-ids from your previous submissions.  i.e. "bzr send -r revid:ian.clatworthy@canonical.com-20080610013832-9dt6c5h67eckiezo..revid:ian.clatworthy@canonical.com-20080610045325-hi3yug3nasoe6e1h ../bzr.dev"
<gour> will loom become part of bzr?
<lifeless> gour: do you mean 'will it be part of the tarball' ?
<lifeless> gour: if so, probably, we plan to roll popular plugins into the release tarballs.
<gour> lifeless: yes. otoh, 'loom' is not listed at http://bazaar-vcs.org/BzrPlugins or i'm blind
<fdv> lifeless: wrt. the knit error, could the revision be cached or already (half way) applied somehow, so that I don't get it from the new repo I set up, but still from the old one (which is broken)?
<lifeless> fdv: yes
<fdv> ah
<lifeless> fdv: I would try importing to a fresh ('bzr init --rich-root-packs') tree
<fdv> crap
<fdv> that's three more days :p
<lifeless> well
<fdv> but if that's what it takes.. :)
<lifeless> you have corrupt content in your target repo
<lifeless> removing knit references is not the simplest thing to explain
<fdv> I can't roll it back somehow?
<fdv> that's all right
<fdv> if it's the only feasible solution, I'll start from scratch
<lifeless> we dont have an automated UI for removing single revisions at the moment
<fdv> I think I have a corner case here :)
<lifeless> oh, there is need for it
<lifeless> it needs someone to write a ui for it using the low level primitives
<fdv> I see
<fdv> are there some docs anywhere? :)
<lifeless> if you have a pack repository, pydoc bzrlib.repofmt.pack_repo
<lifeless> (for a pack repo its basically 'copy everything to a new pack except hwat you want to remove, then discard the old packges')
<abentley> igc: I'm off to bed.  If in doubt, run a test against a local bzr.dev that doesn't use the same shared repo.
<igc> ok
<lifeless> for a knit repo its 'remove low level index entries' by doing the same on a per file-id basis
<gour> svn folks released svn-1.5rc10 :-/ good luck to those living with such software
<fdv> lifeless: ok, I'll try to have a look. Don't have too high hopes, thouhg :)
<gour> ...requiring 10rcs
<lifeless> fdv: don't stress about it :P
<fdv> no, but it'd be interesting to have a look
<vila> beuno: test a little, code a little :) I don't think you need to duplicate tests for a --dry-run option. TDD helps in *reducing* code duplication after all.  Some blackbox tests should be enough.
<lifeless> later all, dinner time
<igc> ok, I think I've stopped BB freaking out now. Let's hope so.
<igc> night all
<gour> night
<poolie> cheerio igc
* poolie 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/
<poolie> 1.6b2 is out
<toyto1> hello guys, does bzr can be integrated with trac?
<toyto1> guys is launchpad.net seems to be like trac?
<Peng> toyto1: There's a bzr-trac thingy, but I don't think it's 100%.
<Peng> toyto1: And yeah, Launchpad has some similarities to Trac. No wiki though.
<gour> seeing that trac-0.11 is still no out...hmm
<poolie> night all
<gour> toyto1: have you seen http://www.redmine.org/ ?
<toyto1> Peng: ah i see:)
<toyto1> gour: what's that? let me check
<toyto1> Peng: I didn't find how-to their with bzr-trac for integrating :(
<gour> toyto1: it's what trac-2.0 will maybe become. it's RoR app, but still
<toyto1> gour: so you mean is that redmine is more advance than trac as of now?
<gour> toyto1: yep, more support for SCM, multi-project etc. however, we choose roundup (http://roundup.sourceforge.net/) - no need for wiki
<toyto1> gour: I see thanks for the info :)
<gour> ;)
<mtaylor> help!
<mtaylor> bzr: ERROR: Revision {foo@bar-20080606164431-373v96de5ba508yi} not present in "revisions.kndx".
<weigon_> ... at a bzr branch ...
<james_w> mtaylor: https://bugs.edge.launchpad.net/bzr/+bug/232270
<ubottu> Launchpad bug 232270 in bzr "Cannot checkout -- KnitCorrupt: attempt to add line-delta in non-delta knit" [Undecided,New]
<mtaylor> james_w: ah
<james_w> are you using a smart protocol for whatever operation you are doing?
<mtaylor> for that one.
<mtaylor> it's possible someone used sftp or something though
<weigon_> james_w: it is all bzr+ssh://
<weigon_> james_w: I have a 2nd tree that is a bit more up-to-date that has that rev-id and I can pull nicely into that tree
<weigon_> only if I use a tree that is "before" that rev-id the branch/pull/log/... all fail
<james_w> if you use sftp:// it should work.
<weigon_> james_w: it does
<weigon_> and interestingly a $ bzr log --show-ids sftp:// shows me the {foo@bar-20080606164431-373v96de5ba508yi}
<james_w> hang on, are you two working together on this?
<weigon_> james_w: yep :)
<james_w> ah :-)
<james_w> ok, it's some problem with the smart server, I've updated the bug report about it, you can subscribe if you wish to follow the progress.
<james_w> a full traceback of the error would be very useful, you can find one in your ~/.bzr.log.
<james_w> you can edit out the details, but the traceback would be really helpful.
<mtaylor> so, there still isn't a pack-based format that you can upgrade to from dirstate-with-subtrees ?
<james_w> you should be able to upgrade to --rich-root-pack if you don't actually have any subtrees I believe.
<weigon_> james_w: http://pastie.org/212084
<mtaylor> james_w: we don't _think_ we are using any (at least, we aren't on purpose)
<weigon_> this is the one for bzr log failing
<mtaylor> james_w: but upgrade --rich-root-pack still b0rks
<james_w> weigon_: thanks. That's a different error from the "bzr branch" error, could you possibly provide that one as well, it would be great to have as much information as possible.
<weigon_> sure
<james_w> mtaylor: is it an error about this problematic revision, or something unrelated?
<mtaylor> james_w: something unrelated - I was trying upgrading to packs to see if that would help ... but now I'm just fixed on the fact that I _can't)
<james_w> heh :-)
<james_w> sounds like it would be worth a separate error report then.
<mtaylor> yay! two bugs in one swipe!
<weigon_> james_w: http://pastie.org/212087
<james_w> thanks team.
<james_w> I'll put those in the bug report if you don't mind, as we don't have good info there yet
<weigon_> shall I add it so you have a reference for more info ?
<james_w> I think there may be enough there to know what is going on. I'm no expert in this area though.
<weigon_> k
<james_w> there's also a public branch there that is reported to exhibit the problem, so it can always be reproduced by the developer.
<james_w> thanks for your help.
<weigon_> the sftp:// idea is good enough for now
<weigon_> thanks
<weigon_> james_w: the story goes on with $ bzr merge ... let me paste it
<weigon_> james_w: http://pastie.org/212089
<james_w> ok, do you understand what the error message is saying?
<weigon_> james_w: it tries to find the common ancestor where the two trees are related and can't find it
<james_w> yup, are these two trees supposed to be related?
<weigon_> this is the same tree that has the other problems :)
<weigon_> they are related just a few revs before the unknown rev-id
<weigon_> I assume that this is just a side-effect, as bzr thinks it can't find one of the rev-ids along the way and jumps out
<awilkins> gour: The SVN team have always been cautious about version numbers ; I remember how long it took them to get to 1.0
<blaudden> Hi, I'm getting extensive merge conflicts when merging two trees(383 conflicts). It feels like it select's a very old base. The manual hints about specifying a specific base to use. But I can't figure out how to do that. Any ideas?
<blaudden> Have tried to remerge with "bzr remerge --weave <conflicted files>" and that will bring the number of conflicts down, but at the same time some changes will be lost and it's not possible to use "bzr extmerge" after that since ther is no .BASE, .OTHER and .THIS anymore.
<spiv> blaudden: try --lca instead of --weave maybe
<spiv> blaudden: I'm not sure what you mean by "some changes will be lost"
<blaudden> spiv: yes, I tried --lca also
<blaudden> spiv: When running the binary it wil crash and I find one place where the merge has removed two lines instead of conflict them. That makes me a little scared and I start to think about other places being merged that way but that doesn't cause an immediate crash.
<fredreichbier> when i use bzr with http+ftp, does that create special traffic or abuse the sever?^^
<spiv> blaudden: that's always a risk with an automatic merge tool
<blaudden> spiv: :)
<spiv> blaudden: just because one branch adds a line here and another removes a line there, in non-overlapping parts of the code, doesn't mean there isn't a semantic conflict.
<spiv> blaudden: a trivial example is a branch that adds an extra parameter to a function, and updates all the callsites to pass the new parameter.  If you have a branch that adds another call to that function, then merge the first branch in, you probably won't get an automatic conflict.
<spiv> blaudden: but the code won't work
<spiv> blaudden: so you ought to run the test suite and/or review the diff and/or do some other QA to check that the result is sane.
<blaudden> spiv: yes, that example seems resonable
<Peng> fredreichbier: Do you mean ftp or http, or some ungodly hybrid of the two? ;P
<spiv> fredreichbier: not sure what you mean by "special" traffic.  It is just regular ftp/http, it doesn't do anything crazy.
<spiv> You can abuse the server with regular traffic if you have enough of it, though ;)
<Peng> fredreichbier: http mostly uses Range requests, which can confuse Squid. It also might make quite a lot of requests in a short amount of time, especially with a knit repo.
<blaudden> spiv: In this example it's someone who changed part of the line, and in addition the order of that line and the line above has changed place in one of the branches.
<fredreichbier> Peng: spiv: i mean http-pulling and ftp-pushing. thanks your your answer ;)
<Peng> fredreichbier: You should use bzr+ssh or at least sftp. ftp sucks. It's not encrypted.
<fredreichbier> Peng: i need access to the server to use bzr+ssh, and i don't have ,)
<spiv> blaudden: please feel free to file a bug with that example if you think bzr ought to do better there, btw.
<Peng> fredreichbier: What do you mean?
<spiv> blaudden: our merges are generally very good, but there's always room for improvment
<blaudden> spiv: ok, I'll see if I can make something reproducible...
<fredreichbier> Peng: i thought i have to set up a bzr server (`bzr serve`?) on my server to use bzr+ssh, don't i?
<spiv> fredreichbier: you just need bzr installed on the remote side
<Peng> fredreichbier: For bzr+ssh, you need to have ssh access (duh), with bzr installed and in the PATH.
<Peng> fredreichbier: bzr+ssh simply sshes in and runs "bzr serve --inet --directory=/".
<Peng> fredreichbier: (Err, the process doesn't stay around like a normal "bzr serve". --inet causes it to close when you're done.)
<spiv> Peng: (it also passes --allow-writes)
<Peng> spiv: Oh, right.
<fredreichbier> thanks Peng ;) I have a shared hoster without ssh access, that's the problem.
<matkor> Hi ! What are options to make partial revert of file ?
<matkor> I see that sb deleted too much changing few lines ...
<Peng> fredreichbier: Um. You just have FTP? Hopefully not telnet..
<Odd_Bloke> matkor: 'bzr shelve' in the bzrtools plugin might help.
<Peng> fredreichbier: You should tell your host that it's the 21st century now.
<matkor> Odd_Bloke: tnx checking ...
<spiv> matkor: you could also try "bzr cat -r 1234 FILE > FILE.older" then "meld FILE.older FILE"
<spiv> (where 1234 is the revision number)
<spiv> (Also depends a bit on what you mean by "revert" I guess...)
<sabdfl> spiv: thanks and congrats on the results of your landings in 1.6 - network performance is transformed here
<spiv> sabdfl: excellent!  There's more to come.
<sabdfl> pull is much faster - i'm close to the server in question so performance has never been an issue, but the change is noticeable nonetheless
<fredreichbier> Odd_Bloke: :-) thanks
<lifeless> sabdfl: thats great news
<fredreichbier> uh. i did a wrong highlight :/
<sabdfl> lifeless: yes, i bet it's really noticeable from .au!
<sven_> hi! i have a problem where 'bzr merge --weave' resolves more than it should. in branch_1, i permute line 5 and 6. In branch_2, i replace line 5 by line 5.1 . 'bzr merge --weave' does not give a conflict; instead it outputs line 5.1, line 6, and line 5, in that order.
<sven_> i would prefer to get a conflict. it is very dangerous to resolve like this without any human seeing it...
<sven_> what is your position on this? does it look like a bug? shall i create a bug report?
<spiv> sven_: off the top of my head I suspect that's working as intended.  To the merge algorithm a changed line looks like a delete and an add, so it would think both sides deleted the line (so they agree, no conflict), and then they both add some lines.
<spiv> sven_: still worth a bug report, though.  It would be good to make the merge better than it already is.
<blaudden> spiv: thanks! sven_ is trying to help me figure out what could be the problems we experience
<sven_> spiv, thanks. yes, i suspected it was something like that. i'll file a bug
<blaudden> spiv: how recomended is it wo use --weave ?
<mtaylor> blaudden: still working on the ugly merge?
<blaudden> blaudden: after having done it 20 times I start to learn :)
<blaudden> mtaylor: ^
<mtaylor> hehe
<mtaylor> we should give the bzr guys the two branches as the are now as a worlds-worst-merge test case :)
<blaudden> mtaylor: ok, I'll check it in....
<mtaylor> hehe
<mpt> Is there a quick way of asking bzr "Show me a diff of branch X compared to what branch Y would look like if branch Z was merged into it", without making a temporary branch that merges Z into Y?
<radix> bzr merge --preview, maybe?
<blaudden> bzr merge --preview ?
<radix> It really only makes sense for two branches though
<radix> like, "show me a diff of what branch X would look like if branch Y were merged into it"
<mpt> hmm
<spiv> mpt: You could get a very rough approximation with interdiff, I guess.
<spiv> mpt: someone could probably write a plugin that does that operation for you without a temporary branch (although making it not simply hold the full temporary branch in memory would non-trivial)...
<spiv> (but possible, I think)
<mpt> meh, I'll just make the temporary branch :-)
<spiv> mpt: yeah, I think that's the pragmatic answer :)
<spiv> sven_: hmm, I cannot reproduce your bad merge
<spiv> sven_: That is, I get a conflict on those lines.
<sven_> spiv, i'm using 1.3.1. trying with development version...
<sven_> spiv, did you use --weave?
<spiv> sven_: I did.  And tried with --lca, too.
<spiv> sven_: with bzr1.3.1
<spiv> sven_: http://pastebin.com/m5efc4c3
<spiv> sven_: (I get the same result with bzr 1.6b2 FWIW)
<blaudden> spiv: nice way to reproduce
<spiv> blaudden: it was about as literal an interpretation of your scenario as I could think of :)
<blaudden> spiv: ok, we'll come up with something worse soon...
<spiv> blaudden: :)
<sven_> spiv, i reproduced it with this: http://pastebin.com/m48d554f9
<sven_> spiv, by 'permute', i meant change the order of the lines without modifying the contents...
<spiv> sven_: Oh I see
<spiv> sven_: right, I can see why it does that
<sven_> spiv, ok, why? :-)
<spiv> sven_: IIUC it correctly, because in branch_1 it sees a line removed between lines 4 & 6, and a line added after 6.  In branch 2 it sees that same line removed between 4 & 6, and a new one added in the same place.
<sven_> spiv, right.
<spiv> sven_: So the removal is done by both sides, which is not considered a conflict (both sides took an identical action), so the only differences are adding two lines.  The two lines are added in different, i.e. non-conflicting, places.
<spiv> And there's no ambiguity about where to insert those lines (the lines adjacent to the insertions didn't change).  So it doesn't consider it a conflict.
<sven_> spiv, that makes sense from an algorithmic point of view. but still i think it is dangerous to merge this automatically.
<spiv> sven_: all automatic merges are dangerous
<Odd_Bloke> Danger, Will Robinson!
<spiv> Many merge algorithms will tend conflict on this sort of change, because they will consider both sides doing the exact same thing as a conflict, so the parallel removals would cause a conflict here.  (Although typically a hard to understand one, conflicts involving removed lines always look confusing because the conflicting bit isn't visible).
<spiv> We generally consider that aspect to be a feature though (instead of a confusing conflict, you get a merge with what both sides tried to do anyway), it's almost always what you want in our experience so far.  Maybe it'd be worth adding a --cautious or something, though
<spiv> sven_: but there's nothing magic about line-based merging algorithms that can guarantee the result makes sense.
<sven_> spiv, of course not.
<sven_> spiv, but 'bzr merge' gives a conflict on these lines. however, we cannot use that since we have a criss-cross merge which results in 383 conflicts. otoh, we cannot use 'bzr merge --weave' if it does not give a conflict in this case...
<spiv> Even when there's clearly no overlap in the lines touched you can have semantic conflicts.  You can't rely on the automated merge tool to give you something that makes sense.
<sven_> spiv, i'm no merge algorithm expert, but could it be possible to give conflict if concurrent changes are "close" to each other (where "close" is a configurable number of lines)?
<spiv> sven_: closeness doesn't matter
<spiv> sven_: you can have incompatible changes in different files
<spiv> sven_: i.e. one branch changes a function definition in one file to take a new parameter, another branch adds a new caller of that function using the old signature in a file the first branch doesn't touch.
<spiv> sven_: any line-based merge will think there's no conflict there, as the changes aren't even in the same files.  But the result is broken and needs conflict resolution.
<spiv> sven_: Anyway, it might be possible to make --weave/--lca more cautious so that it gives a conflict in that case (without making it so conflict-prone that it's as bad as --merge3).  So do file a bug, we want the tool to DWIM as much as possible.
<sven_> spiv, ok, i'll file a bug
<sven_> spiv, thanks for your help!
<spiv> sven_: but it can never be perfect, unless you can supply it with an external merge tool that understands code rather than just lines of text :)
<sven_> spiv, of course :-)
<spiv> sven_: another option is that maybe we could make merge report warnings when it's assuming that identical changes by both sides don't conflict, or similar, so humans have hints about what's perhaps most likely to need checking.
<spiv> Although really it may as well just generate a conflict in that case...
<spiv> sven_, blaudden: finally, even though --lca doesn't produce .BASE file (which unfortunately breaks extmerge, which is a bug in extmerge I think), you could still invoke something like meld manually with the THIS and OTHER file.
<blaudden> spiv: oh really. that seems nice
<blaudden> spiv: is that that same with --weave?
<spiv> It's not as helpful as when there's a BASE file, but I'm fairly sure meld can still help when there's just two sides.
<spiv> blaudden: right.  --lca is basically always at least as good as --weave, btw.
<spiv> (there's an obscure edge case it flat out can't handle yet which is why it isn't a total replacement, but in practice you might as well use --lca rather than --weave)
<spiv> --lca is likely to become the default merge method in future.
<blaudden> spiv: so you suggest that I try with "merge --lca" or just "remerge --lca" ?
<blaudden> we should fix extmerge ...
<pickscrape> I sent a patch through to the extmerge author a while back but it seems to have been ignored :(
<pickscrape> (not for this problem, for something else)
<blaudden> pickscrape: maybe it ws a problem with merging? :-)
<pickscrape> :)
<pickscrape> It was to give the use the option of which merge tool to use if he doesn't have one configured
<pickscrape> Instead of the current hard-coded check order
<spiv> pickscrape: that sounds useful.  Is your branch/patch on launchpad somewhere?
<mpt> jam, thanks for all your help yesterday. After the reconcile (which finished overnight) the branch worked fine.
<spiv> mpt: ah, glad to hear your problem is finally sorted out
<pickscrape> It's not... Would I need a new project for that, or can I just upload it to my own area without attaching it to any project?
<jam> mpt: good, though you probably shouldn't have needed to wait for the full repository reconcile, unfortunately
<jam> the branch fix takes like 2sec
<spiv> pickscrape: there's already a bzr-extmerge project on launchpad
<pickscrape> Oh there is?
<pickscrape> Am I able to just randomly register a new branch and push to it on that project?
<spiv> pickscrape: you can just do "bzr push lp:///~USERNAME/bzr-extmerge/my-branch".  Or just file a bug and attach a patch :)
<pickscrape> Ah right... I'll give that a go :)
<spiv> Er, "lp:~USERNAME/bzr-extmerge/my-branch" would be fine, actually.  Not sure why I put the /// in there...
<pickscrape> spiv: lp:~pickscrape/bzr-extmerge/choose-mergetool
<spiv> pickscrape: thanks!
<mpt> spiv, well, it's fixed in *that* branch. :-) There's another branch that's pretty much hosed because I tried to fix it by copying in an old copy of .bzr, when one of the merges I'd done since then was merging mainline
<mpt> So now there's dozens of unknown files in the tree, some of which should be there, and some of which shouldn't
<lifeless> mpt: erm, wtf. let bzr manage .bzr, you manage your working tree
<mpt> yeah, I know that now
<lifeless> mpt: why was it not obvious (how can we prevent other users doing the same thing)
<mpt> lifeless, because that's what someone told me to do for the same problem last week
<lifeless> who?
 * pickscrape just used the launchpad "Propose for merging" feature for the first time.
<jam> lifeless: when you have a broken dirstate (from a couple of older bugs) you can do "bzr co --lightweight" and then copy it back over
<jam> it was the only recovery tool that we had
<jam> I don't remember the specific problems
<sven_> spiv, blaudden, i reported https://bugs.launchpad.net/bzr/+bug/238895
<ubottu> Launchpad bug 238895 in bzr "'bzr merge --weave' merges unsafely when branch_1 has permuted lines and branch_2 has modified same line" [Undecided,New]
<sven_> right
<whitelynx> i'm using Bazaar to manage several projects with multiple users, and I'm running into an issue; when someone pushes a new branch to our repository, the permissions are set so that nobody else can write to it, and I have to go manually fix permissions so others can push to it. Is there any way to set a umask or something in the Bazaar configuration?
<whitelynx> Also, I had to make everyone part of the same group and have them all default to that group to make the pushed branches have the correct group; however, this means I can't use multiple groups to manage permissions for different projects because whenever someone pushes, it always pushes as their default group
<blaudden> sven_: I updatede your report with the result we get.
<fredreichbier> if i try to push over sftp, i get an Permision Error with ".bzr/README.tmp.1213121278.758560896.7992.40354623", but it creates the branch directory. what can i do?
<fdv> lifeless: I've been looking at this issue with the KnitCorrupt error I talked about earlier. Isn't what I want essentially 'unpull'?
<fdv> lifeless: And couldn't this be accomplished somehow by a pull --overwrite with an appropriate revision range?
<MvG> Is Jan Hudec present here?
<tethridge> please excuse me for asking again, but does anyone know of a project similar to bzr-svn for clear case?
<tethridge> Somebody told me that they had heard that somebody was using it internally at work, but they didn't know who.
<tethridge> I've been asking through different times of the day in the hopes that somebody would know something.
<mwhudson> tethridge: the most knowledgeable people are probably going to appear in 1-2 hours
<tethridge> mwhudson, I'll try again then.  Do you have some usernames that I should look for?
<beuno> tethridge, actually, you might even get a better response from mailing to the list
<beuno> morning mwhudson
<tethridge> good idea
<abentley> mwhudson: I wouldn't say that exactly.
<tethridge> I'm going to try both
<abentley> jam and I are pretty knowledgeable.
<abentley> It's just that idling here isn't what I'm paid for.
<tethridge> abentley, know anything about a clear case plugin?  :-)
<tethridge> oh, and you get paid?
<abentley> tethridge: No, I haven't heard of any such thing.
<tethridge> I'm getting screwed
<abentley> tethridge: I work on the bazaar-launchpad team.
<tethridge> ah
<tethridge> just kidding
<abentley> I'm not too up on the proprietary stuff.  What is ClearCase again?
<abentley> i.e. are you looking for an IDE plugin or an import/export plugin?
<matkor> Hm. Why when I try bzr push lp:~matkor/wicd/experimental-matkor I get bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ematkor/wicd/experimental-matkor/.bzr/repository/lock): Transport operation not possible: http does not support mkdir ? Why bzr tries to use http ?
<jelmer> matkor: the launchpad plugin uses http if you haven't logged in
<jelmer> matkor: try "
<jelmer> bzr lp-login"
<jelmer> or something
<matkor> jelmer: I see .. thanks a lot !
<mwhudson> oh man, i have some mailing list posts to write, it seems!
<mwhudson> beuno: simpletal looks interesting
<beuno> mwhudson, more than pylons + mako?
<mwhudson> beuno: well, i dunno
<mwhudson> as i said, i kind of hate non-tree templating
<mwhudson> but if you're the one doing the work ... :)
<mwhudson> beuno: what does pylons use for the http part?
<mwhudson> (where turbogears uses cherrypy)
 * beuno looks
<beuno> mwhudson, it seems to use wsgi
<mwhudson> uhh
<mwhudson> is that actually an answer to the question?
<mwhudson> i guess it is
<beuno> well, yes and no  :)
<beuno> "paste"
<mwhudson> i guess it means you can plug in ~whatever http server you like
<beuno> By default Pylons uses paste's httpserver
<mwhudson> which would be good because cherrypy makes the baby jesus cry
<beuno> "You could stick to it or use something different, say one from CherryPy 3.0"
<mwhudson> cherrypy 3 is ok, afaict
<beuno> so if you still feel like you need pain on a daily basis, we can stick with it  :p
<beuno> the cool thing is that pylons has kid/genshi too
<mwhudson> well
<mwhudson> i am still skeptical that loggerhead benefits from _anything_ that's in the django/turbogears/pylons/zope category
<mwhudson> really SimpleHTTPServer + some templating engine should be enough
<mwhudson> (for the plugin version, not what we do on lp)
<beuno> yeah, SimpleHTTPServer would be the best way to go
<mwhudson> i guess we may want slightly more sophistication, because we do want to set http headers occasionally
<mwhudson> so maybe wsgi would be an appropriate interface to aim for
<beuno> mwhudson, I believe the dependency issue for ZPT is enough reason to look into other options sooner than later. What do you think?
<mwhudson> beuno: i think if simpletal can work, then that's a small enough dependency
<beuno> mwhudson, I'll check and see what changes have to be made
<mwhudson> beuno: *i* already have too many half-finished not-really-sure-if-it's-a-good-idea loggerhead branches around
<mwhudson> beuno: i don't want you to start collecting them too :)
<beuno> in fact, I'll do it now, while I wait for lifeless to wake up and I can complain about bzr-search
<beuno> heh
<beuno> ok, so you want the other 2 patches first  :)
<mwhudson> well, let's see about simpletal
<beuno> the ZPT thing just itches too much, at least to move it into trunk
<mwhudson> on first blush, it seems like the changes required would be fairly minor
<beuno> ok, so I'll take a shot at simpletal now, and, if it's simple enough, I'll re-send the last patch with simpletal, and the other 2
<beuno> seem ok?
<mwhudson> i will give turbogears some credit, it nicely encourages loose coupling
<mwhudson> beuno: +1
<mwhudson> if nothing else, i think refactoring from the zpt templates to something else might be easier than refactoring the kid templates
<mwhudson> because i think i cleaned up the templates a bit when i rewrote them
<beuno> absolutely, I've been doing all my work based on your zpt branch
<beuno> kid is a bit icky, but it may be the cleanup too
<beuno> either way, there may be some portions of the zpt patch you may want to look at, the non-template bits
<mwhudson> phone brb
<beuno> ah, lifeless, finally  :)   good morning
<jelmer> hmm, post-push hooks don't appear to be working when creating a new branch
<mwhudson> beuno: ok, back
<beuno> mwhudson, I can't find a clear way to use simpletal with TG...  :/
<beuno> documentation on simpletal is a bit...  "lacky"
<mwhudson> well, i guess you need to hackerize the turbozpt package that zpt-templating includes
<beuno> I can't get TG to use simpletal at all
<beuno> and google isn't really being helpful
<mwhudson> let me have a go
<beuno> many people saying they want to move to, but none that actually did
<mwhudson> i see
<beuno> argh, simpletal is only available for 2.4...
<beuno> packaged in Ubuntu at least
<mwhudson> ?
<mwhudson> mwh@grond:~/canonical/repos/loggerhead/trunk$ python2.5 -c 'import simpletal'
<mwhudson> mwh@grond:~/canonical/repos/loggerhead/trunk$
<beuno> ah, no, ignore me
<beuno> I really have to do a fresh install
<beuno> anyway, there doesn't seem to be integration into TG, or am I missing something?
<mwhudson> no, there probably isn't
<mwhudson> but that's ok, we can write it
<beuno> is it still worth it if we have to?
<mwhudson> i really don't think it will take very long
<tethridge> anybody heard of a clearcase plugin similar to bzr-svn?
<tethridge> last time I'm asking
<tethridge> :-)
<jelmer> tethridge: I don't think there is one
<tethridge> I was told that supposedly somebody was working on one for internal use at their company
<tethridge> don't know who though
<beuno> mwhudson, alright, I'm not very familiar with that area, but I'll give it a try
<mwhudson> beuno: let me try first :)
<beuno> yay!  :)
<mwhudson> beuno: is the latest version of the zpt branch on launchpad somewhere?
<bob2> tethridge: maybe someone on the list will know
<tethridge> I'm going to try that
<beuno> mwhudson, I have 3 zpt branches. 1) is that patch I sent to the list, which I can upload if you want. 2) is zpt+ajax+cleanups, 3) is list patch + cleaner URLs
<mwhudson> beuno: ok, i'll use the bundle
<mwhudson> bundles are awesome
#bzr 2008-06-11
<beuno> mwhudson, interesting result
<mwhudson> beuno: ?
<beuno> quick and dirty cleanup of genshi, per Toshio's recommendations
<beuno> cuts the time it takes to generate the template in half
<beuno> let me compare that against zpt...
<mwhudson> ah
<beuno> damn, zpt is still faster
<beuno> ~5sec against ~3sec
<beuno> to render NEWS annotation
<mwhudson> beuno: seem to be getting somewhere with simpletal fwiw
<beuno> mwhudson, ah, cool. It'll be interesting to see how that works out
<mwhudson> yes :)
<beuno> I'm trying to set aside the other options, while I wait
<mwhudson> beuno: tests pass :)
<beuno> mwhudson, oh, very cool!  branch/patch?
<lifeless> beuno: what changes did you make to the genshi templateE?
<mwhudson> my zpt-templating branch, in a few minutes
<beuno> lifeless, replaced the include tag with the actual content, and avoided match:
<lifeless> awesome
<beuno> yeah, amazingly, that cuts render time in half
<beuno> still uses more ram than zpt though, aside from the extra seconds
<lifeless> bugs ftw huh
<mwhudson> oops, pushed to the wrong location
<beuno> lifeless, btw, I found a bug in bzr-search, which I haven't been able to fix very nicely yet, so when you're up to it, and want to help me a bit, I'll be happy to work it out. It also may merit a test.  When you re-index a branch with no changes, md5 collision tracebacks
<lifeless> sure
<lifeless> two issues there
<lifeless> three in fact
<mwhudson> man simpletal's logging is noisy
<lifeless> a) you are indexing already indexed revisions
<lifeless> b) md5 collisions should result in a content-match check followed by ignore(matches) or raise(fails)
<mwhudson> oh and unicode issues, fun
<lifeless> c) we need the component combining facility shortly after we get growing-index-component-counts
<lifeless> a) is the fix needed for this scenario
<beuno> right, my initial though was to compare revisions, but it seems like too expensive of an operation for each time you index
<beuno> I'm wondering if we can safely assume we need to index from the last revision indexed on
<lifeless> so there is no 'last' as such
<lifeless> but we can take the branch revision tip
<lifeless> and do a breadth first search from that out
<lifeless> and when we find a revision that has been indexed, call search.stop_searching_any([revid])
<beuno> that sounds pretty good
<lifeless> (bzrlib.repository has this code, in search_out_something_or_other)
<beuno> I like that   :)
<lifeless> it will need a new method on the Index, to test for the presence of revisions
<lifeless> something like adding a parameter to indexed_revisions
<beuno> mwhudson, revision 244 is the simpletal's?
<lifeless> so indexed_revisions(revisions) -> intersection of revisions and the index
<mwhudson> beuno: 224
<beuno> lifeless, I already have a patch to seperate getting the branches revisions, as it seemed like it would be useful for other operations
<beuno> maybe I can tweak it to accept an optional parameter to stop at
<beuno> mwhudson, right, 224, slipped, I'll take a look now
<lifeless> I don't think that will work ;)
<mwhudson> beuno: at least one more fix coming up
<mwhudson> beuno: simpletal seems a bit slower, probably around the same speed as kid
<mwhudson> uh
<mwhudson> 'your fixed genshi'
<mwhudson> is what i meant to say
<beuno> mwhudson, I'll compare them now
<mwhudson> beuno: get rev 225
<beuno> lifeless, so you'd rather I leave it as-is and duplicate code?
<lifeless> beuno: imagine we have 60K revisions
<mwhudson> beuno: memory usage seems the same or slightly better with simpletal though
<lifeless> beuno: anything that requires getting set(revisions) for *either* the branch or the index will perform badly
<lifeless> beuno: so we have to spider, breadth first search
<beuno> mwhudson, simpletal really does complain a lot...  but that may be a good thing eventually
<mwhudson> beuno: it does seem a little slower than zope.pagetemplate, but the memory usage is very nice
<mwhudson> and yes, it's whiny :)
<mwhudson> which is probably good, it's pointing out mistakes in the templates
<Peng> I wonder how speedy hg's custom template system is?
<lifeless> probably very fast
<lifeless> beuno: does my explanation make sense?
<lifeless> beuno: also the index is a set, its not got an inherent ordering so there isn't 'most recently indexed' as a concept to work from
<beuno> lifeless, not to me, no. But I probably didn't explain well what I meant. Aside from this bug, I moved the logic of getting all the revision ids in a branch to a seperate function, which returns a list. So basically just changed the code for the patch I sent out earlier. On top of that, I think I may be able to add a "stop at this rev" optional argument, so we can re-use that piece of code. Doesn't really have anything to do with search indexes, as far as I
<beuno> mwhudson, seems a bit slower, yes. 6-8 seconds slower to generate my 36k diff. But it does use less memory, and, well, it's nice to depend on than zope
<mwhudson> there are also bugs remaining
<lifeless> beuno: so that piece of code (get all revision ids) is _only_ useful in an entirely empty index
<mwhudson> but yes, seems worth pursuing
<lifeless> beuno: and its actually not needed then, because the search approach I describe will generate the same results
<lifeless> beuno: also note that there is no _single_ revision to stop at - its a graph, you need the surface of the intersection between the two sets (indexed, all) to be able to provide a stop-list, but that means knowing them all a-priori so is thus more expensive
<lifeless> beuno: grab a whiteboard, draw a branch with merges - say 5 mainline revs, 10 in total.
<lifeless> draw a circle around the bottom two mainline revs, should cover 3 or 4 total revs
<beuno> mwhudson, btw, what do you think about removing full text indexing by default in trunk?  It's driving me crazy  :)
<mwhudson> beuno: +1
<lifeless> we need to identify what is outside the circle without looking inside the circle
<beuno> lifeless, I see your point. I'll give it some thought and get back to you. Meanwhile, indexing an indexed-unchanged branch == boom
<beuno> mwhudson, I think just commenting that like out would suffice for now, and you've got the push powers  :)
<lifeless> beuno: right. tell you what, I'll whip it up tonight, its very straight forward (I've written it before). I'm mainly trying to broaden your mind to think about these problems in a clearer way
<lifeless> beuno: because these problems are the heart of the performance-of-bzr issues for many things
<mwhudson> beuno: we need to be careful what happens when people type something in the search box then
<mwhudson> though i dunno, the naive approach only took 20s on bzr.dev
<lifeless> mwhudson: 20s its 19 seconds too long for a web app
<mwhudson> lifeless: yes, indeed
<lifeless> mwhudson: also, I suggest you guys don't limit yourself to bzr.dev for a test branch.
<lifeless> may I humbly present python
<beuno> lifeless, perfect. I'll look into that piece of code as soon as you push it. I understand the problem, and I have a few ideas on how to get around it, but I'd have to put them into practice. I really apreciate the explanation  :)
<lifeless> its 60K revisions, but only a few hundred MB
<mwhudson> lifeless: the ~vcs-imports branch?
<lifeless> es
<mwhudson> or is there a better one?
<lifeless> no
<mwhudson> k
<lifeless> bzr-svn'd
<mwhudson> i use launchpad sometimes :)
<beuno> mwhudson, what took 20s?  It takes a good 25 minutes to index commits here
<mwhudson> beuno: if you run without caches
<mwhudson> the search is very naive
<beuno> ah, right. Well, at this rate, we should be able to benefit from lifeless's efforts real soon and cut that down to under 1 sec  :)
<mwhudson> beuno: https://code.edge.launchpad.net/~mwhudson/loggerhead/zpt-templating is up to rev 226 now
<lifeless> I have to commit this soon
<lifeless>  63 files changed, 4891 insertions(+), 6962 deletions(-)
<jml> hello #bzr
<RAOF> Hello jml :)
<jml> We were doing some tests with RepositoryTestProviderAdapter. It seems to have disappeared from bzr.dev.
<mwhudson> beuno: i notice the javascript on the revision page is broken :/
<lifeless> it is deleted
<lifeless> you should now use
<lifeless> TestScenarioApplier
<lifeless> to apply the scenarios
<lifeless> and peek in bzrlib.tests.repository_implementations.test_suite to see how the scenarios are created
<mwhudson> beuno: and the css on the revision page seems a bit odd, though maybe that's just the new ff
<mwhudson> beuno: the inventory listing also looks crappy, the 'last changed' column is too narrow and the dates are wrapping
<mwhudson> beuno: other than that, i reckon this branch is probably good to land, what do you think?
<beuno> mwhudson, looks better, yes. I doing some last performance tests to convince myself we're not loosing too much, and that it's worth the tradeoff for better dependencies
<beuno> still, 40 seconds to render a file seems too much to me
<mwhudson> where does 40 seconds to render a file come from?
<beuno> so, this could be a good step forwards, as opposed to 1.35m and gigwats of ram
<beuno> mwhudson, my 36k dif
<mwhudson> oh right
<beuno> it takes bzr ~13 seconds to generate it, and the rest is rendering
 * pygi wonders if anyone of the bzr folks is going to Akademy?
<lifeless> when is it?
<mwhudson> beuno: yes, still too slow
<lifeless> certainly Jonathan Riddell will be, but hes more a user :P
<mwhudson> beuno: but much better
<pygi> October 8 - October 13 lifeless
<pygi> pygi, October 15 that is :p
<pygi> ergh
<pygi> my counting xD
<pygi> August*
<mwhudson> beuno: can you work on the things i mentioned above?
<beuno> mwhudson, yup, on it. I'll work towards sending a similar patch to zpt yesterday
<mwhudson> awesome
<beuno> javascript seems fine for me
<beuno> ah, no it doesn't
<beuno> in revision view
<mwhudson> it's probably worth getting trunk loggerhead and zpt-templating running side by side and comparing the look of each page
<mwhudson> i can help with this of course
<mwhudson> but not right now as i'm going to go and get lunch
<lifeless> jam: ping
<beuno> mwhudson, yes, I'll make sure I do that before I send the patch in. I'm going to go home, it's been to many hours at the office. Oh, and also eat something  :)
<pygi> lifeless, so I guess no one :p
<mwhudson> beuno: ok, we will meet again in a few hours then :)
<lifeless> pygi: I would raise it on the list
<pygi> lifeless, was trying to see if we could collect like 3 more people, and start a bzr group (share a room)
<pygi> then we could hack a bit yay :D
<lifeless> that sounds like an excellent idea
<lifeless> there are more people that read the list than hang out in the IRC channel :P
<pygi> lifeless, perhaps but you know, rooms are limited (there are like 6 more beds or so :-/)
<lifeless> pygi: so mail _now_ ? :P
<beuno> lifeless, FWIW, I sent you the patch for bzr-search, just because, as it is now, that's cleaner  :)
<beuno> you can discard it silently, just felt better to send before deleting
<pygi> lifeless, done :p
 * beuno -> home
<lifeless> beuno: thanks
<poolie> hello
<pygi> hi hi poolie
<jml> lifeless: would it be a good idea for TestScenarioApplier to have a method that takes a suite of tests and returns the multiplied suite?
<lifeless> isn't multiply_* already what you want?
<jml> lifeless: not quite. adapt_tests is close.
<jml> lifeless: but it uses an out parameter rather than returning.
<lifeless> jml: (No, not really, we want to decouple: the act of application, the act of accessing and deciding, and the act of making scenarios)
<lifeless> jml: also, EOVERFLOW
<lifeless> I have a 10K patch in my head. space is reduced
<lifeless> seriously:  63 files changed, 4935 insertions(+), 7037 deletions(-)
<lifeless> don't expect arbitrary topics to work until this lands
<jml> lifeless: ok. I'll disagree with you later in more detail :)
<lifeless> that sounds fine
<poolie> jml, i can talk to you about this
<jml> poolie: if you'd like. I've figured out how to do what I want, I just don't yet understand why the API is as it is.
<poolie> i think the api needs to be cleaned up
<poolie> and the various users made consistent
<poolie> i posted about it on friday iirc, you can reply to that if you have any other thoughts
<lifeless> wheee
<lifeless>  63 files changed, 4891 insertions(+), 7387 deletions(-)
<bob2> vf?
<lifeless> yah
<lifeless> migrating the very low level tests across now, so deleting all the old classes
<lifeless> FEELS GOOD
<poolie> jml, is there any meaningful difference between a TestSuite and just a container full of tests?
<jml> poolie: it's a subject of scholarly debate.
<poolie> heh
<jml> poolie: the big difference is you can run() a TestSuite.
<jml> poolie: mostly I don't get why adapt_tests takes a suite as a parameter, rather than returning one.
<jml> poolie: actually, another important difference between suites and generic containers is that TestSuite().addTest(some_suite) works.
<poolie> hm
<poolie> but list.append(a_list) works too...
<jml> poolie: yeah.
<jml> poolie: if TestSuite.run() were implemented with iter_tests, then what I said about addTest wouldn't matter.
<lifeless> poolie: test suites can add capabilities
<lifeless> because they can do things before and after tests
<lifeless> like IsolatedTestSuite for instance
<poolie> so if they can be subclassed then we should presumably not be creating them ourselves
<poolie> as we don't really know which one to create
<poolie> i'm not sure whose decision it _is_ as to which one is used
<lifeless> its the loaders
<poolie> and it may not matter, because the tests can be copied across, or the suites composed
<lifeless> and load_tests is designed to support this
<lifeless> so TSA should not create a suite
<lifeless> blink, I've been sucked in
 * lifeless goes back to code
<beuno> mwhudson, back (and thanks for disabling the search cache in trunk)
<mwhudson> beuno: hi
<mwhudson> i'm working on changing the modified file links on the changelog view to match what trunk does
<beuno> mwhudson, ok, cool. I'll fix javascript and see what else is off
<mwhudson> grr
<jam> lifeless: I'm around for a short time, what did you need?
<lifeless> jam: I mailed you
<lifeless> jam: basically, I have all tests passing but am not setting modes on knit files
<mwhudson> beuno: ah, the javascript problems are '>'s getting turned into '&gt's in the output
<lifeless> I want to know whether you think I need to (fixthetestsANDputmodesupportintothenewcode)
<jam> lifeless: I've often thought about giving up as well, and just telling users to set their umask for their bzr connection
<lifeless> jam: I haven't broken those tests or anything, they just don't seem to hit this code
<lifeless> the patch is quite large now:
<mwhudson> beuno: maybe it's a simpletal buglet, but it's easy enough to work around (put the javascript in a js file...(
<lifeless>  63 files changed, 4937 insertions(+), 7958 deletions(-)
<jam> I'm pretty sure we had them at one point, I don't know at what level
<lifeless> we had them at a couple of levels
<jam> and certainly they could have been removed without realizing
<lifeless> they just aren't triggering for this for some reason.
<jam> I know poolie did some work on moving around where "_dir_mode" was being accessed
<beuno> mwhudson, from what I saw, it removes anything within an HTML comment  <!-- -->
<beuno> at least for the revision view
<poolie> hello jam
<mwhudson> beuno: yeah, that too
<jam> anyway, it is fairly moot for packs, and anyone on knits should be using bzr < 1.3 or so
<mwhudson> if you take out the <!-- --> you get the problem i mentioned
<lifeless> jam: so, you're cool with this? we can always add it in later..
<poolie> lifeless: is it hard to set the modes?
<jam> lifeless: *I'm* okay with it, but I've approved some of your recent changes and *other* people stumble over them
<poolie> with my recent landing it should be easy
<jam> like get_revision_graph
<beuno> mwhudson, ah, yes, you're one step ahead of me. So, move all javascript to .js file, where it should actually be.
<jam> i don't really know whether people are really depending on it or not.
<jam> It seems broken for sftp which would be one of the primary use cases
<mwhudson> revision 229 heading to lp...
<lifeless> poolie: I haven't merged bzr.dev for a bit; I still have to deal with the conflicts there
<lifeless> poolie: I wouldn't say its hard, just not done
<lifeless> poolie: and as I count I have 8 days to land this and stacked
<lifeless> ><
<poolie> sure
<lifeless> I pity the reviewer
<lifeless> (say it like mr T)
<beuno> mwhudson, does the code look small to you to?
<mwhudson> beuno: yes
<beuno> good
 * beuno pops the CSS open
<mwhudson> i probably bungled the css somewhere
<beuno> all fonts seem different
<beuno> the revision info block is bigger
<mwhudson> beuno: yeah, it's a bit odd
<poolie> spiv, you should tweak and merge http://bundlebuggy.aaronbentley.com/request/%3C20080602011607.GA27779@steerpike.home.puzzling.org%3E
<mwhudson> oh man, how do i check that these six incomprehensible urls are the same on the two pages
<mwhudson> beuno: how are you enjoying the css?
<beuno> mwhudson, I'm crying
<mwhudson> oh dear
<beuno> mwhudson, I've went ahead and started to convert the new theme to HTML, even though we're changing it a bit later on
<beuno> just so we can use it ASAP
<beuno> that's how bad it is  :)
<mwhudson> heh
<mwhudson> i would _hope_ we can fix the differences in zpt-templating with less effort than that
<mwhudson> afk for a few
<beuno> alrighty, I'm back to making sense out of the CSS
<lifeless> FINALLY
<mwhudson> beuno: would you like to skype about this?
<lifeless> old knit code deleted, full test run going
<mwhudson> lifeless: hurrah
<beuno> mwhudson, sure, opening it up now
<mwhudson> beuno: read and weep http://bazaar.launchpad.net/~mwhudson/loggerhead/zpt-templating/revision/232
<bud3030> Just had a pc to break couple of wires in the box was little hot
<flint_dude> not able to fix it this late
<beuno> mwhudson, fixed the diff view, trying to figure out the revision info
<mwhudson> beuno: great
<poolie> mwhudson: could you sometime send a patch to add a pydoctor makefile target for bzr?
<mwhudson> poolie: sure
<poolie> is "pydoctor --make-html bzrlib --add-package=bzrlib" about right?
<mwhudson> --make-html doesn't take an argument
<poolie> oh right
<mwhudson> it's --make-html --html-output-dir bzrlib or something
<mwhudson> these days i mostly use pydoctor --server --add-package bzrlib
<beuno> mwhudson, emailed you the patch to fix all the CSS oddness I could find
<mwhudson> beuno: looks good to me
<beuno> :)
<mwhudson> i mean, the css looks pretty nasty, but that's nothing new
<beuno> my head will work for about an hour more. Anything else I missed to get this into trunk?
<mwhudson> nope, don't think so
<mwhudson> i'm going to do a good chunk of diff reading and then merge it
<beuno> good, I'll work on the nicer-urls branch, and stick around if you run into anything you need me to fix
<mwhudson> ok
<poolie> mwhudson: there doesn't seem to be a --server option
<poolie> at least in the version in hardy
<beuno> mwhudson, and just sent you an email with what we'll be working with
<mwhudson> poolie: well, i only made the "release" that that package is based on under mild protest
<mwhudson> poolie: bzr get lp:pydoctor
<poolie> ok
<mwhudson> i'm probably not that far off making a release that i'm actually happy with, come to think of it...
<lifeless> 7K passing
<lifeless> keep thy fingers crossewd
<poolie> mwhudson: is there a way to make it just print the warnings?
<mwhudson> poolie: maybe, the whole 'what gets printed' stuff is a bit over engineered in pydoctor
<mwhudson> poolie: which warnings do you mean?
<poolie> rest syntax errors etc
<mwhudson> if you add a -v do the command line you'll get more information about them
<mwhudson> add two and you'll get even more
<mwhudson> (and a lot of other stuff i expect)
<poolie> yeah it's all the other stuff about every module being imported that is undesirable
<mwhudson> try --verbose-about epydoc2stan
<poolie> ah
<poolie> there is also the issue that our docs are mostly in rest not epydoc
<mwhudson> --docformat restructuredtext
<poolie> oh great
<poolie> :)
<mwhudson> you can make a config file with lots of this stuff in
<mwhudson> this is the one used for the online docs: http://python.net/~mwh/mybzrlib.cfg
<mwhudson> warning: restructuredtext parsing is about 5 times slower than epytext parsing...
<poolie> mm, so i see!
<lifeless> yes yes yes yes yes yes yes yes yes yes yes
<lifeless> Ran 11009 tests in 1359.977s
<lifeless> OK (known_failures=10)
<lifeless> 681 tests skipped
<poolie> way to go
<poolie> btw is spiv around today? maybe just quiet?
<lifeless> he's around
<lifeless> time for bzr send
<lifeless> hahhaha 800K bundle
<spiv> I'm around.
<poolie> hello spivvo
<lifeless> I'm gonig to take a short break (lunch, and do something to take my mind out of the details)
<lifeless> then I'll merge bzr.dev
<mwhudson> yay for bugs in loggerhead trunk
<poolie> down to 8 pending reviews
<poolie> i'm going to take a break too
<beuno> mwhudson, I python2.5 slipped into your branch too, in start-loggerheat.py
<beuno> it seems I committed my testing values at some point, sorry  (commenting out the daemon was the other)
<mwhudson> ah, right
<beuno> so, we can go with plain python
<beuno> or stick to 2.5/2.4 in both
<mwhudson> let's not make this change in this branch
<beuno> fair enough
<beuno> I'm still resolving the remaining 4 conflicts out of 22 from merging my url-cleanup branch to trunk
<mwhudson> i'm still fighting url details a bit
<beuno> what do you mean?
<mwhudson> beuno: click one of the 'changes' links in the table on http://bazaar.launchpad.net/~bzr/bzr/trunk/files
<beuno> mwhudson, right, I reported that as bug #238477
<ubottu> Launchpad bug 238477 in loggerhead "View revisions that affect file doesn't work" [Undecided,Confirmed] https://launchpad.net/bugs/238477
<mwhudson> oh ok :)
<mwhudson> well, that's fixed in zpt-templating now
<mwhudson> but checking all sorts of stuff like that
<beuno> mwhudson, that was just a problem with the URL?
<mwhudson> yeah
<mwhudson> beuno: i merged the branch and am pushing to trunk
<beuno> mwhudson, great!
<beuno> I'll merge my clean-url branch with that, and send a bundle for it. It seems pretty decent now
<mwhudson> sounds good
<lifeless> beuno: bzr-search can now index bzr.dev
<beuno> lifeless, time?
<lifeless> same, 20s
<lifeless> but it can report on the results now :P
<beuno> hahah
<lifeless> 0.7 seconds to query
<lifeless> in theory it will scale better
<beuno> well, that's more than usable today
<lifeless> lunch is nearly over, I'm going to test indexing python now
<beuno> actually, in loggerhead's terms, it's amazingly fast
<lifeless> 60K commits
<lifeless> python-packs$ time bzr index
<lifeless> real    1m9.116s
<lifeless> user    0m51.147s
<lifeless> sys     0m6.468s
<lifeless> give me a search query
<beuno> bzr search the
<lifeless>  time bzr search Robert Collins
<lifeless> bzr: ERROR: No matches were found for the search [u'Robert', u'Collins'].
<lifeless> real    0m2.536s
<lifeless> user    0m0.368s
<lifeless> sys     0m0.084s
<beuno> :)
<lifeless> so, the turns up a lot
<lifeless> my screen is paging and paging :P
<lifeless> I've stopped it
<beuno> hahaha, well, it works!
<lifeless> time to first line is more interesting
<lifeless> time bzr search the | head -n1
<lifeless> Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:43495'. Summary: 'Bug #1445068: getpass.getpass() can now be given an explicit stream'
<lifeless> bzr: broken pipe
<lifeless> real    0m6.195s
<lifeless> user    0m5.840s
<lifeless> sys     0m0.140s
<lifeless> I can tell you why that is as well
<lifeless> the 'the' posting list is going to be freaking long
<lifeless> so the shortest-list it can give results from it reads fully at the moment
<lifeless> this will get worse when documents are indexed
<lifeless> it probably wants to iterate there
<lifeless> and use concurrent iterators across all keys or some such
<lifeless> this needs bzrlib core changes, which I posted about in the context of pack performance today
<lifeless> still:
<lifeless>  time bzr search "Lange"
<lifeless> Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:36422'. Summary: '[Patch #945642] Fix non-blocking SSL sockets, which blocked on reads/writes in Python 2.3.'
<lifeless> Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:25536'. Summary: 'add SSL class submitted by Tino Lange'
<lifeless> real    0m0.538s
<lifeless> user    0m0.332s
<lifeless> sys     0m0.108s
<lifeless> this is pretty fun
<lifeless> I might blog about it tonight
<beuno> I'm going to try and make it work with Loggerhead tomorrow
<lifeless> awesome
<lifeless> k, thats my hour, time to merge bzr.dev :P
<beuno> have fun
<lifeless> indices are fairly large btw:
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh .bzr/bzr-search/
<lifeless> 55M     .bzr/bzr-search/
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh ../.bzr/repository/
<lifeless> 99M     ../.bzr/repository/
<beuno> I'd check to see how much loggerhead's are, but I need my cpu for the next hour
<lifeless> :P
<beuno> 55M doesn't seem that bad for 16k revision text indexed, especially if it's that fast
<lifeless> thats better
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh .bzr/bzr-search/ --apparent
<lifeless> 6.1M    .bzr/bzr-search/
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh ../.bzr/repository/ --apparent
<lifeless> 99M     ../.bzr/repository/
<lifeless> it was all allocation overhead
<lifeless> when I shove it into packs it will be that big
<beuno> :)
<lifeless> poolie: is API CHANGES replacement for API BREAKS ?
<gour> what is this 'bzr search' stuff? something new in 1.6?
<lifeless> gour: its a plugin I wrote on the weekend
<gour> lifeless: it looks cool. something like 'darcs changes' or ?
<lifeless> I don't know what darcs changes is
<lifeless> is darcs changes something like bzr search?
<Peng> lifeless: FWIW, your mailing list message went through.
<lifeless> Peng: thanks
<gour> lifeless: "Gives a changelog-style summary of the repository history" with ability to 'grep' on tags, patches...
<lifeless> gour: no, not really then. its a full text index, (though it currently only indexes the commit messages)
 * gour is inspecting bzr-search on LP
<lifeless> it won't eat your data :P you can install it and play :)
<gour> i just wanted to ask if it eats data ;)
<lifeless> man I hate conflicts. bzr.DWIM
<beuno> mwhudson_, any reason for "kw['start_revid'] = start_revid" in controllers/revision_ui.py?
<beuno> I think it has something to do with what you fixed
<beuno> but it broke my clean-urls branch
<mwhudson_> uh, i forget
<mwhudson_> it's probably not essential
<beuno> I'll triple check
<beuno> just wanted to know if I was missing something obvious
<beuno> running start-loggerhead.py twice makes you loose control of it, and you have to kill -9 it
<beuno> we should probably do something more sensible there
<gour> lifeless: what support do you plan for TERM? regex?
<lifeless> words
<lifeless> possibly phrases
<gour> wildcards?
<lifeless> I have some literature searches to do (though I have some probably naive ideas on that)
<beuno> mwhudson_, everything seems to work fine. I'm going to send my patch with that removed. Just FYI
<mwhudson_> beuno: cool
<lifeless> uhm, wild cards, like stemming (and regexs-to-match-one-term) can be done if someone wants to
<gour> lifeless: boolean searches?
<mwhudson_> what does annotate say about that line?
<lifeless> gour: yah, it is a simple boolean at the moment, every term is AND
<lifeless> to do wild cards, its basically search the term list for matching terms with the wildcards, then do a boolean on that
<gour> lifeless: it just needs some good parser and then it can search everything ;)
<lifeless> gour: do you mean 'it needs to get terms from file texts and so on' ?
<lifeless> gour: because if thats what you mean, its definitely planned, see DESIGN.
<lifeless> there are some complications the more you think about it - given we're dealing with versioned data, what hits are most useful and so on
<gour> lifeless: no, i meant something like mairix's syntax which is, afaik, used in e.g. claws-mail
<gour> mairix is quite fast
<lifeless> oh
<mwhudson_> beuno: that kw stuff looks like super old code
<gour> although, afaik, no utf-8 support
<beuno> mwhudson_, 167.2.12
<lifeless> so the syntax you can support is driven by your back end
<beuno> 2007-08-23
<lifeless> I don't have big plans for this, I wrote it because it seemed like an interesting thing to do
<mwhudson_> beuno: that just changed the indentation
<lifeless> I'll happily hand it over to someone, or review patches that improve it
<gour> lifeless: it could be quite useful
<lifeless> but i'm not sure I'm going to spend hours on it
<beuno> mwhudson_, well, than yes, it's *super* old  :)
<lifeless> gour: sure, it is already :P
 * gour thinks that using mairix could be interesting
<lifeless> doesn't look like a good fit TBH
<lifeless> we have very specific constraints on same management of data to work with FTP etc servers
<gour> 'marix-like' i wanted to say...mairix is for email
<lifeless> oh well, feel free to dive in :P or file detailed feature requests.
<gour> sure, let me explore present solution 1st
<lifeless> ('be mairix like' means nothing to me. "Support '-foo' to exclude documents matching foo" does)
<lifeless> ok merge done, running tests to see what broke
<gour> lifeless: right, let's say, using syntax similar to the one in mairix, explained under "Match words" in man page
<lifeless> gour: I don't have mairix, I don't plan to install it. I'm not trying to be stubborn or anything but referencing something I don't have and don't use *doesn't help*
<beuno> mwhudson_, I have a few more quirks to work out on my branch since the merge with trunk. I'm going to defer sending til tomorrow, when I'm more awake
<mwhudson_> beuno: sounds good, i'm not awake enough to read it today anyway :)
<lifeless> (because everyone can point at their favourite and say 'be like that'). I could spend ages just reading them all. But there are more users than authors for bzr-search (already :P)
<lifeless> so I think it makes sense for the larger group, which has the requests, to do the effort of creating specific suggestions
<lifeless> in particular, things like 'what is it about mairix's search language you like'
<gour> the biggest win is that it's very fast
<lifeless> indeed, that is a useful thing :)
<gour> here is some simple example of the syntax http://rafb.net/p/4kdE6G75.html i'm just saying as idea, not that it has to be like that at all...i.e. support for boolean (and, or, not) and some wildcarding would be enough
<lifeless> I think I prefer the google style language
<lifeless> where everything is AND
<lifeless> to do not you do -TERM
<lifeless> (giving AND NOT)
<beuno> I'm off to bed
<lifeless> anyhow, it sounds like you are really saying "I want more than exact word searches"
<beuno> mwhudson_, great marathon today. Congrats on getting trunk in better shape  :)
<gour> how do you handle rebuilding of the index?
<lifeless> which is fair enough - but like I said, I'm doing this to scratch my own itches at the moment, which is mainly about the challenge of the thing
<lifeless> what rebuild
<lifeless> :P
<lifeless> more seriously, the disk format is logically done now, but the individual elements of an 'index component' are in separate disk files rather than a single pack file
<gour> what about OR? or it is done by running two queries one after another?
<beuno> aaaaand another reason why commit messages are immutable: it wouls break bzr-search  :p
<beuno> s/wouls/would
<lifeless> incremental index operations generate additional components
<lifeless> and I'll use a bog standard exponential backoff to combine components to amortise time-to-insert and time-to-query
<gour> that's good
<lifeless> it has no OR support today, but yes, to do or I would expect serial queries inside the engine with a union
<gour> btw, what follows after bzr-1.9? 1.10?
<lifeless> yah
<lifeless> its just a serial
<gour> will 1.6 release consider guadec conference and gnome needs?
<lifeless> I sure hope so
<gour> yesterday i was reading about imendio plans to push gtk-3.0 out...too bad, they're on git already
<lifeless> poolie: ping
<poolie> lifeless: pong
<lifeless> want a quick call before EOD?
<poolie> sure
<lifeless> poolie: if you are still around the updated patch is in the moderator queue
<lifeless> holy cow
<lifeless> I strongly suspect this is as long a slope as bzr itself...
<mwhudson> ?
<lifeless> bzr.dev$ time bzr search VersionedFiles
<lifeless> File id 'versionedfile.py-20060222045106-5039c71ee3b65490', revision 'robertc@robertcollins.net-20070921013648-i9w180g6ea73w9mf'. Summary: 'No summaries yet.'
<lifeless> File id 'fetch.py-20050818234941-26fea6105696365d', revision 'andrew.bennetts@canonical.com-20070821235535-37okm0uaprwku9cu'. Summary: 'No summaries yet.'
<lifeless> ...
<lifeless> real    0m0.501s
<lifeless> user    0m0.420s
<lifeless> sys     0m0.076s
<mwhudson> nice
<lifeless> mwhudson: that is, I just implemented a crude index-file-texts patch for bzr-search
<mwhudson> that must bump up the indexing time quite a lot?
<lifeless> $ du -sh .bzr/bzr-search/ --apparent
<lifeless> 44M     .bzr/bzr-search/
<lifeless> real    5m53.305s
<lifeless> user    4m2.547s
<lifeless> sys     0m14.733s
<lifeless> and 545MB of memory at peak
<mwhudson> huh, not bad
<lifeless> thanks
<lifeless> without --apparent, 316M of disk in the index :P. Really must put them into packs.
<lifeless> probably can improve things by doing a two-phase task
<lifeless> 40K terms, or so
<lifeless> make that 73K
<lifeless> revno 21 if you feel tempted to, say, index launchpad ;P
<lifeless> "boom"
<mwhudson> i think i'd like to be able to use my machine for a little while longer :)
<lifeless> you could index, say, twisted. for fun.
<mtaylor> I don't know if this is a bzr or launchpad thing - but I think bzr since the output looks like it's just bzr log reworked...
<mtaylor> if you look at https://code.launchpad.net/~mysql/mysql/mysql-5.1-telco-6.3
<lifeless> go on
<mtaylor> all you see are a bunch of merge changesets, without any idea of what went on beneath them...
<pygi> lifeless, your plan to conquer the world by sending a mail to m-l did not work :p
<lifeless> pygi: I know, so I sent another
<lifeless> mtaylor: thats an lp thing, because bzr log does know and shows the indented merge
<mtaylor> hm. oh you're right... it's missing that doesn't show them, right?
<lifeless> yah
<mtaylor> k. thanks.
 * mtaylor goes to bug launchpad
<mwhudson> it's known
 * mtaylor aborts mission to annoy launchpad
 * mwhudson clicks browse code and wonders if that was a good idea
<mtaylor> any time anybody wants a good will-this-work-quickly? testcase, doing stuff with the mysql trees seems to be a good place to start :)
<lifeless> mtaylor: yah
<mwhudson> how big is the tree?
<lifeless> mtaylor: how much ram do you have ?
<mtaylor> big tree
<mtaylor> I have 3G
<lifeless> you might like to try bzr-search out then
<lifeless> I'd be interested to know how badly it fars
<mtaylor> ooh. yes, I might.
 * mtaylor goes to try it
<mtaylor> anything specific I should try to give you good feedback ?
<lifeless> well
<lifeless> rev 21 adds full text indexing
<mtaylor> so "bzr index" should make the indexes, right?
<mwhudson> mtaylor: roughly how many files?
<lifeless> so try with rev 20, (time bzr index), and them rm -rf .bzr/bzr-search, and try with rev 21
<mtaylor> ok
<lifeless> bzr search term [term ...] performs a search
<lifeless> currently case sensitive
<mtaylor> can you do bzr search "term with spaces" ?
<lifeless> not yet
<lifeless> I need to do some reading/thinking
<lifeless> I imagine there are canned answers for that in the field
<mtaylor> probably so
<mtaylor> running index using r20 now
<mtaylor> without fulltext - real	0m59.664s
<mtaylor> mwhudson: 9600
<mtaylor> mwhudson: but around 60k revisions
<mwhudson> mtaylor: so pretty big but not huge
<mtaylor> correct
<mwhudson> ~3 times the size of launchpad
<lifeless> I should note
<mwhudson> nothing insane like OOo :)
<lifeless> this is not in any way optimised today
<mtaylor> mwhudson: a fresh branch normally takes around 25 minutes
<mtaylor> lifeless: that's fine :)
<mwhudson> mtaylor: in a repo?
<lifeless> its not completely-stupidly-naive
<mtaylor> mwhudson: well, the first time
<lifeless> does mysql have fulltext-and-phrases search indices?
<mtaylor> well, fulltext indexes
<mwhudson_> grr
<mtaylor> I'm not sure it does phrases
<mwhudson_> mtaylor: in a repo? <- last thing i said, dunno if it got through
<mtaylor> mwhudson_: yeah - but the first time - subsequent branches, of course, are not bad
<lifeless> so my first idea for phrases is an adjaceny graph
<mwhudson_> ok
<lifeless> start by getting candidates for simple AND
<mtaylor> mwhudson_: I think the biggest problem with that is the non-updating status bar bug
<lifeless> then look for term, term in an adjacency graph for that
<mtaylor> mm
<mtaylor> that sounds reasonable
<lifeless> tats about 40 seconds worth of thought in the weekend
<mtaylor> hehe
<mtaylor> well, if you want to look at other work in the field, definitely check out sphinx search
<lifeless> yeah
<lifeless> I was pointed at that
<lifeless> seems interesting, but only the search api seems to be python accessible
<mtaylor> hm. I wonder how hard it would be to embed...
<mtaylor> dang it
<lifeless> :)
<mtaylor> now you've got me thinking about YET ONE MORE project
<lifeless> thing for me is I want this to run over the bzr vfs
<lifeless> which means being safe on a small set of IO primitives
<lifeless> and having their back end talk back to python
<lifeless> it all seemed rather uninteresting, so I wrote an engine instead :P
<lifeless> mtaylor: so, whats the memory use up to ?
<lifeless> so mwhudson when are you getting a internet connection ?
<lifeless> mtaylor: has the fulltext run started thrashing yet ?
<radix> lifeless: have you written than indexer yet
<radix> is that what mtaylor is testing
<radix> s/than/that/
<lifeless> radix: https://launchpad.net/bzr-search/
<awilkins> How's the XMLRPC server thnig going?
<lifeless> awilkins: verterok might know
<awilkins> I just reverted two revisions and commited them as one but I still have one hanging around as a pending merge, how can I get rid of it?
<mwhudson> revert has a --forget-merges option or something, but i don't really undestand the question
<awilkins> mwhudson: That was the right answer though :-)
<awilkins> I uncommitted two revisions, then committed the changes from those two revisions as one revision ; it retained the merge marker for one of those revisions which caused problems
<awilkins> Gah, still got problems though
<fullermd> Er.  That really shouldn't happen...
<awilkins> It seems stuck now... it won't push to a branch it really should be pushing to without complaint "have diverged"
<awilkins> I don;'t hink I did anything bad....
<awilkins> \All I did was hand-merge  some changes from the bzr-gtk plugin windows install and commit them
<mtaylor> lifeless: it wound up eating all my RAMs
<lifeless> mtaylor: yah
<lifeless> mtaylor: I suspected it might :P
<mtaylor> hehe
<lifeless> let me put a quick 'batch by 5000' in there
<mtaylor> well, you were correct!
<spiv> awilkins: perhaps "bzr missing" will help
<lifeless> mtaylor: I'm just acceptance testing this patch
<lifeless> 225MB peak
<lifeless> thats much more tolerable
<mtaylor> yes. much more!
<lifeless> when it finishes I'll see if the performance blows chunks or not (it doesn't have the grouping-logic done yet
<lifeless> also, the heuristic I'm using - 5K commit - is not that suitable for very wide trees
<lifeless> possibly I should instead use 200 or something ;P
<lifeless> 273 mb resident now
<lifeless> ok, 4m47 to index
<lifeless> now to search
<lifeless> yeah, performance has been hit, largely disk cache I think, but all the same -
<lifeless> 133505 files
<lifeless> I have a plan for that - incremental development FTW
<mtaylor> hehe.
<mtaylor> I just told someone yesterday "oh yeah, you need this patch I'm working on right now to do that..."
<lifeless> ok, pull, rev 22
<mtaylor> k
<mtaylor> running
<lifeless> please keep an eye on top
<mtaylor> yup
<lifeless> I'm very interested in memory
<mtaylor> up to 500m resident
<mtaylor> seems to be holding steady at 506m
<mtaylor> nope
<mtaylor> 602
<lifeless> if you want to tweak this, in index.py look for 5000
<mtaylor> 650
<mtaylor> ok
<lifeless> but see how it goes first
<lifeless> large trees do imply large developer machines :P
<mtaylor> you'd think :)
<mtaylor> 725
<matkor> Hmm how can I get info about given revision (342.29.1) who did it ? when etc ?
<lifeless> matkor: bzr log -r 342.29.1
<lifeless> mtaylor: once it starts the progress bar 0...5000 again it will be roughly stable
<mtaylor> 1000
<mtaylor> it's going to start another status bar?
<lifeless> you have 3 :P
<lifeless> it does a progress bar for each group of 5K
<lifeless> I haven't really done a UI for this, beyond proof-of-capability
<mtaylor> so, what's it doing before that status bar is displayed?
<lifeless> well
<lifeless> at the start it finds what revisions to index
<lifeless> then it topo sorts them
<lifeless> groups by <size>
<lifeless> then for each group it makes a new component index
<lifeless> reads the inventories (this shows the progress bar) for those commits
<lifeless> reads the lines introduced (roughly) by those commits
<lifeless> and then reads the commit messages
<lifeless> writes that component out
<lifeless> and loop
<mtaylor> I seem to be stable at around a gig so far
<mtaylor> and it's just making kcryptd work now
<mtaylor> which, I suppose, one would expect with an encrypted root partition
<lifeless> :P
<lifeless> so its flushing an index probably
<lifeless> my entire drive is enrypted
<lifeless> now - the posting lists for each term are a separate index
<lifeless> this creates hundreds of thousands of files for me with the 5K group
<lifeless> I hope you have btrees enabled for your file system :)
<mtaylor> hehe.
<mtaylor> nope
<mtaylor> plain-ol ext3
<lifeless> ext3 has btrees
<lifeless> uhm dirindex or something the option is called
<mtaylor> but not unless I've enabled them, right?
<lifeless> how old isyour install, what distro
<lifeless> (as in, what distro install CD created your file system)
<mtaylor> ubuntu. hardy - reinstalled from scratch  a couple of months ago to get the encrypted root
<lifeless> you'll be fine :)
<mtaylor> so, hardy alt cd
<mtaylor> ok
<lifeless> stable ?
<lifeless> (I mean, is it stable at 1G ?)
<jelmer> Peng, do you know if mercurial has something like "bzr send" ?
<spiv> tune2fs can tell you what options are set on your ext2/3 partition, e.g. "tune2fs -l /dev/sda3 | grep features"
<lifeless> mtaylor: (I mean, is it stable at 1G ?)
<mtaylor> lifeless: yes. it seems to be stable
<mtaylor> ooh!
<mtaylor> and I've got status bar now
<lifeless> right, its doing another group
<mtaylor> well, I had a status bar for a short time
<lifeless> its almost certainly done that quite a few times
<mtaylor> the bit with the status bar seems to be the quick bit. :)
<lifeless> :P
<lifeless> how many mb is the .bzr/repository ?
<mtaylor> lifeless: 635M
<toyto1> hello lifeless, this is possible 'bzr commit -m "My Message" > filename.txt'?
<lifeless> so, I would geuss at 1 hour or so to index
<lifeless> toyto1: what would you like that to do ?
<toyto1> lifeless: let's say viewing the files that you have commited, like if you'll notice the 'bzr commit' it will open the default editor right?
<lifeless> yes
<toyto1> instead of viewing that editor i want to make it a file instead of a log file or let's say i use 'bzr commit -m "my message" > file.txt so that file.txt can be used as my backup for files that had been in the trunk
<toyto1> or is there a way for bzr commands to list the files inside a trunk?
<toyto1> let's say 'bzr filelist' will list the files or it can be 'bzr filelist > file.txt'
<lifeless> bzr ls
<lifeless> bzr ls URL
<lifeless> bzr ls -r X URL
<toyto1> thank you lifeless, may i kow what's the -r means?
<lifeless> toyto1: its used to specify revisions
<lifeless> toyto1: I recommend you read our user guide
<toyto1> lifeless: ah thanks, yeah i was reading the user guide but I didn't notice reading it :( never had that idea yet
<lifeless> mtaylor: can you do find .bzr/bzr-search/indices -name "*.rix"
<Pieter> does bzr search work with large repositories yet?
<mtaylor> Pieter: that's what we're testing :)
<Pieter> ah
<mtaylor> lifeless: I get 6 results
<Pieter> is it in the branch now? or do you need changes in bzr.dev?
<mtaylor> Pieter: branch. I just pulled it off launchpad
<Pieter> let's try it then :)
<mtaylor> if you have a large repo - it's not quick to index :)
<Pieter> I'll try on emacs
<mtaylor> Pieter: lp:bzr-search
<mtaylor> Pieter: emacs is in bzr now?
<Pieter> mtaylor: yeah, I already have it
<toyto1> lifeless: I have found a good user guide it's 'bzr help commands' :D
<Pieter> mtaylor: no, they're switching
<mtaylor> sweet!
<Pieter> mtaylor: but someone imported their cvs in bzr and made it public
<lifeless> mtaylor: its completed 30K revisions then
<mtaylor> well, then I shoujld be done in another hour or so then
<lifeless> Pieter: its /functional/ on larger repos now
<lifeless> Pieter: how much ram do you have, and how many files are in the emacs repo ?
<Pieter> lifeless: 2GB RAM
<Pieter> let's see how many files
<Pieter> 3000 files, 89000 commits
<lifeless> K
<lifeless> you should be fine
<Pieter> it's still cloning though
<lifeless> you don't have a copy alrady ?
<Pieter> yeah, but I didn't want to use my pristine clone :)
<lifeless> it writes to .bzr/bzr-search only
<lifeless> check BUGS out for current caveats
 * mgedmin hugs everyone
<mgedmin> bzr is reading my mind again
<mgedmin> and working just the way I want it to work
<lifeless> cool
 * mgedmin discovered that "bzr push" and "bzr merge" remember the last location separately
<Pieter> lifeless: what does it currently index
<Pieter> ?
<lifeless> commit messages and file contents
<lifeless> its pretty basic stuff
<lifeless> lots of obvious room for improvement
<lifeless> the biggest actual caveat today is that it creates hundreds of thousands of files
<lifeless> because I haven't written a transport adapter to allow the index layer to read an index from within a .pack file
<lifeless> which I will get around to pretty soon
<lifeless> the main impact of that is that you have to have dirindex on on ext3 to have it work well :)
<Pieter> :)
<lifeless> it also badly needs some ui love
<Pieter> won't do wonders on my hfs then :P
<lifeless> like overall progress during indexing
<lifeless> uhm, should be ok I imagine. Well - even though its a known defect feel free to report a bug if it blows horrible chunks
<lifeless> if you want a teaser without the file text content searching, revert to revision 20, which only indexes commit messages
<lifeless> (it has to do less, so obviously is a lot faster)
<Pieter> I tried that some time ago, but then it crashed somewher in bisect in bzr
<lifeless> 'bzr revert -r XXX' ?
<Pieter> I meant the index
<lifeless> oh right
<lifeless> revno 20:
<lifeless> message:
<lifeless>   New disk format, one step closer to being in packs, and fixes the issue with overflowing bzrlib's index bisection capabilities.
<Pieter> :)
<lifeless> (I knew going it would fail on big environments till I built up additional capabilities, but I wanted early-results so took an incremental approach)
<lifeless> all the mundane framework stuff like basic ui, format marker, open/close/create etc
<lifeless> thats all in place, so actual changes now can deliver real improvements (like the full text stuff, which was about 40 minutes to do)
<lifeless> s/full text/file text/
<lifeless> anyhow, feedback appreciated
<lifeless> if it chews ram (I would expect about 600MB stable for your tree) let me know - file a bug
<lifeless> performance too
<lifeless> mtaylor: welcome back
<lifeless> mtaylor: how many .rix now ?
<lifeless> Pieter: I'm just pushing a patch to drop the batch size to 2500 revisions, you may prefer that - less memory pressure
<lifeless> it will degrade search performance until I write the batch-combining logic
<lifeless> (or someone sends me a patch :))
<mtaylor_> lifeless: my machine is taking a very long time to answer that question
<mtaylor_> oh, and bzr is up to 1.2G
<lifeless> mtaylor_: dentry cache :)
<lifeless> mtaylor_: you will have _many_ files :)
<mtaylor_> hehe
<lifeless> actually
<lifeless> I was being nub
<lifeless> cat .bzr/bzr-search/names
<lifeless> thats the root node
<lifeless> each line is a block of batch_size (e.g. 5K) revisions
<lifeless> (actually its arbitrary size revisions, but your version only writes in one group size)
<Pieter> lifeless: memory pressure is fine so far -- no more than 350MB
<lifeless> Pieter: ok cool; its proportional to (term_count * document_references) per batch
<lifeless> well, I say proportional, thats the key driver
<Pieter> I wonder how big the index will be
<lifeless> so lots of small changes will use less memory than lots of big changes
<Pieter> the repo itself is 300MB
<lifeless> use du --apparent
<lifeless> the next stage will combine all the little files
<lifeless> by writing them end to end in a big single file
<lifeless> (next stage of development)
<lifeless> I would expect, 200MB or something
<lifeless> heres the one for bzr
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ find .bzr/bzr-search/ | wc -l
<lifeless> 133505
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh .bzr/bzr-search/
<lifeless> 549M    .bzr/bzr-search/
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh .bzr/bzr-search/  --apparent
<lifeless> 50M     .bzr/bzr-search/
<lifeless> robertc@lifeless-64:~/source/baz/bzr.dev$ du -sh ../.bzr/repository/ --apparent
<lifeless> 99M     ../.bzr/repository/
<lifeless> (../.bzr/repository is the shared repository containing all my branches)
<Pieter> my du doesn't have apparent
<Pieter> it's at 400k files so far
<lifeless> oh
<lifeless> well
<lifeless> the posting lists are generally very small
<lifeless> I forget the distribution name, its the one for use of words in programming languages :)
<lifeless> Pieter: mtaylor_: gnight
<Pieter> see ya
<lifeless> please do let me know (email to the list or a bug report in launchpad)
<lifeless> how it goes
<lifeless> oh
<lifeless> for reference
<lifeless> its subsecond to start outputting hits for most every search I do on bzr.dev.
<Pieter> I think I'm going to stop it and wait until it's a single-file thing
<Pieter> it's just doing disk trashing now
<lifeless> do you lurk here?
<lifeless> I can ping you when it is
<Pieter> yes
<lifeless> k, I will do that then if you like
<Pieter> yeah, thanks
<lifeless> no problems
<lifeless> good night
<mtaylor_> I know this is off-tope
<mtaylor_> I know this is off-topic
<mtaylor_> nm
<ricardokirkner> hi, I am having an issue with bzr running as a smart server under wsgi. the error I am getting is: 'module' has no 'ElementTree' attribute.
<ricardokirkner> this is happening when trying to open the bzr shared repository
<ricardokirkner> the server is using bzr 1.5 while the client is using 1.3
<ricardokirkner> any ideas? I managed to trace a possible location for that problem to the xml_serializer.py file, where there is an import elementtree which falls back to the elementtree implementation of python2.4 which does not have the ElementTree attribute, but after changing that specific line, the problem is still there, so I am still trying to figure out where the problem is
<maanskyn> does anyone here have any experience with loggerhead?
<trepca> hey
<trepca> is there any support for attribute insertion as in subversion where you inserted "$Revision: $" which was then replaced with actual revision on commit ?
<statik> jam: do we have a bzr logo like the one on bazaar-vcs.org but without the blue background?
<jam> statik: http://bazaar-vcs.org/LogoOptions
<jam> It comes in an SVG
<jam> or a bunch of .png sizes
<statik> jam: thanks!
<jam> statik: btw, looking forward to what comes out of that :)
<statik> me too
<ricardokirkner> has anyone successfully integrated bzr with trac for multiple projects using http authentication for both read and write? (I am facing several difficulties here)
<jelmer> ricardokirkner: read/write in trac is unrelated to trac-bzr - or do you mean something else?
<ricardokirkner> sorry, yes
<ricardokirkner> I think the trac part is irrelevant here
<ricardokirkner> what I am trying to achieve is to have bzr use apache's authentication plugins (like for example ldap, which I already have working)
<ricardokirkner> the thing is: authentication works ok (it doesnt depend on bzr)
<ricardokirkner> but the integration through mod_<something> is not working correctly
<jelmer> ahh, ok
<ricardokirkner> first I tried mod_python, but I got some issues that according to my research were due to mod_python
 * jelmer doesn't have much experience with bzr and apache
<ricardokirkner> so I tried to use mod_wsgi, and I am still having issues (very strange ones)
<ricardokirkner> regarding 'module' has no 'ElemenTree' attribute, when trying to open a repository
<ricardokirkner> but this does only happen when I try to open the second project's repository
<ricardokirkner> the first open works ok
<ricardokirkner> and if I restart apache and try the other way around, the same thing happens, but with the projects reversed
<emilis_info> is it possible to commit a file to an older revision that has already been committed?
<mtaylor> emilis_info: no
<emilis_info> heh :/
<mtaylor> emilis_info: you can uncommit, and then redo the commit
<mtaylor> but a commit is a commit
<emilis_info> I understand that, but that would require me to uncommit a few revisions back...
<mtaylor> yeah. then you're pretty much screwed. :)
<emilis_info> the files in these revisions are completely independent
<emilis_info> doh, I guess I'll just do another commit
<emilis_info> :)
<mtaylor> emilis_info: well... you could branch your current branch into a different place up until that revision
<mtaylor> emilis_info: then in the new branch, you could uncommit the last rev, then recommit adding in your new file
<mtaylor> then you could merge your other changes in maybe...
<mtaylor> but it might get ugly
<mtaylor> you probably should not do ^^
<emilis_info> seems really ugly from your description :)
<fredreichbier> anybody here who uses bzrweb from http://vmlinux.org/jocke/bzr/index.py?
<gour> i need some advice what kind of workflow to use with bzr
<gour> atm i used darcs for one project - study notes...
<gour> there are few courses, each has several written assignments with some questions. we could say project with few componenents, each having few features
<gour> i plan to create shared repo and would like to work on specific 'component' and then merge to the main 'trunk' by having clear history
<gour> do you suggest to create branch for each 'feature' (question) and when i finish with it, then to merge back to main trunk and discard 'working' branch?
<pickscrape> Sounds like you're talking about partial tree branches, or whatever it's called
<gour> hmm, dunno
<pickscrape> Currently when you branch you branch the whole tree, and your working copy contains that whole tree
<gour> in darcs i can cherrypick patches and push them to the main trunk keeping the history clear and after finishing with the 'feature' i can easily dismiss unwanted branch.
<pickscrape> Sounds a bit like rebase?
<gour> i do not mind having the whole tree, but to have somewhat clean history in the 'main'
<gour> hmm, no experience with git, but can take look at bzr's rebase
<fullermd> That ["do you suggest..."] sounds like what I'd do...
<gour> fullermd: thanks
<Leonidas> gour: what do you mean by "clear history"?
<Verterok> moin
<james_w> hi Verterok
<Verterok> hi james_w
<fdv> Hi. Does anybody know whether it's possible to push a set of revisions as one to an svn repo?
<Odd_Bloke> fdv: As a single revision, or all at the same time?
<Odd_Bloke> Both are possible, but require different methods.
<fdv> Odd_Bloke: as a single revision
<fdv> then I don't necessarily have to have my code in a completely good state for small commits
<Odd_Bloke> fdv: You should merge the branch with those revisions into a pristine checkout/branch of the SVN repo.
<fdv> ah, so that's possible, too?
<fdv> I don't necessesarily have to talk directly to the svn repo?
<Odd_Bloke> fdv: Well, you'll merge into the checkout of the SVN repo and commit it having first sorted out conflicts/tested it is working properly.
<Odd_Bloke> This creates a single mainline revision, which is either in the SVN repo (a checkout) or can be pushed there (a branch).
<fdv> Odd_Bloke: right, that seems fine
<fdv> so, basically, I have two trees, then, a working tree and a 'commit' tree, and I merge my changes into the commit tree everytime I wish to push to svn
<fdv> Odd_Bloke: sounds feasible. Thanks :)
<Odd_Bloke> fdv: Yup, that's it.  No worries. :)
<fdv> (well, apart from that the repo will probably be about 7-8GB.. :p)
<LarstiQ> if you don't really care about the bzr history in svn, or roundtripping, you could also coversion
<fdv> roundtripping and coversion?
<fdv> sorry, just not familiar with the terminology
<LarstiQ> fdv: roundtripping would be doing a commit with bzr, send it over to svn, and pull with bzr from it again, getting the equivalent revision.
<Odd_Bloke> fdv: Coversioning would be where you just init a bzr branch in your SVN checkout, do intermediate work in bzr and then commit normally in SVN.
<LarstiQ> fdv: coversioning is when you use two seperate versioning control systems to version one tree, without them knowing about the other
<LarstiQ> fdv: so no sharing of history, but sometimes that is what one wants
<fdv> ah, right
<fdv> thanks for great help, once again :)
<fdv> I think I have to work with this for a while to find out how it's best to incorporate into our workflow
<fdv> (or what kind of workflow one can accomplish)
<james_w> statik: I was just today trying to put together a screencast about bzr.
<james_w> I got stuck trying to find something that I could use to edit the video without crashing.
<Odd_Bloke> statik: You're emurphy on Twitter?
<james_w> hi Odd_Bloke
<Odd_Bloke> james_w: o/
<lifeless> mtaylor: hi
<lifeless> beuno: also, hi
<jelmer> 'morning lifeless
<beuno> mornin' lifeless. I see you've managed to index files as well  :)
<lifeless> yeah
<lifeless> people kept bitching about it
<lifeless> so I'm like fuck-it, I'll do it
<james_w> moanin' lifeless
<beuno> hahah
<beuno> so that's the secret...
<lifeless> hi james_w, jelmer
<mwhudson> beuno: good morning
<beuno> good morning to you mwhudson
<mwhudson> so i looked at pylons a bit last night
<beuno> mwhudson, I've been thinking about what would be enough to make a Loggerhead release. To get things rolling again. Maybe we can add nicer-urls, clean up setup.py, and... well, the templating change is already a big one by itself
<mwhudson> i wasn't very impressed :(
<beuno> really? Hard to use? Incomplete?
<beuno> "just ugly"?
<mwhudson> ugly, from my personal pov, and not really appropriate for loggerhead
<mwhudson> i think i'm quite stuck in my ways in some things
<mwhudson> i like xml templating and i like object publishing
<mwhudson> (as opposed to routes-type things)
<beuno> fair enough. Did that include looking at Mako as well?
<mwhudson> also pylons seems to have and encourage quite a lot of magic
<mwhudson> no
<beuno> ok, well, a better look at Genshi may be worth a try instead
<beuno> either way, if pylons is that ugly, we may as well concentrate on the core instead, now that the templating engine is saner
<mwhudson> wrt a release, if we could get away from cherrypy, i'd say we were pretty close to a release-candidate
<mwhudson> cherrypy3 is an option i guess, but it conflicts with cherrypy 2 :(
<poolie> good morning
<beuno> how about paste?
<beuno> morning poolie
<mwhudson> beuno: i'm still not really sure what paste is :)
<mwhudson> hi poolie
<mwhudson> beuno: are you going to bzr send your cleaner urls branch?
<beuno> mwhudson, http://pythonpaste.org/
<mwhudson> beuno: yes
<beuno> mwhudson, yeah, I just need to cleanup the latest quirks introduced when merging from trunk
<mwhudson> beuno: that site is very bad at explaining what paste is :)
<poolie> beuno, hi
<beuno> heheh, AFAIK, it can replace cherrypy, which is why I have that in my head
<mwhudson> ah, http://pythonpaste.org/do-it-yourself-framework.html seems like the page i was looking for
#bzr 2008-06-12
<beuno> mwhudson, I have to run off for a while. I need to run some errands I've been putting off. I'll read the backlog when I get back, and finish up the cleaner-url patch. FWIW, it's in: lp:~beuno/loggerhead/zpt.cleaner_urls
<mwhudson> beuno: okidoke
<mwhudson> i should do some non-loggerhead stuff too
<igc> morning
<Peng> jelmer: If you haven't gotten an answer, you can use 'hg export' to create a patch-like file.. Not sure about the email part. The patchbomb extension, perhaps.
<jelmer> Peng, hg doesn't have a bundle-like format that preserves vcs metadata?
<Peng> jelmer: 'hg export' does.
<Peng> jelmer: The git diff format can store binary data.
<Peng> jelmer: Mangled line endings can cause problems though.
<jelmer> Peng, ah, thanks
<lifeless> igc: where is your stacked loom again ?
<jml> abentley, lifeless: do you know if https://bugs.edge.launchpad.net/bzr-loom/+bug/201613 is now fixed?
<ubottu> Launchpad bug 201613 in bzr-loom "pushing looms does not work properly" [Critical,Triaged]
<jml> the associated branch is 'trunk', so...
<jml> also, what's BzrDir.clone expected to do when the associated bzrdir is for a loom?
<abentley> jml: I know that a hacky fix was applied, so it should be better, but not perfect.  The wrong hook will fire.
<abentley> I don't know why BzrDir.clone would do anything different when the associated bzrdir is for a loom.
<lifeless> jml: as abentley says
<lifeless> jml: works, wrong hook.
<jml> ahh ok.
<stefanv> hey guys, I have a question about workflow.  I'd appreciate it if you could point me in the right direction.  Whilst developing a feature in a new branch, it is useful to keep up to date with the latest changes made in "trunk".  Why does bzr force you to merge, even if a pull wouldn't have resulted in a conflict?  This makes many merges appear in the revision log.  Is there a workaround, or am I missing the point?
<stefanv> For example, if I'm working on project/somedir/*, and the project changes project/otherdir in trunk, that would require a merge from my side.  But I'd be quite happy to just rebase my branch on theirs...
<stefanv> instead of merging, I would then again be able to pull
<stefanv> If this is all crazy-talk, just point me to the right FAQ, please...
<lifeless> stefanv: so this is a whole-tree vs partial-tree thing
<lifeless> stefanv: in CVS each file has its own timeline, so you can 'pull'(update there) and it has to relevance to other files
<lifeless> stefanv: the same goes for SVN
<lifeless> stefanv: darcs doesn't really have a timeline, which is why a similar thing works there
<lifeless> stefanv: for whole-tree systems, like bzr, hg, monotone, git, it doesn't matter which files you edit - concurrent activity requires some action to resolve.
<lifeless> stefanv: there are different low level tools that can be used, they basically boil down to either /rewrite history/ or /merge the activity/
<stefanv> lifeless: the problem is that we see many merge entries in our logs, which seem kind of unnecessary.. we would have been happy to just base the branches off the new trunk, if possible
<lifeless> rewriting history is problematic - it turns tested code into untested code, it makes collaboration much harder
<spiv> Rewriting history just to get an arguably nicer presentation seems like overkill to me :)
<stefanv> spiv: it worries the developers when they see so many merge messages, but maybe that is just a mental block we need to get over.  the idea of a "merge" is still somewhat severe, coming from SVN.
<stefanv> lifeless: thank you for the detailed answer.
<stefanv> if merges could take place without conflicts, though, why merge instead of just pulling?
<spiv> Because pull is a way to update a mirror of a branch.
<spiv> But if you have a branch with independent changes, it's not a mirror, so it cannot have the same history.
<stefanv> Ah, that makes sense.
<spiv> If your branch has no new commits in it, then you can use pull.  But then it's not a very interesting feature branch either :)
<stefanv> Doesn't hg fast-forward?
<stefanv> spiv: true :)
<lifeless> stefanv: 'merge --pull' does what 'fast-forward' does
<lifeless> stefanv: which we put in for folk that enjoy that particular workflow
<lifeless> stefanv: with respect to merges - merging is what happens when concurrent development takes place
<lifeless> stefanv: and bzr can't tell that "standard_includes.h" is unable to cause a test failure in "uses_standard_includes.c"
<lifeless> stefanv: which is why we don't commit it automatically (though you can definitely write a wrapper script if you wanted to)
<stefanv> lifeless: shouldn't the developer take the responsibility of only merging valid changes in?
<stefanv> lifeless: bzr can't really protect against that, either way
<lifeless> right
<lifeless> all a merge record in the history means is that a developer has done that
<stefanv> lifeless: is there a way for a developer to hide all those merge records?
<stefanv> lifeless: i.e. if he wants to say "here is my new feature, but you guys really don't need to know about successful merge attempts"?
<stefanv> lifeless: or should we just use the --short option for logs?
<lifeless> It is possible to write a plugin to hide them from e.g. log. They do have semantic value to bzr (to make merge work correctly for instance)
<stefanv> Launchpad doesn't have a very detailed log display, unfortunately.
<spiv> stefanv: out of interest, what does e.g. http://bazaar.launchpad.net/~bzr/bzr/trunk/changes lack that you'd like to have?
<stefanv> Oh, that's fine.
<stefanv> I'm referring to the one displayed on the code page.
<spiv> Oh, right.
<spiv> thumper: ^
<stefanv> It basically comes down to this: we need to be more careful about labelling merges with mainline.
<stefanv> We need to include something like "Merge in MrX's changes to the build machinery." -- to give credit to the developer
<stefanv> Instead of relying on his name appearing in the "changelog".
<thumper> hello
<stefanv> spiv: https://code.launchpad.net/~vcs-imports/libs/main
<stefanv> spiv: revisions have a tendency not to appear in that display :)
<mwhudson> yes, we'd like that to be better
<poolie> beuno: are you still here?
<stefanv> mwhudson: if you could implement the snazzy display we see on a tool like olive, that would kick serious ass
<mwhudson> indeed
<mwhudson> that sounds like an .... interesting ... challenge
<stefanv> we've moved IPython onto Launchpad... so we're in it for the long haul
<mwhudson> one we may even be able to do, but it's a considerable amount of work
<spiv> stefanv: Commits with multiple authors (because it's a merge of many revisions) could be displayed much better by Launchpad.  I think there's work towards doing that, actually.
<stefanv> spiv: that's great news
<spiv> mwhudson: it shouldn't be *too* hard. </handwave>
<LarstiQ> stefanv: of course, bzr log will still show you all those revisions.
<LarstiQ> stefanv: and if you're merging dev in a feature branch, those revisions will allready be credited earlier on
<lifeless> LarstiQ: yes, but web uis are more interactive, FSVO inter
<LarstiQ> lifeless: I agree the trunk log page is really bad
<mwhudson> spiv: no, that shouldn't be
<mwhudson> though i don't think we have enough data in the launchpad db to make a merge sort trivial
<LarstiQ> lifeless: recently lots of people have been complaining that their revisions get lost in merges. Not sure why that plays up now.
<ToyKeeper> About the pull vs merge issue, hg handles it with multiple heads...  you can pull even if diverged, but the changes go to a different head.
<ToyKeeper> I'm not sure whether that's possible in bzr, or if it's even a good idea.
<spiv> ToyKeeper: well, that's just keeping a separate branch
<spiv> (in bzr terms)
<lifeless> and in hg terms too :)
<stefanv> when are those heads merged?
<lifeless> in hg, when you do 'hg merge'
<lifeless> (which you normally do immediately)
<stefanv> right... and only then is it really useful...
<ToyKeeper> It can basically let you switch between various branches, in the same directory...  work on one head for a while, then a different head, without changing directories.
<ToyKeeper> I get the impression hg has the feature because git has it, but it seems conceptually simpler to have different directories for different lines of development.
<stefanv> Yes, that sounds like a potential source of confusion.
<ToyKeeper> I suppose it would be nice for large projects, to avoid having two copies of history, but both bzr and hg have other ways to do that.
<spiv> It's also nice to avoid rebuilding large working trees.
<spiv> And some tools (eclipse is one I think?) also prefer the absolute path not to change, so to work with those tools it can be more convenient to change one tree in place rather than have many trees.
<spiv> So we have "bzr switch"
<ToyKeeper> It'd be nice if launchpad merge requests used a merge directive instead of a branch.
<spiv> thumper: ^
<thumper> ToyKeeper: hello
<ToyKeeper> It seems expensive to use O(project history) space for those instead of O(patch).
<thumper> ToyKeeper: we have plans, cunning plans
<ToyKeeper> :)
<thumper> ToyKeeper: with the new stacking, space will be O(patch)
<LarstiQ> thumper: when does that roll out?
<thumper> ToyKeeper: but also we are considering being able to email Launchpad a merge directive :-)
<thumper> LarstiQ: we are hoping RSN
<ToyKeeper> At first I was sure I was doing it wrong.  :)
<thumper> LarstiQ: planned release is 1.2.6
<ToyKeeper> Wow, that's much sooner than I thought it'd be.
<thumper> ToyKeeper: it is something we have been looking at for a while
<mwhudson> speaking of stacking
<lifeless> Pieter: done
<LarstiQ> thumper: I know it has been discussed much longer.
<thumper> LarstiQ: that it has
<thumper> LarstiQ: I think we started talking about it seriously in October last year
<LarstiQ> thumper: oooh, 1.2.5 is current. Cool!
<mwhudson> can someone explain briefly to me the connection between the branches that igc has been sending to the list and the big bundle lifeless sent yesterday?
<lifeless> "big bundle" heh heh heh
<lifeless> ig1: where is your stacked loom again ?
<ig1> lifeless: http://people.ubuntu.com/~ianc/bzr/shallow-branch/
<stefanv> is there a way to apply a bundle, but to assume that the base is the current tree, instead of the one it came from?
<lifeless> stefanv: why? doesn't merge do what you want/
<beuno> poolie, back
<lifeless> beuno: I fixed the huge-numbers-of-files things before work this morning
<beuno> lifeless, you're going too fast, I can't keep up  :p
 * beuno pulls again
<lifeless> spiv: is there a bzr-svn python trunk in packs around?
<beuno> lifeless, I have one locally
<beuno> igc passed it on to me in the sprint
<beuno> want me to try and index that?
<lifeless> L
<lifeless> LWhatever we decide, I think we should at least file a bug for it
<lifeless> and maybe add some FIXME here and there, so that a newcomer will
<lifeless> have a hint or two about what is the way we want things to be
<lifeless> done and don't get puzzled by finding several different ways in
<lifeless> bah, copy n paste garh
<lifeless> beuno: yes
<spiv> lifeless: http://code.python.org/python/
<spiv> (docs at http://www.python.org/dev/bazaar/ should you need them)
<beuno> lifeless, I get: ImportError: No module named transport
<lifeless> beuno: argh
<lifeless> beuno: pushing a replacement revision now
<beuno> and indexing...
<beuno> ah, random progress bars!
<lifeless> thats the inventory walk
<beuno> ~200mb sustained ram usage
<beuno> that's as much as it takes to just render a 36k diff with LH   :)
<lifeless> what are you indexing ?
<beuno> python tree
<lifeless> interesting; mine is at 585 :P
<beuno> I haven't passed 201 RES at any point
<beuno> it sure likes CPU though  :)
<lifeless> are you running 64-bit or 32 ?
<beuno> 32
<lifeless> I'm on 64
<lifeless> I suspect thats the difference
<beuno> yeah
<beuno> it just jumped to 218
<beuno> but it's not that much of a memory hog
<lifeless> well it finished
<lifeless> its tunable easily
<lifeless> dynamic tuning is harder, because python
<lifeless> time bzr search Andrew Bennetts
<lifeless> File id '3801@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:Misc%2FACKS', revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:46995'. Summary: 'No summaries yet.'
<lifeless> Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:39595'. Summary: 'Patches #1298449 and #1298499: Add some missing checks for error'
<lifeless> File id '3801@6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:Misc%2FACKS', revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:39595'. Summary: 'No summaries yet.'
<lifeless> real    0m1.412s
<lifeless> user    0m0.736s
 * lifeless goes back to merging big branches
<lifeless> sys     0m0.096s
<lifeless> oh, I must say, that having written a search engine now, my respect for evolution--
<beuno> beuno@beuno-laptop:~/bzr_devel/test_repos/python$ time bzr index
<beuno> real	10m42.939s
<beuno> user	10m9.302s
<beuno> sys	0m3.868s
<lifeless> 4 seconds to search a similar corpus, *in C*
 * mwhudson wonders about spotlight hooks on os x...
<beuno> lifeless, 0.5 to search random terms on the python tree.  *very* cool  :)
 * beuno goes tackle the nice-url LH branch
<mwhudson> beuno: so i think bits and pieces from paste will probably be sufficient to make a wsgi app version of loggerhead
<mwhudson> i think what's in loggerhead will become two wsgi apps though
<mwhudson> one that displays a single branch (replacing BranchView in the current code)
<mwhudson> and another that has a browse branches view and dispatches branches to the former app as defined by loggerhead.conf
<mwhudson> (for compatibility if nothing else)
<beuno> sounds sensible
<beuno> I'll look into what it will take to replace cherrypy for paste's bits, unless you where planning on doing that
<mwhudson> except aaaaaaaaaaaaargh
<mwhudson> oh, hm
 * beuno hides
<mwhudson> oh phew
<mwhudson> i thought for a moment there that paste shared cherrypy's insanity about %2F's in urls
<beuno> ah, that would close a bug we have laying around
<mwhudson> indeed
<mwhudson> that bug is one of the two reasons i want to get rid of cherrypy
<mwhudson> (it breaks browsing bzr-svn imports)
<mwhudson> (although the cleaner-urls branch will help there too)
<beuno> ah, right, I hadn't thought of that
<mwhudson> the other is that there's no way of distinguishing _ and . in urls
<mwhudson> so if someone registers branches called foo.bar and foo_bar in launchpad, you'll only be able to browse code to one of them
<beuno> that sounds stupid. That's cherrypy screwing up?
<mwhudson> yes
<lifeless> its a feature!
<mwhudson> the %2f thing is probably stupider fwiw
<lifeless> %2f is at least a standard
<beuno> yeah, . _ is odd
<beuno> why would it think it's the same????
<lifeless> or do I not understand the discussion :P
<mwhudson> lifeless: no, that foo%2fbar is the same as foo/bar makes sense
<mwhudson> lifeless: however with cherrypy foo%252Fbar is the same, too
<lifeless> oh!
<lifeless> hmm
<mwhudson> beuno: cherrpy replaces . with _ because it does url traversal with getattr
<lifeless> try %252f%25.%25.
<beuno> ah, ew
<lifeless> (and escape dot, forgotten the asc() value
<lifeless> try %252f%2546%2546
<lifeless> see if you can escape :)
<lifeless> (double escaping is a great way to have bugs)
<lifeless> so . and _ for traversal its nuts
<AfC> Out of curiosity, why does URL escaping have to be user visible at all?
<lifeless> if you are going to escape, escape properly
<mwhudson> lifeless: doesn't seem to work
 * AfC is presently doing a `bzr push` and I must admit that seeing
<mwhudson> lifeless: but i don't really want to think about it
<lifeless> mwhudson: minor relief; I'd want to look at the code though TBH
<AfC> Using saved location: bzr+ssh://afcowie@master.gnome.org/home/users/afcowie/public_html/bzr/gtk%2B/trunk/
<AfC> seems ... less than ideal
<lifeless> AfC: in the general case a url can be in any encoding
<lifeless> AfC: e.g. that could be in big5
<mwhudson> lifeless: the code is like this:
<mwhudson>         # Decode any leftover %2F in the virtual_path atoms.
<mwhudson>         virtual_path = [x.replace("%2F", "/") for x in virtual_path]
<AfC> Um, if you say so.
<lifeless> AfC: the short story is, its a bug in std66
<lifeless> they could have said 'its utf8', instead they recommend that providers (e.g. your server) use utf8, but consumers are told 'it is opaque'
<AfC> All I know is I wrote "gtk+" and know that the directory I am in is named "gtk+" and the one I am pushing to is named "gtk+".
<lifeless> I'm kind of surprised + is being escaped, offhand
<lifeless> I'd need to check the BNF
<lifeless> AfC: thats because you're on linux going to linux, and all the systems are running locales whose language is one where + maps to 2B.
<lifeless> AfC: it can easily get extremely feral
<AfC> still don't know why %2B has to be shown to a user.
<lifeless> the options are:
<lifeless>  - the url (7-bit data, safe to present)
<lifeless>  - the decoded url (8-bit data, unknown encoding)
<mwhudson> while i'm whinging about loggerhead, why in the world is http://bazaar.launchpad.net/~mwhudson/pydoctor/dev/changes/1111 a 500?
<lifeless>  - use heuristics on the decoded url to get a unicode string)
 * mwhudson goes off to do more useful things
<lifeless> running full tests on this merged stacked branch now, first thread
<AfC> My locale is en_CA.UTF-8. That should be more than sufficient to present characters like ' ', '+', and '~'.
<lifeless> but its not your locale that the url is it
<lifeless> is *in*
<lifeless> its in the locale of the process of the remote server
<AfC> Just seems it would make for a nicer UI for mere humans. Bazaar likes to be good at that sort of thing, so I hear.
<lifeless> *at best*
<lifeless> indeed, and I raised this on the http wg list
<lifeless> backwards compatibility I hear
<lifeless> AfC: I'm saying  I would like to do better, but we also try to be correct, and there is a tension here - some things are harder than others
<lifeless> mtaylor: ping
<beuno> mwhudson, sent the clean-urls patch
<beuno> at some point, I'd like to fit in a good week or two of work to just cook up tests
<mwhudson> ah yes
<mwhudson> that would be really really nice :)
<beuno> for which, btw, we have one failing in trunk
<mwhudson> ah dammit
<mwhudson> it's the diff truncation one isn't it?
<beuno> yes  :)
<beuno> aaaand, I'm off for today
<lifeless> beuno: gnight
<beuno> mwhudson, let me know if you need any changes to the clean-urls patch. I'll check back in a few hours
<mwhudson> beuno: the navigation links still use ugly urls
<mwhudson> but i like it :)
<beuno> lifeless, night!  I've been thinking of several ways to tackle the re-indexing problem, so I may give it another shot if I get my hands on some free time
<beuno> mwhudson, argh, I forgot to pass that on from my first branch
<beuno> I *really* need to clean up my LH branches
<lifeless> beuno: yah, my lunch at the moment
<lifeless> beuno: I'm actually just about to do it once I finish putting everything into single packs
<beuno> lifeless, ah, cool. I'll keep my eye on it, and use that time to get it workin in LH  :)
<mwhudson> beuno: and clicking the 'browse files' link in the annotate view breaks
<lifeless> beuno: I'd love to have bzr-gtk/bzr-eclipse/loggerhead start having use of it
<lifeless> beuno: users -> drive interfaces
 * igc lunch
<beuno> mwhudson, that's odd. I didn't touch that...  let me poke at it
<beuno> ah, that's why it breaks. I didn't touch it  :)
<mwhudson> you took the clear=1 out
<beuno> yeap
<beuno> I'll do another pass at changes against trunk
 * Verterok looking if eclipse have a extension point for the search actions
<mwhudson> beuno: but thanks heaps for doing this :)
<beuno> mwhudson, glad to
<beuno> I hate the way we handle URLs though
<beuno> we shouldn't have to explicitly have to tell it not to drag the values...
<mwhudson> yes
<Verterok> lifeless: as far I can see, bzr-search integration into bzr-eclipse don't  look too difficult :D
<lifeless> Verterok: cool
<beuno> mwhudson, sent the patch with the fixed clear=1. I'll get the navigation links working tomorrow, as my patch doesn't apply cleanly, and I'm already 20 minutes late  :)
 * beuno waves at Verterok 
<Verterok> if I can get some spare time, I'ld try to get a working prototype
 * beuno -> out
<mwhudson> beuno: bye
<Verterok> g'nigth beuno
<lifeless> Verterok: that would be pretty damn cool :)
<Verterok> lifeless: indeed :)
<Verterok> I'll try to do it as an extension to bzr-eclipse...so it 'll be completely optional
<lifeless> yeah, thats a good idea ;)
<Verterok> and 'll make my life a lot easier than trying to include it in bzr-eclipse  :)
<poolie> lifeless, spiv, i'm going to talk to spiv then jump into reviews
<poolie> starting with spiv's resubmitted test patch then the big mutha
<mwhudson> lifeless: do you want to hear about some typos in BUGS in bzr-search?
<mwhudson> "does not component components." and "does not component components."
<mwhudson> no
<mwhudson> "requires nearly 200B of memory"
<lifeless> is MB mega bytes or bits. I forget, continuously
<mwhudson> bytes, according to teh wiki
<lifeless> anyhow thanks done and pushed
<lifeless> poolie: igc: the "Development1" patch is the one that needs to change to support stacking on VersionedFiles
<igc> thanks lifeless
<lifeless> (and thus the one I would hesitate to land until thats done)
<lifeless> I'm writing the mail I promised now
<poolie> lifeless:  easy mnemonic: "B" is bigger than "b"
<lifeless> I'll try
<lifeless> :)
<Peng> Re Loggerhead templates, what about Jinja? Or Jinja2? It's not tree-based, but it is supposed to be fast.
<Peng> mwhudson_: Eek, lp:loggerhead doesn't use packs?
<mwhudson_> Peng: no, haven't got around to upgrading it
<lifeless> mwhudson_: bzr upgrade sftp:// do it now :P
<mwhudson_> jinja made my eyes bleed on an 0.1 s impression
<mwhudson_> lifeless: on *my* connection after 17:30 ?
<lifeless> yeah, its a small branch
 * Peng just spent almost 5 minutes pulling new revisions over http. :P
<lifeless> kick it off and forget about it
<mwhudson_> Peng: one of them was huge i suspect
<mwhudson_> the zpt-templating merge merged over 100 revisions
<lifeless> or better yet, screen + devpad
<mwhudson_> lifeless/Peng: done
<Peng> :)
<Peng> Also, my copy had a few inconsistent parents that reconcile can fix.
<mwhudson_> Peng: i reconciled trunk too, thanks for the pointer
<Peng> :)
<mwhudson_> (from a machine in the data centre :))
<Peng> Heh, that's cheating. :P
<poolie> i'm reading igc's "Development1 format"
<lifeless> poolie: thats the one I'm now editing
<lifeless> poolie: its the one that has to change
<Verterok> lifeless: just a quick hack, but is a proof that can be done :-) http://guille.beuno.com.ar/images/bzr-eclipse-search-fullscreen.png
<lifeless> Verterok: oh man, that rocks
<lifeless> Verterok: would you prefer to do hit summaries yourself?
<lifeless> Verterok: e.g. do you want a minimal output of just the keys, or do you want the humanesque output it generates at the moment
<AfC> Verterok: *nice*
<AfC> Verterok: excellent place to put it.
<AfC> I told you about those slanty tabs, though :)
<lifeless> btw, at my lunch I stabilised the disk format
<lifeless> its now unlikely to change until major feature changes - like extreme scaling work, or phrase searching, that sort of thing
<Verterok> lifeless: I was planning to write a xml output so I can integrate it more easy
<lifeless> Verterok: that would be lovely. I'd be delighted to include that in the plugin
<lifeless> Verterok: either as a separate command or an option
<Verterok> lifeless: great. so, that's my next step
<lifeless> I'm calling it a day for /work/. been paging back in stacking and my mind has melted
<Verterok> lifeless: I'll draft an xml format and send it to the list
<lifeless> cool
<lifeless> I would suspect that only returning the document keys is most appropriate
<lifeless> your existing bindings for getting file texts and revisions and so on should be more than adequate to generate summaries in eclipse itself
<lifeless> but you know more than me about that; so please feel free to specify what you'd like most:)
<Verterok> actually, the current bindings call bzr
<Verterok> but the upcoming xmlrpc service that should be a lot easier
<Verterok> s/but/but with/
<lifeless> exactly
<Verterok> lifeless:  keys == revid, I'm right?
<lifeless> Verterok: see DESIGN
<lifeless> Verterok: ('f', FILEID, REVID) for instance
<Verterok> ok, thanks!
<lifeless> is a file hit at a particular revision id
<lifeless> ('r', '', REVID) is a revision hit
<Verterok> I'm slowly getting it :) thanks
<Verterok> I'm off for today
 * Verterok heading to bed
<Verterok> seeya
<lifeless> night
<uniscript> hi there
<uniscript> I have two repos: A & B with email interaction only. A is at rev 3, B was at rev 3 but now is at rev 7. How do I create a bundle to update A to rev 7 from B without access to A?
 * igc dinner
<uniscript> cd B && bzr bundle . -r 3..7 ; doesn't cut it because there is nothing much in the bundle since bzr says: well I have the files why put them in the bundle?
<lifeless> Kinnison: have you seen bzr-search?
<Kinnison> lifeless: I've not, is this your new indexy thingy for bzr? If so, what is it meant to do?
<Kinnison> (I saw your blog posting about databases but unfortunately couldn't come up with anything useful)
<lifeless> Kinnison: https://launchpad.net/bzr-search
<lifeless> Kinnison: enjoy
 * Kinnison has been following the threads about stacked branches with interest
<Kinnison> Hmm, bzr-search looks amusing, but I can't think of anything particular to do with it right now
 * Kinnison writes it on his white-board to think about
<uniscript> sounds interesting, where might I find a summary on stacked branches and where things are up to?
<lifeless> Kinnison: its a replacement for bzr log --message, bzr grep, amongst other things
<lifeless> Kinnison: also annotate
<lifeless> Kinnison: I've been thinking about the annotation problem for a bit, and I think annotate is just a very crude search
<Kinnison> hmm, I guess
 * Kinnison needs coffee before he can think about this in detail
<lifeless> :)
 * Kinnison goes to see if the machine has finished making black heaven
<Kinnison> lifeless: any specific bzr requirements for the plugin?
<lifeless> nah
<lifeless> I mean, I've only tested with .dev, but its darn generic
 * Kinnison will update his .dev anyway
<Kinnison> coo, branching from launchpad requires SSH
 * Kinnison removes the air-gap firewall from between his PC and his SSH keys to try again
<lifeless> nah, its just because it knows you
<lifeless> if it didn't it would do http
<Kinnison> pity it doesn't either fallback
<Kinnison> s/either/
<lifeless> I believe there is now a bug open
<Kinnison> heh
 * Kinnison wonders why his key hasn't mounted
<lifeless> not enough ponies
<Kinnison> it's as though hal is not responding
<fog> Hi, I have a little problem with "bundle"...
<fog> I have the branch of a friend locally (call it X) and i merged from him into my branch (call it Y)
<fog> then I did some changes to my branch, now I want to send him the changes...
<fog> sincerely from the docs I don't understand what the submit and public branches are... :(
<Kinnison> lifeless: I've decided that my best bet for trying this search tool on a respectable codebase is to make a branch of one of our projects at work
<Kinnison> lifeless: so bzr-svn is currently amusing itself with our svn server
<james_w> fog: you probably want "bzr send ../X"
<james_w> the submit branch is the branch that you are wanting to submit your changes to
<james_w> the optional public branch is a public location where your branch can be accessed if the other person would like to merge from that instead
<james_w> (or it allows you to do --no-bundle)
<fog> james_w: ah.. I understand. thank you very much.
<fog> james_w: mm.. why bundle bundles my shelved changes?
<lifeless> Kinnison: ok
<lifeless> fog: you have committed them I think :P
<james_w> hi lifeless
<fog> lifeless: nope, I just shlved them.
<james_w> send doesn't use the working tree, so that would be very strange.
<fog> james_w: something is not working.. because I forgot to commit my changes but they appear in the bundle (togheter with the shelved ones...)
<fog> ok, let me restart with a clean tree...
<Pieter> lifeless: I'll check it out then :)
<Pieter> if I've done a bzr pull, how can I get a log showing only the changes that were pulled?
<fog> james_w: ok, I branched my fried branch, copied the modified files,commited and sent. it worked, thanks.
<lifeless> Pieter: after the pull no; you can do 'bzr missing' before the pull, or note the revision number before you pull and do log -r $number..
<Pieter> hmm, too bad
<lifeless> something for us to improve on
<lifeless> its actually a little tricky :/
<lifeless> hmm, I should teach commit-notify to include all the changes in a gui window
<lifeless> spiv: lets talk tomorrow about the tuple keyspace
<Pieter> lifeless: it's done already
<Pieter> nice
<lifeless> Pieter: cool
<lifeless> Pieter: now try searching :)
<Pieter> I did.. it's pretty fast :)
<lifeless> pure python FTW
<lifeless> Pieter: cool, well it works and is fast :) not much more to say really, except that I love feature requests, ui tweaks, and patches :)
<Pieter> lifeless: it'd be nice to see the context a string is found in :)
<lifeless> yeah a summary
<lifeless> I have some plumbing to do
<lifeless> I want the core of the system to be really robust
<lifeless> fire n forget level
<lifeless> then I'll look at that; unless someone beats me to it
<lifeless> be good to do hits on deletes too, but our deltas don't record that (they are not reversible deltas)
<lifeless> one of the reasons its half decent at indexing is not doing diffs
<Pieter> dato: if you're trying to export a parentless commit for the same branch, it's easier to just do a "reset refs/heads/branch" than creating a temporary branch
<Pieter> (in bzr-fast-export)
 * lifeless kills npviewer.bin again
<jelmer> lifeless: did you see my reply about pqm?
<lifeless> jelmer: yes, and its moving now
<jelmer> lifeless: cool
<jelmer> lifeless: is there any branch with your versionedfile API changes available ?
<jelmer> lifeless: in particular the removed API functions, so I can make sure the rebase, svn and remove-revisions plugins keep working for 1.6
<lifeless> jelmer: yes,the one in the bundle header
<lifeless> I'm pushing it again to be sure now
<Kinnison> lifeless: should I expect a progress bar from 'bzr index' ?
<Kinnison> lifeless: 'cos it's sat not showing me anything, having pegged one of my CPUs
<lifeless> Kinnison: no, UI comes lastish
<Kinnison> kay
<Kinnison> oooh, done now
<Kinnison> that was actually quite quick, for indexing this codebase over 6000 revs
<Kinnison> but the search output is perhaps not as nice as it could be
 * Kinnison picks his way through some results
<lifeless> yes
<lifeless> there are two big problems with searching
<lifeless> well three
<lifeless> selecting good results
<lifeless> selecting a good number to show
<Kinnison> nod.
<lifeless> oh yeah, and showing the results nicely
<james_w> I'm halfway through a merge, and I want to find out what the remaining changes in my working tree are compared to the branch that I just merged, is there a way to do that?
<Kinnison> File id '3720@507b4074-7016-0410-bdd2-fba35d1e0378:import%2Fable%2Ftrunk:core%2Fsystem%2Fmachine%2Fvr1000%2Fvr1000.c', revision 'svn-v3-trunk2:507b4074-7016-0410-bdd2-fba35d1e0378:projects%2Fable%2Ftrunk:11722'. Summary: 'No summaries yet.'
<Kinnison> that's *so* not a useful result
<lifeless> I don't claim that this does any of them :P
<Kinnison> and yet, does tell me what I would need in order to look
<lifeless> Kinnison: yah, index.py if you want to improve the output
<lifeless> (the display I mean, I'm not asking for folk to solve the really hard bits for me)
<Kinnison> heh, it's 13:00 and today I've done exactly 20 minutes of the work I was meant to so-far
 * Kinnison had a potential-customer-based-diversion :-(
<james_w> ah, bzr diff --old other-branch, seems to be what I want.
<lifeless> Kinnison: well, that means this diversion can keep you entirely distracted
<Kinnison> such a wonderful offer
<Kinnison> :-)
<mtaylor> lifeless: dude. even just removing the .bzr/bzr-search dir to try your new patch is taking FOR EVER
<ricardokirkner> hi everyone
<ricardokirkner> how can I debug the bzr+http protocol?
<ricardokirkner> I am getting some errors, and I want to find out exactly where this is happening in the code
<mtaylor> ricardokirkner: I'm guessing tcpdump isn't the answer you're looking for
<ricardokirkner> no, actually I want to find out what part of the bzr code is responsible for handling the bzr+http protocol, so I can set a breakpoint there and go step by step until I find the line that is causing the problem
<ricardokirkner> I think the smart/server.py file is responsible for bzr:// protocol, does it also handle bzr+http?
<james_w> ricardokirkner: yeah, I think so
<james_w> adding -Dhpss to the command line will print more information to your ~/.bzr.log
<Peng> Wait...bzr with https doesn't verify SSL certs, does it?
<ricardokirkner> yes, I did that, but it didn't give me useful information
<ricardokirkner> maybe you know what might be happening... I am getting an error response
<Peng> You could -Dhttp too.
<ricardokirkner> 'module' has no attribute 'ElementTree'
<Peng> Um.
<Peng> From which side?
<Peng> And, that's not supposed to happen.
<james_w> ricardokirkner: ah, that sounds like the module is being replaced by another from somewhere else.
<ricardokirkner> I am using python2.4 here, maybe this might be because I have elementtree and cElementTree installed?
<ricardokirkner> the strange thing is.. this happens only when using the smart server over http
<ricardokirkner> but not when using the smart server directly
<ricardokirkner> and, when using over http, this happens only when I access a second repository (it works ok with the first repository hit, regardless of which one it is, but breaks with the second, regardless of which)
<james_w> yeah, from your description it sounded like apache was swapping somehthing around
<ricardokirkner> james_w, so maybe apache is modifying the PYTHONPATH variable? that might be the reason?
<james_w> something like that
<james_w> or even possibly playing around with the loaded modules
<james_w> I'm not familiar with apache and python though, what method are you using for running the python?
<james_w> (mod_python, fastcgi, etc.)
<ricardokirkner> the server is running several trac instances, so I guess it's using mod_python... originally I was using mod_python for my bzr wsgi interface, but according to some issues with that I tried to use mod_wsgi directly (which is what I am using now)
<james_w> is there something you can turn on in python to get debugging info about imports?
<jam> james_w: well there is "bzr --profile-imports" :)
<james_w> hi jam
<jam> there is a script 'profile_imports.py' in the bzr source tree
<jam> you could adapt that if you want
<james_w> is there any chance that lazy_import could be messing with this?
<jam> I don't really know about working on it with apache, etc
<jam> lazy_import is only used explicitly
<jam> it doesn't cause other things to be lazily imported
<jam> so it is unlikely, though always possible
<ricardokirkner> I just turned mod_python off in the web server, and bzr started working, so this is a compatibility issue with mod_python somehow
<ricardokirkner> ups
<ricardokirkner> not
<ricardokirkner> still broken
<ricardokirkner> ok, this is absolutely beyond me... the error is hapenning at the line with
<ricardokirkner> elementtree.ElementTree._escape_attrib = _escape_attrib
<ricardokirkner> just before that line I did log the elementtree.__file__ and elementtree.__path__ values
<ricardokirkner> and on both calls (the one that works, and the one that don't) it returns exactly the same value
<james_w> ricardokirkner: can you add a log of dir(elementtree) as well please?
<ricardokirkner> yes, just wait a second
<jam> ricardokirkner: it could easily be that one of them didn't import "elementtree.ElementTree"
<jam> which is actually a module IIRC
<ricardokirkner> ok... now I found a difference I didn't saw before
<jam> the class is actually. elementtree.ElementTree.ElementTree
<ricardokirkner> the first time (the one it works) it outputs as __path__ /usr/lib/python2.4/site-packages/elementtreeElementPath
<ricardokirkner> while the second time it outputs /usr/lib/python2.4/site-packages/elementtree__builtins__
<fredreichbier> elementtree is xml.etree.ElemenTree afaik for python2.5
<fredreichbier> *Element
<ricardokirkner> the __file__ variable is always the same
<jam> ricardokirkner: i think the file is based on the .pyc file
<jam> which may have been pre-computed in a different directory
<ricardokirkner> yes
<jam> so if I compile a file and then move the .pyc it remembers the old path
<ricardokirkner> mhhh.... are you suggesting I should remove the .pyc file and let it be regenerated?
<ricardokirkner> ok, again... the previous was incorrectly pasted together
<ricardokirkner> in both cases I get both __file__ and __path__ to be the same
<ricardokirkner> but.. in the first case, dir(elementtree) outputs ElementPath and ElementTree while in the second case it doesn't
<ricardokirkner> now. how can that be?
<jam> ricardokirkner: because they are sub-modules that aren't imported yet
<jam> they are *not* classes that are in the 'elementtree' file
<ricardokirkner> but I am executing the same line at the same point in execution time
<jam> someone needs to do "import elementtree.ElementTree" first
<jam> ricardokirkner: it sounds like it is a race with something else that is doing the import for you
<ricardokirkner> mhhh
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<jam> ricardokirkner: you might try this:
<jam> http://paste.ubuntu.com/19664/
<jam> it looks like we have our own possible import race
<ricardokirkner> jam, I did something like that, and it appears to have worked.. but on that  issue
<ricardokirkner> after importing the parts from cElementTree
<jam> depending on if cElementTree imports elementtree.ElementTree
<ricardokirkner> shouldn't it be importing cElementTree as elementtree
<ricardokirkner> instead of importing of elementtree?
<jam> ricardokirkner: no, they don't have the same objects
<jam> in the past, cElementTree used specific objects out of elementtree.ElementTree
<jam> (like elementtree.ElementTree.ElementTree)
<ricardokirkner> jam, what I did is http://paste.ubuntu.com/19666/
<ricardokirkner> can you tell me what is wrong with that ?
<jam> ricardokirkner: the second "from elementtree import ..." is importing from the *real* elementtree
<jam> cElementTree doesn't have a sub-module ElementTree
<jam> it has a *class* ElementTree
<jam> ricardokirkner: elementtree's disk layout is a bit.... psyco
<jam> there is a class... called ElementTree
<jam> available as either
<jam> cElementTree.ElementTree
<jam> *or*
<jam> as  elementtree.ElementTree.ElementTree
<ricardokirkner> but, if I imported cElementTree as elementtree, after that, referencing elementtree shouldn't be pointing to cElementTree , actually hiding the old elementtree?
<jam> ricardokirkner: no
<jam> the *local variable* is pointing there
<jam> but "from XXXX import YYYY" doesn't look at local variables
<jam> it looks at "sys.modules"
<jam> which contains the "real" names
<jam> the patching you see later on
<ricardokirkner> jam, alright, that was confusing for me, but if you say so, I will take your word on that until I can look into it a bit further to grasp why that is so
<jam> is also touching the *module* 'elementtree.ElementTree' not the class "elementtree.ElementTree.ElementTree"
<jam> so doing "import cElementTree as elementtree" doesn't give us the module where we expect to find it
<jam> http://paste.ubuntu.com/19664/ is all you should need to do
<ricardokirkner> so, forcing the import of elementtree.ElementTree after importing elementtree could be an option, right? (I mean, this isn't so bad as not be considered as a patch for next release?)
<jam> ricardokirkner: I was going to submit it right now
<jam> for review
<ricardokirkner> ok, then I am applying it right now, so I can get back to work :-)
<ricardokirkner> thank you very much
<ricardokirkner> it was kind of hard to trace for me, so the help is very much appreciated
<jam> I'm happy to help when I can
<wingo-tp> good day. i seem to be experiencing the KnitCorrupt bug from https://bugs.launchpad.net/bzr/+bug/234748, when running bzr check or bzr upgrade, but it is still there even with newest bzr. bzr reconcile fails also
<wingo-tp> has that fix actually been merged to bzr.dev?
<ubottu> Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Fix released]
<wingo-tp> it seems that it has...
<vila> jam: ping, bzr-commits disagree with that bzr revno http://bzr.arbash-meinel.com/branches/bzr/1.6-dev/annotation/ says >-/
<vila> I wanted to have a look but it seems that you don't push there ? How come the bzr-commit mails can diverge ?
<vila> jam: I'm more interested in looking into your stuff that understanding the divergence, so a push or a correct url will be enough :)
<jam> vila: I don't automatically push anymore, but I'll do a push right now
<vila> jam: thks
<jam> there is a small bug I need to commit a fix for, give me a sec
<vila> a whole minute even...
<wingo-tp> ahem. does anyone know what might be up with the KnitCorrupt thing/
<wingo-tp> ?
<jam> vila: 2 bits, I'll be doing the real work on the 'annotation' branch
<jam> but you may want to grab annotation_policy_cmd
<jam> because it exposes 'bzr annotate --policy=XXX'
<jam> wingo-tp: there are different variations on what causes KnitCorrupt to be raised
<jam> sometimes it is genuine disk corruption
<jam> the specific case listed in that bug has been fixed
<jam> Do you know if that is what you are experiencing?
<vila> jam: for a start, I want to have a look at the tests adaptation/application since lifeless said he want to get rid of all classes
<wingo-tp> jam: i pulled from bzr today, so if that bug is fixed, it is not the bug that i am experiencing
<wingo-tp> disk corruption would be the badness
<jam> wingo-tp: are you seeing "Knit *inventory* corrupt"
<jam> or just "Knit Corrupt" ?
<jam> (do you have the traceback to paste)?
<jam> !past
<ubottu> Factoid past not found
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<wingo-tp> i do have it, /me goes to pastebin
<wingo-tp> http://paste.ubuntu.com/19674/
<jam> wingo-tp: any chance you would have had 2 conversions of the arch tree
<jam> possibly with one of them having more history than the other?
<wingo-tp> perhaps it had something to do with the fact that it was imported from arch a long time ago, but i have upgraded it since -- i first saw this error when trying to upgrade to ricj-root-packs
<wingo-tp> jam: this is possible, i suppose
<jam> wingo-tp: so what it *could* be, is that at one point you did a conversion with a different amount of history
<jam> which caused the "last-modified" fields in the inventories to differ
<jam> at some point after that, the branches were merged together
<jam> and they didn't notice that the inventories they were referencing had a different text
<jam> and so they pulled across a delta which technically only applies to the *other* base
<jam> and thus when applied to this base, the sha-1 doesn't match
<jam> I would have thought you would encounter the error sooner rather than later
<jam> I probably can hack something together as a workaround, but a real fix is probably a bit involved.
<wingo-tp> odd.. i mean, i can bzr log all of the branches in this repo
<jam> wingo-tp: we don't need inventories to do 'bzr log'
<jam> just revisions
<jam> different place
<wingo-tp> ok
<jam> if you did "bzr log --verbose"
<jam> Then you would probably get the failure
<wingo-tp> indeed i do get the failure
<wingo-tp> after a merge with another arch branch
<jam> wingo-tp: is this a recent conversion?
<wingo-tp> no it is not
<wingo-tp> about august 2006
<jam> wingo-tp: is this a recent merge of that other branch, though?
<wingo-tp> jam: nope
<jam> the guile-gnome-pkg--release--0--base-0 branch?
<wingo-tp> no, i completely left arch around august of 2006
<jam> I'm talking mostly about a branch derived from that revision
<jam> not merging that revision specifically
<wingo-tp> and have not done merges from other branches that hadn't been forked off of this one
<wingo-tp> i guess what you are saying is possible, but i don't think so.
<jam> wingo-tp: I'm just trying to figure out why you are hitting it *now* rather than earlier
<wingo-tp> jam: well, i've never run bzr check before
<jam> do you have any idea of things that have been happening recenty?
<jam> oh, well I suppose that might do it
<wingo-tp> so if a previous bzr upgrade happened and did not run bzr check...
<jam> if you never access that revision, it wouldn't ever find it broken
<wingo-tp> that very well could be
<jam> specifically, we check sha1 sum whenever we extract the full text
<jam> but you may have never needed to do that
<wingo-tp> right
<jam> I'm guessing you have a very small few nodes that are effected
<jam> and it is restricted to a specific local part of ancestry
<jam> wingo-tp: how high of a priority is this for you, as in, does it block something you are trying to do?
<jam> I don't have a lot of time to write a workaround right now, unless you really need it
<jam> wingo-tp: but I *would* ask you to submit a new bug
<jam> if you can, link to the branch that shows the problem
<wingo-tp> jam: i can wait a while, i think;
<wingo-tp> how do you think this will affect people who have checkouts of this branch? they will have to re-pull, no? will all the sha1's be different, like in git?
<wingo-tp> it's  http://arch.gna.org/guile-gnome/bzr/pkg/
<jam> wingo-tp: only a few local sha1s will be changed
<jam> I'm not sure how we would be able to propagate that to everyone
<jam> it shouldn't change the whole ancestry
<wingo-tp> i should just tell everyone to branch again, no?
<jam> wingo-tp: they would have to clear out any repository that they have
<wingo-tp> ok
<jam> It is probably easier to just have them all run whatever fix I come up with
<wingo-tp> (thanks for looking at this, btw)
<jam> anyway, time for me to go to lunch
<wingo-tp> bug #239499
<ubottu> Launchpad bug 239499 in bzr "corrupt knit index on an old arch-imported bzr repo" [Undecided,New] https://launchpad.net/bugs/239499
<wingo-tp> tx much!
<Tsmith> hey
<Tsmith> I have a main trunk/ and a branches/tsmith;  I want the changes in trunk/ to be applied to tsmith/ how do i do this?
<james_w> hi
<james_w> do this:
<james_w> cd branches/tsmith
<Tsmith> k
<james_w> bzr merge ../trunk
<james_w> resolve any conflicts
<james_w> bzr resolve
<james_w> bzr commit
<Tsmith> 6: tsmith 2008-06-12 Merge with trunk -r4.
<Tsmith> 5: tsmith 2008-06-12 Change file perms to 0664 and ownership to tsmith:users.
<Tsmith> is that right?
<Tsmith> does each branch have a unique -r #?
<Tsmith> bzr is so friggin awesome :O
<pickscrape> OT: Would I be right in thinking that https://bugs.launchpad.net/php is the correct place to report bugs that only affect php on ubuntu?
<Tsmith> hey what does bzr switch do?
<Tsmith> or better: where's  the doc? :p
<pickscrape> Tsmith: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#switch
<Tsmith> great stuff
<james_w> pickscrape: https://bugs.launchpad.net/ubuntu/+source/php5
<james_w> Tsmith: each branch doesn't have unique revision numbers, however, they do have unique revision ids
<james_w> Tsmith: if you do bzr log --show-ids in your branches/tsmith branch then you will see the unique ids that they are assigned
<Tsmith> ahhhh
<james_w> you will also see the revisions from the trunk that you did not have before the merge indented under the merge commit, indicating that they were merged in there.
<james_w> you will also see that they have a three digit revision number.
<Leonidas> is there a way to mark a branch as "merged, please don't try to merge again"?
<pickscrape> james_w: thanks. So it's the *ubuntu* project, not the PHP one.
<Tsmith> revno: 3.1.1
<james_w> this means that you have the same revision on trunk and your branch, they have the same revision id which means they are the same. They have different revision numbers though.
<james_w> so if you want to talk about a specific revision then either use its revision id, or use the revision number *and* the branch in which it has that number.
<james_w> pickscrape: yup.
<james_w> Leonidas: nope, but if you try and merge again it will tell you that there is nothing to do.
<jelmer> james_w: hi
<pickscrape> james_w: how would I browse there? In other words, how should I have found that myself?
<Leonidas> james_w: yeah, thats probably good enough.
<pickscrape> (Sorry for the continued OT)
<jelmer> james_w: did you see my patch that added support for +bzr in bzr-builddeb?
<james_w> hi jelmer
<Tsmith> i'm sorry to bug you guys so much, but I wwould like to now push my local repository to my server.  What do i do so that only the bzr repository and not all the files in it are on the server?
<james_w> jelmer: yup, thanks for sending it, I shouldn't have missed it. I'll merge it tomorrow.
<james_w> pickscrape: I'm not sure, if you knew you wanted to file a bug against Ubuntu then starting at the Ubuntu project may have been right. Launchpad isn't all about Ubuntu.
<james_w> pickscrape: though these projects that are there but not used by the upstreams do confuse matters somewhat.
<jelmer> james_w: cool, thanks
<james_w> Tsmith: that will happen by default. Normally people ask why it doesn't happen the other way round :-)
<james_w> Tsmith: do you have bzr installed on the server?
<Tsmith> yes
<james_w> Tsmith: cool, "bzr push bzr+ssh://server/location/on/server" should get you what you want.
<james_w> Tsmith: though you may want to set up a revision storage area there first which will make it more efficient to push multiple branches.
<Tsmith> that'w hat i want
<james_w> Tsmith: (as an aside, I'm not sure if you are aware, but bzr doesn't care what you call your branches, so you don't need trunk/ and branches/ you can call them not-trunk/ and tsmiths-not-a-branch/ if you like)
<Tsmith> yeah
<james_w> ok, to do that then you need the "bzr init-repo" command.
<james_w> bzr init-repo --no-trees bzr+ssh://server/location/for/repo/
<Tsmith> got it!
<james_w> this creates a "shared repo". shared isn't about multiple users, it's about sharing revision storage between branches for efficiency.
<james_w> now, any branch that you push below /location/for/repo/ on your server will store it's revisions there, so when you push a new branch it will only have to push any revisions that aren't already there, which should be a lot less work.
<james_w> you may wish to set one up on your local machine as well, as it makes things like branching quicker, as well as reducing disk space usage.
<Tsmith> k
<james_w> if you do that then don't use --no-trees, as you do want the branches to have working trees, so you can actually get some work done.
<Tsmith> i have a dummy question
<Tsmith> i have a local repo w/ two branches
<james_w> doing that in your existing area won't make the existing branches use the shared storage though, I can explain how to get around this if you like.
<Tsmith> i have pushed the main repo successfully, after following your instructions.  do i now need to push the branches too?
<james_w> you ran "bzr push" while in trunk/?
<Tsmith> yes
<james_w> ok, so you pushed the trunk *branch* up
<Tsmith> yes that's right
<james_w> bzr works on branches, not on repos
<Tsmith> k
<james_w> so you have only pushed the revisions that are needed for trunk, if you want your branches to be available on the server as well then you need to push them separately.
<Tsmith> k
<Tsmith> is there the oposite of .bzr/ignore? i only want to show *.php *.inc, etc.
<Peng> Using a complicated regexp perhaps?
<mtaylor> Tsmith: just don't add anything but the *.php and *.inc in the first place?
<mtaylor> Tsmith: like "find . -type f -name '*.php' | xargs -n1 bzr add" or something?
<Tsmith> lol bzr status shows a massive list ;p
<Tsmith> i found the solution:
<Tsmith> .bzrignore in the trunk's root
<mpt> I have an obscure question about conflict resolution that isn't covered in <http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#conflicts-types>
<mpt> What should I do when I have both a path conflict and a contents conflict for the same file?
<mpt> Which should I resolve first?
<tolstoy> Folks: When I do a "push" to a local directory, I get the whole file tree. Is there a way to suppress that?
<tolstoy> We're using a server as a "source-of-truth" and I'd like to be able to properly create repos without the trees even if working locally.
<tolstoy> bzr remove-tree fixed it, I guess.
<james_w> tolstoy: yep, that will fix it. To create a shared repository that does this by default use the --no-trees option to init-repo
<tolstoy> Okay. Odd that "push" removed trees only when it's a remote file system. Then again, I guess that makes sense.
<james_w> tolstoy: yeah, it's hard to do it remotely so it doesn't
<james_w> the inconsistency with local push could be removed I guess, but so many people wonder what's wrong when remote push doesn't create/update a working tree that we should probably do it when we can.
<james_w> mpt: I'm not sure how you can have both types at once.
<james_w> mpt: I imagine you have to resolve both at the same time, in that you can only call "bzr resolve" when both are fixed.
<mpt> james_w, it was a criss-cross
<james_w> mpt: in terms of doing it you probably want to move the correct file in to place first, and then fix the content.
<mpt> ok
<mpt> We have a maximum branch length, so I thought I'd be clever and pull some revisions out of this branch and merge them into mainline, and then merge mainline back into this branch
<mpt> (a maximum branch length for code review purposes, I mean)
<mpt> ... But I forgot that I'd renamed the files in this branch, in a revision *after* the one I merged into mainline.
<pickscrape> Is there any plan in place for allowing partial working copies?
<lamont> is it normal for bzr visualise to say 'AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'" ??
<lamont> that's bzr 1.6~beta2-1 and bzrtools 1.6.0-1, fwiw
<james_w> pickscrape: at the last sprint we talked about a way that would let you do that and a few other things, but I don't think anyone's got anywhere near implementation.
<james_w> lamont: hi, what's your version of bzr-gtk?
<lamont> 0.93.0-1.
<lamont> I bet that's it, eh?
<james_w> yeah, that's too old
<pickscrape> james_w: thanks, good to know it is at least in mind. That's one thing I know I'll get a few complaint about when we switch :)
<lamont> 0.94.0-1 is new enough?  (latest intrepid)
<james_w> pickscrape: yeah, though we're even further off limiting the amount of repository data you need for a partial working tree.
<Tsmith> hey bzr up -r4 filename doesn't work.  is there a way to update a file to a particular -r?
<james_w> pickscrape: so it would at least allow you to ignore parts of the tree you didn't care about, but wouldn't reduce the time to branch
<james_w> lamont: I don't think it will be, we should really get that updated.
<pickscrape> james_w: I'm not actually bothered about that. It's mainly so people can just 'checkout' the bits they actually care about with regard to the work they're currently doing.
<pickscrape> They'll all be using shared repositories anyway, so they'll have the lot regardless.
<lamont> james_w: pretty please... :-)
<pickscrape> But I understand that in the more general use case limiting revision size would also be nice :)
<james_w> lamont: I don't think there's been a release to update to though.
<lamont> james_w: yeah... 0.94.0 according to http://bazaar-vcs.org/bzr-gtk?action=show&redirect=BzrGtk
<james_w> lamont: if you can confirm whether 0.94 works I would appreciate it.
<james_w> pickscrape: yeah, I think that's why a lot of people want it, but it can be done in separate stages at least.
 * lamont builds bzr-gtk_0.94.0-1~hardy1
<james_w> pickscrape: I wouldn't want it to lead people to mix projects in one branch though.
<pickscrape> At the moment we do it in svk by doing svk co -N and then svk revert -R on each subdirectory we want
<james_w> pickscrape: we can have nested trees for allowing people to grab a related set of branches.
<Tsmith> omg
<Tsmith> is bzr up -rrev not supported? :o
<james_w> Tsmith: nope, sorry, missed your question.
<james_w> you probably want "bzr revert -rrev filename"
<pickscrape> james_w: Hmmm... nested trees... I'll have to have a look at that.
<james_w> beuno: hi, you around?
<lamont> james_w: bzr-gtk 0.94.0-1 is love
<james_w> lamont: ah, great, thanks
<beuno> james_w, hey, yeah
<james_w> beuno: unping :-)
<beuno> james_w, cool :)
<beuno> hi anyway
<james_w> hi, how are you?
<beuno> pretty good. Knee deep un loggerhead code. Yourself?
<james_w> good thanks.
<tolstoy> beuno: Loggerhead? Is that being updated since the ancient stuff at the website?
<james_w> tolstoy: there was a release recently, at which website are you looking?
<tolstoy> Hm. I'm looking for it now.
<tolstoy> I last looked some weeks ago.
<james_w> the maintainer has changed, and I don't know if that has left an old website around.
<tolstoy> What's the "new" one?
<beuno> tolstoy, we updated trunk yesterday
<tolstoy> https://launchpad.net/loggerhead?
<tolstoy> http://www.lag.net/loggerhead/
<tolstoy> Ah, that's the home page I've seen before.
<beuno> tolstoy, launchpad, yes
<tolstoy> So if I want to use it, I should just "bzr" it?
<beuno> we hope to release a new version in a while
<beuno> yeap
<tolstoy> Sounds good.
<tolstoy> I've got the unpleasant task of trying to configure it to "view" multiple branches of multiple projects.
<beuno> tolstoy, let me know if I can help you with that  :)
<tolstoy> Will do.
<tolstoy> Er, I'll see if I can find a mailing list for it.
<tolstoy> Are you Michael Hudson?
<tolstoy> Ah, Martin. Okay.
 * mwhudson bounces
<beuno> tolstoy, that's Michael Hudson  ^  :)
<beuno> mornin mwhudson  :)
<mwhudson> hello
<mwhudson> beuno: so i'm increasingly of the opinion that paste provides enough bits to build the server side of loggerhead
<beuno> mwhudson, glad to hear that
<beuno> it seemed to me that it's used for enough use cases that it should fit ours
<mwhudson> yeah
<mwhudson> and it's use-the-bits-you-need approach, while a bit confusing, means that we don't get lumbered with things like stupid url mangling (for example)
<mwhudson> i think paste + simpletal is a reasonably nice small set of dependencies too
<beuno> yes, absolutely
<mwhudson> i can see how this would let me write a plugin
<beuno> they both have nice packages too
<mwhudson> hm, not sure instantly how to run a paste server in the background
<mwhudson> i'm sure there's something for that though
<beuno> well, I was thinking of looking into how pylons uses it for that part
<thumper> mwhudson: paste?
<mwhudson> thumper: http://pythonpaste.org/
<thumper> mwhudson: to replace turbogears and cherrypy?
<mwhudson> yeah
<Tsmith> hi
<Tsmith> how can you tell where a .bzr repo is pulling from?
<Peng> Tsmith: You mean a branch. And, "bzr info".
<Peng> Also, if you run "bzr pull", it gives it. :P
<Tsmith> tahsnkf ro bzr infoo ;)
<Tsmith> so if you do bzr co bzr+ssh://, bzr behaves almost exactly like svn, in that when you commit, you can up on another system with the same co, but if you bzr branch, you have to do pull from the bzr+ssh:// to get the updates
<Peng> If you use a branch, yeah, you have to push/pull.
<lifeless> moin
<lifeless> mtaylor: yes ext3 is remarkably slow about delete in that case :)
<pickscrape> Would anyone be able to point me in the right direction with solving this: 'KnitPackRepository' object has no attribute 'get_revision_graph' (from trac-bzr)
<lifeless> pickscrape: that was an old api, which was O(history)
<lifeless> pickscrape: these days you would do g = repository.get_graph(), and then make whatever graph queries you need
<pickscrape> lifeless: seems that trac-bzr is still using it. Thanks for point me at that, I'll have a look at fixing it.
<lifeless> np
<pickscrape> lifeless: trac-bzr was using the output from ï»¿get_revision_graph as input for tsort.merge_sort, but it's not liking what comes out of get_graph. I've tried get_graph().iter_ancestry(), to no avail. Any clues?
<lifeless> iter_ancestry yields tuples
<lifeless> key, values
<lifeless> values is None sometimes, when there is a ghost
<lifeless> so filter those out and you should be fine
<lifeless> for revid, parents in iter_ancestry:
<lifeless> if parents is not None:
<lifeless> parent_map[revid] = parents
<lifeless> then feed parent_map to tsort.merge_sort
<pickscrape> lifeless: thanks, I'll give that a go. Not sure how I've got ghosts in my repos though, they're pretty small.
<lifeless> well, you may not need the filtering, others will
<pickscrape> Yes, I really meant that might not explain why it's not working for me already
<lifeless> pickscrape: fair enough
<lifeless> mtaylor: hi
<mtaylor> hi lifeless
<lifeless> mtaylor: yes, ext3 finds deletes of massive trees problematic :)
<mtaylor> the rm was killing my box earlier for that reason, so I stopped it
<mtaylor> I'm going to re-run it tonight while I sleep
<lifeless> you can just mv .bzr/bzr-search delete-me
<lifeless> bzr index
<mtaylor> lifeless: good point
<mtaylor> I did index a smaller project quite quickly
<mtaylor> I get this now:
<mtaylor> $ bzr search SF_ReadRangeNo
<mtaylor> File id 'ndbscanoperation.jav-20070517181935-98huwjarzuh25b30-25', revision 'mtaylor@mysql.com-20071120023241-84qiaykyp2sv70yk'. Summary: 'No summaries yet.'
<lifeless> cool
<lifeless> need to do a summary of why it hit though
<lifeless> the file_id, revision_id tuple can be used to get the tree:
<lifeless> revtree = repository.revision_tree(revision_id)
<lifeless> file_contnet = revtree.get_lines(file_id)
<lifeless> path = revtree.id2path(file_id)
<lifeless> or we can get the bytes without the file via repository.iter_file_bytes
<mtaylor> neat
<lifeless> then its simply a case of repeating the index on that file and choosing a part of it to display
<lifeless> we might want to store such coordinates in the index to handle big files better
<mtaylor> ok. running a new index on mysql... and going to bed...
<lifeless> gnight, and thanks for guinea pigging this
#bzr 2008-06-13
<foxbuntu> can someone give me a hand with this mess: http://paste.ubuntu.com/19747/
<bob2> do you have a /.bzr dir or something?
<foxbuntu> bob2, where?
<bob2> in /
<foxbuntu> of the branch...yes
<foxbuntu> this branch has been fine until tonight
<bob2> no, in /
<foxbuntu> oh
<foxbuntu> nope
<bob2> or does ~/Desktop/mythbuntu_branches/mythbuntu-apple-trailers contain etc?
<foxbuntu> it used to, I removed it
<bob2> did you touch anything in  ~/Desktop/mythbuntu_branches/mythbuntu-apple-trailers/.bzr?
<foxbuntu> nope
<bob2> dunno, sorry - perhaps try the list?
<foxbuntu> bob2, I resolved it, I must have broken it somehow, I just pulled the lastest copy of the branch and it works now
<jml> I often find myself wanting to switch to the top thread of a loom or to the bottom thread.
<jml> What would be a good command line syntax for this?
<lifeless> hmm
<lifeless> switch top: switch bottom: I guess
<lifeless> if you mean switch and not up-thread
<jml> I do mean switch.
<lifeless> k
<jml> who do I speak to if I want to get my blog syndicated to Planet Bazaar?
<lifeless> pooolie
<mkanat> Hey hey.
<mkanat> How do I exclude a particular directory from a "bzr diff"?
<lifeless> bzr diff | filterdiff -x dir
<lifeless> is what comes to mind
<mkanat> lifeless: Okay.
<mkanat> I assume that's part of patch-utils.
<lifeless> diffutils I think, but yeah
<mkanat> Ah, yeah.
<mkanat> lifeless: I tried diff-options="--exclude" once, but that didn't work.
<lifeless> probably need "--exclude old/PATH"
<lifeless> but we call diff individually, not sure it would honour it in that case
<mkanat> Ahh, hmm.
<mkanat> I'll try.
<lifeless> wow, http://andrew.puzzling.org/ is a little borked. or something
<mkanat> lifeless: filterdiff doesn't work.
<lifeless> mkanat: no?
<lifeless> mkanat: I find I usually need to tweak the pattern a little to make it happy then it plays nice
<mkanat> bzr diff -rancestor:bzr://bzr.everythingsolved.com/bugzilla/3.2 | filterdiff -x extensions/ > ~/diff
<mkanat> I tried it without the / too.
<lifeless> mkanat: also, please do file a bug, -x is reasonable to have
<mkanat> Does it need a * or something?
<mkanat> lifeless: Okay. :-)
<lifeless> mkanat: try new/extensions
<mkanat> lifeless: Okay.
<lifeless> (and variations). or old / - see thhe path in the diff header
<mkanat> === added file 'extensions/launchpad/code/install-before_final_checks.pl'
<mkanat> --- extensions/launchpad/code/install-before_final_checks.pl    1970-01-01 00:00:00 +0000
<mkanat> +++ extensions/launchpad/code/install-before_final_checks.pl    2008-06-12 21:24:07 +0000
<bob2> lifeless: a.p.o -> displaying mashed up text snippets of the entries?
<lifeless> bob2: yeah
<lifeless> like apache had a bad day
<lifeless> spiv: ^
<lifeless> mkanat: oh. emm, try "extensions/**" then I guess
<mkanat> lifeless: Ahh, good idea. :-)
<mkanat> lifeless: Ahh, yep. :-)
<mkanat> I did it with just * but that worked.
<bob2> some weird firefox/backwards interaction
<lifeless> bob2: it works with other thing?
<lifeless> spiv: ping
<lifeless> reconcile on knits of launchpad -> pain
<cara> Hi all
<lifeless> hi
<poolie> hi lifeless
<poolie> i'm going to read "stackable branch ui 2"
<cara> I'm having an issue with bzr where it gives me this error message. bzr: ERROR: Path(s) are not versioned: These are the steps I took to get this error message:
<cara> 1) bzr init <directory>
<cara> 2) cd <directory>
<cara> 3) bzr branch <url-to-branch/trunk>
<cara> 4) bzr branch <url-to-branch/trunk> mybranch
<cara> 5) cp /files/I/needed/for/mybranch /path/to/mybranch
<cara> 6) cd /path/to/mybranch
<cara> 7) bzr commit /path/to/files/in/mybranch
<cara> whoa lag
<poolie> cara: you need to bzr add the new files
<cara> ooo
<poolie> cara, 'bzr add' in the root of the branch should be enough
<cara> hehe
<cara> for the files I copied over?
<cara> or do I copy them over that way?
<mkanat> lifeless: bug 53992 was already there.
<ubottu> Launchpad bug 53992 in bzr "diff should have an -x option (exclude certain files)" [Wishlist,Confirmed] https://launchpad.net/bugs/53992
<lifeless> cool
<poolie> after you've copied them in
<cara> do I still have to commit them?
<poolie> yes
<poolie> add tells bzr to track them
<poolie> commit actually takes a snapshot
<cara> oh
<cara> ok
<cara> thanks poolie
 * cara hugs poolie
<cara> you're such a sweetie
 * cara would have been up all night trying to figure out what the heck was going on 
<cara> I kinda just jumped into the bzr thing.
<poolie> you're welcome
<cara> you just don't know how happy I am right now lol
<poolie> i'm really happy to hear that then :)
<poolie> please do ask if there's anything else confusing
<cara> oh yeah.. How do I remotely remove a branch I created?
<cara> would I have to literally log onto the server and delete the branch? I actually pushed the branch
<mneptok> cara: IIRC, bzr remove-tree protocol:/path/to/branch
<RAOF> mneptok: That's not actually going to remove the branch, though, just the working tree, right?
<mneptok> RAOF: yeah.
 * mneptok pouts
 * RAOF :P
<thumper> can't you just use ssh to remove it ?
<thumper> cara: it depends on what access you have to the remote machine
<jml> cara: is this on Launchpad?
<cara> launchpad?
<cara> thumper: I don't know
<thumper> cara: where did you push the branch?
<thumper> cara: and what command did you use?
<cara> bzr push bzr+ssh http://link.to.branch
<lifeless> yay tshirt
<cara> err
<cara> bzr push bzr+ssh http://link.to.branch cara or something
 * cara is sleepy
<thumper> lifeless: I got one too :)
<thumper> cara: perhaps best to come back when not sleepy :)
<thumper> cara: or do you really need to get rid of it now?
<cara> nah I will come back later thanks thumper
<cara> hey thumper do you use gentoo?
<thumper> cara: nope, kubuntu
<jml> lifeless: yeah, mine arrived yesterday
<cara> hehe I use kubuntu too :)
<lifeless> so, is this inversely proportional to code written or something
<cara> I thought I seen you in a gentoo channel looooooooooooooooooooooooooooong time ago
<mwhudson_> i got mine yesterday too
<cara> been trying to figure out how set the time
<cara> everything is grayed out
<thumper> cara: right click on the clock applet and click on "set date and time"?
<thumper> cara: s/set/adjust/
<jml> lifeless: if it were inversely proportional, I would have got mine five years ago.
<mwhudson_> :)
<lifeless> jml: order not dates
<lifeless> loonch time
<poolie> cara: you need to press the 'unlock' button in that window
<poolie> it's a bit unobvious
<poolie> it's meant to be like the mac idiom of showing things readonly until you authenticate
<poolie> which is not a bad idea, but doing it just in one place in confusing
<poolie> hth
<beuno> got a the tshirt today too  :)  (evening)
<poolie> oh great
<beuno> thanks poolie
<lifeless> beuno: I've pushed the change I was mentioning yesterday
 * poolie takes a deep breath
<poolie> ok seriously into your collossal patch now
<lifeless> sorry :)
<bob2> haha
<lifeless> bob2: 17K lines.
<beuno> lifeless, ah, just pulled revision 29
<beuno> si it won't break on re-indexing now?
<lifeless> right
 * beuno goes look at the code
<lifeless> should a second or two to index a new commit too
<bob2> heh, net negative lines of code, tho
<lifeless> yah
<beuno> lifeless, so. Get the current list of revids, and go one by one through the revids in the branch, and stop when you find a match?
<lifeless> get the current index (lazy load - no IO at that point), then yes. Oh, I forgot to stop the search, thats why its slow.
<beuno> :)
<beuno> I was going to ask how you did that part
<lifeless> $ time bzr index
<lifeless> real    0m1.257s
<lifeless> user    0m0.792s
<lifeless> sys     0m0.184s
<lifeless> incremental on bzr.dev
<lifeless> still too slow
<bob2> is the ideal for it to be fast enough to run it automatically when the branch is altered?
<lifeless> I want a tip_change hook for it
<lifeless> then my branches can be indexed
<bob2> spiffy
<lifeless> and I can forget its installed
<beuno> that would be cool
<beuno> and fairly easy I suppose
<lifeless> lsprof-file ftw
<lifeless> oh well, I guess it can fork()
<lifeless> 81% in bzrlib.index.GraphIndex.iter_entries()
<lifeless> I have to fix that, but not today.
<lifeless> oh heh. that explains why its slow.
<lifeless> I'm reconciling knit based launchpad in another window, and I forgot.
<beuno> lol
<lifeless> still: just did a pull() on bzr.dev:
<lifeless> $ time bzr index
<lifeless> real    0m8.902s
<lifeless> user    0m6.540s
<lifeless> sys     0m0.312s
<beuno> yeah, 8sec may be a too slow for a handful of revisions
<lifeless> thats with reconcile in background
<lifeless> I'm not unhappy :)
<lifeless> will try later and see
<beuno>                                                                                                                                                             
<beuno> real	2m26.834s
<beuno> user	2m19.133s
<beuno> sys	0m0.888s
<beuno> new index on bzr.dev
<lifeless> :)
<lifeless> not bad
<lifeless> should be subsecond to run again
<lifeless> oh, let me push
<beuno> and
<beuno> beuno@beuno-laptop:~/bzr_devel/bzr.dev$ time bzr index
<beuno> real	0m5.908s
<beuno> user	0m5.756s
<beuno> sys	0m0.160s
<beuno> after pulling and re-indexing
<beuno> ~3 seconds when there is nothing to index
<lifeless> you want revno 30, pushing up now
<beuno> :)
<beuno> 0.2sec
<lifeless> yeah
<lifeless> so that should be 3 seconds to index new revs above, not 6
<beuno> yeah, shaved off those 3 seconds to compare
<beuno> stopping the iteration and only removing NULLs if there actually are any
<beuno> this is shaping up nicely!
<mwhudson> hello again beuno
<beuno> hi again mwhudson
<mwhudson> beuno: is https://code.edge.launchpad.net/~beuno/loggerhead/zpt.cleaner_urls up to date?
<beuno> let me check
<beuno> mwhudson, yes. It's missing the navigation links fix, which is what I was starting now
<mwhudson> ok
<bob2> lifeless: should index lock the branch?
<lifeless> bob2: it read locks it
<bob2> ah
<lifeless> bob2: oh, during the what-to-index lookup
<mwhudson> beuno: i don't think you need to pass the revno into the revisioninfo template function
<lifeless> it does
<mwhudson> beuno: doesn't the change parameter have a revno attribute?
 * beuno checks
<beuno> mwhudson, do you mean the revid?
<mwhudson> ah uh one moment
<mwhudson> the way loggerhead does urls makes me so sad :(
<beuno> good, I like it when we hate the same things
<beuno> makes it more probable to get rid of it
<beuno> I had to add that to display the revid in the revision view
<beuno> because we didn't show it before, which I think is dumb
<mwhudson> isn't there change.revid then?
<mwhudson> yes, that's an improvement
<beuno> well, we don't pass change to revid AFAIK
<beuno> ah, wait
<beuno> maybe we do
<mwhudson> ... of course, after we've got rid of the revision cache we should just be passing bzrlib Revision objects around ...
<beuno> yes please  :)
<beuno> revision cache is my next target
<mwhudson> sweet
<mwhudson> i guess it will be a two phase thing
<mwhudson> delete the cache
<mwhudson> get rid of these bizaare change/entry things
<mwhudson> though we may need to be slightly clever to carry revnos around
<beuno> mwhudson, we don't pass change
<mwhudson> -def revisioninfo(url, branch, entry, modified_file_link=None):
<mwhudson> +def revisioninfo(url, branch, entry, revid, modified_file_link=None):
<mwhudson> what is entry here then?
<mwhudson> but well, ok :)
<beuno> it doesn't have revid for some reason  :/
 * beuno is confused now
<beuno> ok
<beuno> I *do* have change
<mwhudson> the -history.get_revno(entry.revid)+entry.revno stuff is kinda funny
<beuno> funny as in...?
<beuno> it seemed unnecesary to go get that info when we already have it
<mwhudson> funny as in "ha ha how bad is loggerhead"
<beuno> heh, yes. There seem to be a few layers of randomness on it
<beuno> fixed and pushed my revid nonsense
<beuno> and I missed something, revision 245 coming up
<beuno> hm, loggerhead is playing with my head
<mwhudson> it does that
<beuno> ok, no 245, loggerhead just has the habit of not dying when I tell it to
<beuno> so *I* was right, not *it*
<mwhudson> the proper thing to remember is that the answer to the question "is there a reason for it doing this particular thing this odd way" is usually "no"
<beuno> heh, yes, I learned that the hard way
<mwhudson> me too :)
<beuno> I spent quite a few hours looking at code, thinking I was missing something
<beuno> we should add that to the README  :p
<mwhudson> we seem to be making great strides on replacing the entire code base
<mwhudson> which should alleviate the need for that :)
<beuno> yes, that's a more optimistic way of looking at it
<beuno> I'm just mad at it for making me go in circles for 10 minutes
<beuno> now, let's get revnos into navigation links working properly...
<mwhudson> beuno: at some point (probably not right now) we should have a think about what we _want_ loggerhead's urls to look like
<beuno> mwhudson, absolutely. Have a plan rather than a mashup of things. I'll give it some thought
<mwhudson> any kind of plan, no matter how insane, would probably be progress
<beuno> I kinda like the idea of mimicking bzr commands
<beuno> like log/revno
<beuno> may be more intuitive for everyone, users and developers
<poolie> lifeless: cstringio has some kind of limitation wrt binary data but i can't remember precisely what it is
<poolie> do you know?
<poolie> is it only if you give it unicode objects?
<mwhudson> yes, don't give cStringIO unicode
<mwhudson> very strange things happen if you do
<mwhudson> it really should be 8 bit clean though :)
<lifeless> poolie: yes
<lifeless> poolie: StringIO(u'foo').getvalue() returns bytes such that decode('UCS4') works :{
<lifeless> (e.g. the native internal representation of u'' strings is coerced into a plain string
<lifeless> mwhudson: they are not strange, very predictable
<mwhudson> lifeless: well
<mwhudson> i don't think strange and predictable are necessarily in opposition
<lifeless> :)
<mwhudson> 'suprising'
<lifeless> sure
<lifeless> 'not inferrable until seen'
<lifeless> does 3K fix this
<lifeless> if not someone needs bitchslapped
<mwhudson> beuno: brain too fuzzed to review the branch properly i think
<mwhudson> i'll get to it over the weekend or monday morning
<beuno> mwhudson, sure, no problem. I'll push the navigation changes in a while, so you can do a complete review
<mwhudson> cool
<beuno> And wrap up the theme tomorrow. At least the changelog and generic stuff
<beuno> still working on the diff view to get the html/css *just* right
 * mwhudson stops for the day
<beuno> mwhudson, navigation links fix pushed
<beuno> ah, well, have a good weekend then  :)
<mwhudson> you too!
 * beuno is one day behind so still has friday  :p
<beuno> so that means I may still get bzr-search into an experimental branch  :)
<beuno> that's it for me today too
<beuno> g'night
<lifeless> beuno: gnight
<Tsmith> hey
<lifeless> hi
<Tsmith> i'm trying to uncommit a revision, but i keep getting the message "Unable to obtain lock file:///var/bzr/blinds.com/.bzr/branch/lock
<Tsmith> held by tsmith@blinds.com on host 5200MHz.xmule.ws [process #11135]
<Tsmith> locked 7 hours, 25 minutes ago
<Tsmith> "
<lifeless> well, is that process still alive ?
<lifeless> (if thatis your host, check with ps ax/top)
<Tsmith> i guess i should check both hosts
<Tsmith> 11135 is not an active process
<lifeless> if its not alive anymore, try bzr break-lock
<Tsmith> is that the same thing w/ CVS locking up and me requiring a sourceforge ticket?
<lifeless> not really
<lifeless> cvs is broken-by-design in this area
<Tsmith> ha
<lifeless> you can break your own lock
<Tsmith> i read a fictional story today about dvcs changing a woman's life
<lifeless> we can't avoid stale locks completely - network interruptions/power failures etc
<Tsmith> but i really do feel like bzr changed my life
<lifeless> cool!
<Tsmith> <-- my wifi scrwed up
<Tsmith> when the lock happened
<lifeless> yah
<Tsmith> (i'm not crazy, but using BZR after 10 years of CVS or SVN (the last year) produces feelings in me akin to when i saw the grand canyon for the first time)
<Tsmith> esp when i bzr switch branches ;o
<lifeless> :)
<jamesh> vertigo?
<Tsmith> yeah exactly
<Tsmith> now i'm just wondering if there's a place i can plunk down a few hundred to inspire someone to create bzr up -r functionality
<lifeless> I believe there is a crude patch
<lifeless> needs some love
<Tsmith> i specifically need it to update files based on datetime diffs
<Tsmith> like svn up -r {2008-06-10}
<Tsmith> i find bugs all the time ni a codebase of 1.5 million lines
<Tsmith> i have to do a LOT of sleuthing by date
<lifeless> ah. bisect doesn't help ?
<lifeless> hmm, this is the sort of case bzr-search _might_ help with
<Tsmith> i do not see that command bzr help commands
<lifeless> bisect is a plugin
<Tsmith> the company i work for, i'm the lead "fixit" guy
<Tsmith> we have a 4-server dev cycle; code on your box, up to dev server, up to UAT, up to prod
<Tsmith> the problem is, the lead of each site ups all the code to the prod server for htat site
<Tsmith> they do this using svn
<Tsmith> by hand
<Tsmith> like svn diff -r100...101 > changes.diff; patch -p0 < changes.diff
<Tsmith> there's no branching
<Tsmith> there's no tagging
<Tsmith> it's actually pretty sad; for every 3 bugs fixed, 5 more are created, 3 alone by this very merge process; and there's no way to revert
<Tsmith> the main pusher for the main website in March, for instance, accidentally svn up'd in the root of the prod, and we spent 2 months cleaning up the damage
<Tsmith> lol
<lifeless> ouch
<Tsmith> so i'm in charge of www.blinds.ca
<Tsmith> i am responsidble for all the pushes
<Tsmith> what *I* do is i have a bzr repository w/ branches that mirror my local box, dev, uat, and prod
<Tsmith> and i run rsync against the prod before i do a commit, so i can revert the commit if there are any problems
<Tsmith> cuz every one uses svn and management is very hostile towards positive change (they love negative change, incidentally)
<lifeless> erg
<lifeless> you have my sympathy
<Tsmith> nah man bzr saves me lol
<mtaylor> lifeless: real	32m52.967s
<lifeless> mtaylor: thats significantly faster. woo
<mtaylor> yup. woo indeed!
<lifeless> mtaylor: also, it will auto-update if you grab the latest code
<mtaylor> the index will?
<mtaylor> good
<Tsmith> lifeless: bzr bisect is exactly what i need; awesome!
<lifeless> Tsmith: cool
<Tsmith> gosh
<Tsmith> i think some of the people in this channel need to give me thier paypal addresses (lloks @ lifeless)
<jml> Tsmith: lifeless's paypal address is jml@mumak.net
 * jml whistles innocently
<lifeless> jml: thank you for proxying my due
<lifeless> (I don't use paypal)
<mtaylor> Tsmith: mine is monty-paypal@inaugust.com
<mtaylor> Tsmith: but I didn't write any of bzr
<lifeless> Tsmith: seriously though, there's no need - I am partly-paid, partly scratching-my-own-itch for what I do on bzr.
<lifeless> Tsmith: if we are ever in the same city, all I would say is 'buy me a beer'
<Tsmith> ha what city are you in/
<lifeless> Sydney for most of the year
<Tsmith> sorry i dont think that's in my path ;p
<lifeless> but work has me travel frequently - I'm at UDS for example
<lifeless> We'll likely be in the US again late this year
<AfC> Rebase creates new revisions with different parents and thus the potential for later merge conflicts, right?
<AfC> Is `bzr merge [--force] ../other-branch/path/to/file` or `bzr merge -r 526..527 ../other-branch` any different?
<mwhudson_> i think rebase basically does bzr merge -r N..N+1 over and over again, doesn't it?
<AfC> mwhudson_: {shrug}
<AfC> I'm more interested about whether either preserves *any* information in super secret revision properties that might someday in the glorious future be useful to construct better histories / merges. If so, then that would be the technique to prefer, I would have thought.
<AfC> ï»¿/me is attempting to cherry pick. What an surprise.
<AfC> [Robert has been so adamant over the years that rebase is evil that I don't even have the plugin installed]
 * mtaylor doesn't understand the need for rebase
<lifeless> anecdotally, re rebase-is-bad http://blog.red-bean.com/sussman/?p=96
<bob2> linus is mostly anti-rebase for more pragmatic reasons
<matkor> http://bundlebuggy.vernstok.nl/bzr-gtk/ dead ?
<vila> lifeless: excellent blog entry ! I sooo agree...
<lifeless> gnight all
<fdv> Hi. I'm getting the following slightly cryptic error from bzr rspush: "bzr: ERROR: Unprintable exception NotStandalone: dict={'_preformatted_string': None, 'location': 'file:///local/bzr/main/main/'}, fmt=None". Does anybody know what this means?
<james_w> hi fdv
<james_w> that's a bug in the exception class that is causing it to print that garbled message
<james_w> as to the real meaning is should be displaying something like "bzr: ERROR: Something about the branch not being standalone: file:///local/bzr/main/main/"
<fdv> james_w: ok..
<james_w> apparently rspush only works if you have a standalone branch, not using a shared repository
<fdv> but what does standalone really mean here?
<james_w> fdv: if you could file a bug against bzrtools for the first bit that would be great
<fdv> I'll try :)
<james_w> a branch is not standalone if it is using a shared repository, or it is bound somewhere else. Are either of those true here?
<fdv> I've branched from an svn repo
<fdv> but I don't think it's bound
<fdv> that'd mean I'd either have had to do a checkout or a bind, right?
<james_w> yup
<james_w> are you using a shared repository?
<fdv> ehrm..
 * fdv feels kind of stupid :p
<fdv> what's a shared repo? :)
<james_w> ah
<james_w> it's what you get with the "init-repo" command
<fdv> really?
<james_w> it's an area where branches can share their revision storage to reduce disk space usage, and to speed up branching and fetching operations
<fdv> I've done bzr init-repo --rich-root-pack; svn branch <svn repo>; svn pull <svn repo>
<james_w> yup, you've got a shared repo then
<fdv> aw, right
<gour> what's wrong with svn?
<james_w> you could also ask for the error message to be improved in the bug report.
<fdv> james_w: I'll do that
<fdv> thanks
<fdv> gour: what do you mean?
<james_w> no problem
<gour> 11 RCs with "...It contains
<gour> a couple of critical bugfixes implemented since the release of
<gour> 1.5.0-rc9"
<gour> it's better to throw white towel into DVCS ring
 * gour is waiting for svn-1.5 to use bzr-svn. bloody deps on that bindings :-/
<fdv> gour: will it be easier to use bzr against svn 1.5?
<gour> fdv: yes, no need to patch as with 1.4 (memory leaks)
<fdv> gour: right
<fdv> gour: I did incremental pulls, that seemed to work somehow
<gour> fdv: i need svn only for pandoc, nothing else, neither i want to have it ;)
<fdv> :)
<gour> i'm told that next release of bzr-svn won't depend on svn's (python) bindings
<fdv> right
<nevans> so... now that bzr is super duper fast, when are we gonna get good cherry-picking support and nested branches?  ;-)
<nevans> more to the point, is there some way to tease the current milestone priorities out of launchpad?
<nevans> or is there some way that someone (like me) with very limited python experience and time can help push those things forward?  :)
<james_w> hi nevans
<james_w> I think the best way to help at the moment would be to test stacked branches and help shake out any bugs so that we can release 1.6 with fewer bugs
<james_w> once that's shaken out then some of the other features will have more chance to get worked on
<nevans> testing I can do.  :)
<nevans> (although I've occasionally had to hold back at older versions because of bzr-svn regressions, and I need to use bzr-svn for my day job)
<james_w> ah, I don't know if bzr-svn is compatible with what will be 1.6 yet.
<jelmer> the 0.4 branch is
<james_w> hi jelmer
<james_w> good to know
<nevans> jelmer: you're awesome.  ;-)  I'm using 0.4 -r1219 at the moment.
 * james_w remembers to go and merge jelmer's patch
<nevans> james_w: should a bzr client (<1.6) be able to access stacked branches via bzr:// (presumably the server is at 1.6)
<james_w> nevans: no, I don't think that will work, I'm not sure though.
 * gour just converted (with tailor) one darcs project file and now start serious use of bzr :-)
<gour> *starts
<gour> i need to push changes from my laptop to the desktop...with darcs i went via ssh. what to use with bzr?
<gour> (there is no web-access to the desktop, only ssh)
<pickscrape> ssh?
<Verterok> gour: bzr push sftp://desktop/path/to/branch
<Verterok> or bzr push sftp://gour@desktop/path/to/branch
<gour> Verterok: thanks, the 2nd one worked. what would be required to use bzr+ssh ?
<bob2> just need to have bzr in your PATH on the remote side
<gour> i've bzr on remote side in PATH
<gour> is the syntax same as with sftp?
<bob2> just need to use bzr+ssh:// instead of sftp
<gour> cool. i had problem with the syntax earlier ;)
<gour> bzr+ssh is probably recommended for such usage..
<toyto1> gour: with bzr+ssh, the server must have an installed bzr?
<gour> toyto1: it has. it's my desktop machine
<toyto1> gour: ah :) thanks gour. We use sftp but it's okay for now, but does bzr+ssh would be faster than just sftp? or with bzr in the server would be the choice if speed is a concerned?
<gour> toyto1: it must be faster
<gour> toyto1: yes, bzr+ssh needs bzr on the server-side
<toyto1> gour: thanks for sharing gour :)
<gour> toyto1: you're welcome
<LEW21> Hi! Is it possible to use $Id$, $Rev$ etc. in Bazaar?
<james_w> LEW21: no, not yet, sorry.
<james_w> hopefully in the next couple of releases.
<LEW21> Ok, thanks
<dpm> is there a way to make 'bzr commit' ignore files which differ only on their timestamp (i.e. they are binary identical)?
<fullermd> We call that 'bzr commit'   8-}
<dato> dpm: commit does that by default
<dpm> hmm, I might have misread the diff on my last commit, then. I could have sworn that the two files were identical.
<dpm> thanks for the info
<fullermd> That's one behavior I *SO* don't miss from CVS...
<fredreichbier> hm, how do i exclude a file from a commit although it changed?
<dato> dpm: maybe the executable bit was changed?
<dato> well, 5 min was enough for mr. fredreichbier
<dato> fullermd: what?!
<fullermd> dato: Well, it doesn't actually make a new revision, but the file shows up for commit forever when the timestamp is changed.
<dpm> ok
<abentley> ï»¿fredreichbier:ï»¿ specify all the files you *do* want to commit.
<dato> abentley: he left (hence my comment)
<abentley> dato: How dare he! :-)
<ddaa> jelmer: ahoy
<jelmer> ddaa: hi!
<gmpff> I need to decide on a distributed VCS.
<gmpff> What's the biggest advantage of bzr above the rest (i.e. hg, darcs, git, monotone) ?
<lifeless> jelmer: just missed him :)
<lifeless> gmpff: its nice to use ?
<gmpff> lifeless: That sounds reasonable.
<metajack> has anyone gotten bzr-svn to work on osx leopard with recent subversion trunk without segfaulting?  I followed instructions in the wiki, but it just crashes trying to fetch from an https url, and for svn+ssh it hangs.
<lifeless> metajack: I don't know either way. jelmer: might
<jelmer> metajack, does it hang for svn+ssh or is it just slow?
<metajack> i thought it was just slow, but i let it run for quite a while. it was not chewing up memory or anything.
<lifeless> gmpff: seriously, we're reasonably fast (and improving). For most things you want to do there is a way to do it in all of (dvcs*). There are some unique things in each dvcs,
<gmpff> lifeless: I]
<jelmer> metajack: If you run with -Dtransport it will write debug output into ~/.bzr.log
<metajack> jelmer: ok, i'll do that quick.
<gmpff> lifeless: I'm not too concerned about speed. More about easy branching and merging, seamless disconnected operation and serverless sharing.
<lifeless> we have had a focus on doing the right thing, being truely lovable, from day 1. And we have an inode abstraction which gives us true renames (as far as I know that is unique to darcs and bzr)
<lifeless> we have _very_ robust serverless sharing
<lifeless> and branching is easy, as is merging
#bzr 2008-06-14
<lifeless> we're pretty good on disconnected, if I may say so myself
<gmpff> I saw the story about the renames as first class citizens. And usability seems to be a big driver.
<gmpff> Cool - thanks for the info! Think I'll give it a try.
<lifeless> excellent. Just ask here and I'm sure someone will give you a hand, though often weekends are a little quieter than the week
<gmpff> Thanks.
<jelmer> lifeless: Do you know what triggers display or hiding of progress bars?
<lifeless> jelmer: yes
<jelmer> lifeless: bzr-svn's progress bars are sometimes not shown by bzr, even though I know they'r ebeing created
<lifeless> do they appear eventuall?
<lifeless> s/ll/lly/
<jelmer> yeah
<lifeless> ok
<lifeless> there is debounce protection for small operation
<lifeless> *operations*
<lifeless> what can happy is that your first operation takes more than 0.1 seconds
<lifeless> e.g, many seconds
<lifeless> without doing a nested child bar or other output
<lifeless> and this results to the user in no visible output until the first operation finishes
<lifeless> its possible this is what you are triggering
<jelmer> hmm, I don't think that's the case. afaik there are progress bars for everything now
<jelmer> *anything significant
<lifeless> jelmer: can you trigger this behaviour?
<jelmer> it appears to be somewhat random to me but I've never spent time looking into it once I hit it
<lifeless> next time it hits, ctrl-\ and you'll be in pdb
<lifeless> its the only thing that occurs to me
<lifeless> I suppose its possible that there is a bug in the bar nesting resulting a nested bar not triggering a show after the MIN_PAUSE
<lifeless> or many extremely small bars never getting past MIN_PAUSE each
<jelmer> hmm
<lifeless> wow
<lifeless> inventory extraction really blows
<lifeless> .37 seconds each
<lifeless> makes indexing...slow
<mwhudson> this is the main bzrlib performance pain point in loggerhead too
<mwhudson> make log -v fast and everyone will be happy
<lifeless> mwhudson: well
<lifeless> I need paths_for(revs_to_fileids) to be fast
<lifeless> which is in principle log -v FILENAME
<lifeless> to get the xml's only:
<lifeless> 0.014
<jelmer> lifeless, so it's the xml parsing that's slow basically?
<lifeless> its a significant factor
<lifeless> anyhow, new feature time in a sec
<lifeless> I'm on make it work
<lifeless> thats better:
<lifeless> :!bzr search COPYING
<lifeless> COPYING in revision 'robertc@robertcollins.net-20080608052044-s7ktacyyyiib8zi4'. Summary: 'No summaries yet.'
<lifeless> nice and fast:
<lifeless> Misc/HISTORY in revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:17190'. Summary: 'No summaries yet.'
<mwhudson> lifeless: yes, the inventory object creation seems like it might be a bit too all or nothing atm
<lifeless> so, 1) make it work completed
<Peng> "No summaries yet."?
<lifeless> right
<lifeless> if you do a search that hits a commit message you see
<lifeless> Revision id 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:15502'. Summary: 'Fix a problem reported by Oleg Broytmann, who complains that very'
<lifeless> file hits used to show the fileid, revision id pair
<lifeless> my most recent push makes it show the PATH and revision id
<lifeless> but adds 0.3 of a second for every revision indexed
<beuno> lifeless, around?
<lifeless> yes
<lifeless> (must diet sometime)
<beuno> I'm finally trying to get Loggerhead to use bzr-search
<lifeless> cool
<beuno> and, btw, it's always very nice to go through your code   :)
<beuno> anyway, I just want revids for loggerhead, and, well, each type of hit seems to handle that differently
<lifeless> so
<lifeless> what do you mean 'just want revids' ?
<beuno> the results
<beuno> as to what revisions ids match that query
<lifeless> rather than say specific paths ?:)
<lifeless> btw, did you see:
<lifeless> 11:39 < lifeless> Misc/HISTORY in revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:17190'. Summary: 'No summaries yet.'
<lifeless> current tip, its extremely slow to index in this manner, I'm fixing that now.
<beuno> yes, I say, and I pulled, and I jumped right into getting this working  :)
<beuno> you're even giving the UI some lovin'  :p
<lifeless> yah, sexy is a feature :)
<lifeless> anyhoo
<lifeless> I guess I'm saying 'why do you want to limit yourself to just the revision_id'
<beuno> well, I guess it's because I already have the rest of the information
<lifeless> do you ?
<lifeless> so you have file_id, revision_id -> path mappings already available?
<beuno> and, the current interface for loggerhead accepts a list of revids
<beuno> yeap
<lifeless> so
<lifeless> I think there are a couple of ways to tackle this
<lifeless> one is to make the Hit interface more pluggable
<lifeless> so loggerehead can have its own hit types
<lifeless> this would involving making the constructor interface homogeneous
<beuno> yes, although from a glance, it seems to be that if all types had revids and fileids (if applicable) available in the same way, well, that would also cover all the use cases similar to LH
<beuno> but I may be over-simplifying things
<lifeless> another is to make a revision key always be available which lh could interrogate
<lifeless> but I think that that is possibly/likely overconstraining the interface
<lifeless> anyhow
<lifeless> what would you prefer
<lifeless> do a patch to make it be like that, with enough tests that I can't accidentally change it on you
<lifeless> and I'm cool
<beuno> I'd prefer to "do the right thing", although lazyness is pushing towards the easy fix
<beuno> I'm looking at how I can make the contructor interface pluggable
<beuno> in a non-hackish kind of way
<lifeless> I don't think the right thing is entirely clear yet
<lifeless> so I'd rather do the thing-that-is-easiest-for-you
<beuno> I wonder if there are many more use cases for different types
<lifeless> well
<lifeless> tags
<lifeless> threads
<lifeless> phrases
<lifeless> I'm considering the logics of working tree indexing
<lifeless> and taking the very core and making it fully generic
<beuno> working tree indexing?
<lifeless> yeah
<lifeless> wonder where a line of code is in your working tree
<lifeless> TAGS is kindof primitive
<lifeless> can't lookup phrases
<lifeless> (for instance)
<beuno> as in the last revision?
<beuno> or uncommitted changes too?
<lifeless> uncommitted
<beuno> I've been also thinking that something *really* cool to add on top of this is something like "who worked on this class/method"
<beuno> I suppose it would be language-specific
<lifeless> last revision in already available, just need an interface to search for revision ids directly (and stash them as terms(
<beuno> but that would of been very useful for me many times
<lifeless> it would be interesting indeed
<lifeless> the way I would approach is is to add a term for the method to a result which is an author
<beuno> and that should a fairly straightforward UI in LH
<beuno> "click on the class/method in annotate, or search for it"
<lifeless> possibly author,fileid,revision_id or something
<beuno> hm, yes
<lifeless> but this is an example where revision_id starts to become less relevant as a mandatory piece of info
<beuno> right, I can see that
<lifeless> anyhow, tell me what works best for you and either do it, or I will for you
<beuno> but I'd have to whip a new UI in LH, so I can tailor that around what bzr-search gives me
<beuno> I'll take a stab at a patch now
<lifeless> the shortest-possible-path for you is an isinstance check in LH
<lifeless> 1) make it work
<lifeless> :)
<beuno> actually, yeah, but being able to get revids in a nicer way will probably tend to break less with newer versions
<beuno> anyway, yes, I'll make it work in a hackish-sort-of-way, and then go back  :)
<beuno> aaaaaaaaaand, it works  :)
<lifeless> oh yay
<lifeless> I think I have a corrupt test data set
<lifeless> jelmer: ping
<lifeless> ah no, rich root breaks my optimised code
<lifeless> much better
<lifeless> did 100 in 0.0627507519722 each
<lifeless> thats down from 0.37
<lifeless> its also chopped 150M of memory usage :)
<beuno> what did you do?
<lifeless> patience kemosabe
<beuno> hahah
 * beuno stis back down
<beuno> *sits
<beuno> well, LH uses bzr-search
<beuno> it and rocks
<lifeless> revno 34
<beuno> mwhudson, ^
<lifeless> and you can peek
<lifeless> beuno: fantastic
<lifeless> beuno: screen shot! or demo site!
<lifeless> I would love to show bkor it running :)
<mwhudson> beuno: nice!
<beuno> let's see if the router will let me redirect 8080
<lifeless> 34 is pushed FWIW
<mwhudson> loggerhead could probably steal that paths_from_ids code
<lifeless> I don't know if it is faster when looking at a full revision
<lifeless> but generally we aren't looking at a full revision in the search code
<lifeless> (even though we need full xml to process things)
<beuno> lifeless, http://200.127.6.219:8080/bazaar/bzr_garbage/changes
<beuno> search away
<lifeless> cool
<lifeless> so, you're not showing FileTextHits any different to revision hits?
<beuno> not yet  :)
<lifeless> no worries
<beuno> the sql cache got in the way and I lost a bunch of time on that
<beuno> (it turns out it doesn't like duplicate hits)
<beuno> I also want to show hwo many results there are, highlight it (text if in commit message, file if in file)
<beuno> s/hwo/how
<lifeless> excellent
<lifeless> well, feel free to send me patches to make bzr-search nicer for you
<beuno> but I should probably have some way to index the repos from LH first  :p
<lifeless> I *like* patches
 * lifeless goes hunting a gnome sysadmin
<beuno> heh, will do
<lifeless> I think a limit is the next thing
<lifeless> to be able to say 'no more than 1000 revs' or whatever
<beuno> yes, that's probably sensible
<beuno> and, an "order by relevance"
<lifeless> I'm thinking for LH actually
<lifeless> well, relevance is actually the hard thing about searching :P
<lifeless> relevance talks about precision, if you want to read up on IR theory
<beuno> yeah, start with something basic, like most amount of hits, prioritize commit messages maybe
<lifeless> mwhudson: actually, I think ids_to_paths should be on Repository
<lifeless> mwhudson: but, backward compatibility etc
<beuno> something basic will be much better than seemingly random order
<lifeless> lol small deltas:
<lifeless> did 100 in 0.00272021055222 each
<lifeless> beuno: there is no weighting in the core at the moment though
<lifeless> beuno: so any order is equivalent as far as the system is concerned
<lifeless> who beuno
<beuno> ehm, Martin?  :p
<lifeless> getting your last name right
<lifeless> to do a demo to Lynne of the web search
<lifeless> she was asking how the code was going :)
<beuno> who Lynne?   :p
<lifeless> erm, my Fiance! :)
<beuno> ah!  you're enganged. I somehow don't know that
<lifeless> hehe, enganged :)
<lifeless> it would be nice to show more details, I get back 1594.2.17  when searching on your name
<lifeless> but can't figure out why :)
<beuno> NEWS?
<beuno> oh, no
<lifeless> could you run 'bzr search Albisetti' on that tree?
<beuno> yes, one sec
<lifeless> no progress bar is shitting me
<lifeless> time to fix that
<beuno> lifeless, bzr search doesn't return that revid
<beuno> LH's cache must be screwing with me again
<lifeless> beuno: so, first bug found :)
<beuno> yes, thank you  :)
<beuno> I'm going to rip out most of the cache next week, so if it is a cache bug, it should be squashed with that
<lifeless> mmm
<lifeless> would be nice to be sure of it/be able to show people this :)
<beuno> oh, yes, I won't defer it, just that I won't fix the cache if it is
<beuno> I'll do some cleanups, like, not hardcode '/home/beuno/bzr_devel/bzr.garbage' into the code, and push it
<lifeless> sweet
<lifeless> mwhudson_: welcome back
<lifeless> python-packs$ time (bzr search socket inet_pton | head -n1)
<lifeless> Mac/Include/pyconfig.h in revision 'svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:22230'. Summary: 'No summaries yet.'
<lifeless> bzr: broken pipe
<lifeless> real    0m0.726s
<lifeless> user    0m0.592s
<lifeless> sys     0m0.084s
<beuno> that's with the inventory tweaks?
<lifeless> they only affect index time
<lifeless> search is orthogonal
<beuno> ah, diffs didn't tell me *where* that change was  :p
<lifeless> I thought the commit log would :P
<beuno> well, if we had a bzr pull --show-log...
<beuno> (yes, I did ignore the commit message, it's just a good time to plug in a feature I want)
<beuno> ugh, I'm stuck and sleepy. I'm off to bed
<beuno> g'night
<lifeless> gnight
<lifeless> abentley: abentley@panoramicfeedback.com-20070410141425-86yh4m1cb6wwnwwm seems to have a corrupt inventory
<lifeless> abentley: oh, nvm, it's a format behaviour I have not accomodated
<abentley> You mean the fact that it has a unique root?
<lifeless> I didn't remember what format 5 looked like
<lifeless> I've written a custom path-from-xml extractor thats 5 times faster than deserialising to an Inventory
<abentley> lifeless: But we're still on format 5...
<lifeless> on average that is, for processing deltas when you don't need all-paths
<lifeless> abentley: right, format-5 rich roots were not in my test suite
<lifeless> I tried format-5 plain, and rich-root-pack in my test suite
<abentley> lifeless: that's quite nice.
<lifeless> It seems to have worked out well. I'd like to fit it into Repository or some such
<lifeless> its not optimised yet either
<lifeless> but 5 times faster was sufficient to stop at for now
<lifeless> I'm hoping that some of what I develop may go into the core packs as faster lookups for common things
<lifeless> this just came together as an interesting project :)
<johnf> with bzr-svn is it possible to work out which svn revision number I've just merged?
<lifeless> I don't know
<Peng> If you find a way, I'd like to know.
<Peng> Could tags be used? Does bzr scale well with thousands of tags?
<AfC> Peng: I don't think you'd want one tag per Subversion revision.
<AfC> johnf: if you have a branch which is just a straight pull of a svn+ssh:// URL, then I think the Bazaar revno == Subversion's. I could be wrong, but that was the impression I got. Let me test that hypothesis some.
<Peng> AfC: Why not?
<AfC> Peng: signal to noise ratio, of one thing: it would make other uses of tagging a little less palatable to use.
<Peng> Yeah..
<Peng> I'm really curious if it would still perform well though. (But not curious enough to test it myself.)
<AfC> Hm. bzr[-svn] revno = 219 ; subversion revno = 249
<AfC> Guess not.
<lifeless> Peng: they don't
<lifeless> I would check the svn revision for a property
<lifeless> jelmer may have stashed it there
<Peng> AfC: svn revisions are repo-wide; bzr revisions are branch-wide.
<gour> svn should be thrown away...they still have problems after 11 RCs with 1.5.0
<lifeless> hmm, I should add text hit summaries before blogging
 * lifeless goes to do that
<johnf> aha bzr version-info has it
<johnf> revision-id: svn-v3-trunk0:90e61fa5-4541-0410-a685-e5b9dba3c764:trunk:74
<johnf> svn revision 74
<lifeless> man
<lifeless> crying tiger is _hot_ tonight
<thekorn> hi, is there a way to only show the commit messages from the 'main-line' with 'bzr log'
<thekorn> not the messages  of the merged changes
<lifeless> log --line
<lifeless> or --short I think too
<thekorn> thanks lifeless, --short looks good
<jelmer> james_w: ping
<rexium> Does anyone know how to commit to an sf.net svn repo with bzr-svn? (or have a link to the relevant documentation?)
<jelmer> johnf, ping
<james_w> hi jelmer
<jelmer> james_w: debian bug 472543 - does that patch look sensible to you?
<ubottu> Debian bug 472543 in bzr-builddeb "bzr-builddeb: FTBFS: Unknown command "test-builddeb"" [Serious,Open] http://bugs.debian.org/472543
<johnf> jelmer: pong
<jelmer> johnf: The subversion revision number is sometimes part of the bazaar revision id
<johnf> jelmer: yep eveuntually worked that out and even blogged about it :)
<james_w> jelmer: That should have been included in the last upload, maybe I messed up the changelog, let me look.
<jelmer> james_w: The BTS doesn't contain any claims it's been fixed
<jelmer> johnf: It's not something that's guaranteed though - if the commit was pushed from bzr, it could be a completely different revno
<jelmer> rexium: Simply use it like any svn repo with bzr-svn
<rexium> jelmer, I am getting authentication issues
<jelmer> rexium, see the FAQ entry about authentication and http
<james_w> jelmer: ah, my mistake, let me close it.
<james_w> jelmer: thanks for catching it.
<jelmer> james_w: Thanks
 * jelmer is chasing down RC bugs at a BSP atm
<james_w> anyone want to review my first attempt at a bzr screencast?
<james_w> http://jameswestby.net/scratch/introducing_yourself.ogg
<Leonidas> james_w: you speak a little bit too fast, I think.
 * Leonidas watches it to the end now
<gour> james_w: i think the same - too fast and too long sentences. otherwise it's very nice
 * gour watched till the end
 * Leonidas too
<Leonidas> Yeah, the text in the console is even pretty much readable.
<james_w> thanks, I'll try and slow down for my next one.
<matkor> james_w: great, but I agree previous comments about speed of talking
<gour> james_w: what do you use for casting?
<james_w> heh, recordmydesktop to capture
<gour> james_w: use 'comma' in your speech ;)
<james_w> but it gets pretty messy from then to get to the finished product.
<james_w> gour: heh, what are they?
<gour> heh, atm i'm doing some video-editing in cinelerra
<james_w> I tried that, but I couldn't work it out at all.
<gour> james_w: look for this ',' sign on your keyboard :-)
 * gour thinks video-editing on linux still sucks. hopefully lumiera will fix it, but the project needs help
<jelmer> james_w: btw, did you see the announcement of the extremadura vcs-pkg meeting?
<james_w> jelmer: yeah, I never registered my interest.
<Pilky> james_w: the podcast is good, the audio could do with some work though
<Pilky> the music needs to fade in/out before/after you finish talking
<Pilky> plus your voice could probably do with being a bit loud
<Pilky> *louder
<james_w> I like having a bit of overlap, but I could cut the music a bit further.
<Pilky> oh, a bit of overlap is fine, it just seems a bit too much overlap, and seems to drown out your voice a bit
<james_w> My mic picks up a lot of noise on my laptop, so I can't have it too much louder, but I'll put my new soundcard in my other machine and see if it is any better there.
<james_w> thanks for the feedback though.
<jelmer> james_w: Ah, ok
<jelmer> james_w: Thanks for merging that patch btw
<rockstar> Is there a bzr plugin that will help me create debs from a bzr repository?
<Jc2k> bzr-builddeb?
<Jc2k> rockstar: https://launchpad.net/bzr-builddeb
<rockstar> Awesome, thanks.  I knew there was something, but bzr-deb doesn't google well...
<Jc2k> :)
<rockstar> That should belong to the bazaar project group, methinks
<james_w> hi rockstar
<james_w> give me a shout if you have any trouble with it.
<rockstar> james_w, well, I'm not a great packager.  Ideally what I would like is a tool that just creates a dummy debian/ folder with default files in it...
<james_w> rockstar: dh-make will do that for you
<james_w> rockstar: I've added it to the bazaar group, thanks.
<rockstar> james_w, well, not without needing a .orig.tar.gz first
<james_w> rockstar: ah true, though it probably has a "native" package mode that will avoid the need for that.
<james_w> rockstar: yup, dh_make -n
 * rockstar wipes egg off his face
<scorpioxy> hey guys, i am trying to push via ssh. Isn't the url syntax similar to that of sftp? sftp works, ssh i think is spitting a command not found.
<james_w> scorpioxy: you need to have bzr installed on the server to use bzr+ssh://
<scorpioxy> james_w: i think i do. Issuing bzr does the right thing.
<james_w> is it installed in the $PATH?
<scorpioxy> james_w: yes
<james_w> and "ssh server bzr" doesn't complain?
<scorpioxy> james_w: umm...what is that? do you mean bzr serve?
<scorpioxy> james_w: oh oh...never mind
<scorpioxy> james_w: it says command not found...but bzr is in my $PATH...this is a shared host, does it have anything to do with that?
<james_w> scorpioxy: is it in a part of the $PATH that is set in .bashrc or similar?
<james_w> I've got to go, but I will point you to $BZR_REMOTE_PATH, and suggest that you hang around, because someone else might be able to help.
<scorpioxy> james_w: alright, thanks
<ddaa> jelmer: on the bug tracker, I saw you say something along the lines of:
<ddaa> "branching schemes are unecessary. Kill, kill, ex-ter-mi-na-te"
<ddaa> could you elaborate on how they are unecessary?
<jelmer> ddaa: hi
<jelmer> ddaa: Yes - they do not need to be part of the revision id
<jelmer> ddaa: Since we can just follow the history of the path we're branching
<ddaa> uh
<ddaa> sorry, dvcs neurons a bit rusty
<jelmer> the idea would be to replace branching schemes with a somewhat similar thing called 'repository layouts' that is less intrusive
<ddaa> I'd love to hear about it.
<jelmer> e.g. just used to determine what a branch is when converting the whole repository, but not when analysing history
<ddaa> let me think aloud for a bit
<ddaa> ATM, branching scheme are not used to "guess" merges right?
<jelmer> no, merges are never guessed - only tracked explicitly using file properties
<ddaa> The only way you get merge in bzr-svn history is (currently) through revisions created by bzr, svk and eventually svn>=1.5.
<jelmer> correct
<ddaa> the thing is, those merges involve other paths in the svn repo
<ddaa> and that's where branching schemes get involved
<jelmer> why would that involve branching schemes? We just allow all paths in the repo as branch paths
<ddaa> sorry, I do not think I'll be able to make much sense, this stuff has just gone too hazy :(
<ddaa> my concern comes from the fact I needed to create a new branching scheme to hack around a limitation in bzr-svn
<ddaa> i.e. when pushing a commit, it tried to inspect some branches that I do not have access to, and failed 403
<ddaa> It really should not need to look at those branches (such as "/toolkit/trunk") when pushing to my branch (such as "/language/trunk")
<jelmer> that's the bit that's going to be replaced by repository layouts
<jelmer> it's calling Repository.has_revision() to figure out which of the revisions it will push are already present somewhere in the repository
<ddaa> but it was easier for me we write a RestrictedTrunkBranchingScheme that just looks at /foo/trunk, /foo/branches/*, and /foo/tags/*
<ddaa> jelmer: the current behaviour is meant to allow things like "commit on A, merge A into B and commit B, push B"?
<ddaa> (where A and B are svn branches)
<jelmer> the current behaviour is meant to support something like this:
<jelmer> pushing large branch foo to /branches/foo
<jelmer> then pushing large branch bar which descends from foo to branches/bar
<jelmer> the latter would do a copy from /branches/foo to /branches/bar and then push the extra revisions not yet present in foo
<ddaa> I see.
<jelmer> anyway, that bit is not going away, it's jsut going to be more flexible
<jelmer> so it would be possible for the user to specify how hard bzr-svn would have to look for revisions to reuse
<ddaa> are you actually working on this (or planning to, at least), or is that a "someone would need to siphon out jelmer's brain and take over" kind of plan?
<jelmer> I'm working on this bit by bit
<jelmer> The initial work (now done) was adding support for having more than one mapping scheme present in the same version of bzr-svn
<jelmer> so it's now possible to support revisions created with and without branching schemes without having to use a different version of bzr-svn
<jelmer> most of the branching-scheme-less mapping also already works and I've done ad-hoc testing of it
<ddaa> it knocked my socks off when I saw that if I pushed revisions from with my custom branching scheme, and then switched back to the standard trunk1 scheme, it preserved the shape of the ancestry graph.
<ddaa> jelmer: which kind are you? Motivated by thank you or by complains?
<jelmer> ddaa: yes
<jelmer> ddaa: I mean, both
<ddaa> I can do both :)
<ddaa> So: Thanks, at work they use svn (thanks god!), now I have something which will allow me to make merges without having to reimplement gnu-arch-era star-merge in scripts...
<ddaa> also, making bzr-svn to work gave me the motivation to install ubuntu on my office workstation (thanks WUBI)
<ddaa> (between newline translation on windows native and issues recompiling the python bindings on cygwin, I could not make it work on windows)
<jelmer> ddaa: (-:
<jelmer> compiling the bindings on Windows should be a lot easier soon
<jelmer> I've redone them using pyrex
<ddaa> Now, if only it worked correctly without this ghastly hack of mine, I would be able to recommend it to the other IT folks.
<ddaa> HOOOORAY
<ddaa> about pyrex
<jelmer> I really regret not having done that earlier, the patches I contributed to the current bindings took much more time than the pyrex bindings
<ddaa> anyway, the recompiling issue will solve it itself when svn1.5 gets out, right?
<ddaa> now, with a usable windows version, and better support for access restrictions, that would really take some pain out of the folks who try to do patch management on parallel branches using svn ATM.
<ddaa> they seem to think it's a law of nature that integrating "deltas" (as they say) involves a mind-dulling amount of conflict resolution.
<ddaa> well... it's probably is, considering how shit the code is probably organized wrt to version control, but bzr would certainly take some of the pain it out if only they could use it.
<ddaa> jelmer: is that enough motivation for now?
<jelmer> ddaa: :-) Certainly
<jelmer> I'm still waiting for the complaints though :-P
<ddaa> hu
<ddaa> I complained that I could not make it work on windows and that I could not recommend it to my co-worker in its current state...
<ddaa> the rest of the complaints would relate to the lack of a tortoisebzr, but that's not your dept...
<ddaa> jelmer: I'm starting to miss free software hacking
<ddaa> maybe I could give you a hand if you could give me some bite-sized task and a bit of mentoring.
<ddaa> I know a bit about bzr and svn conversion kind of things :)
<jelmer> ddaa: (-:
<jelmer> ddaa: The launchpad bugs page probably has some interesting todo things
<ddaa> jelmer: what's the benefit of using revision props instead of file props?
<ddaa> it only provides a marginal performance improvement, as all revisions without revprops will still need to be inspected for fileprop changes for backwards compatibility, and it adds a major new code path.
<ddaa> I can see how that's "more pure", but I do not see how that's a good technical choice.
<ddaa> oh, right bug 128496 hit me too, and it's particularly nasty as on french localized windows installation the $HOME contains such non-ascii chars.
<ubottu> ddaa: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/128496/+text)
 * Peng pats ubottu.
<ddaa> bug 128496 "Unable to open native working tree with non-ascii filenames" https://bugs.launchpad.net/bzr-svn/+bug/128496
<ubottu> Launchpad bug 128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New]
<ubottu> Launchpad bug 128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New] https://launchpad.net/bugs/128496
 * ddaa punches ubottu in the nose
<Peng> Haha.
<jelmer> re
<jelmer> ddaa: Revision properties don't show up in "svn diff" and they don't annoy users of commit notification emails or trac users
<jelmer> ddaa: Also, they don't confuse "svn merge" (which tries to merge those preoprties as well)
<ddaa> Ok, that seem like good reasons :)
<jelmer> ddaa: s/pyrex bindings/C bindings/
<ddaa> meh?
<ddaa> Why bother? Pyrex does all the tedium for you. And it's deliciously geeky too.
 * ddaa thinks he saw something on cheeseshop not too long ago that claimed to be the successor of pyrex
<Peng> Cython.
<Peng> I don't know its current status as Pyrex has come back from the dead.
<jelmer> Pyrex and Cython were both too limited
<jelmer> They couldn't handle the callbacks in the subversion API that need to return a Subversion error struct when an exception is raised
<ddaa> That's funny, I do not remember having such a problem when I investigated pyrex bindings to libsvn for launchpad back then.
<jelmer> I confirmed with the pyrex/cython developers that it was something that couldn't be handled with either at the moment
<ddaa> IIRC, the technique I used was
<ddaa> 1. as the svn callback, use a wrapper function that has a try/except catch all and return the appropriate error if it caught an exception
<ddaa> that's a C function
<ddaa> 2. as the baton of the svn callback, use a python callable
<ddaa> or a combination of the callable and any desired arguments
<ddaa> the key being that all svn callbacks are associated to "batons"
<ddaa> jelmer: how is that insufficient?
<ddaa> lifeless:  just in case you missed that one, I know you'll love the look of it. http://pypi.python.org/pypi/multimethod/0.2
<jelmer> ddaa: If you catch the exception you can't reraise it again and change the returned struct
<ddaa> oh... I see
<ddaa> it's for the commit stuff, right?
<jelmer> yeah, commit editor and ra reporter
<ddaa> you want to let exceptions from the commit callbacks (I did not look at those) bubble all the way up _through_ the layer of libsvn involved.
<jelmer> yep
<jelmer> and if I return NULL it will call continue calling python callbacks
<ddaa> sure, you need to give an error status to libsvn so it returns early. The thing is that you need to store the exception data and traceback in global storage to preserve it while control moves back to the python caller.
<ddaa> Which means you need to play really ugly games with the GIL.
<ddaa> otherwise you could have insanity in multithreaded context
<ddaa> that's the issue you were trying to solve?
<tro> vila: is there a revision of the webdav plugin that's compatible with bzr 1.5?
<tro> right now i'm getting "not installing http[s]+webdav:// support (only supported for bzr 1.6 and above)" with the latest revision
<jelmer> ddaa: other things were annoying as well - pyrex doesn't support the C preprocessor for example
<jelmer> so there's no proper way to support both svn 1.4 and functions from svn 1.5 when they're available
<ddaa> THAT bit sounds scary
<jelmer> e.g. there's no way to do #ifdef SVN_MINOR_VERSION > 5
<ddaa> I see
<ddaa> okay, you're clearly outside the kind of problems pyrex tried to solve.
<ddaa> If I were you
<jelmer> yeah, and the Python C API is quite sensible
<ddaa> I would not have been this much of a perfectionist.
<jelmer> it took me about a day to do the initial bits in Pyrex and then another day to rewrite all of it in C
<jelmer> 18 hour days :-)
<ddaa> You're going to make me look bad. When I was asked how much time it would take to move cscvs-launchpad to pyrex bindings, I said "weeks".
<ddaa> You know, test suites, code reviews, etc.
<ddaa> and also hundreds of users relying on daily code imports.
<jelmer> well, this was about 36 hour in total so that's pretty much a full work week
<jelmer> and I already had a lot of the test code
<jelmer> and it's not finished yet - there's some segfaults remaining in the C code
<jelmer> nor did I have to do the workarounds you'd have to do in Pyrex :-)
<jelmer> so I don't think weeks is an unfair estimate
<ddaa> Not that the work itself was particularly difficult. But getting stuff up to launchpad code-review quality takes fixing up a lot of details like naming, coding standards, docstrings, etc.
<ddaa> Well, they'd have been happy with c bindings too.
<ddaa> There's also the fact that you grok a lot more about libsvn than I do.
<ddaa> That's funny when I think of it.
<ddaa> At my current job, I'm hacking up a prototype, with better test coverage than mission-critical production code.
<ddaa> It's funny enough that I got into a one-of-kind research-development mission where I got to pick Python as implementation language in a business where almost everything is short-cycle development in C++/VB/C# :)
<ddaa> I need to get this mission over with as soon as possible, or I'll go crazy.
<ddaa> Investment banking is definitely not my cup of tea.
<jelmer> :-) So you're working mostly on Windows these days?
<ddaa> Mostly, yes.
<ddaa> Until I decided to install ubuntu on my workstation.
<ddaa> I went out to learn what the workplace is really like.
<ddaa> But somehow, my profile got me into one very special mission.
<ddaa> Maybe I should have tried to look dumber ;)
<jelmer> (-:
<awilkins> No abentley?
<jelmer> ddaa: well, at least you get to do python now rather than something horrible like C++
<ddaa> Well, I did C++ in a previous life.
 * awilkins did VB6 in a previous life
<ddaa> If you can get over the "fighting with the compiler" bit, there's plenty of interesting puzzles there.
<ddaa> The shame is that most of those puzzles involve working around shortcomings of the language :)
<ddaa> I mean... most of those puzzles are about working around the language.
<jelmer> heh
<ddaa> right, the situation could be a whole lot worse.
<ddaa> So I still expect to drive this project to completion. Which will probably take another six months or so.
<vila> tro: the 1.6 restriction is mostly me being lazy to test against previous revisions. The tests may require a 1.4 or 1.5 but the code itself should be ok with any bzr version you can put your hands on. But out of curiosity, why do you need to stick with 1.5 ?
<libwilliam> I was listening to a podcast where they talked about Bazaar doing something with XML files for integration into other apps. Is this in progress or implemented already?
<beuno> libwilliam, yes, it's a plugin, bzr-xmloutput
<beuno> a few projects are using it
<beuno> https://launchpad.net/bzr-xmloutput
<libwilliam> beuno, thanks ill check it out
<beuno> libwilliam, was that the IDE Integration podcast?
<Verterok> libwilliam: the xmlrpc bit isn't there yet, but we 're working on it
<Verterok> hi beuno
<beuno> hey Verterok :)
<beuno> libwilliam, Verterok is the author, so you can blame him for anything that goes wrong  ;)
<libwilliam> bueno, i'm trying to find it again, it might have been from a post I read on This Week In Bazaar or the Launchpad Podcast
<libwilliam> great news, now I know who to point the finger at =)
<libwilliam> I am doing the integration with Anjuta, and was doing alright using the C/Python API, but I got hung up on trying to get a list of the log messages, so I remembered hearing about this XML thing so figured I would check it out
<Verterok> sure :)
<beuno> libwilliam, so you're William Fagan?
<libwilliam> ya
<beuno> I just added an "email" column to the IDEIntegration wiki: http://bazaar-vcs.org/IDEIntegration
<beuno> to be able to keep in touch with everyone
<beuno> libwilliam, so you're making progress with anjuta?
<libwilliam> I just updated the page
<beuno> libwilliam, cool, thanks. Have you got any code published yet?  May help to get it out there as soon as possible, for drive-by contributions
<beuno> brb
<Verterok> libwilliam: I'm working in the xmlrpc service for it, my current prototype focus on keeping the same CLI/command oriented interface to minimize the python/bzr startup time for each call...
<libwilliam> ya I am doing alright. I have a lot of the functionality in. Now I am stuck on some issues with doing some things in Bazaar because I am so lost with the Python API
<Verterok> libwilliam: next step is to provide low level api (in comparsion to CLI commands)
<libwilliam> For example, my log GUI needs to get the log message, commiter, timestamp etc to put into the treeview and I am having a hard time understand the API to get that data
<beuno> libwilliam, well, with XML it will be trivial
<beuno> but if you want to use the Python API, let me know and I'll be happy to help you whip up that code
<Verterok> libwilliam: did you looked bzrlib/log.py?
<libwilliam> Vertorok, ya I have been looking at the log.py, I have been trying to reproduct the _show_log essentially in C but it has been a pain, so thats when I decided to go look for the XML
<Verterok> oh, I get it, I can't even imagine how to get that done in C :P
<libwilliam> ya, its been a depressing afternoon trying to figure it out =)
<libwilliam> so without me really looking into it yet, with the xml plugin would I like request a log, and it will output to xml, then I would parse the xml file?
<libwilliam> excuse me for the ignorance, I am asking without looking into it yet
<Verterok> libwilliam: yep, the default output is stdout, but you can redirect to a file
<ddaa> probably, if you are looking to minimize the python spawning cost, you could use the "shell" command (in bzrtools I believe)
<Verterok> libwilliam: just a note, xmloutput trunk overrides builtins commands, my current work is in the standalone_commnand branch to be completetly independent of the bzr builtins commands
<ddaa> to spawn a slave bzr process, then run whatever command line you need and get its output across a pair of stdin/stdout pipes
<Verterok> ddaa: sure, the main problem I have with CLI is the win32/*nix mismatch :( (it's a pain to make it work right in win32)
<ddaa> really, bzr should offer line protocol to allow access to most of the API functionality without involving a C api, but nobody was really interested enough to make this happen
<Verterok> actually, cmd.exe is...well ugly :)
<ddaa> ugh
<libwilliam> verterok, that sounds like it will solve a lot of the issues I have been to scared to dive into. I would like to get this into the next Anjuta build for the next gnome, will the standalone be done by then, if so I will start using that instead of the trunk version
<Verterok> libwilliam: bzr branch lp:~guillo.gonzo/bzr-xmloutput/standalone_commands :D
<Verterok> it's a work in progress, but all the commands implemented in trunk are already there ;)
<Verterok> libwilliam: the xmlrpc service branch I'm working builds on top of the changes in standalone_commands, so it's safe start using it
<Verterok> I'm using it in my current dev branch of bzr-eclipse
<libwilliam> nice =), I have to go, but it sounds great. can I shoot you an email this week with any questions I have?
<Verterok> sure
<libwilliam> thanks a ton everyone, i will be dropping soon
<libwilliam> dropping in soon*
<lifeless> ddaa: hi
<ddaa> hey lifeless
<ddaa> how is it goin?
<ddaa> getting stacked?
<lifeless> :)
<lifeless> closing in on stacked quite rapidly
<lifeless> down to the last bits of implementation
<lifeless> seen bzr-search?
<ddaa> looks like mwhudson_ got around to eradicating buildbot
<ddaa> that's the end of an epoch
<lifeless> the dinosaurs have fallen
<ddaa> I saw some bugmail that suggested that
<ddaa> did not look at bzr-search, just saw your blog
<ddaa> I do not have a use case for this at all at the moment
<ddaa> I'm working on a project I'm writing from scratch.
<lifeless> what is it?
<ddaa> I mean work as in "for real money"
<lifeless> cool
<lifeless> is it open?
<ddaa> hell no
<ddaa> it's some stuff to model exotic equity derivatives
<lifeless> ah, traders :P
<lifeless> probably challenging and fun
<ddaa> actually, not traders, more back-office kind of stuff
<ddaa> it's probably highly challenging and fun compared to other projects in this line of work
<ddaa> I feel a bit lonely though. My code is mostly covered by unit tests using niemeyer's mocker, and I have some second thoughts about it.
<lifeless> you're working solo?
<ddaa> pretty much, I have a binom who's handling some of the "figure out the financial meaning of the crap in the database" tedium, and some other people around trying to understand what they want me to do.
<ddaa> But as far as object modelling, python coding and testing go, I'm a lone cowboy.
<lifeless> that can be lonely indeed
<lifeless> teddy bears are not as good as people
<ddaa> There are some good IT folks around I can use as teddy bear when the need arise.
<ddaa> My favourite is the guy who's running the 2000 cpu pricing farm.
<ddaa> probably something thumper could relate to :)
<ddaa> anyway, did you hear about this multimethod hack I pointed you at
<lifeless> oh, backlog
<lifeless> lets see
<ddaa> Whenever I have to code a Visitor pattern to implement multiple dispatch, I can't help but think "python should know better"
<lifeless> mmm
<lifeless> multimethod fits in functional languages really nicely, its part of the idioms
<lifeless> I don't know that it fits in python well - I mean guido did a multimethod implementation ages ago, but its not been merged
<ddaa> I seems to me the whole zope adapter thing is a kind of multiple dispatch.
<ddaa> (being zope, it's probably much more complicated than that, but I guess you see what I mean)
<lifeless> mmmm, from a certain angle I guess, and if only one method is being called
<lifeless> but in ocaml or erlang, multimethods are pervasive
<lifeless> if-then constructs even use them
<ddaa> sounds funny
<lifeless> its really elegant, but this is why I am saying they don't feel pythonic to me
<lifeless> its not that you can't, or that if you do its ugly
<ddaa> from my perspective, dispatch and conditionals fit very distinct niches in the OO world.
<lifeless> its that its not integrated in
<ddaa> it's not part of the culture?
<lifeless> no, its not part of the language
<lifeless> making dispatch do lookup-on-parameters is a hack layered on the language
<lifeless> its implemented as double-dispatch
<lifeless> mmm, do you know ocal/erlang/that-other-common-functional-language-that-isn't-lisp?
<ddaa> you mean haskell
<lifeless> yes!
<ddaa> and no. I have meant to look at those, but I never did.
<lifeless> I think it also has pattern matching
<ddaa> The closest to multimethods was guile's implementation of CLOOP
<lifeless> so, it was very hard for me to really grok this until I learnt enough of one to think in it
<ddaa> * the closest I got to multimethods
<lifeless> and when I did, there was a very large penny that dropped
<ddaa> pattern matching seems to be core in all ML derivatives
<lifeless> coming back to python though, are multimethods really pythonic - are they the simplest way, clean, clear, easy to understand
<lifeless> ddaa: yeah, I think ML derived guarantees pattern matching :)
<ddaa> It certainly depends on the situation.
<ddaa> I saw an occurence recently when I ended up doing manual type dispatching because I could not be bothered to code a Visitor.
<ddaa> mh...
<lifeless> I think as something that some-methods-might-do its inherently unclear (until its available for all methods as a standard language feature)
<ddaa> I think I see your point.
<lifeless> but that said, if it works for your code and looks nice
<ddaa> For example, it looks like this implementation of multimethods would only work for module-level functions, not methods.
<lifeless> use it, but document clearly that you are, and try to make it as obvious as possible when its being used etc
<ddaa> I'll probably abstain.
<ddaa> At some point, I'll have to design a micro-language to generate the object model I'm currently prototyping.
<ddaa> Maybe we can construe some way for you to give me feedback on this.
<lifeless> you can always drop me a mail
<lifeless> man
<lifeless> evolution
<lifeless> man
<lifeless> now that I've written a search engine
<lifeless> my respect for evolution has shrunk substantially
<ddaa> I understand how evolution gives you pain.
<ddaa> for me it's been in the "stuff that sometimes has to use" box for some time...
<ddaa> they to have this vastly overengineered internal service with its own micro-language to drive their search and vfolder system.
<ddaa> * they seem to have
<ddaa> I still cannot type though.
<lifeless> :P
<ddaa> I think it's called "camel-helper" or something like that.
<ddaa> use sylpheed, it's least painful of the local mail readers I've used.
<ddaa> But I think I told you that one year ago already :)
<lifeless> yah
<lifeless> I use evo because for all the things that shit me, other setups shit me more
<ddaa> BTW I found something MS Outlook is very good at.
<lifeless> ?
<ddaa> Arranging pointless meetings.
<lifeless> ahha
<ddaa> This whole email-calendar integration thing.
<mwhudson_> ddaa: hello!
 * mwhudson_ is not really here though
<ddaa> I'm going bedwards too.
<lifeless> ddaa: good to catch up, do drop by more often :)
<ddaa> I've busy with addictions.
<ddaa> First stopping smoking. Then buying a Wii.
<ddaa> I'm only just coming out of the Wii addiction.
<lifeless> serial addictions :)
<ddaa> seriously so
<ddaa> beddy time
<ddaa> cya around
<lifeless> bye!
#bzr 2008-06-15
<jelmer> ok
<jelmer> packaged bzr-loom, bzr-avahi and bzr-upload
<lifeless> nice
<lifeless> bzr-search ? :P
<lifeless> hmm
<lifeless> time to grab trackerd's source
<jelmer> lifeless: Sure, once it's not under such heavy development anymore :-)
<beuno> lifeless, I thought of something I'll need for loggerhead in bzr-search. Using custom locations for indexes
<lifeless> beuno: open_index_for is the place to extend to do that
<beuno> I'll take a shot at a patch as soon as I properly get LH using bzr-search
<lifeless> I wrote it with that in mind, e.g. to allow indexing bzr-svn repositories to ~/.bazaar/search/UUID/
<beuno> great, should be easy-ish then
<lifeless> specifically, an index is given a root transport when its opened
<lifeless> and separate branch object
<beuno> jelmer, have you continued using bzr-upload?
<jelmer> beuno: yeah, I use it now and then
<beuno> vila was relunctant to make it public yet, but, if there's going to be a deb, I suppose we should announce it somehow
<jelmer> beuno: Symlink support is a problem for some branches though, so I have to fallback to manual copying :-(
<beuno> I have too, and haven't run into any major issues
<jelmer> beuno: I've just created a package, it's not been uploaded yet
<jelmer> If you'd rather not have it out there yet, I'd be happy to wait
<beuno> actually, I'd prefer it is, so we can have more contributors  :)
<beuno> and it seems to work good enough en most cases
<beuno> but, well, vila has to agree too
<lifeless> beuno: did you upload your bzr-search LH branch ?
<beuno> lifeless, not yet, no. I was burnt out yesterday and was having problems getting the branch PATH to send to bzr-search (aka, don't hardcode the path)
<beuno> I'm looking at it now, but I'm leaving to a birthday in ~20-30 minutes, so I don't know if I'll make it  :/
<beuno> it's a stupid thing, really. I was just going around in circled yesterday
<lifeless> release early release often :)
<lifeless> just push-with-caveats
<beuno> yes, I just thought making people edit the source code to change my local path seemed pushing that too far
<beuno> I'll try to fix it, and, if now, push anywa
<beuno> *anyway
<beuno> lifeless, pushed it to: lp:~beuno/loggerhead/bzr-search_integration
<lifeless> beuno: cool
<lifeless> beuno: so why does LH need non-colocated indices?
<lifeless> I mean:
<beuno> lifeless, it may not, but there may be use cases where LH can't write to the .bzr directories
<lifeless> if a user creates an index
<lifeless> then other pull/push operations update it
<lifeless> LH doesn't need to do indexing
<beuno> yes, that should be the default behaviour
<beuno> having that hook is perfect
<beuno> right now we have an odd timer which re-scans every 6 hours  :/
<beuno> but I can see a few use cases where LH will only be able to read the repos, not write to them
<lifeless> oh man
<lifeless> I am loving this
<lifeless> I'm looking around the tracker source code
<lifeless> so to find where dpopen occurs I do a bzr search dpopen :)
<beuno> desktop integration, very sexy
<lifeless> well
<lifeless> I don't think bzr-search is a good idea for the searchbar ;)
<lifeless> but I wanted to see what tracker does under the hood
<lifeless> also look at telling it to ignore .bzr
<lifeless> (I may be wrong about bzr-search being a good idea for the deskbar search, its just current opinion)
<beuno> why don't you think it's a good idea?
<lifeless> context
<lifeless> which is another way of saying that it will reduce precision
<beuno> hm, I haven't used tracker to know about how that can be achieved. It's the first thing I remove when doing fresh installs  :)
<beuno> but, conceptually, being able to track down commits and source code *does* sound good for someone who uses such a thing
<beuno> of course, there are many other more interesting places to get it working first, like bzr-gtk
<beuno> and bzr-gedit
<beuno> which I suspect can share the code
<lifeless> yah
<beuno> I'm off to get drun... ehm, a birthday party
<lifeless> :)
<lifeless> oh oh oh I should do suggestions
<tro> vila: no packages for 1.6 for ubuntu yet. i didn't want to install it from source, that's all :)
<tro> vila: nm. i see there's a beta-ppa repo available now. i'll install from there
<lifeless> ok, this should be interesting
<lifeless> indexing all debian source
<bob2> haha
<lifeless> remember that mega repo I created?
<lifeless> 16K branches, 22G
<lifeless> while index is per-branch the underlying code isn't so coupled
<lifeless> so:
<lifeless> >>> import bzrlib
<lifeless> >>> from bzrlib.plugins import search
<lifeless> >>> index = search.index.open_index_url('.')
<lifeless> >>> r = bzrlib.repository.Repository.open('..')
<lifeless> >>> from bzrlib.ui.text import TextUIFactory
<lifeless> >>> bzrlib.ui.ui_factory = TextUIFactory()
<lifeless> >>>
<lifeless> >>> index.index_revisions(index._branch, r.all_revision_ids())
<lifeless> :)
<bob2> bwaha
<tro> what does this mean? "bzr: ERROR: Repository KnitPackRepository('https://myusername@server.org/bzr/.bzr/repository/') is not compatible with repository KnitPackRepository('file:///home/tro/code/asdf/.bzr/repository/')"
<tro> i'm trying to push an existing checkout to a remote webdav branch
<tro> webdav repo, sorry
<bob2> is bzr-svn involved?
<lifeless> tro: one of the repositories is rich root, one isn't
<tro> bob2: i thought it was, but i just tried with a brand-new empty one and it didn't work
<lifeless> tro: how did you make the brand new empty one?
<lifeless> bbiab
<tro> lifeless: i think i created the repo with the same version of bzr, but maybe 1.5 instead of 1.6
<tro> i used bzr init-repo --no-trees
<tro> i'll try updating the bzr version on the remote side and recreate the repo (it's empty now anyway)
<bob2> the remote one seems to be rich root
<tro> what's the default that is created with "bzr init-repo"
<bob2> --pack-092
<tro> i don't have to worry about old bzr versions. should i just recreate the repo with --rich-root-pack ?
<bob2> well, once you figure out which is whichm yeah
<tro> how do i find out which format a tree is in?
<bob2> repository, technically.  bzr info https://myusername@server.org/bzr/.bzr/repository/ ; bzr info file:///home/tro/code/asdf/.bzr/repository/
<tro> ok, now i see that my checkout is the one that's in pack-0.92. any way to convert it to rich-root-pack?
<bob2> what command ddi you run that caused that error? co?
<tro> bzr push
<tro> hmm .. when both the remote repo and the local checkout are in pack-0.92 i get the same error
<bob2> dunno how you can get that error if both sides are pack-0.92, sorry
<lifeless> tro: bzr info -v will tell you the format of a url
<lifeless> tro: can you do that and show the repository format line here from each output
<lifeless> afk again
<tro> lifeless: from the shared repo:
<tro>        control: Meta directory format 1
<tro>     repository: Packs containing knits without subtree support
<tro> from the checkout:
<tro>        control: Meta directory format 1
<tro>   working tree: Working tree format 4
<tro>         branch: Branch format 6
<tro>     repository: Packs containing knits without subtree support
<tro> they're both pack-0.92
<lifeless> tro: but you get that error when you push  ?
<lifeless> tro: did you do 'bzr info -v URLITISPUSHINGTOO' ?
<kumi2> hm, on linux I see a No handlers could be found for logger "bzr" message when I use the bzr command
<kumi2> and I get duplicate messages on stdout
<kumi2> [ 8249] 2008-06-12 23:11:37.746 INFO: All changes applied successfully.
<kumi2> All changes applied successfully.
<lifeless> kumi2: please file a bug, that shouldn't happen
<mwhudson> codespeak's svn still seems to defeat bzr-svn
<jelmer> 0.4 branch?
<mwhudson> yeah
<mwhudson> jelmer: http://pastebin.ubuntu.com/20308/
<jelmer> hmm, something is not concatenating urls right
<james_w> Hi all
<sven_> hi! i get a traceback when running 'bzr parent bzr+ssh://some/repository/some/file'. see http://pastebin.com/m1c159a5c . not sure if thati
<sven_> not sure if that's supposed to work, but it seems wrong to get a traceback anyways...
<james_w> what's "bzr parent"?
<jamesh> james_w: by the look of the arguments list in the output, not the problem
<james_w> no, I was just curious
<jamesh> probably the parent of the current branch
<james_w> it's not a command I've seen before, I was wondering where it came from. It might be useful to have in the core.
<jamesh>   mysql_plugins        /home/sven/.bazaar/plugins/mysql_plugins [0.3.7]
<sven_> sorry, bzr parent is from a plugin library i'm using. new paste with `bzr parent` substituted: http://pastebin.com/m4523db02
<sven_> jamesh, james_w ^
<jamesh> sven_: so, looking at your output, the error came from the "bzr annotate" call rather than the "bzr parent" call in backticks
<sven_> jamesh, yes
<jamesh> sven_: just trying to reproduce locally
<james_w> I think you are seeing https://bugs.edge.launchpad.net/bzr/+bug/237067
<ubottu> Launchpad bug 237067 in bzr ""bzr check" on bzr+ssh:// branch returns ObjectNotLocked error" [Undecided,New]
<james_w> read John's first comment for the details.
<jamesh> don't see an exception, but it is pegging the CPU (this is bzr+ssh to localhost)
<sven_> hmm, ok. i don't understand the thread completely. should i add my paste to that bug report?
<james_w> I don't think it's needed, John seems to know what's goind on.
<james_w> I triaged the report, so hopefully it will get noticed and fixed.
<sven_> james_w, jamesh, thank you!
<james_w> no problem
<qense> Does bazaar support something like this: http://upload.wikimedia.org/wikipedia/en/a/ac/Hgk.png ?
<qense> I don't mean the graphical program, but the tree merging
<qense> If it exists in bzr, how do you do it?
<qense> (and is there a way to generate those fancy graphics? :))
<jelmer> "bzr viz" is similar to hgk
<jelmer> (part of bzr-gtk)
<james_w> hi qense
<qense> hello james_w
<qense> bzr viz looks great
<gour> qense: yes, it is really great
<rockstar> Hey devs, I'd like to take a whack at fixing bug 109115.  It's marked trivial, so I didn't think it'd require too much.
<ubottu> Launchpad bug 109115 in bzr "nicer error when unable to commit large files" [Medium,Confirmed] https://launchpad.net/bugs/109115
<james_w> hey rockstar
<rockstar> Hi james_w
<james_w> I'm not sure how that should be tested, perhaps create a file like class that returns a huge amount of data
<james_w> the fixing it shouldn't be too hard though, just finding an appropriate place to put a try block.
<james_w> you might want to start off by creating the exception that will be thrown when the error is hit: bzrlib/errors.py
<rockstar> james_w, yea, I think I've got a fix.  The testing method seems to be the most difficult part.
<james_w> it might be something that will be allowed in without a test, but if we can come up with a way then it would be better.
<rockstar> Yea, it's always better to have a test.
<rockstar> However, writing a test is what's going to help me personally start understanding the code base itself.
<james_w> true
<james_w> so the problem is when you commit it reads a copy of the file in to memory, and then falls over?
<rockstar> Yea, if the file is too big, it fills up virtual memory.
<james_w> at what level did you put the try block?
<rockstar> bzrlib.tuned_gzip:352 has an if statement that makes sure the filesize > 0.  I added a filesize max limit to it.
<james_w> ah, ok.
<james_w> so this can be tested really low then
<james_w> I've never looked at tests for that area though.
<rockstar> Yea, I'll have to explore.  I'm still reading HACKING.txt - Thought it would be good to just give everyone a heads up that I was working on it.
<james_w> ah cool, thanks for working on it.
<james_w> had you used bzr before you started your current job?
<bpeterson> are there any plans to allow blocking and unblocking of revisions like svnmerge.py
<mdamt> Any insight how to run bzr like in launchpad.net? I mean the client uses bzr+ssh:// but don't want to provide the shell access to the users. Using /usr/bin/scponly didn't work.
<mwhudson> well, launchpad uses a custom ssh server
<mdamt> Hmm tricky...
<fullermd> You could do it with any restricted shell.  I think scponly has some configurability...
<mwhudson> but you can allow users to only be able to execute 'bzr serve --inet --allow-writes /'
<mwhudson> or whatever it is bzr+ssh uses
<mdamt> So basically using the shell that only allows to run bzr?
<mwhudson> not really
<mwhudson> it's an openssh thing, you can restrict the commands a given user can run
 * mwhudson has to run away, biab
<mdamt> Ok, many thanks!
<mdamt> Wow the solution was very easy. I made this script as the bzr-use-only shell: ï»¿http://dev.blankonlinux.or.id/browser/infrastruktur/bzr-ssh-shell/bzr-ssh-shell
<beuno> mwhudson, I've been spying on your paste branch...  seems we're close to dropping turbogears and cherrypy  :_
<beuno> :)
<mwhudson> beuno: yeah, let's hope so
<mwhudson> it's very very hackish at the moment, but it does work
<beuno> mwhudson, btw, you wouldn't happen to know a good way to get a branch's path through the history object, would you?
<mwhudson> path?
<beuno> yes, absolute path to it
<mwhudson> i guess by looking at the bzrlib branch object
<mwhudson> why do you want it though?
<mwhudson> currently loggerhead works fine with branches access over e.g. http
<beuno> bzr-search integration  :)
<mwhudson> and, mumble, it would be nice if it carried on that way
<beuno> http://bazaar.launchpad.net/~beuno/loggerhead/bzr-search_integration/annotate/argentina%40gmail.com-20080614235107-upywmflu0p2b1t1w?start_revid=argentina%40gmail.com-20080614235315-sd5uapabc2aym4f0&file_id=search.py-20080614235103-lpt63f7b2drplju8-1
<beuno> that's where I need to plug it in
<beuno> (I call that within the History class, so I can pass on an extra value)
<lifeless> moin
<beuno> howdy lifeless
<thumper> lifeless: morning
<lifeless> hi thumper
<thumper> lifeless: are you at the vibe?
<lifeless> not yet
<thumper> going though?
<lifeless> wtoday for sure
<lifeless> other days will depend on stacked progress
<mwhudson> beuno: ah, um, ok
<mwhudson> beuno: h._branch.transport.base ?
<mwhudson> no, that probably isn't right
<poolie> hello
<poolie> me too
<beuno> mwhudson, I suppose I can pass whatever location LH is using too, of course. I meant
<beuno> absolute path as in "branch location"  :)
<beuno> hi poolie
<mwhudson> beuno: right :)
<mwhudson> i think the kids call these things URLs nowadays
<lifeless> mwhudson: the function is open_index_url :P
<lifeless> beuno: I refactored though, there is open_index_branch too now
<mwhudson> sounds like a better fit
 * beuno looks
<igc> lifeless: quick heads up on that performance testing - all ok at first glance
#bzr 2009-06-08
<jbalint> hello!
<jbalint> i rebased my changes against some other stuff, but how can i push it to launchpad?
<jbalint> is --overwrite safe?
<dash> what does 'safe' mean? :)
<SamB> jbalint: you've read all the warnings in git-rebase(1)?
<jbalint> dash: will it just remove all the revisions after they diverge on the destination branch?
<jbalint> SamB: well, first i'm not using git, and second, i dont see any wrnings on rebase plugin help
<SamB> jbalint: I didn't ask if you were using git!
<SamB> the warnings are applicable regardless
<jbalint> ok, mightve helped to mention that
<thumper> jbalint: as long as you are fairly sure that no one else depends on your old chagnes
<thumper> then push --overwrite to LP will work fine
<jbalint> ok, thanks
<Peng_> How should I link an already-fixed bug with the release it was fixed in?
<Peng_> "Nominate for release"? I don't want to add any administrative burden, though.
<Peng_> (Bug #241133 and 1.13, FWIW.)
<ubottu> Launchpad bug 241133 in bzr "Don't suggest the user specify -Dhpss" [Medium,Fix released] https://launchpad.net/bugs/241133
<cammoblammo> What's the status of nested trees these days?
<pattern> if i use "bzr rename foo bar", will "foo" be retroactively named "bar" in all previous versions?
<pattern> i mean "bzr mv foo bar"
<fullermd> Peng_: Set a milestone, I think, but milestones for past releases may be closed.
<fullermd> pattern: No, just for future ones.  Previous revisions are already set in stone, that's why they're previous  8-}
<pattern> so what happens when i do a "bzr diff -rX..Y bar" when X is a version in which "bar" was named "foo" ?
<fullermd> It'll show a rename and any changes to the content you made.
<pattern> great
<fullermd> (now, patch(1) probably won't understand and do the rename if you try and use the diff for that, but...)
<pattern> thanks.. i'll keep that in mind
<fullermd> The only way you can generally make patch(1) do that is have the diff be something like "remove all lines from foo, add [almost] the same lines to bar"
<fullermd> That's a little less friendly to read, though   :p
<fullermd> pattern: e.g., http://www.pastebin.ca/1451535  for a rev with a rename and adding a line
<Peng_> fullermd: Ahh, good suggestion. I'll try it.
<pattern> thanks, fullermd
<pattern> i will consider doing something like that, should i have the need
<Peng_> fullermd: Ahh, I don't think I can set a milestone, since I'm not a bzr developer.
<vila> hi all
<Peng_> Good morning!
<hsn_> anybody have experience with doing CVS import via cvsps-import? Is there way to attach tags to branch?
<sidnei> hello there, what's the right procedure to upgrade a branch hosted on launchpad? bzr upgrade --format=... && bzr push will do?
<jpds> Yep, and I thought a button for doing that from the webui was going to be done/in planning.
<james_w> upgrade and push won't change what is on lp
<james_w> you need "bzr upgrade --format=... lp:branch" for that
<jam> vila: good morning
<vila> jam: hi John, just tried to ring you but abandoned after the 6/7 or 8th 'still trying' :-) Should I try again ?
<jam> sorry about that
<jam> my wife is on a conference call *all day*
<jam> she got out of traveling to europe
<jam> but then has to sit on the phone for the whole conference
<vila> oh, np then
<jam> you can call my cell phone if you still want to chat
<vila> jam: ok
<siretart`> hi
<siretart`> I'm stuck during a merge, can you perhaps help me out here? In my merge, I have a lot of conflicts. I want to resolve these conflicts by 'reverting' to the version of the "OTHER" branch
<siretart`> I would be expecting some 'bzr revert --other' switch, but it seems to be unavailable
<siretart`> in the past, I've used 'bzr revert -rrevid:$REVID $file' for that
<siretart`> but now I'm using bzr-builddeb to merge to a new upstream version, which makes it hard for me to guess the revid of the "other" branch
<siretart`> is there some way to learn the revids involved in a merge somehow?
<siretart`> I expected 'bzr status -v --show-ids' to tell me that, but it doesn't :-(
<siretart`> this is bzr 1.15, btw
<ja1> siretart`: well the ugly hack is "head .bzr/checkout/dirstate"
<ja1> which should tell you the revision of OTHER
<siretart`> ja1: that sounds promising, but I don't quite grok the format of that file :(
<ja1> siretart`: line 3
<ja1> should have "2 <revision-id> <revision-id>"
<siretart`> without spaces for me, but yeah, I see that
<siretart`> ah, right, so the 2nd id should be the 'other' branch
<siretart`> thanks!
<ja1> well, with a "\0" not a space
<siretart`> ok
<siretart`> excellent, that works for me
<siretart`> may I still suggest to add some option '--other' to the the revert command? ;-)
<jam> you can suggest whatever you like :)
<jam> but yeah, some way to reference "the new merge parent" would be useful
<siretart`> or maybe as a new revision specifier
<siretart`> james_w: hi there
<siretart`> james_w: I've just patched bzr-builddeb to contain an switch to ignore using pristine-tar even if it is installed on the system
<james_w> hey siretart
<james_w> how are you?
<james_w> why don't you want to use it?
<siretart`> james_w: for some reason pristine-tar just hangs indefinitly when called by bzr-builddeb, no idea why
<siretart`> sek
<james_w> ah
<james_w> I think that I might have a fix for that
<beuno> james_w, hi
<beuno> could you fire off an upload of bzr.dev to the PPA?
<james_w> hey beuno
<james_w> beuno: sure
<beuno> james_w, thanks
<beuno> how was your vacation?
<james_w> good thanks, very relaxing
<james_w> seems I misplaced my GPG key somewhere in Spain though, and I can't find the backup today
<siretart`> re
<siretart`> james_w: thanks, I'm fine (again, was rather sick last week, but I feel better now)
<siretart`> trying to upgrade one of my older packages, and wanted to use bzr-builddebs merge capabilities
<james_w>   387 James Westby	2009-05-13
<james_w>       Don't deadlock when the pristine-tar delta is large.
<siretart`> james_w: anyway, are you interested in merging my --avoid-pristine-tar switch?
<james_w> I stupidly didn't read a big fat warning in the subprocess docs
<siretart`> aah, that sounds exactly like the problem I'm experiencing
<james_w> so I can fix that
<james_w> I'm not against the flag, but I'd rather not merge it unless there is a real need for it
<james_w> if I can fix bugs instead then that would suit me fine
<siretart`> ok
<james_w> siretart`: it's in lp:bzr-builddeb/2.1 if that suits you
<james_w> I should seek an SRU for the couple of bugs that I have fixed
<siretart`> oh, I'm following lp:~bzr-builddeb-hackers/bzr-builddeb/trunk, is that branch deprecated?
<siretart`> too late, I've already upgraded without pristine-tar now :-)
<james_w> :-)
<james_w> it's not deprecated
<james_w> it was just still pushing :-)
<siretart`> I have to admit that I nowadays maintain quite a bounch of packages in git these days, mainly because of the packaging teams I'm active in
<siretart`> what I miss most in bzr is an interactive rebase, so that I can cleanup and combine unpushed commits
<cody-somerville> siretart`, Does the bzr rebase plugin not have interactive mode?
<siretart`> not in my copy of it
<james_w> I don't think it does yet
<siretart`> I've just pulled lp:bzr-rebase, but it doesn't seem to be there
<siretart`> bzr: ERROR: Invalid url supplied to transport: "lp:bzr-builddeb/2.1": Project bzr-builddeb has no series called "2.1"
<siretart`> err, uh?
<james_w> uh?
<james_w> oh, seems I never created the 2.1 series
<james_w> lp:~bzr-builddeb-hackers/bzr-builddeb/2.1
<james_w> or it's in trunk now
<Tak> argh @ git
<Tak> how good is bzr-git (or git-bzr or whatever)?
<james_w> improving rapidly :-)
<Tak> do you think it's Good Enough for readonly use?
<ddaa> I'd say try it.
<ddaa> If it does not crash, it's good enough for read-only use :)
<ddaa> It's not like it's going to make you lose any data.
<ddaa> even if it's buggy or unstable, then you might get corruption errors down the road, that shoud not prevent you from accessing your older commits
<ddaa> or
<ddaa> you could drink until the pain is tolerable
<ddaa> then keep using git :P
<dash> or you could drink and use bzr
<dash> (guess what I picked)
<ddaa> in this case, that's recreative drinking
<ddaa> not drinking-to-numb-the-pain
<ddaa> that leads to drinking-to-forget-that-git-led-you-to-alcoholism
<dash> i didn't say what was in my bzr branch
<siretart`> james_w: it seems that the trunk branch and 2.1 branch have diverged quite a bit. is 2.1 supposed to be behind or ahead of trunk?
<james_w> behind
<james_w> it will have a higher revno though
<james_w> I merged them today
<siretart`> oh, I see
<james_w> ah
<siretart`> hm. I'm quite happy with trunk, but it is missing some revisions from 2.1.. hmmmm
<james_w> it's a mirrored branch, so if you are going off LP it won't be up to date yet
<siretart`> oh
<hsn_> supports bazaar 1.10 server side commit hooks?
<cellofellow> how do I restore a deleted file?
<LeoNerd> revert it?
<cellofellow> without reverting all my changes to other files?
<cellofellow> bzr revert filename didn't work, as the file doesn't exist
<cody-somerville> cellofellow, bzr revert <file>
<cody-somerville> specify a revision
<cellofellow> ok
<LeoNerd> bzr revert -r-1 filename
<cellofellow> oh, ok, thanks
<cellofellow> ok, that worked, thanks
<RockyRoad> garyvdm: hi :) are you around ?
<garyvdm> Hi RockyRoad
<RockyRoad> how are you ? how goes qbzr ?
<RockyRoad> I have a little problem again, with lauchpad
<RockyRoad> the uncommit succeeded locally, but push does nothing (doesn't revert)
<RockyRoad> It's the right branch, because I can see the message "updating branch" on lp page
<RockyRoad> https://code.edge.launchpad.net/~m-baert/planet-drupal/planet-6-x
<RockyRoad> I'm back on rev 25 in my work directory
<RockyRoad> It's still 26 on lp
<RockyRoad> Is there something I missed ? or is it because the commit was done yesterday ?
<RockyRoad> (Yes I could ask on lp, but you know the context now ;)
<maxb> Isn't it generally considered a bad idea to uncommit things which are already pushed to a public repo?
<RockyRoad> I think a similar sequence worked yesterday
<LarstiQ> maxb: yes
<LarstiQ> RockyRoad: maybe you're missing --overwrite?
<maxb> RockyRoad: so don't do that, then?
<RockyRoad> LarstiQ: good idea I missed it
<RockyRoad> maxb: it's a dev branch, not that public
<RockyRoad> LarstiQ: THANKS \o/ it worked :_
<RockyRoad> :)
<RockyRoad> I will repush it with no code diff, very soon
<RockyRoad> better commit message, and after a CVS commit
<RockyRoad> and adding a changelog file for cvs
<RockyRoad> nothing that should really break users' platforms
<garyvdm> RockyRoad: Sorry - was not watching irc
<LarstiQ> RockyRoad: right. The thing is, anyone who was just mirroring your branch now will get a Diverged branches error (if they have the commit you just uncommitted)
<LarstiQ> RockyRoad: wether that is a problem is up to you, but it can be nasty
<garyvdm> The other option is to (which maxb is suggesting) is to do a bzr revert -r -2, and bzr commit, bzr push
<RockyRoad> garyvdm: np it's solved ... I think .... still learning with LarstiQ, maxb .... and you :)
<RockyRoad> LarstiQ: honestly I doubt it can be the case, but I'm interested to know more about this diverged branch issue. Is it that nasty ?
<LarstiQ> RockyRoad: it can be overcome relatively easily in the simple case, but it disrupts people's workflow
<LarstiQ> RockyRoad: you can try it for yourself, take a branch, make a copy, uncommit, new commit, and pull
<Tak> I hit that the other day
<RockyRoad> I'd be glad to know them if there are other devs working on it
<RockyRoad> LarstiQ: good idea. I'll do it, to see ... and know for later occasions.
<RockyRoad> Thanks all :)
<superm1> hi guys. i'm looking for the best way to move some source files from one project to another while maintaining information about version history on those files if possible
<LarstiQ> superm1: how are both branches related?
<superm1> LarstiQ, well so one is a "common" project and the other is a child project. moving a lot of the code from the child project into the common project
<superm1> so the branches never have had a common anscestor
<LarstiQ> right
<RockyRoad> I don't know if it would help, but I just finished something a bit similar
<RockyRoad> http://www.rocky-shore.net/misc/bzr-rebuild.html
<RockyRoad> sorry I didn't update it yet with the last things garyvdm helped me with yesterday
<superm1> yeesh that looks complex
<RockyRoad> the key as I understood is to use merge with a revision range
<RockyRoad> to make a common ancestor
<superm1> so i guess i'll need to look at what revisions i care about in these source files then
<RockyRoad> yes find exactly the two history points to connect
<RockyRoad> LarstiQ: I'm explaining it with my bzr-noobie language
<RockyRoad> you surely know better than me, but it sounds so similar ...
<superm1> so let me get this right, i'll manually copy the files into the new tree, and 'bzr add' each of them for "initial checkins", that's my new last history point
<superm1> and then something along the lines of bzr merge the revisions from there and earlier that i need to bring history in for?
<LarstiQ> superm1: I wouldn't do it that way
<LarstiQ> superm1: you can force a common ancestor with -r0..
<LarstiQ> superm1: but maybe by reference nested trees are good enough for you
<RockyRoad> superm1: a "bzr push lp:~user/project/branch" copies all  at once
<superm1> RockyRoad, well i'm doing it all locally so i can easily undo things for now
<superm1> LarstiQ, i'll try and read up on reference nested trees then
<RockyRoad> so just copy the directory
<asabil> hi all
<LarstiQ> james_w: if you have a identi.ca account I haven't found it, but: do you know www.philosomatika.com ?
<james_w> LarstiQ: I didn't
<james_w> thanks
<poolie> hm no jam?
<poolie> hello all anyhow
<garyvdm> hi poolie
<jam> hi poolie
<jam> I was just heading out
<poolie> np
<poolie> i was just going to try to catch up
<poolie> i have another call now, but we could talk tomorrow maybe?
<thumper> am I supposed to be able to branch from a 1.6 format repository into a brisbane-core repo?
<thumper> I have my branch command stuck on "Transferring revisions 0/1509"
<thumper> with 100% on one core
<GaryvdM_win32> thumper: It's doing a upgrade on the revisions that it's pulling - so it will be slow
<thumper> GaryvdM_win32: thanks, I see that it has not got to 100/1509
<limmer> i'm having trouble opening bzr viz getting this message
<limmer> ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExisted: Launch helper returned with unknown return code 0
<limmer> has anyone had this problem?
<GaryvdM_win32> limmer: Thats a know bug. Workaround: run bzr viz again
<GaryvdM_win32> You have to run it twice every time after you boot your machine.
<limmer> GaryvdM_win32, wow, i feel ridiculous
<limmer> thanks
<GaryvdM_win32> limmer: It's a pleasure. P.S. have you tried qbzr?
<limmer> i havent
<GaryvdM_win32> It shows you a visualization like bzr viz, and it also allows you to collapse/expand branches
<limmer> very cool, i'll have to give it a shot
<GaryvdM_win32> Which is useful if you have complex branches.
<GaryvdM_win32> Great
<GaryvdM_win32> s/qbzr/qlog
<limmer> installing now
<limmer> GaryvdM_win32, qbzr is awesome! ty for the tip
<limmer> cheers
<GaryvdM_win32> It's a pleasure
<igc> morning
<igc> hi GaryvdM_win32
<GaryvdM_win32> Hi igc
<mwhudson> bzr info $branch_which_tries_to_stack_on_not_there_branch is a bit confusing
<GaryvdM_win32> Grr - while I was a uds, the guy who was sub'ing for me at work infected our work computer with a virus called mabezat which I just cant get rid of
<beuno> mwhudson, when you get a chance
<beuno> can you tell me what needs to be done to get these to MPs in:
<beuno> https://code.edge.launchpad.net/~beuno/loggerhead/serve-config/+merge/6821
<beuno> https://code.edge.launchpad.net/~beuno/loggerhead/deprecate/+merge/6929
#bzr 2009-06-09
<beuno> mwhudson, ta
<mwhudson> beuno: i'm a pushover :)
<beuno> very effective pushover ;)
<spiv> Good morning.
<lifeless> hai
<Kissaki> hi
<Kissaki> morning... haha
<garyvdm> igc: how important do you think it is to finish 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
<igc> garyvdm: pretty important ...
<igc> at a minimum, we want a placeholder class so ...
<igc> that all GUIs get nicer revision selection as the widget changes/improves
<igc> garyvdm: the first implementation doesn't need to be too clever - it just needs to exist :-)
<garyvdm> It's current status is that it works, but some time one 1 cell gets selected, rather than the whole row.
<garyvdm> and you can't select multiple rows - which would be nice for things like merge - to do cherry picks
<lifeless> http://www.xaprb.com/blog/2009/06/07/the-cache-oblivious-algorithms-inside-tokuteks-tokudb/
<igc> garyvdm: where can I see it in action now?
<Gnx-> can I specify a file to always be overwritten in new revisions?
<garyvdm> igc: lp:~qbzr-dev/qbzr/revision-selector
<garyvdm> then bzr pull
<garyvdm> err bzr qpull
 * igc grabs it
<igc> damn - AbsentContentFactory exception :-(
<garyvdm> igc: unfortunately to fix the problems with it, I need to rewrite some of the qt combo box code so I can modify it's behaviour
<garyvdm> Gnx-: can you explain in a bit more detail
<garyvdm> Do you want the file to be overwritten when you pull a new revision?
<Gnx-> garyvdm: well I'd like to include a sqlite database, and it does not like merging
<Gnx-> but I'd want it to always be the version from the lats commit
<Gnx-> last
<garyvdm> Gnx-: with you now - but I don't know the answer
<garyvdm> sorry
<Gnx-> so basically I'd like to have the overwrite option for just one file
<Gnx-> I know I can have it for push/pull in their entirety
<garyvdm> Gnx- does bzr detect that it is a binary file, or does it think it's a text file and try merge it?
<Gnx-> garyvdm: it thinks its a text file
<Gnx-> and throws content conflict
<garyvdm> Gnx- Hmm - that seems like a bug :-(
<garyvdm> Gnx- Bug 218128
<Gnx-> garyvdm: so it should detect binary files?
<ubottu> Launchpad bug 218128 in bzr "some binary files detected as text: provide a way to flag files binary?" [Wishlist,Confirmed] https://launchpad.net/bugs/218128
<Seablade> Hmm before I make a complete fool of myself, is there an IRC channel for TortoiseBZR?
<lifeless> this is i
<Seablade> Haven't found anything via google yet
<lifeless> it
<garyvdm> Seablade - no - you can ask here
<Seablade> Ahh ok, now to make a fool of myself then:)
<Seablade> Is there a way using tortoisebzr to checkout from an SVN server with credentials?  I can't seem to find a place to enter them, and the checkout process seems to be hanging so I assume it is looking for them
<garyvdm> Seablade - I think you have to put the password in the url.
<Seablade> TortoiseBZR installed as part of the Bzr for windows installer for the record
<Seablade> garyvdm: Hmm didn't try that, now I gotta remember the syntax for doing that, thanks
<Seablade> garyvdm: I will let you know if it works
<garyvdm> I know jelmer added ui code that asks for a username and password. Qbzr only implements the just password version. (TortoiseBZR - uses qbzr btw)
<lifeless> jam: pyrex for heads I think
<lifeless> jam: when you're into inner function removal for optimisation...
<garyvdm> Sorry igc: that AbsentContentFactory exception - was that using the revision selector?
<Seablade> garyvdm: Yes I knew that much of TortoiseBZR and QBzr were the same, just wasn't sure how much.  Hmm looks like the username and password in the URL seems to be crashing it, gotta do a sanity check but I think I got everything correct
<Seablade> garyvdm: Hmm there should be no need for quotes when supplying username and password through the URL is there?
<lifeless> igc: use nosmart+ should avoid the error
<lifeless> garyvdm: you need to run the branch repairer
<igc> yep - plain http worked as well
<lifeless> poolie: I had no further changes to make to the advisory I drafted; abentley suggested including more of the immediate actions in it, which I could work in if you like, or we could send it out
<lifeless> mwhudson: where are you guys at in runing the repairer over all stacked branches?
<mwhudson> lifeless: somewhat stalled, i guess
<garyvdm> Seablade: You should only need to specify a username - it will then ask you for the password.
<Seablade> garyvdm: Hmm let me try that, the protocol should just be https if it is checking out over svn+https correct?
<idnar> Lightweight checkout (format: dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
<idnar> what exactly does "or" mean there?
<garyvdm> Seablade - I don't know that - have not use bzr-svn much.
<Seablade> garyvdm: Looks like it, it is checking out now, or at least seems to be, thanks
<lifeless> idnar: inclusive
<idnar> well, I mean, why can't it tell me which one it actually is?
<lifeless> idnar: because the ui is trying to be too smart
<lifeless> idnar: what it means is 'this is the style of checkout you get with any of the above formats'
<Gnx-> garyvdm: do you think if I slipped some non-text in the beginning of the file it would behave correctly in bzr?
<idnar> ah, okay
<lifeless> idnar: because they all share the same 'working tree' code
<idnar> so I guess I'd want to run bzr info against the repository I checked out
<Seablade> garyvdm: Ok I can reproduce that crash at least, it seems to happen when in tortoiseBzr I tell it to checkout to a location(destination) that does not end in the svn repository name
<Seablade> garyvdm: So for isntance if I checkout https://blah/els to C:\Projects it dies, but doesn't if I do it to C:\Projects\els
<garyvdm> sorry Gnx-, Seablade - I'm a bit busy atm.
<Seablade> garyvdm: np, just tossing it out there if anyone needs the info, I have the checkout working at least, which was the main goal.  If I have to deal with a slittle screwy directory structure I certainly can;)
<lifeless> idnar: depends on what you want to find out, but yes
<mwhudson> is it possible the bzr 1.14 release branch never got merged back to bzr.dev?
<mwhudson> (or that it did, but after the 1.15 branch was cut?)_
<mwhudson> i guess i can find these things out for myself
<lifeless> I sure hope so
<idnar> are bzr+ssh URLs relative to $HOME?
<SamB> idnar: I think you need a /~/ if you want that
<idnar> hmm, /~/ doesn't work but specifying the full absolute path does
<lifeless> idnar: no, they are abspath to the virtual root (which depends on server config as normal)
<lifeless> idnar: host/~/ is used with sftp to mean '.' in the SFTP protocol, as it has no good mapping in std66 and the I-D for sftp
<lifeless> :// was bong
<lifeless> spiv has a patch (not landed I think) to let /~/ be used with bzr+ssh too
<SamB> ":// was bong" ?
<lifeless> SamB: sftp:// was bong
<SamB>   bong
<SamB>        v : ring loudly and deeply; "the big bell bonged"
<thumper> lifeless: just confirmation before I delete them, but the content of obsolete_packs is ok to delete if no bzr commands are in progress right?
<thumper> lifeless: when do obsolete_packs get cleaned out?
<lifeless> thumper: when bzr does a pack
<lifeless> thumper: which is every 10 commits on average
<thumper> lifeless: I don't believe that
<lifeless> thumper: check the code if you like
<thumper> lifeless: because I just pulled stuff in that seemed to do a pack
<thumper> and I hve stuff there from over a month ago
<lifeless> thumper: file a bug then
<lifeless> thumper: The pack algorithm is as follows:
<lifeless> a) make new pack
<thumper> I have 2.3 gig of obsolete_packs in my LP repo
<lifeless> b) delete obsolete_packs contents
<lifeless> c) activate new pack
<lifeless> d) move obsoleted packs and indices to obsolete_paks
 * igc off for lunch and medical stuff
<garyvdm> How come bzr pull . -rsubmit: --overwrite only pulls the lca of . and :submit? I thought it would pull the tip of :submit like bzr pull :submit --overwrite
<spiv> garyvdm: because ". -rsubmit:" resolves to that particular revision
 * garyvdm re reads bzr help revisionspec
<lifeless> submit: is the lastmerged rev of the submit branch
<garyvdm> Ok - I thought that -rsumbit: gave you the tip of :submit.
<garyvdm> I thought wrong...
<poolie> lifeless: hi
<garyvdm> Hmm - so -r ancestor::submit == -r submit:
<poolie> lifeless: which advisory?
<lifeless> poolie: about stacked repositories
<lifeless> garyvdm: yes
<jam> lifeless: certainly I agree about pyrex if I was fully fine tuning. Mostly I'm algorithm exploring, and wanted to make sure it was comparable to our existing code
<poolie> jam, lifeless, i'd like to do 1.16rc1 a bit early, like this week, to help with brisbane-core testing
<poolie> and to let it be rolled into launcphad
<jam> poolie: sure
<poolie> do you see any problems, or any bugs that'd block it?
<poolie> lifeless: spiv does have a patch for ~ but he agreed it was bad to do it at the ssh level so he's going to rethink it
<poolie> ie it's still in his queue
<poolie> lifeless, jam, also, what do you think about changing both the on-disk marker and the ui name for this format to say '2a'
<jam> poolie: I think we should make it 2 or 2-something
<jam> vincent agreed this morning
<poolie> until i was writing that mail i was going to say just '2' or '2.0' but the thing is
<poolie> at least in the general case if not here
<poolie> we can't rule out changing it before code 2.0 comes out
<poolie> and having obviously different but related names seems to be useful
<spiv> '2a' seems like a reasonable compromise given the constraints (such as lack of time machine).
<poolie> ok
<poolie> i'll put up a patch
<lifeless> poolie: well its a dev format already
<lifeless> and currently we promise not to break them
<lifeless> poolie: I'm fine with the next change to it being e.g. 2.0beta
<lifeless> (I mean, I agree that we should put 2.0 in the disk format asap)
<spiv> poolie: https://code.edge.launchpad.net/~jspashett/bzr/76616_ignored_on_add_confusing/+merge/4864 has a comment from you saying "looks good, I'll merge", but lp doesn't think it is merged?
<mwhudson> jelmer: awake still?
 * mwhudson sends mail instead
<poolie> spiv: i think i rebased his patch
<poolie> he also said that i might have merged the wrong thing
<lifeless> chalk up another way rebase interferes ;)
<poolie> i'll come back to it sometime
<poolie> lifeless: i can't work out whether you're agreeing about format names or not
<KhaZ> I'm trying to debug an ssh error; how do I set BZR_SSH again?
<KhaZ> (For debugging purposes, I mean.)
<lifeless> poolie: I think we should have the next production format be called 2.0 on disk in some way; If we have no further planned changes then I think changing the format label would break early adopters and we should instead add another format with only a disk label change
<spiv> poolie: ok.  When the current PQM queue clears that will be the only proposal left on https://code.edge.launchpad.net/bzr/+approvedmerges, if that's extra incentive :)
<lifeless> poolie: It wasn't clear to me what you were proposing to do
<lifeless> KhaZ: I'm not sure, it might be one of openssh/paramiko/...
<KhaZ> Ah; got it!  Looks like I got owned by hosts.deny.  Whoops. ;)
 * spiv -> lunch
<Peng_> Cool, my Loggerhead repo fails a check. :D
<lifeless> Peng_: which one?
<Peng_> lifeless: Which repo or which check?
<lifeless> whih check
<Peng_> if (self.text_sha1 != tree._repository.texts.get_sha1s([key])[key]): KeyError: ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj')
<lifeless> hax!
<lifeless> (thats actually fairly serious)
<lifeless> we need tools to repair this
<lifeless> please file a bug
<Peng_> Crap, real
<Peng_> The copy on my server passes, so even in the worst case I've lost little to no data.
<Peng_> Err, really?*
<Peng_> lifeless: Any chance of ruining a remote repo if I push to it?
<lifeless> well it means there is an inventory claiming that  ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') exists, and yet its missing.
<lifeless> so that revision can't be reconstructed
<lifeless> I don't think you'll make it worse pushing to it
<Peng_> What if I push a revision in this repo to a remote one, though?
<Peng_> Argh, this is a pain.
<lifeless> backup the target repo first
<Peng_> Indeed.
<Peng_> lifeless: If another repo passes check, it's safe to say it isn't broken in this way?
<lifeless> probably :)
<Peng_> lifeless: Any idea how this could've happened?
<Peng_> Sigh, I want a faster CPU. Check is slow. :P
<lifeless> Peng_: bzr-svn possibly
<lifeless> Peng_: or a bug
<Peng_> lifeless: This isn't a bzr-svn repo, though.
<Peng_> Anyway, I'll file a bug once I'm done working around this.
<Peng_> Well, the good news is it looks like this hasn't affected my serfer or lp:loggerhead.
<lifeless> Peng_: it could be a fetch ailure, or a knit related ordering bug back some time ago
<lifeless> if that key exists in your other repo, try fetching a stream directly in python to fill it
<Peng_> lifeless: How should I test if it exists?
<lifeless> Peng_: _repository.texts.get_sha1s([key])[key])
<lifeless> with key = ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj') and so on
<Peng_> And the key is that tuple?
<Peng_> :)
<jml> poolie: available for a call?
<lifeless> jml: do you want to get together for the europython talk and do some notes/whatever
<jml> lifeless: yes, sounds like a great idea
<lifeless> jml: if so I'd be delighted, but I'll let you drive it (as I'm not going)
<lifeless> cool
<jml> lifeless: how's thursday evening?
<lifeless> this week is kinda full - but next week anytime should be fine
<jml> lifeless: ok cool.
<Peng_> lifeless: My other repo does not have that key.
<lifeless> Peng_: then you have a local rev (perhaps jelmer@samba.org-20090529150418-05on2fgizfqs77fj) which is either a ghost in other repos, or part of a dead branch, that is faulty.
<Peng_> lifeless: Ohhhhhhh! I just remembered!
 * Peng_ suddenly pings out, never to be seen again.
<idnar> haha
<poolie> jml: hi
<jml> poolie: I'm just out of batteries, may I call you on your mobile?
<poolie> jml: am a bit starving at the moment, would about 3pm be ok?
<jml> poolie: 3pm is perfec.n
<poolie> k
 * jml off.
<poolie> off to post ian's swag and get lunch
<Peng_> lifeless: Anyway. There was a branch, lp:~jelmer/loggerhead/smart-server (since deleted) that was, like, broken. I tried to branch it into this repo. Maybe that introduced the bad revision.
<lifeless> Peng_: likely
<Peng_> lifeless: Yeah, I just checked .bzr/branch/last-revision on my copy of the branch, and it is indeed that revision.
<Peng_> lifeless: Still think I should file a bug?
<lifeless> Peng_: how long ago was that
<lifeless> Peng_: and do you have knits locally?
<Peng_> lifeless: Note the date in the revid, 2009-05-29. My repo was (and still is) 1.9-rich-root. The remote repo presumably was too, since I don't remember a knit warning when branching it.
<lifeless> Peng_: actually yes. File a bug - we should neither have permitted the damage, nor your repo to be damaged, and we should allow it to be fixed.
<Peng_> .bzr.log++
<Peng_> lifeless: Filed https://bugs.edge.launchpad.net/bzr/+bug/385054
<ubottu> Launchpad bug 385054 in bzr "check: Missing key in get_sha1s" [Undecided,New]
<lifeless> jelmer: do you have that original source branch?
<Peng_> lifeless: Do you think the repo is safe to use as long as I don't interact with that revision?
<Peng_> jelmer: That is, the original, broken lp:~jelmer/loggerhead/smart-server
<lifeless> Peng_: yes
<Peng_> lifeless: So I can keep using it? You sure? :D
<Peng_> Why am I suddenly paranoid?
<lifeless> I don't know. Are they after you ?
<Peng_> lifeless: The Illuminati corrupted jelmer's branch to interfere with my work! or something!
<idnar> Peng_: don't answer that, he's one of them!
<Peng_> Oh crap!
<idnar> now you've done it, the Admiral will be here any second
<Peng_> Quick favor: Could someone link bug #241133 with the 1.13 milestone?
<ubottu> Launchpad bug 241133 in bzr "Don't suggest the user specify -Dhpss" [Medium,Fix released] https://launchpad.net/bugs/241133
<spiv> Peng_: I can't; the 1.13 milestone is no longer an option in the dropdown.  1.14rc2 is as far back as it goes.
<Peng_> spiv: OK. Thanks.
<lifeless> Peng_: don't stress.
 * jml is back
<Peng_> lifeless: You're just saying that because adrenalin makes it harder to read my mind!
<jml> poolie: whenever you're ready
<Peng_> bzr check seems to fail over bzr+ssh. "revno does not match len(mainline) 366 != 0".
<Peng_> Oh, actually, it had already checked the repo. That was just the branch.
<poolie> jml, hi!
<jml> poolie: skype?
<poolie> if you like
<spiv> lifeless: hmm, pqm is still silently swallowing my merge requests for lp: URLs :(
<lifeless> spm: ^
<poolie> jml: i'm going to change 1.16 to that date -- https://edge.launchpad.net/bzr/1.16
<Peng_> "bzr check" sure is dreadfully inefficient over the smart server. :)
<lifeless> Peng_: yes
<jml> poolie: thanks
<lifeless> Peng_: feel free to add a verb for it
 * Peng_ runs away.
<vila> hi all
<poolie> hello vila
<vila> poolie: I've started a buildbot. Only jaunty and OSX 10.5 to start with.
<vila> poolie: selftest is failing right now :-)
<poolie> even on jaunty?
<vila> poolie: at least one failure is related to pb noise, I was wondering if you had pending changes in that area ?
<poolie> are the results public?
<vila> the only test failing on jaunty is one testing 'bzr --version' stderr and finding some pb artifacts there, really not a big problem
<poolie> it's a bit surprising
<poolie> i do have some changes pending
<fullermd> Y'know, I had some weird test failures the other day I mentioned here...
 * fullermd digs.
<fullermd> test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7.
<vila> poolie: the buildbot is not public so far, but is under bzr and I keep notes
<poolie> spiv, hi?
<poolie> can you tell me more about bug 380314?
<ubottu> Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,Confirmed] https://launchpad.net/bugs/380314
<spiv> poolie: hello
<poolie> i guess specifically
<poolie> are you working on it, and is it needed for 1.16? (it seems so)
<spiv> To be honest, I'd forgotten about it, but I targetted it to 1.16 for a reason :)
<spiv> I'll start on that basically right now.
<Peng_> Huh, I can't get "bzr check --branch bzr+ssh://..." to fail again.
<Peng_> Maybe it only does if I check the whole repo too.
<poolie> ok
<poolie> what were you doing before i disrupted you? :)
<spiv> It shouldn't be a lot of work, I ought to have it done in time for the probable rc on Thursday.
<spiv> :)
<spiv> Today I've been closing off various small things, e.g. approved branches, a little bit of administrivia.
<vila> fullermd: and only that test ?
<spiv> Specifically, right when you pinged me on IRC I had just finished making a coffee :)
<poolie> :)
<vila> poolie: sorry, get distracted, does your pending changes includes setting the ui from an env var ?
<poolie> not yet
<poolie> i know it needs to be done
<poolie> at the moment i'm trying to make sure it gets cleaned off when there's other output
<poolie> i will come back to that
<poolie> lifeless: it's a good document
<poolie> you could put it in devnotes
<lifeless> poolie: Sure. Is devnotes a branch of bzr itself?
<poolie> no
<fullermd> vila: Well, I didn't run the whole test suite.  I just noticed that by accident since it got run when I was checking something else.
<vila> fullermd: ok, may be worth filing a bug for it so that it doesn't get lost :-/
<lifeless> poolie: can I ask why it isn't ?
<lifeless> I thought the developer docs subdir was working well
<fullermd> I've got a new workstation in pieces across my office.  Was planning to try a full testsuite run after I got it live, just to see what it's like when it takes less'n an hour to run...
<vila> fullermd: yeah !
<vila> fullermd: what processor/memory ?
<fullermd> Phenom II 955, 8 gig DDR2-800
<lifeless> fullermd: thats amd yead?
<fullermd> Yah.
<fullermd> Intel's still made it impossible for me to buy their chips, the bastiches.
<fullermd> I'd'a considered the i7 if the memory controller weren't b0rked  :|
<vila> fullermd: I'm curious to know about 'bzr selftest --parallel=fork' timings on it :-)
<vila> as soon as all tests pass there of course :)
<fullermd> I'm just dreaming of what it'll be like when firefox is merely really annoyingly slow.
<lifeless> fullermd: impossible?
<fullermd> Let me have my dreams.
<lifeless> fullermd: I'm sure they will take your money
<fullermd> They always have before.  Consistency is a virtue.
<vila> fullermd: why are the memory controller borked ?
<fullermd> Oh.  Because they integrated a memory controller, and then didn't let it support ECC.
<fullermd> AMD did.  So I can grab any AMD chip and put decent memory in.  With Intel, you always either had to be VERY careful and picky about motherboards, or buy Xeon.
<fullermd> And now that they've integrated the memory controller, you can't even be picky about motherboards anymore.
<vila> But don't you want the fastest DDR3 memory anyway ?
<fullermd> I don't care HOW fast I can get the wrong answer   :p
<fullermd> I care about my data; I don't consider ECC to be optional.
<vila> You have to educate me here I'm affraid because I may not understand what ECC is about then :-/
<fullermd> Detecting and correcting bit errors.
<fullermd> Same reason the new system is running ZFS with SHA256 block checksums.
<vila> And DDR3 don't do that ?
<fullermd> (I'm not paranoid.  I've been around long enough to know my hardware really _is_ out to get me!)
<fullermd> Oh, it can.  But DDR3 is still twice the price of DDR2, and the speed difference isn't near big enough to justify that.
<fullermd> Maybe in a couple years, I'll replace the board and load up on DDR3 when the price is down and 4GB DIMM's are at a good price point.  The processor will handle either.
<vila> Oh I see, the *other* strategy :-)
<fullermd> (it's a lie of course, I'll probably sit on the system unchanged for 6 or 8 or 10 years, like I always do.  But it's a nice dream  :P)
<vila> fullermd: I suggest you do yourself a favor and buy an SSD, you won't believe the impact on raw performances...
<fullermd> Oh, with my EXTRA money?   :p
 * fullermd doesn't have a couple grand to spend on storage...
<vila> you can find some for 150$ these days, worth the price for ~64GB to play with
<poolie> lifeless: because it's not a branch of bzr
<poolie> they're not really in sync with each other, like the user documentation is meant to be
<fullermd> The cheap ones all have abysmal random write performance.  You gotta get up into the $600 or so ones before they don't fall apart there.
<fullermd> Then double the price to get 2 of 'em to mirror...
<poolie> if we're landing something that is in sync, like documentation of code that's actually come in, that does belong in there
<igc> back
<fullermd> vila: I've got the new series Velociraptors.  They're plenty fast.
<fullermd> vila: (anyway, the hard drives could be pretty slow and still be a nice improvement over my current ~12 year old ones  :P)
<vila> haaa, Monsieur is using mirrored velociraptors and is talking about PRICE ? :-)
<poolie> hello igc
<fullermd> Hey, the raptors WERE the cheap option.  I'm a SCSI nazi.
<vila> pfew, I gave up with SCSI years ago :-/
<jml> if I do 'bzr init foo' inside a brisbane-core repo, the branch is format6 -- is this expected?
<poolie> igc, a large bag of UDS shwag is in the mail :)
<poolie> spiv, want a quick call?
<lifeless> jml: yes its a defence of repositories as currently defined
<lifeless> defect
<jml> lifeless: ok thanks.
<lifeless> poolie: have we moved all the extant theory documents out then ?
<spiv> poolie: sure
<lifeless> poolie: I'd rather not have two places to go looking for such things
<jml> how would I upgrade those branches to branch7 format?
<lifeless> jml: upgrade --<format>
<jml> lifeless: what goes into <format>
<poolie> ay
<lifeless> whatever you used to make your repo
<poolie> no, i haven't cleaned up all existing documents
<poolie> this is mostly an alternative to putting them on the wiki, which
<poolie> is annoying to edit especially when you're flying or on a super flakey network
<lifeless> oh
<lifeless> well, with this sort of think I would normally get some feedback and land it in bzr.dev.
<lifeless> Do you want this to change?
<lifeless> s/think/thing/ (Sorry about typos, am really EOD'd already)
<poolie> or an alternative to having it just on the list
<poolie> oh of course the other difference with this branch is that, like the wiki, unlike dev, it's clearly not pre-review
<lifeless> ah, [that wasn't clear]
<poolie> i did send a mail
<poolie> which may have been unclear :)
<lifeless> its likely in my backlog, I was a little distracted
<poolie> so, it's ok to land it in bzr.dev
<poolie> i do have some qualms about having speculative or thinking-out-loud documentation there
<poolie> i kind of feel if it's in a release it ought to all relate to that release
<poolie> also, possibly having somewhere it's shared and mutually editable without going through review is good
<poolie> though we could of course do that with just a devnotes branch of bzr
<lifeless> or a loom even :P
<jml> I didn't make this repo :(
<lifeless> jml: well, --development-rich-root should do it, but I haven't checked
<igc> thanks poolie
<jml> ahh right, was running in wrong directory
<jml> thanks.
<lifeless> poolie: I agree that there is a tension between the timelines of documents
<lifeless> poolie: this shows up a lot in translations
<lifeless> poolie: yeah, your email about that was pretty much sent right before the weekend between allhands and UDS; as you know monday morning had me emulating a chicken
<lifeless> poolie: I encourage you to put some thought into devnotes-as-an-experiment
<lifeless> so for instance, how do you get the same degree of review and consideration of whats in it as bzr.dev gets from the reviews on the list
<lifeless> I will look at it tomorrow and make sure I've read whats in it
<lifeless> but I really have to EoD now
<poolie> lifeless:
<poolie> > Perhaps weakrefs?
<poolie> [ ] metaprogramming
<poolie> [ ] code generation
<poolie> [ ] C extensions
<poolie> [ ] kernel module
<poolie> [ ] flub
<lifeless> weakrefs on the progress bars in the thing that maintains the stack
<poolie> maybe
<lifeless> then it can cleanly discard the most recent addition if a generator is existed early
<lifeless> FSVO clean
<poolie> the thing is
<poolie> even conceptually, getting away from the details of python implementation
<poolie> if the UI model is that there is a stack of nested activities
<poolie> and if activities can trail off with no clear ending
<poolie> there seems to be a problem...
<poolie> so you can handle this by generalizing the model, to say there can be an arbitrary DAG of progress tasks going on
<poolie> some of which hang around for a bit and terminate during gc
<lifeless> meep!
<poolie> and then you work out how to draw that on a single line of text :)
<poolie> or, as i'm doing now, you rethink whether generators should really be doing this
<lifeless> so
<lifeless> the concern I have is not whether generators should be doing this, but whether any code used by generators can...
<lifeless> [I mentally voted against generators doing progress bar creation/finalisation some time ago]
<lifeless> OTOH I may not be thinking all that clearly right now.
<poolie> code used by them in the sense of regular functions called by generators?
<lifeless> yah
<poolie> that shouldn't be a problem
<poolie> i'm moving away from passing pb arguments down the stack
<lifeless> right
<poolie> so they can just create one, use it, and clean it up when they're done
<lifeless> so the idiom I have is:
<lifeless> for generators, do progress by inserting a filter from a non-generator function
<lifeless> and the non generator has to be one that doesn't return the generator
<poolie> i'm not sure i understand
<poolie> but, i'm also not working on it atm and i have to stop soon
<lifeless> sure
<lifeless> just chewing the fat
<poolie> do you mean you have a plain function wrapping the generator?
<poolie> or vice versa?
<jml> pushing up a new bbc branch to local launchpad:
<jml> HPSS calls: 22 (10 vfs) SmartSSHClientMedium(connected=False, username=None, host='bazaar.launchpad.dev', port=None)
<jml> surprised to see so many vfs calls.
<lifeless> jml: pastebin the calls made please
<lifeless> poolie: the former sometimes; or the former and the latter simultaneously sometimes.
<spiv> jml: local launchpad is running bzr.dev?
<spiv> There is a weakness with the HPSS call count ratchets in our test suite atm where they tend to hardcode the format to 1.9.
<spiv> So a regression in number of vfs calls vs. 1.9 formats is certainly possible :/
<jml> spiv: yeah.
<lifeless> plain(generator(wrapped_helper))
<lifeless> spiv: I'm hesistant to multiply them
<lifeless> spiv: but perhaps we should bulk move them to chk
<lifeless> spiv: also, network deltas - is that now top of your stack and do you need any help on it
<lifeless> jml: pastebinned?
<spiv> lifeless: top of my stack is https://bugs.edge.launchpad.net/bzr/+bug/380314
<ubottu> Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,Confirmed]
<lifeless> oh right.
<lifeless> uhm, it should?
<jml> lifeless, spiv: http://paste.ubuntu.com/191488/
<spiv> lifeless: well, a better bug title perhaps is "bzr pull -r 123 fails on a stacked branch via HPSS"
<jml> client & server logging interleaved, unfortunately
<lifeless> spiv: my immediate reaction is to stop calling revision_history
<lifeless> jml: bzr-search
<jml> dammit.
<lifeless> jml: so there are two causes
<lifeless> bzr-search
<spiv> lifeless: yeah, the way that revisionspec does the revspec->revid mapping could probably be better, I think there's some nice logic somewhere that can work backwards from the branch last-revision info.
<lifeless> and tags being written via VFS
<jml> I don't know where bzr-search lives right now -- it's not in .bazaar/plugins
<lifeless> jml: push --no-plugins is the easiest 'temp removal' test
<spiv> jml: I 2nd lifeless' diagnosis FWIW.
<jml> as long as the server side isn't using it
<jml> although I don't think it will here
<lifeless> jml: we need to implement set_tags_bytes to remove 9 of those 10
<poolie> OK
<poolie> movie sign!
<lifeless> poolie: I am meeting a prospective DD in the city tomorrow @6 to sign his key
<jml> lifeless, spiv: thanks.
<lifeless> poolie: if you wanted to get together this week, tomorrow avo would thus work well for me.
<poolie> k
<lifeless> poolie: [just saying]
<poolie> will ask s
<vila> Will 1.16 be usable to switch bzr and launchpad to 2.0 format ?
<poolie> vila, yes!
<poolie> We Can Do It
<asabil> hi all
<lifeless> check and reconcile are still multi day operations for that format
<lifeless> I worry about the logicistics
<lifeless> I'm not sure we've finished fixing the bugs from the bzrtools upgrade experiment either
<poolie> vila, probably better for now if you shelve the buildfarm and test or debug this...
<lifeless> I'd like to see bzr switch safely and effectively to the 2.0 format before lp does, because bzr has a smaller codebase
<vila> poolie: I already stopped working on the buildfarm :)
<lifeless> the mails I've been sending about conversion experiments would be a good place to start
<lamalex> Is anyone using bzr-git successfully?
<spiv> lamalex: Launchpad is, at least...
<lamalex> hm, anyone around who knows anything about it?
<lamalex> i cant talk to my companies git repo with it, keep gettng bounced with sh: bzr: not found
<lamalex> bzr: ERROR: Connection closed: please check connectivity and permissions
<lifeless> lamalex: what url are you giving bzr?
<lamalex> bzr+ssh://user@git.mycompany.org/~/git/mycompany/system/product.git
<lamalex> i just got it by cloning that repo locally, and branching from there
<spiv> lamalex: if bzr isn't installed on the remote end, then bzr+ssh can't work.  But I think bzr-git makes git:// URLs work?
<lifeless> lamalex: thats a bzr url - you're telling bzr to use bzr on that url.
<lifeless> lamalex: you want git+ssh://....
<lamalex> ah, makes sense
<jml> pushing up a brisbane-core branch while running the puller over another almost destroyed my system...
<jml> that said, I hadn't tried that with a branch as big as those two before with any other format.
<asabil> I tried checking out an svn repository using bzr-svn (the bzr.dev branch) to a development6-rich-root repository
<asabil> it took some hours, but the resulting repository was about 11GB
<asabil> after running a bzr pack on the repository, it went down to 700M
<asabil> also, it seems like the branch wasn't in development6-rich-root format by default (bzr info was showing format: unknown)
<asabil> are these known issues ?
<asabil> the svn code is WebKit trunk
<lifeless> asabil: the branch or tree will be different - info -v will show you
<lifeless> the size is surprising, I thought bzr-svn did many transactions
<asabil> I already upgraded to the branch to development6-rich-root
<lifeless> might ask jelmer if its disabling pak or something 'clever'
<asabil> oh and the 11GB is contained in 2 .pack files
<asabil> each one is about 5.5GB
<asabil> having such large files made the process of branching extremely slow over time (as the pack files grew bigger)
<lifeless> I'm not sure that the size is what made it slow
<lifeless> anyhow, if you had more revisions bzr would have autopacked itself earlier
<lifeless> I agree its bad, perhaps file a bug for jelmer.
<jml> hmm.
<jml> bummer.
<jml> spiv: just got this error wish local testing: http://paste.ubuntu.com/191520/
<jml> spiv: I'm guessing it's a direct consequence of bazaar 1.15 hpss improvements.
<spiv> jml: possibly, what's the -Dhpss trace?
<spiv> jml: potentially it's a direct consequence of a stacking-logic issue being exposed by hpss...
<spiv> jml: (not that there's much practical difference for you)
<jml> spiv: http://paste.ubuntu.com/191522/
<lifeless> jml: could be the far end trying to open it
<jml> lifeless: could be, but the far end has that url protocol registered
<spiv> The response to the BzrDirFormat.initialize_ex call has the lp-NNN... URL as the final_stack_pwd.
<spiv> I'm not sure what the best way to fix that is, but I think the pressure to fix the bug that server-internal URLs are returned to the client is growing...
<jml> spiv: heh
<jml> spiv: well, this is of course a 1.15 rollout blocker for us.
<lifeless> jml: make sure there is a bug
<spiv> please file a bug and target it to 1.16 I guess
<lifeless> I wrote init_ex; tomorrow I can chat with you
<jml> will do.
<bialix> igc: around?
<bialix> nope
<bialix> igc: ?
<bialix> igc: about your qversion/qsysinfo patch
<igc> hi bialix
<bialix> can you provide screenshot or ascii-drawings of how it looks for you?
<igc> bialix: shall do
<bialix> I could try to recreate the form for this dialog
<bialix> so it will be usable with older PyQT
<igc> bialix: what's the minimum PyQT we support?
<bialix> I'm not sure how to deal with different PyQt versions whoes thouygh
<bialix> igc: I guess 4.3
<bialix> although in the README claims it should be 4.2
<igc> bialix: cool, I was hoping it was at least that
<bialix> we need to update this info
<bialix> at least I can test and guarantee it works pretty well for 4.3.1
<bialix> don't have 4.2.x installer and even don't have desire to go so far back
<bialix> btw Ian, I think bzr explorer should invoke q-dialogs with --ui-mode flag
<bialix> so user will see the result
<bialix> although in this case user should explicitly close dialogs when operation successfully finished
<igc> bialix - see bug 381161
<ubottu> Bug 381161 on http://launchpad.net/bugs/381161 is private
<igc> bialix: what exactluy is that flag?
<igc> exactly
<bialix> igc: this is private bug, I can't see it
<igc> I've seen it around but haven't looked into it
<bialix> igc: this flag was introduced for TortoiseBzr
<igc> bialix: bug 385161 sorry
<ubottu> Launchpad bug 385161 in qbzr "qversion command needed" [Undecided,New] https://launchpad.net/bugs/385161
<bialix> this flag force Close button for dialogs when operation finished successfully
<igc> bialix: UUIIC, it ought to translate (layout wise) ok to OS X
<bialix> without this flag q-dialogs close itself when operation finished
<igc> bialix: do all qcommands support it?
<bialix> we desperately needs mode dev docs for qbzr
<bialix> no, unfortunate;y
<bialix> no, unfortunately
<igc> bialix: yes please
<bialix> ask questions, and I'll try to write the docs
<igc> bialix: no problem, I can use it for the ones that do at least
<AfC> poolie: still up?
<bialix> igc: can you make additional screenshot from Qt-Designer>
<bialix> ?
<bialix> I've got the idea
<bialix> just want to see some more (internal) info
<bialix> igc: what do you think about adding i18n for explorer?
<bialix> I'd suggest to use qbzr approach. I think it's very close to ideal
<igc> bialix: I really want it to see that happen
<igc> bialix: I'm said to use LP for translations ...
<bialix> so, just cherrypick qbzr/lib/i18n.py would be good start
<igc> but I'm not sure what to do to seed the process to happen
<igc> ok - I'll take a look
<bialix> I manage current qbzr translations
<bialix> I'll try to provide you the patch to compile pot
<bialix> we have all this in qbzr
<bialix> and it pretty reusable, IMO
<bialix> also, what about adding 'explore' as alias to 'explorer' command?
<igc> bialix: sure. Also bug 385161 now has Windows preview snapshot
<ubottu> Launchpad bug 385161 in qbzr "qversion command needed" [Undecided,New] https://launchpad.net/bugs/385161
<igc> bialix: so if bzr 1.16rc ships late this week, what timeframe makes sense for a qbzr release?
<bialix> thx
<bialix> igc: I've released 0.10 recently
<bialix> usually we release each months or so. from this period there is enough bugfixes and improvements
<vila> and what improvements !
<bialix> so, I'm doubt we need 0.11 next week.
<bialix> only if there is something really Critical
<igc> bialix: sure
<bialix> you can bribe be of course ;-)
<bialix> s/be/me/
<igc> bialix: :-)
<bialix> as vila said: hate when typo breaks good joke
<vila> :-D
<bialix> bonjour monsieur
<vila> hi Alexander
<bialix> igc: re qversion: do you prefer GroupBox, or just bold headings and indented bodies?
<igc> bialix: group box. I'm thinking that the way OS X displays them will be nicer there and it doesn't matter a lot on other platforms
<bialix> vila: does my greetings breaks french etiquette? I've read recently 'monsieur' is intended when somebody talks to person he is not very familiar
<vila> bialix: That's right, 'Monsieur' is a bit formal
<bialix> excuse moi s'il vous plait
<vila> bialix: on the other hand, when speaking to friends or relatives, 'Monsieur' acquire an other meaning which is a bit aggressive :-)
<bialix> aggressive?
<vila> bialix: I'm perfectly aware that this is not your intent here :)
<bialix> I'll be more careful
<bialix> it's just sounds funny (a bit)
<vila> yeah, like, when you argue with a friend and tone begins to warm, you may end up saying things like: "I know what I'm talking about, *me*, Monsieur" :-)
<bialix> in the 18-19 centuries in Russian noble people used french instead of native Russian to talk each with other
<lifeless> IIRC in england they used french
<lifeless> as well
<bialix> interesting
<lifeless> again in the nobility for a relatively short time
<vila> Yeah, you mean the ones that are known in France as "Les Russes Blancs" (White Russians)
<vila> IIRC French was the international diplomatic  language at one point hence the *latin* expression lingua franca :-)
<bialix> vila: I'm not sure
<bialix> not sure about Russes Blanc
<vila> bialix: You think it has another meaning ? For me it refers to noble expatriated Russian, I thought it matched
<lifeless> vila: http://www.wikihow.com/Make-a-White-Russian
<vila> lifeless: :-) Same name, yes
<bialix> vila: no, I'm just never heard this nicks before
<vila> bialix: ho, it may well be french-only :)
<bialix> vila: I can think about people who ran away from Russia when there was Revolution (1917)
<vila> yup, these ones
<bialix> they called "white russains"
<bialix> well, that's it
<mwhudson> they were called white during the civil war too, right?
<bialix> yes
<bialix> bielogvardeitzy
<bialix> this is how they in Russian
<bialix> white guardians
<vila> na gavariu pasrusky
<bialix> correction: parusky
<bialix> :-D
<vila> rats ! That was a typo ! You mean the spelling is right ? That's the only russian sentence Valentine taught me :)
<vila> Talk about typo ruining jokes :)
<bialix> spelling is almost right
<bialix> just thinking about I don't heard you
<bialix> anyway I understand you
<bialix> je ne parle pas in Francais
<vila> I wrote it phonetically, with some google help it should be: na gavaru pa ruski, right ?
<vila> je ne parle pas Fran,cais
<bialix> well, 'na' -> 'ne' or 'neh'
<bialix> gavaru -> gavaryu
<bialix> pa -> po
<bialix> otherwise it's very close :-D
<vila> :-D Yeah, thanks google :)
<vila> It should be written in cyrillic anyway
<bialix> many people have to use latin keyboard
<bialix> and thus we have latinica form for russian
<bialix> so, people will understand this
<vila> bialix: more seriously, I got another occurrence of pyQT4 not installed: in a setup where qbzr is installed but not PyQT4, 'bzr merge' was failing (instead of just refusing to load the plugin)
<bialix> because qbzr override merge command with --qpreview flag
<bialix> file a bug!
<vila> k
<bialix> it's critical enough
<AfC> My understanding is that 1.15.1 has not been published. That correct?
<AfC> I'll file these bugs on that assumption.
<vila> BasicOSX: Do you plan to release 1.15.1 ?
<vila> AfC: come back, the answer is not known yet ! :-/
<vila> bialix: since you're there ! Can you subscribe me to the qbzr google group ? AFAICS invitations is the only way to come in :-/
<vila> bialix: if possible use my '+lp' email
<lifeless> bialix: if you want people to be able to apply, make it moderated not restricted
<bialix> lifeless: we have 3 admins in qbzr@google
<bialix> luks, garyvdm and me
<vila> lifeless: Did you have some specifics in mind when you said "I'm not sure we've finished fixing the bugs from the bzrtools upgrade experiment either"
<bialix> something has changed recently and it seems I'm not aware
<bialix> vila: about PyQt dependency
<bialix> vila: I'm not sure probing PyQt on every bzr ionvocation is right thing to do
<bialix> it takes some time to import this library
<vila> that's not what I suggested
<vila> ha err, wait
<bialix> so I'd rather fix the bug with merge, and not to change existing lazy load
<lifeless> bialix: oh I"m talking about people being able to 'join' rather than 'be invited', not about who the admins are
<bialix> lifeless: I'm sure qbzr group should not be SO restricted
<vila> bialix: oook, I didn't realize the intent there... so yes if you lazy load, we'll have to continue the whack-a-mole game :)
<bialix> whack-a-mole, gha!
<vila> bialix: I never subscribe to a google group so far, so I may have misunderstood the process
<bialix> vila: I've just subscribe my gmail account without any problems
<vila> from where ?
<bialix> http://groups.google.com/group/qbzr/subscribe?hl=en
<bialix> do you have google account?
<bialix> not necessary gmail
<vila> ghaa, what did I try  last time to miss that 8-/ Ohhh, I wasn't connected (I connect only when *required*)
<bialix> I can add you directly, but it's better to understand first what's going wrong
<vila> bialix: my brain
<bialix> no, I don't believe!
<vila> bialix: and my will to use a non-gmail address
<bialix> this is not problem
<bialix> I've subscribed from my usual ukr.net mail
<bialix> lifeless: we just using pre-moderation of emails from new members to deny the spam
<bialix> otherwise the group is open to everyone'
<lifeless> kk
<vila> bialix: if I subscribe from my gmail account, I can't change the email to be used :-/
<bialix> so don;t
<bialix> subscribe from you free.fr mail
<bialix> you need to create free google account for this mail. that's it
<vila> bialix: I prefer to use a single mail (with the +lp suffix) for the all the bzr related communications
<vila> otherwise yes, I would have created a dedicated qbzr address
<bialix> I'm not sure I understand +lp
<bialix> lifeless: who I should to poke to ensure russian translation will have a chance to be merged to 1.16?
<asabil> jelmer: ping ?
<vila> bialix: my email includes a '+lp' just before the '@' it's a suffix that is not part of the "real" mail but most smtp servers know about that and route the mails accordingly
<bialix> vila: so you can filter the mail easily?
<bialix> nice trick
<vila> bialix: exactly and track who use which suffix without to create new emails
<bialix> ok, I understand
<vila> bialix: it works well for mailing lists, less so for web-based subscriptions because so many web devs know better and forbid '+' in emails :-/.
<bialix> do you want me to try add you directly?
<vila> bialix: yes please
<bialix> Email subscription options  	
<bialix> 	No email - Web-only participation
<bialix> 	Send email for each message and update
<bialix> 	One summary email a day
<bialix> 	One email with all activity in it
<bialix> what do you prefer?
<vila> email for each message
<spiv> vila: that's why I use - rather than + :)
<spiv> bialix: to make sure it's in 1.16 the best thing to do it make sure the RM (jml) is aware of it, and you've already done that by replying to his 1.16 email
<spiv> bialix: I'm sure jml won't mind if you ping him regularly to make sure, though :)
<bialix> jml: :-)
<bialix> vila: check mail
<vila> spiv: huh ? And it works ? I thought smtp servers had to recognize it explicitely and every conf file I've seen for sendmail or postfix always use '+' and '+' only 8-)
<vila> spiv: Or do you administer your own domain ?
<spiv> bialix: the other thing you could do is file a bug and target it to the 1.16 milestone; perhaps jml will recommend that.
<spiv> vila: I do (well, my wife does)
<vila> spiv: lucky man ! His wife does....
 * vila already administer too many family stuff :)
<spiv> vila: I frankly don't know the first thing about postfix conf files, but happily I don't need to :)
<vila> spiv: postfix is a breeze, sendmail on the other hand... :-)
 * awilkins has learned something viz : the '+' thing
<vila> awilkins: it also seems that spam harvesters don't like such emails ;)
<awilkins> Or they just trim the suffix :-)
<bialix> lifeless: still around?
<vila> awilkins: surprisingly that seems too hard for them... I guess they have enough and don't need to dig more
 * awilkins resolves to use "plussies" from now on
<bialix> vila: do you receive welcome message?
<spiv> Yeah, that's the problem with having lots of me-* aliases... I often get the same spam to every single alias.
<lifeless> bialix: vaguely
<vila> awilkins: what I mean is that I *never* receive spam on a '+' address and I don't receive a lot on the main one either (far less than the spam trap I created to get a reference point for example).
<bialix> I have test script for bzr-search and it seems found the bug in bzrlib/btree_index.py as well
<spiv> The usual spam filtering measures cut out the vast majority of them of course, it's just annoying for the ones that get through...
<lifeless> bialix: is this you ? http://www.facebook.com/profile.php?id=1041185773
<bialix> no, this is another man. I'm Belchenko, it's Boychenko
<bialix> vila: it seems something wrong with google brilliant minds: http://groups.google.com/group/qbzr/search?q=author:v.ladeuil+lp@free.fr&hl=en
<vila> bialix: %40 ftw
<bialix> excuse moi?
<awilkins> Escape the + char or it's a query operator
<awilkins> ?
<vila> bialix: oops, I meant %2B oof course :) http://www.google.fr/search?q=v.ladeuil%2Blp%40free.fr
<bialix> I did not create the query by hands, as you understand
<vila> bialix: aaah :)
<bialix> so, I can try to subscribe you with %2b if you still did not receive welcome mail
<lifeless> bialix: are you passing str or unicode to btree ?
<lifeless> bialix: anyhow, hand the script to me and I'll play tomorrow
<vila> bialix: welcome message just arrived, thanks !
<lifeless> bialix: (facebook) - I thought it might be a transliteration thing.
<bialix> lifeless: attached to bug report
<bialix> but I can't reproduce it now
<bialix> no, it's reproducible
<vila> quantum bug for you, it's both reproducible and not reproducible :)
<bialix> :-P
<bialix> you need to pass both unicode and non-unicode strings in one list to trigger
<guilhembi> Latest bzr.dev and latest bzr-gtk (dev branch) don't play together, in "bzr gannotate":
<guilhembi> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'ProgressBarStack'
<guilhembi> and a traceback...
<vila> guilhembi: see bug #385191
<ubottu> Launchpad bug 385191 in bzr "removal of ProgressBarStack has broken bzr-gtk" [High,Confirmed] https://launchpad.net/bugs/385191
<vila> :-/
<guilhembi> vila: thanks
<bialix> lifeless: https://bugs.launchpad.net/bzr-search/+bug/383102 two bugs for you by money of one!
<ubottu> Launchpad bug 383102 in bzr-search "bzr search can't find non-ascii text" [Medium,Triaged]
 * awilkins particularly enjoys bugs that vanish when you aim a debugger at them
<vila> awilkins: that's schrodinger bugs :)
<lifeless> bialix: so u'foo' should be just 'foo'
<awilkins> I thought it was Heisenbugs
<lifeless> bialix: If we are going to be passing just str in
<awilkins> A Schroedinger bug would be a bug which is in an indeterminate state until you exmaine it
<bialix> well, we should do
<bialix> you can ignore UnicodeDecodeError if you wish
<vila> awilkins: you're both right and wrong: http://catb.org/jargon/html/S/schroedinbug.html
<awilkins> Right about the debugger though http://catb.org/jargon/html/H/heisenbug.html
<vila> awilkins: yup
<lifeless> bialix: I'm assuming the CLI commands are broken, but won't fix until we have the API directly working for you in qbzr
<bialix> lifeless: with my testing script I see that internal search engine unable to find russian text
<bialix> I've also provided the patch for CLI
<lifeless> yup, thanks
<lifeless> just playing with the test branch now
<bialix> I think you have to force check that query_list contains only plain strings
<bialix> in your API
<bialix> to avoid any unicode errors
<lifeless> assuming thats the final outcome for sure
<Mez>   Conflict: media.new is not a directory, but has files in it.  Created directory.
<Mez>   Conflict: media.new is not a directory, but has files in it.  Created directory.
<Mez> grr./..
<Mez> what does that mean?
<Mez> I'm pretty sure if it has files in it, it's a directory
<awilkins> Are you on ReiserFS?
<Mez> not that I know of
<Mez> nope, ext3
<awilkins> Maybe the other tree has a FILE called media.new
<awilkins> And youi have a directory
<awilkins> Or vice versa
<awilkins> But I'm just guessing
<lifeless> bialix: night
<bialix> night
<lifeless> bialix: I know its a index problem now
<bialix> ok
<jam> morning vila
<jam> hey bialix, lifeless
<jam> lifeless: what are you still doing up?
<vila> jam: hey !
<bialix> jam: !!!
<guilhembi> vila: there are probably other problems: bzrlib.util.bencode moved to bzrlib.bencode in the latest bzr.dev,
<guilhembi> so bzr-gtk code which does "from bzrlib.util import bencode" will fail, this impacts revisionview.py and commit.py.
<guilhembi> vila: should I make a bug report?
<vila> guilhembi: sure
<guilhembi> Meanwhile I'm fixing our MySQL-internal plugin which uses bzrlib.util.bencode and broke too.
<guilhembi> ok, filing
<igc> bialix: any thoughts on bug 384988?
<ubottu> Launchpad bug 384988 in bzr-explorer "File > Open does not follow shortcuts (soft links) on win32" [Undecided,New] https://launchpad.net/bugs/384988
<bialix> igc: I have no idea. I'd say PyQt/Qt should use native windows dialogs if possible, but I can't be 100% sure
<bialix> so it's more PyQT bug
<bialix> from PyQT help:
<bialix> The easiest way to create a QFileDialog is to use the static functions. On Windows, these static functions will call the native Windows file dialog, and on Mac OS X these static function will call the native Mac OS X file dialog.
<bialix> so, it seems like PyQt tries to call native dialog
<bialix> at least it claims so
<bialix> wait
<bialix> from the PyQt help:
<bialix>  QString dir = QFileDialog.getExistingDirectory(this, tr("Open Directory"),
<bialix>                                                  "/home",
<bialix>                                                  QFileDialog.ShowDirsOnly
<bialix>                                                  | QFileDialog.DontResolveSymlinks);
<bialix> look at the last argument
<sidnei> hey vila, jam
<jam> hi sidnei
<bialix> igc: by default PyQt uses native dialog and symlinks should be resolved
<sidnei> jam: i am planning to setup kerguelen as a buildbot slave, would that be ok?
<jam> sidnei: seems fine to me, though getting Martin's ec2 instance might be better
<jam> at a minimum, kerguelen has DNS issues
<jam> (it doesn't resolve anything that I haven't put into 'hosts')
<sidnei> jam: we punted on ec2, waiting for elmo to setup something in the dc
<sidnei> (yes, i noticed the hosts thing :)
<sidnei> jam: i thought the stuff in hosts was some attempt at preventing unwanted outbound connections, didn't know it was a real issue.
<jam> sidnei: The hosts say "we have to completely rebuild the machine" to fix it
<jam> so we said "screw it, will manage hosts"
<jam> rather than re-install everything
<igc> thanks bialix!
<jam> sidnei: the other problem is that we are only allowed 2 "logins" to kerguelen
<jam> I assume that a build bot needs to be running as a user
<jam> so we would be down to 1 login
<jam> which is probably enough, at least until someone forgets to log out
<bialix> igc: I've re-read help one more time, and I'm sure it should works as any native application
<sidnei> jam: it does, but it doesn't consume a login. it runs as a service user.
<jam> k
<jam> given that it is the machine where we currently build bzr, it certainly seems fine to make it a buildbot slave :)
<sidnei> perfecto. now in search for a master. :)
<sidnei> i think i will wait for the lp buildbot master to be moved in the dc too, hopefully that will make it easier. this is happening soon.
<sidnei> jam: fyi, i have a buildout-based setup which can do a 'from scratch' build, downloading all of the svn, db4, libintl, tortoiseoverlays and unpacking them in the right location. just waiting on a bugfix to be merged to one of the recipes to put this through review.
<jam> sidnei: interesting, especially given I have that in 'build_release.py' :)
<jam> I didn't think we used db4
<jam> do you mean bdb ?
<sidnei> jam: yes, bdb. and yes, i saw build_release.py, and i think you will enjoy the new thing. it's less... convoluted. :)
<jam> sidnei: perhaps. Some of the "convolution" is because of real-world issues I ran into.
<jam> But hey, if you can get win32 to autobuild for me
<jam> I certainly have no qualms with it :)
<sidnei> jam: i've kept most if not all of the things from build-release, like getting trunk then branching from the tag, doing a build in the separate 'release' dir that gets blown away, etc.
<vila> sidnei: I setup a buildbot master yesterday here, but 1) that's my first buildbot install ever, 2) It is accesible from my LAN only :-/
<sidnei> vila: eh, thanks anyway ;)
<vila> sidnei: I'm interested in your slave setup anyway :-) Especially if you handled installing twisted/buildbot on win32 (I used easy_install on OSX though)
<sidnei> vila: there's some documentation over here: http://lists2.idyll.org/pipermail/pybots/2006-September/000098.html
<visik7> under windows
<visik7> .bazaar/plugins where is ?
<vila> sidnei: why oh why such setups always end up being nightmarish :-)
<sidnei> vila: it's not that hard actually, that was my first try. it is much simpler now. also, i was trying to build lxml which had many dependencies
<vila> sidnei: yeah, kidding, only the second item in the list is relevant, in fact I think once the dev env is up, buildbot install shouldn't be a problem
<sidnei> vila: correct.
<bialix> visik7: see output of `bzr version`, line started with 'Bazaar conbfiguration'. This is the path to .bazaar on Windows
<bialix> also you can use BZR_PLUGIN_PATH to override the default path
<bialix> and there is C:\Program Files\Bazaar\plugins is you have installed bzr.exe in default location
<vila> guilhembi: by the way, since bzr-gtk is currently broken, update qbzr and try qlog again, you should see that improvement in performance :)
<vila> s/that/some/
<guilhembi> vila: on a MySQL 6.0 branch, qlog took 12 secs to display the graph, now takes 10. It took 3 secs to expand a merge revision in the graph, now  takes 1. Good!
<vila> guilhembi: and it consumes far less space too when you begin to open merge nodes
<guilhembi> vila: what space? screen space?
<vila> guilhembi: yes, it uses far less "columns" to display the graph
<guilhembi> bbl
<vila> huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ?
<awilkins> vila: Does it update the WT including the uncommitted changes that were already there? Or the changes from the source branch?
 * awilkins tests
<Kissaki> I checked out, and now I want to commit, for which I should require a username and password. On commit it does ask me for password, twice, but fails... (not for username
<Kissaki> where/how can I specify login name?
<awilkins> Kissaki: In authentication.conf
<Kissaki> (using bzr with svn server)
<awilkins> Kissaki: Ah
<Kissaki> I managed to do it before, but don't remember how I did it...
<awilkins> Kissaki: Might also help to do something requiring auth with the SVN client (like taking a lock and then releasing it)
<awilkins> svn lock --username <url>
<awilkins> svn lock --username <username> <url>
<awilkins> Duh
<awilkins> I'll forget my own head next
<Kissaki> I don't have svn here
<Kissaki> jut bzr :)
<Kissaki> hm, it seems it could also be a problem with authserver...
<awilkins> Kissaki: The other thing is that Bazaar doesn't cope with refusal well. Try prefixing your urls with svn+
<awilkins> (Is it svn over http)?
<Kissaki> yes
<awilkins> Try the svn+ prefix
<awilkins> Kissaki: Bazaar is probably asking for .bzr/smart URLS which the SVN WebDAV server will probably refuse to be nice about
<awilkins> Anyway, time to go home
<Kissaki> didn't use svn+ on the other one though
<BasicOSX> morning (from the US) at least
<BasicOSX> Any bzr-core people online? Any one going to address http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/58794 or just take it as someone venting?
<bialix> jam: ping
<bialix> not here
<james_w> hey Bob
<james_w> do you know why the files were missed from 1.15?
<BasicOSX> james_w:  no, I cannot duplicate it either. Same pbuilder, same machine, same build procedure
<james_w> odd
<BasicOSX> james_w:  I will admit I stopped checking for them, since it was my understanding (wrongfully so) that a build would fail of the pyrex-ified files weren't created and that the .c files where going to be revisioned
<vila> BasicOSX: hi Bob, did you planned to release a 1.15.1 ?
<BasicOSX> RM is in an odd position. I can make releases every day, but there needs to be coordination between RM and dev, so I was going to push 1.15.1, but it was pointed out that bug 380314 should be rolled into 1.15.1, then I got busy at work.
<ubottu> Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,Confirmed] https://launchpad.net/bugs/380314
<vila> BasicOSX: yup, RM is an odd position :-)
<BasicOSX> vila:  I hate being ask if I plan to do a release, much rather the position be bzr-core telling RM do a release
<BasicOSX> as I said above, I can do releases everyday, but that's wasted work without bzr-core stating there's something new to release
<BasicOSX> RM is ultimately grunt work, happy to do it, but when to do it is more of a bzr-core thing (imho)
<james_w> I'm not so sure
<vila> BasicOSX: That's just that *I* didn't closely follow what planned, I thought some bugfixes was targeted as 1.15.1 and then I understood at least one of them couldn't make it, and... then I thought I should check with you :)
<james_w> in my experience an RM that pushes for releases with certain things is important for good quality
<vila> BasicOSX: Also, being RM also implies you're the one to say *NO* to devs, who will always want to delay just to get that one last fix in
<james_w> otherwise the developers will just tend to focus on the shiny
<vila> BasicOSX: I had trouble with my mail client last week and lost track of some mails, but I thought spiv prepared a branch for meging in 1.15, cn't find the mail back though :-(
<BasicOSX> hmm, in my professional career, that focus on release date is project manager (PM) roll. RM is rolling up the code for release.
<BasicOSX> but point taken
<BasicOSX> AS a developer in real life, I hate PM :-) because they are always taking away my shiny new play things :-P
<vila> BasicOSX: yeah I know, things are a bit different here, PM is more the tie-breaker when devs can't agree, in professional carrer, PM is also responsible for the planning and distributing work, that can't work with a community
<vila> so we end up in making the RM the human  gatekeeper for what goes into a release and the one that should respect the planning of time-based releases
<Peng_> jelmer or beuno: ping
<BasicOSX> There's a slice of volunteer time vs real world time in the RM roll too.  Andrew's comments on ML make it seem like RM is that is not volunteer. But I'm taking the comments personally as I'm RM right now.
<vila> Of course that's an ideal definition and then we can still fight and drag the RM into discussions about how important this feature or that bugfix is sooo important that *he* should delay the release
<vila> BasicOSX: Don't take it for you. Andrew is firing at the project not at the RM
<vila> I think his main point is that we are making other packagers life harder. We still have work to do in that area to streamline the process.
<BasicOSX> I know, been in the  FOSS world long enough to understand the personalities, still irritating to read a vent like that but not offering any constructive solution. Easy to vent. Hard to propose a solution.
<vila> BasicOSX: And you helped a lot in that area by documenting all glitches you found, so focus on that: you did a great job, it's not finished nor perfect, so what ? :-)
<beuno> Peng_, hi!
<bialix> vila: re PyQt and merge bug. It's not clear how to separate PyQt from basic code. I have a fix for your problem, but we still will play whack-a-mole game with you. At least I'm trying to fix the bugs you found as fast as I can.
<Peng_> beuno: Ah, hi. Um. The patch to __init__.py to only add loggerhead to sys.path if necessary broke "bzr serve --http" for me. Oddly, it successfully imports loggerhead.apps.transport, but that can't import loggerhead.apps.branch.
<Peng_> beuno: (Well, I assume that's the patch that broke it.)
<vila> bialix: I understand that, no problem, I'll keep thinking about it but unless we find a better implementation, let's continue that way, who knows, that may have been the last mole :)
<beuno> Peng_, ah
<Peng_> I guess I should file a bug. I dunno, it confused me enough that I wanted to discuss it.
<beuno> Peng_, I don't quite know why
<beuno> jelmer may know
<beuno> I'd file a bug and assign it him
<beuno> and run  :)
<bialix> vila: this mole was born as result of massive refactoring made by Gary. So it's the last mole until we did next big refactoring ;-)
<Peng_> beuno: I'll run and hide behind you. :P
<vila> bialix: I hopefully inoculate him the test virus, so next refactoring may go better :-)
<Peng_> beuno: Maybe I'll just CC him instead.
<bialix> i.e. I don't expect it *the last one ever*
<bialix> heh
 * beuno runs off to lunch
<vila> bialix: I know my setups are quite unusual anyway, qbzr but no PyQt and I appreciate your efforts to support it :)
<bialix> well, usually your setup helps find easy bugs
<bialix> so I'm fixing them for fun
<vila> bialix: I'm slowing getting away from such plugin sharing between setups but I wish bzr-core has better support for activating/desactivating one plugin at a time
<vila> bialix: hehe, always happy to help people have fun :)
<bialix> between setups?
<bialix> wdym?
<bialix> do you know about BZR_PLUGIN_PATH env variable?
<vila> depending on the machine I work on some ~/.bazaar directories are mounted via NFS so the plugins are installed once for say Ubuntu and OSX, and no PYQT on OSX for me so far :)
<vila> Yeah I know about BZR_PLUGIN_PATH :)
<vila> But most of the time I run into problems when trying to run the whole test suite *without* using --no-plugins (since that also desactivate the lp plugin for example)
<vila> so I cd ~/.bazaar/plugins ; mv bogus DISABLED
<vila> and I do mv DISABLED/bogus . when I need the plugin again :-/
<bialix> but why you keep qbzr plugin without PyQt4 anyway?
<vila> because I use it from the Ubuntu side where PyQT4 *is* installed
<bialix> so, why not put qbzr in the ~/.bazaar/plugins/ubuntu-only and add this location to BZR_PLUGIN_PATH?
<vila> bialix: Because I'm lazy ? :-) I'm going away from such sharing anyway
<BasicOSX> boo on me for -not- listening to my latop when it said it was a reserve power!
<vila> BasicOSX: :-D
<vila> bialix: lib/subprocess.py use DOS line endings ?
<bialix> vila: I'm not surprised about this
<bialix> Gary used Windows a lot in the past
<vila> bialix: ok, just wanted to make sure it wasn't some filtering leakage
<bialix> don't blame me
<vila> I don't blame anybody, my editor handle that fine :-)
<bialix> you can try to find CRLF in some log*.py modules, I guess
<bialix> vila: https://code.launchpad.net/~qbzr-dev/qbzr/bug-385177
<vila> bialix: it works ! Thanks
<bialix> np
<BasicOSX> vila:  Ping? unusual problem, got time to look at it? http://pastebin.com/m788e3e2
<BasicOSX> bzr push says "No new revisions" bzr submit to PQM says public branch is out of date
<vila> BasicOSX: just wait a bit, it a mirroring delay, shouldn't exceed 10 minutes though
<BasicOSX> hmm, never seen that when push to lp:
<BasicOSX> I'll note it in doc
<vila> BasicOSX: I almost *always* see it when issuing pqm-submit just after the commit
<BasicOSX> I've seen it when http but not lp
<vila> the mirroring occurs generally in less than 2/3 minutes
<BasicOSX> push happened 12:26pm CDT, it's now 12:34pm, still getting error.
<johnskulski> Hey, trying to get into bzr by checking out a svn project we have at work. I did a $ bzr branch file://var/svn/project and made my changes, i committed them but they do not show up in the svn repository (thought the commit is in the bzr log)
<beuno> johnskulski, since you used "branch" instead of "checkout", you probably need to push your changes with "bzr push /var/svn/project"
<vila> BasicOSX: you nearly got me there ! 1.15.1 not 1.15 check your public_branch setting :-)
<johnskulski> beuno, yeah just pushed it. is 'checkout' provided by bzr-svn
<beuno> johnskulski, nope, bzr
<beuno> a checkout is bound to it's parent branch
<beuno> and a branch is independant
 * BasicOSX groans
<beuno> johnskulski, so you can commit to a branch and push whenever you like
<vila> BasicOSX: sorry about the misleading comment about mirroring delay :-/
<johnskulski> beuno, i see. is this the command they talk about when saying bzr can support a centeralized workflow as well?
<beuno> johnskulski, exactly
<BasicOSX> totally my fault vila, cut-n-paste error
<BasicOSX> I think I should change the release doc to force RM To put info into command line view locations.conf
<johnskulski> beuno, and one more. the workflow for branched is 'commit' are 'saves for user' and then you push to some other branch, where as with centeralized checkouts, you commit --local to 'save for user' and then commit (no local) to commit for realz
<beuno> johnskulski, you nailed it
<johnskulski> great! thanks for the clarification beuno
<beuno> johnskulski, happy to help. Let us knwo if you have any more questions
<johnskulski> sure I willl, we're going ot be doing an svn to bzr migration at work later this year :-X
<beuno> johnskulski, yay
<beuno> johnskulski, be sure to add yourself to: http://bazaar-vcs.org/WhoUsesBzr
<beuno> (if you're allowed to)
<johnskulski> beuno, noted, thanks!
<BasicOSX> Something wrong with PQM? Submitted, it played, no email response, pass or fail.
<vila> BasicOSX: try replacing your lp: url by the http:  equivalent
<vila> I heard spiv had some troubles with lp urls too recently
<BasicOSX> :-(
<bialix> vila: ping
<stianse__> using the module filecmp from within a plugin works ok on linux but not on windows.
<stianse__>  does python for windows come with its own python installation without the filecmp module?
<bialix> are you using bzr.exe?
<stianse__> yes
<bialix> then it's possible this module is missed
<bialix> which one plugin used this module?
<sidnei> bialix is correct, since we use py2exe not all of the standard library is included
<stianse__> bialix: a plugin i'm writing right now :)
<bialix> so you have 2 choices:
<stianse__> soon finished, just wanted to check if it worked on windows. it didn't.
<bialix> 1) provide a copy of this module with your plugin (like qbzr does)
<bialix> 2) copy this module to C:/Program Files/Bazaar/lib/library.zip
<stianse__> bialix: I guess 1) is better since others probably will run into the same problem
<bialix> you have 3rd option: file a bug and force bzr devs to include this module into bzr.exe for you
<sidnei> i guess we could force py2exe into including more things into stdlib. not all things make sense though, like BaseHttpServer. or maybe it does *wink*
<bialix> the patch is simple: lok at setup.py
<sidnei> s/into/from
<stianse__> bialix, sidnei: thanks, i think I will do both 1) and 3)
<bialix> sidnei: yes, one can force py2exe to include more stuff than auto-detecting
<sidnei> bialix: i know, just trying to think about how to draw the line
<bialix> draw the line?
<sidnei> one could argue that every module from stdlib should be included, if we are supporting plugins
<sidnei> though some clearly do not make sense, at least right now
<bialix> well, I'd prefer to improve this area on case-by-case approach
<sidnei> sure, that works too :)
<kenichi> hello, has anyone seen a problem where a commit to a branch (with >1k revisions in it) somehow sets the revno to 0?
<bialix> at least for "default plugins" that shipped with td installer we force additional libs based on ModuleFinder
<bialix> kenichi: no
<LarstiQ> kenichi: yes, possibly
<bialix> does log still works?
<kenichi> a bzr log -l 10 shows logs for revnos 2, 1, 0, -1, -2 ... , -8.  googling "negative revno" returns nothing...
<bialix> bzr reconcile
<LarstiQ> kenichi: did you perform a merge prior to the commit?
<bialix> may be it helps
<kenichi> i'm still tracking down what exactly happened.  the committer is in hanoi, so ...
<LarstiQ> kenichi: it sounds like : bzr init; bzr merge previous-work; bzr commit
<LarstiQ> kenichi: so one question you could ask is how they started a local copy
<LarstiQ> kenichi: if the answer is `bzr init` instead of `bzr branch` (or checkout/get/etc), you're on to something
<kenichi> LarstiQ: yeah, that's the one way we came up with for this to happen.  but... i would think that the older 1000+ revs would be "sub-revisions" of the merge-in commit in that case, no?
<LarstiQ> kenichi: indeed. I haven't seen this specific effect of negative revnos for a whole lot of releases.
<LarstiQ> kenichi: which bzr versions are in play here?
<kenichi> LarstiQ: the server on which this happened runs 1.10 (/me is not happy with that but is gated..), i'm waiting to hear version of the client.
 * kenichi guesses ~1.13
<LarstiQ> kenichi: hmm, I thought it didn't occur anymore at that time
<LarstiQ> kenichi: is the project public? If so, could you make a tarball of it for analysis?
<kenichi> LarstiQ: sorry, it is not.  Though if, in my investigations, i can replicate the results with a "test" repo, i glady would.
<LarstiQ> kenichi: that's good too :)
<LarstiQ> kenichi: anyway, to get out of it
<LarstiQ> kenichi: given a messed up branch, I'd `bzr pull --overwrite -r revid:lastgoodbranchtip`
<LarstiQ> well, depends on how much work was done on top of that
<bialix_> LarstiQ: IIRC there was attempt to teach bzr reconcile fix incorrect revno
<bialix_> kenichi: can you make a copy of your broken branch and run reconcile there?
<LarstiQ> bialix_: ah
<kenichi> LarstiQ: thanks, that is similar to what we did: pulled each rev-id to another local work branch, then push --overwrite to the mainline.
<LarstiQ> kenichi: I forgot a . in that
<LarstiQ> kenichi: right
<LarstiQ> kenichi: `bzr pull . --overwrite -r revid:lastgoodbranchtip`
<kenichi> bialix_: i have a tarball of the whole repos.  i'll give it a go.
<kenichi> (in it's fubared state)
<kenichi> s/it's/its/
<LarstiQ> kenichi: good
 * LarstiQ looks up which tram to take home
<kenichi> "Fixing last revision info 2 => 1127" looks promising :)
<bialix_> :-)\
 * LarstiQ detaches and goes home
<LarstiQ> kenichi: cool :)
<kenichi> bialix_: it is taking quite a while, "Calculating text parents 26850/39745"...  sound normal?  a co-worker is running 'bzr check -v' on his own copy of the fubared repos; said it's been going for hours.
<bialix_> perhaps
<bialix_> bzr check is known to be very slooooooooooooooooooooooow
<kenichi> LarstiQ: can you elaborate on when you *did see* the negative revno effect before?
<bialix_> kenichi: he's going home
 * bialix_ summons vila
<mwhudson> jelmer: hi
<sevenseeker> I have a remote machine I would like to push a branch to, can I do that (it is running 'bzr serve')
<Gnx-> so anybody have any thoughts on how I could force a file to be always overwritten when pushing/pulling?
<Peng_> sevenseeker: You should use bzr+ssh. If the server has bzr installed, and you have SSH access, it should work automagically.
<Peng_> sevenseeker: It's possible to enable pushing to bzr://, but it doesn't support auth, so anyone could do whatever they wanted.
<sevenseeker> Peng_: We use keys for entry via ssh (ssh -i foo) how can I utilize this with bzr+ssh?
<Peng_> sevenseeker: It'll work automagically.
<Peng_> sevenseeker: Unless you actually have to pass arguments to ssh, but that's dumb.
 * Peng_ /away!
<sevenseeker> Peng: thanks, are you saying that I can pass '-i' to bzr I am not sure I understand what 'automagically' means in this context.  e.g. ssh -i pubkey foo@foo.com --> bzr push -i pubkey bzr+ssh://foo@foo.com/spambranch
<beuno> sevenseeker, it should search for your pubkey automatically
<sevenseeker> beuno: thanks, search by name or just try until it succeeds?
<sevenseeker> sorry for silly questions
<beuno> sevenseeker, I suppose it does whatever ssh does
<beuno> don't know the details to be honest
<beuno> vila may, but he's probably not around
<sevenseeker> ok, I only grok enough to be dangerous about ssh :)
<beuno> same here  :)
<BasicOSX> Got reverse-bitten by sync bug now too. lp:/bzr/bzr.1.15 doesn't have my changes
<jml> james_w: new nightlies! wooooo!
<james_w> at last! :-)
<BasicOSX> Someone do me fav and QA the bzr-1.15.1 tar and zip at ftp://ftp.real-timecom/pub/bzr ? Just want second set of eyes looking at them for pyrex-ifed files before going public. Thanks.
<jml> mwhudson, lifeless: I'll be back a bit later, then we can talk about the hpss stacking issue maybe?
<mwhudson> jml: sure
<jml> BasicOSX: ... and if no one else has done so, I can QA those when I get back too.
<mwhudson> lifeless: can you tell me what "cache oblivious" means in a short sentence?
<mwhudson> oh nm, wikipedia has an article
<poolie> hello all
<poolie> hi beuno
<lifeless> mwhudson: maximising cache performance in algorithm design without cache size parameters
<mwhudson> right
#bzr 2009-06-10
<lifeless> I hope so :P
<jml> hello
<jml> I'm going to actually try to reproduce the problem with the steps I outlined.
<jml> and then probably re-assign the bug to launchpad-code, and then trace what init_ex does on the server side.
<lifeless> so
<lifeless> init_ex is designed to do as much initialisation as the current logic then in bzr.dev permitted to be made unconditional or conditional on constant parameters
<lifeless> and returns many results
<mwhudson> jml: cool
<lifeless> one way to do this would be to write an acceptance test for pushing to default stacked
<jml> lifeless: that's definitely something we plan to do.
<mwhudson> i thought we had such a thing
<jml> mwhudson: I don't think we do.
<mwhudson> oh right
<mwhudson> we have puller tests to do with stacking
<lifeless> I think if you did, it would have broken
<mwhudson> "oops"
<lifeless> or is itself broken
<mwhudson> lifeless: right, i was going on the "we have a broken test" theory
<mwhudson> i was wrong
<vxnick> hi guys - I'm trying to push an update to launchpad but bzr is saying I need to merge then push (which I do) but to no avail
<spiv> vxnick: did you commit the merge?
<vxnick> yep
<vxnick> I uncommitted the previous revision however
<vxnick> because I put some bits in the wrong place so wanted to have them show under that revision
<vxnick> rahter than a new one
<spiv> vxnick: hmm.  Are you sure you've merged from the branch you are trying to push to?
<vxnick> 100% sure
<lifeless> vxnick: then you have to push --overwrite, because uncommit doesn't propogate automatically
<vxnick> ah thanks
<lifeless> vxnick: because its a form of history editing
<vxnick> so I guess uncommit isn't ideal for push/pull scenarios?
<lifeless> note that if you're pushing to a branch other people can push to, you may end up removing their changes by doing this
<lifeless> vxnick: rule of thumb - never uncommit after you have pushed
<vxnick> noted, it's just me at the moment
<vxnick> thanks
<lifeless> vxnick: you can if you need to, but understand the mechanics ;)
<vxnick> yeah, I'll double-check next time :)
<vxnick> push --overwrite did the trick, many thanks guys
<vxnick> another one to add to my repertoire ;)
<pygi> mwhudson: thanks for the response
<pygi> I pretty much think that locations.conf should be ok, yes
<mwhudson> pygi: cool
<poolie> lifeless: wrt rich-root and similar changes, will people be able to bzr branch their existing launchpad un-landed branches into an upgraded repo?
<poolie> or will they need to upgrade all of them individually?
<jml> james_w: I notice the bzr-nightly-ppa for hardy doesn't have 1.16dev
<lifeless> poolie: I think it is important that they check and reconcile all their revisions
<jml> lifeless: wait, pebkac
<jml> double pebkac!
<lifeless> its possible for revisions in different branches to interact badly with some combinations of ghsots
<lifeless> I'd *like* to be able to say 'run check -r submit:' and if that is clean branch it into your shared repo
<lifeless> but current check can't do that because it checks everything
<lifeless> poolie: certainly they can run the commands to branch it into an upgraded repo, but that says nothing about data integrity
<lifeless> poolie: did you want me to pop over [say around lunch till 5ish] ?
<poolie> lifeless: ok, i have to go out to a movie at about 5 though
<lifeless> I have this meeting in the city @6 so that suites me fine
<lifeless> I'll tell him to bring it forward a bit
<poolie> lifeless: you asked yesterday if i'd read some advisory
<poolie> which one was that?
<lifeless> the one I drafted about the smart server problems. I wasn't asking if you'd read it, but if you had any more edits to make before we sent it to bzr-announce
<jml> Errors were encountered while processing:
<jml>  /var/cache/apt/archives/bzr_1.15+4422+116~08.04_i386.deb
<jml> E: Sub-process /usr/bin/dpkg returned an error code (1)
<jml> :(
<lifeless> \o/
<poolie> lifeless: no more changes, please send it
<poolie> jml, did you get an actual error?
<poolie> lifeless: could you send a draft advice on how launchpad devs should upgrade?
<poolie> spiv, pushing a new branch to launchpad was HPSS calls: 61 (23 vfs) SmartSSHClientMedium(connected=False, username=u'mbp', host='bazaar.launchpad.net', port=None)
<poolie> seems surprisingly bad
<jml> poolie: no.
<jml> that's it.
<lifeless> poolie: [lp devs] I've been working towards that prior to allhands
<lifeless> poolie: my opinion is that its not ready for lp devs. Its still way to fragile a process and I think all we'd learn is the fragility.
<lifeless> poolie: I will refresh the doc though
<lifeless> poolie: and we can discuss further after that
<mwhudson> poolie: launchpad is still 1.14
<lifeless> poolie: with 1.15 and no tags it should be 0 vfs
<lifeless> poolie: wth 1.14 and tags, 9 vfs calls.
<lifeless> sorry, with 1.15 and tags, 9 vfs calls
<poolie> k
<lifeless> but as mwhudson says, its still 1.14 on the server
<lifeless> jml is looking into a critical upgrade bug for going to 1.15
<spiv> poolie: what lifeless said
<spiv> I think it might be good if the -Dhpss output mentioned if any UnknownSmartMethod were seen, to make the new client/older server case less alarming.
<poolie> spiv, good point
<SamB> I think you guys should make the bzr-announce list more prominent
<vxnick> I think I know the answer to this, but is there anyway I can branch (or checkout) a single file from a repo? The repo itself only contains this one file
<lifeless> bzr cat
<lifeless> to get the contents
<lifeless> or bzr branch to branch the branch
<SamB> I barely managed to find the URL to sign up when I was *looking* for it just now
<SamB> and that was only because I heard you talking about sending something to it!
<poolie> jml: installing that package worked for me
<jml> poolie: on hardy?
<poolie> on jaunty
<jml> ok.
<jml> I'll install from source then.
<jml> ok, now I'm perplexed.
<jml> http://paste.ubuntu.com/192055/
<jml> ahhh. plugins.
<poolie> the traceback should say
<poolie> it's kind of a bug that the message didn't
<jml> yeah.
<jml> Anyway, I've now successfully reproduced bug 385132 without involving Launchpad.
<ubottu> Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132
<jml> lifeless: you said there were tests for this in bzrlib -- where might I find them?
<lifeless> for the specific behaviour of honouring default policy
<lifeless> bzrlib.tests.blackbox.test_push.*acceptance has one
<lifeless> jml: ok, thanks for showing it w/out lp
<poolie> lifeless: quick call?
<jml> np.
<lifeless> poolie: sure
<jml> grrr. bzrtools out of date :(
<jml> lifeless: I've just added a patch & linked a branch that add tests that reproduce the bug.
<jml> Launchpad bug mail is being slow today. :(
<lifeless> bug 385132?
<ubottu> Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132
<jml> yeah.
<jml> lifeless: are you planning on fixing bug 385132 today?
<ubottu> Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132
<lifeless> jml: maybe
<lifeless> jml: its clearly very important
<lifeless> jml: however I have nothing on my plate that isn't.
<jml> lifeless: should I ask someone else? (spiv? myself?)
<spiv> jml: I'd be happy to look at that after I'm done with bug 380314
<ubottu> Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,Confirmed] https://launchpad.net/bugs/380314
<jml> spiv: cool, thanks.
<spiv> jml: which realistically means "tomorrow"
<jml> spiv: :(
<spiv> (I might be wrong, but I'd rather surprise than disappoint)
<lifeless> jml: I suggest digging into it yourself
<jml> yeah, that sounds like a winner. I'll do some RM work first though.
<mwhudson> do we have any idea which change introduced the regression?
<lifeless> ping or ring at anypoint if you need assistance understandin the intent vs actuality
<lifeless> mwhudson: bugger, I was slack in the docstring, didn't mention the version
<mwhudson> lifeless: ?
<lifeless> I think its just the new verb not being completely correct rather than a regression
<lifeless> type object 'EventsCodes' has no attribute 'IN_MOVED_TO'
<lifeless> funky
<mwhudson> ah
<mwhudson> i guess that's good
<lifeless> landed in 4304
<lifeless> -> poolies
<poolie> lifeless: i don't find your rfc about log very compelling either way
<poolie> lifeless: want a lift? i wouldn't mind leaving the house...
<igc> hi all
<jml> igc: hello
 * jml dons the trousers of release management
<jml> igc: how's bug 362030 looking?
<ubottu> Launchpad bug 362030 in bzr "files whose content changed after EOL filtering erroneously marked as modified" [High,In progress] https://launchpad.net/bugs/362030
<poolie> jml nethack mode on :)
<igc> jml: I'm completing the tests now
 * poolie heads to the couch
<poolie> hello igc
<igc> hi poolie
<igc> poolie: late start today sorry - needed some sleep
<jml> igc: cool. :)
<jml> poolie: you still planning on doing bug 385191 for 1.16?
<ubottu> Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed] https://launchpad.net/bugs/385191
<fullermd> igc: With that fix done, is all the filtering stuff "expected" to DTRT?
<poolie> igc, no problem
<poolie> jml, iirc vila said that it's purely a bzr-gtk bug because it's been deprecated for a while
<poolie> so i wasn't going to do anything else on it
<jml> poolie: ok, I'll mark it as Invalid then?
<poolie> oh i thought he did
<jml> sounds like a "yes" to me :)
<igc> fullermd: branch-specific rules are still outstanding. Otherwise, yes.
<jml> bzr's policy is still to say "fix released" when a fix lands on trunk, right?
<poolie> yes
<fullermd> igc: 'k.  Last time I fiddled with it, I ran into so many oh-but's that I just gave up, but it seemed like most of them were at least known and at best in-progress.
<fullermd> igc: So, cool.  I'll try fiddling with it again as soon as I get out from under the deluge currently innundating me.  Expect an email from me in, I dunno, 50 years or so  ;)
<igc> fullermd: thanks. I wouldn't bother too much before 1.16
<fullermd> Well, I'd never bother with a release.  That's what bzr.dev is for  ;p
<lifeless> jml: is it the value for final_stack or final_stack_pwd that are wrong?
<jml> lifeless: wrt bug 385132? Whatever the second-last value in the returned tuple is, that's the one that's wrong.
<ubottu> Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132
<lifeless> thats final_stack_pwd
<lifeless> it should be a relpath, I think, for our cases
<lifeless> there are unit tests for this api
<lifeless> in bzrlib.tests.bzrdir_implementations (or perhaps per_bzrdir).test_bzrdir
<jml> lifeless: thanks, that helps.
<jml> I'm looking at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch06a8r%24v7c%241%40ger.gmane.org%3E
<jml> and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch06a8r%24v7c%241%40ger.gmane.org%3E
<jml> they look like the same patch to me -- should I merge the first one into bzr.dev?
<BasicOSX> Could someone QA the 1.15.1 tar and zip at ftp://ftp.real-time.com/pub/bzr/? I am gun-shy and want 2nd set of eyes making sure the pyrex-ified files are in there.
<jml> poolie: sorry, I think there's been some bug collision on bug 385191.
<ubottu> Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed] https://launchpad.net/bugs/385191
<jml> BasicOSX: sure, I'll get to that now
<poolie> jml, ok, but it looks like violent agreement? :)
<jml> poolie: ok, so you just accidentally assigned it to yourself & the 1.16 milestone?
<jml> poolie: if so, great. :)
<jml> BasicOSX: in the tarball, there's no C file corresponding to ./bzrlib/_walkdirs_win32.pyx
<poolie> jml, i don't know how that happened
<poolie> i did not click it
<poolie> is launchpad bug i think
<BasicOSX> I followed the release procedure to the letter -and- a make does it's all built
<jml> BasicOSX: same in the zip.
<BasicOSX> but I do see ./bzrlib/_walkdirs_win32.pyx
<fullermd> That file isn't pyrexified for me either on the standard make.
<BasicOSX> bug in make disst?
<jml> BasicOSX: I'm bumping hard against the walls of my ignorance here.
<fullermd> Never been built on any previous releases that I can see either.
<fullermd> (so it's not a regression, but or not)
<fullermd> Presumably it would only matter for somebody building for win32 directly from the tarball...
<BasicOSX> make dist does not build it
<BasicOSX> ie, make dist on linux
<mwhudson> i think it would only get c-ified on win32
<mwhudson> looking at setup.py
<poolie> <jml> "your RM thinks..." <-- nice one
<poolie> in expression and sentiment
<BasicOSX> I was under the impression that things goe pyrex-ified on install, but the last release went out with none and it caused problem
<BasicOSX> engrish spoken here also
<jml> BasicOSX: I think it's perfectly OK for a 1.15.1 release.
<poolie> BasicOSX: the thing is we'd rather assume the RM has pyrex even if the installer doesn't
<BasicOSX> poolie:  _walkdirs_win32.pyx not in tar or zip when build in linux ok?
<jml> BasicOSX: given that it's not a regression.
<jml> (but poolie has the say here, I think)
<poolie> the .pyx file is the original source, it must be present
<poolie> um
<jml> BasicOSX: it's the C file that's missing.
<BasicOSX> oh, sorry miss understood
<poolie> mwhudson: you may be right, but i thought we could generate the C files regardless of platform
<poolie> however i think it's more ok if they're missing
<poolie> on windows
<mwhudson> poolie: you probably _can_
<poolie> um
<mwhudson> poolie: but in this case, we certainly don'
<mwhudson> t
<poolie> my impression is that on unix there will be many people with compilers but not necessarily pyrex
<poolie> on windows, probably only hardcore people will be compiling and it's reasonable for them to have it
<BasicOSX> poolie:  does RMS always send a condolences  on a regression release?
<poolie> but better just to ship it all
<poolie> yes :)
<poolie> it worried me too :)
<jml> poolie: so we ought to be including the C for all of the .pyx files. we haven't so far, which means that it's ok for 1.15.1, but we should fix it for some unspecified future release?
<jml> possibly 1.16, given that bug 385453 is already filed against it.
<ubottu> Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453
<fullermd> I note, for the record, that for 1.15 (and the last time we lacked the built .c files in a release.... 1.12?), I just added pyrex as a build dependancy to the port.
<fullermd> And I'm seriously considering just leaving the dependancy in place for the future, Just In Case.  It's _tiny_.
<BasicOSX> what the heck, some how a title of 1.15.1 is 1.15.1 "" but I cannot remove the ""
<fullermd> (I mean, seriously, it took like 10 seconds to download, build, and install, on my old hardware)
<BasicOSX> nm, control-E killed line and it's gone
<lifeless> so
<lifeless> we should be versioning the pyx files now
<lifeless> its on my todo
<lifeless> but anyone can do it
<poolie> jml; i thought that fixing this was the purpose of doing the .1 release?
<jml> poolie: oh.
<jml> poolie: I thought the purpose was fixing the smartserver error regression.
<spiv> The build error was the original reason, the error regression just piggy-backed on that IIRC.
<jml> ahh ok.
<spiv> There was also hope for a while that the gc-stacking fixes would be suitable for a 1.15.1, but they became too large.
 * jml writes out his revised understanding:
<poolie> BasicOSX: so does 1.15.1 actually include the C files?
<jml> poolie: no.
<jml> <jml> BasicOSX: in the tarball, there's no C file corresponding to ./bzrlib/_walkdirs_win32.pyx
<spiv> Most Windows users will use the pre-built installer though, so that's possibly not such a big deal.
<poolie> but for the other ones?
<lifeless> spiv: it borks nearly every linux distro
<lifeless> spiv: as they have been depending on the C files
<BasicOSX> I see the .c in the zip file.  http://pastebin.com/d7ff67cf
<jml> poolie: all of the other ones are there.
<spiv> lifeless: linux distros have been depending on building _walkdirs_win32?
<BasicOSX> but I do -not- see them in the tar
<lifeless> spiv: no, they run setup.py, setup.py builds or not, and depending on the exact distro we either end up with .so's or not.
<BasicOSX> and the bad news is I sent the announce email
<lifeless> spiv: and as they don't consistently fail when there are no .so's, users get slow bzr
<jml> BasicOSX: http://pastebin.com/m3d0b70e0
<lifeless> as in fact our ppa was doing for a bit
<jml> BasicOSX: I see the C files in the tar.
<BasicOSX> correct, I forgot the '$'
<spiv> lifeless: the only missing .c file is _walkdirs_win32.c, if I'm understanding the situation correctly.
<BasicOSX> my apologies
<jml> spiv: you are.
<jml> at least in that respect :)
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.15.1 released 09 June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<spiv> BasicOSX: congrats on another release.
<jml> BasicOSX: thanks :)
<BasicOSX> Transition of RM roll on a "pffft" on my part
<jml> :D
<lifeless> spiv: we're talking at different levells
<jml> while everyone is talking about pyrex :)
<jml> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch00992%24d67%241%40ger.gmane.org%3E <-- am I ok to land that?
<lifeless> jml: poolie said he would land it
<lifeless> jml:  if its not landed its certainly approved to land
<jml> cool.
<lifeless> spm: ping
<lifeless> spm: meet spiv. spiv makes pqm break with lp branches.
<lifeless> spiv: meet spm. spm makes pqm work with lp branches.
<lifeless> Now, will you both talk to yeach other please!
<bialix> jml: hi
<jml> bialix: hello
<bialix> hello. I'd like to say you about Russain translation patch, because you're RM for 1.16
<bialix> I'd like to have this patch merged and released as part of 1.16, so more russian-spoken people will use it and review it
<bialix> what should I do to help you?
<bialix> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch0ld7v%24jjb%241%40ger.gmane.org%3E
<jml> bialix: you should find someone to review it for you, I think.
<bialix> poolie, igc: hi
<igc> hi bialix
<bialix> igc, can you help me with review of Russian translation patch?
<igc> bialix: sorry that I haven't got to all your emails yet - flat out on an important eol patch
<igc> bialix: not just now sorry
<bialix> ok
<bialix> 2 all: if anybody can review the patch (only the part related to Makefile changes) -- I'll be very  grateful
<jml> bialix: btw, is there a bug associated with this patch?
<bialix> not yet, but I can file if this is best way
<jml> bialix: please do, & assign it to the 1.16 milestone.
<bialix> I can't assign to milestone. I'm not part of bzr devs LP group
<jml> bialix: ok, I'll assign for you, on the assumption that this change is easy enough for the 1.16 release
<bialix> jml: https://bugs.launchpad.net/bzr/+bug/385464
<ubottu> Launchpad bug 385464 in bzr "Russian translation for user documentation" [Undecided,Confirmed]
<vila> hi all
<bialix> vila: hi!
<bialix> vila: can I resuade you to look at my russian translation patch, I need to find reviewer for Makefile changes
<bialix> s/resuade/persuade/
<vila> bialix: ok
<jml> poolie: you available for a fairly quick call?
<bialix> vila: btw, thanks for your hint about SavedCommitMessageManager in bzr-gtk
<bialix> I have many questions about that class. Who is designed it?
<vila> bialix: but I thought your submission was a bit strange (empty bundle), can you make a merge-proposal instead. Even if the diff is huge, we'll be sure the real stuff is up for review
<bialix> the branch is  lp:~ru-bzr/bzr/doc-ru
<bialix> this is merge directive, it's not empty
<bialix> do you want full preview diff?
<bialix> I can make it without bundle part
<vila> bialix: oh, merge directive without diff silly me, of course
<vila> bialix: no forget it, I'll mirror that locally to review
<bialix> resulting htmls available at my site
<bialix> for preview
<vila> bialix: I'll generate them locally as part of the review anyway
<bialix> ok, that's fine
<jml> vila: hello
<jml> vila: when you get a chance, can you please take a look at https://edge.launchpad.net/bzr/+milestone/1.16 and tell me if you think we need anything else for the 1.16 release
<vila> jml: you mean on a general point of view, right ?
<jml> vila: yeah. any things that are critical to a good 1.16 release & aren't on that list.
<fullermd> What about fairings?
<vila> ok, so nothing on my radar yet (bug #385453 can be fixed by adding the C files though)
<ubottu> Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453
<jml> vila: cool.
<jml> fullermd: fairings?
<jml> fullermd: what are they?
<spm> hi spiv :-)
<fullermd> jml: Well, that's the real question, ain't it?  ;>
<jml> vila: jam seems to be against adding C files right now. since we are close to release, I figure we should adopt a simpler solution for 1.16.
<vila> jml: ha, ok, I haven't read his mail yet, but on the principle I trust him :)
<spm> spiv: so aiui, your lp:spivs-awesome-code branches to bzr aren't getting thru PQM?
<jml> vila: cool. :) I'll be around for a while longer, so feel free to ping me if you think of something.
<vila> jml: ok
<spiv> spm: well, they get through, but when they reach the top of the queue they silently fail (i.e. no email reply)
<spm> spiv: do you think it's possible the sheer awesomeness of the code overwhelms PQM?
<spiv> spm: my guess would be that something has broken pqm's ability to authenticate to bzr+ssh://bazaar.launchpad.net/, actually :)
<spm> heh. lets not interject real data/facts here!
<spiv> spm: I wasn't, that really is just speculation :)
 * jml afk for a bit
<spm> spiv: ok. this is really weird. rob and myself fixed this the other day - the *same* fault/broken config file is back. argh.
<spiv> spm: was that for the lp pqm, though?
<spm> bzr
<spiv> spm: wacky!
<fullermd> Well, he didn't specify a _direction_...  "the other day" could well be tomorrow  :p
<spm> :-)
<spm> spiv: oki, give it a whirl now?
<vila> urgh, http://paste.ubuntu.com/192236/
<vila> spiv: does the above rings a bell ?
<vila> bialix: what format did you use for lp:~ru-bzr/bzr/doc-ru ? I can't branch it nor pull fom it :-(
<bialix> Branch format 7
<bialix> Repository format:  	Packs 6 (uses btree indexes, requires bzr 1.9)
<bialix> I can send you complete patch with bundle
<spiv> spm: I don't have a pending branch handy, I'll let you know tomorrow most likely if that's ok.
<spiv> vila: you can usually work around that bug in the branch by using nosmart or sftp
<spm> spiv: np
<bialix> spiv: thx for the fix of Connection reset by peer. I'm ought to test it properly
<spiv> bialix: that's ok, it was just something that jam pointed out at the sprint and it looked like a quick fix to do between test runs :)
<bialix> glad it finally fixed
<vila> spiv: 8-} adding nosmart works, even if the progress bar reports bzr+ssh... meh. Anyway, I thought that symptom was fixed in several different ways already, there are still more ?
<poolie> jml, hi
<poolie> am talking to robert, you can call if it's urgent
<spiv> vila: the damaged branches are still damaged.
<vila> spiv: ha yes ! Sorry
<spiv> vila: https://launchpad.net/bugs/354036 's description has the gory details :P
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed]
<spiv> "Undecided,Confirmed"?
<spiv> ubottu: wha?
<ubottu> Sorry, I don't know anything about wha?
<spiv> Oh, the "bzr (Ubuntu)" bug.  Learn some context about the channel you're in :P
<bialix> vila: entire bundle sent to you
<spiv> bialix: (you may want to run the fix script attached to 354036 to repair your doc-ru branch)
<vila> bialix: it's ok, spiv reminded me that my memory is suffering... what's the name of the disease ?
<fullermd> "ghost memories"  ;)
<bialix> spiv: should I? it works for me and other ru-bzr people
<jml> poolie: it's not. I'll survive :)
<bialix> spiv: is not http:// URL is workaround?
<spiv> bialix: the bug description on 354036 gives the precise details of the issue.  People that don't already have those revisions will probably encounter that error if they use bzr+ssh or lp: URLs.
<spiv> bialix: http:// (and sftp:// and nosmart+bzr+ssh://) URLs do workaround the problem, yes.
<bialix> spiv: the bug description and comments is scary long
<spiv> bialix: don't worry about the comments, the description is fully up-to-date.
<bialix> you know this patch does not work with bzr.exe?
<spiv> Which patch?  The fix-branch.py script?
<bialix> running with bzr.dev
<bialix> spiv: should I run this script from my source branch?
<bialix> i.e. what is working dir expected>
<bialix> ?
<vila> huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ?
<bialix> the script just prints: Missing inventories: set([('pqm@pqm.ubuntu.com-20090423015537-xfgqsbjj9ctpcd3o',)]) and hangs
<bialix> spiv: ^
<jml> poolie: the main thing I want to know is, for 1.16, should I be concerned with landing the many "Approved" patches listed on bundlebuggy?
<bialix> running from local source branch gives me different message: Missing inventories: set([])
<vila> jml: *I* will be concerned if I was you and will (well, *I* won't, but we're talking about you :) at least target bzr.dev *after* cutting a 1.16 branch...
<jml> vila:
<vila> jml: I will just PING (note capitals) the authors :)
<jml> vila: :)
 * vila adds more smileys everywhere just in case 
<AfC> ping: Verb. To throw an electronic message at someone. Ping: Verb. To throw a "ping-pong" ball at someone. PING: Verb. To throw a large bowling ball at someone. :)
<bialix> spiv: I'm not sure if this script is working. It just print message and then nothing happens. I don't see big network activity or something similar. It looks like it just hangs
<vila> AfC: is that from a real source or did you just made it ? :-D
<AfC> Just made it up
<AfC> vila: feel free to use it :)
 * bialix can keep it running for all day, of course. But not sure it makes sense
<vila> AfC: here you are: http://bazaar-vcs.org/Quotes
<spiv> bialix: hmm, it shouldn't hang.  If there are missing inventories, it will fetch them from the stacked-on repository then exit.  If there are none ("set([])") it will simply exit immediately.
<AfC> vila: There are some very funny passages on that page
<bialix> so, it definitely hangs
<vila> AfC: :-)
<spiv> If it hangs it might be something odd like the SSH subprocess/thread not exiting perhaps?
<bialix> you ask me?
<bialix> I don't know
<spiv> I ask the world in general :)
<spiv> I don't expect anyone to know the answer...
<bialix> entire mind of universe, I guess
<vila> well *I* expect someone knows the answer about:
<vila> huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ?
<vila> :-/
<spiv> Anyway, it should have done the fix.  If you interrupt it and re-run you'll probably see that it's fixed it (i.e. it will report "set([])").
<vila> Or should I just test against old bzr releases ?
<spiv> Or, it really has hung while trying to fetch the missing bits, which would be odd!  But maybe a traceback would show something.
<spiv> vila: I would expect push to a WT would keep the uncommitted changes (and apply them against the new base tree, if necessary)
 * bialix asking ubuntu guy (Dima Vasiliev) to run this script one more time
<vila> and fail if they conflict with already present uncommitted changes ?
<vila> and not be propagated if I branch from where I just pulled ?
<spiv> vila: well, produce conflicts anyway.  Not precisely what you mean by "fail" here.
<vila> and not be propagated if I branch from where I just pushed ?
<bialix> spiv: if you say so, I guess it's fixed
<vila> spiv: yes, conflicts sorry
<bialix> but it was not broken for me anyway, so I can't check this
<spiv> bialix: *nod*
<vila> bialix: you can try branching in a standalone branch (i.e. outside your shared repo)
<poolie> jml: not necessarily
<poolie> you should be concerned about any ones that are marked 1.16
<vila> bialix, spiv: not fixed from here, nosmart+ still needed
<jml> poolie: ok, thanks.
<poolie> and you should help me guilt everyone into landing them
<poolie> but not necessarily for 1.16
<poolie> i landed a couple of mine today
<jml> poolie: I'm happy to do that post-1.16 :)
<bialix> spiv, vila: Dima said it just prints: Missing inventories: set([]) and then exit
<bialix> vila: just running bzr get in temp dir outside any shred repo with bzr.exe 1.15. Still don't see error
<bialix> 50% done
<bialix> vila: Dima just branching on Ubuntu with official bzr 1.15 without errors
<bialix> it smells like regression in bzr.dev
 * bialix assumes vila runs bzr.dev
<fullermd> Fails for me with both.
 * vila assumes bialix runs a magic version :)
<vila> bialix: just to be sure, can you run bzr info -v in your temp dir and check which repo is used /
<vila> bialix: just to be sure, can you run bzr info -v in your temp dir and check which repo is used ?
 * bialix thinks about the fact he and Dima have write privileges to this branch, and other people are not :-P
<fullermd> Well, python tracebacks might as well be Russian to _me_...   so maybe his bzr just understands it while ours don't?  ;)
<bialix> fullermd: you're incredible right
<bialix> hdime: hi
<bialix> hdima
<bialix> hdima: hi
<hdima> hi
<bialix> vila, fullermd: here is Dima
<bialix> ask him
<bialix> my branch command still working
<bialix> it seems my i-net channel little than yours
<hdima> bzr branch work fine for me, I don't see any errors
<bialix> hdima: show here output of `bzr info -v` please
<hdima> bialix: wait a sec
<bialix> or pastebin it
<vila> hdima: the bug (AFAIUI) should only be triggered if you don't have some revisions locally, so using a shared repo masks the bug
<poolie> vila, hello, goodbye! :)
<vila> poolie: have a nice evening ! ;)
<poolie> let's try to talk tomorrow, if S will let me :)
<vila> poolie: cough, Friday instead, I'm not there tomorrow
<hdima> vila: I've create fresh branch in empty directory so I don't think it was masked
<poolie> ok
<vila> hdima: bzr info -v will tell us for sure
<hdima> And I've ran fix_branch.py which returns: Missing inventories: set([])
<hdima> vila: Ok, but I've just deleted the branch and branch it again :-)
<vila> hdima: argh ;)
<jml> "bzr: ERROR: No module named bencode" -- what do I install?
<bialix> my branching still in progress: [#########-          ] bzr+ssh > 141913KB   122KB/s | Fetching revisions:Inserting stream
<vila> jml: use --no-plugins or BZR_PDB=1, it's bzr-gtk and bencode related
<bialix> jml: some plugin is not updated yet, I guess
<jml> vila, bialix: thanks.
 * jml considers aliasing ./bzr to './bzr --no-plugins'
<vila> jml:  you just said jam fix has landed somewhere what bzr version are you using ?
<hdima> Ok, here it is: http://paste.pocoo.org/show/122163/
<vila> jml: put your RM hat on and repeat: "I should not use --no-plugins when wearing my RM hat" :)
<jml> vila: I'm fixing https://bugs.edge.launchpad.net/bzr/+bug/385132
<ubottu> Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged]
<jml> vila: I'm wearing my Launchpadder hat.
<jml> vila: *and* my RM trousers.
<bialix> vila: http://paste.pocoo.org/show/122163/
<vila> jml: oh, np then ! Go ! Use --no-plugins !!!
<vila> bialix, hdima: I'm lost :-/
<hdima> bialix: the same output :-)
<bialix> no, it's your output
<hdima> bialix: =))))
 * bialix just pointing it for vila
<vila> bialix: rats ! I thought it was yours and was comparing both ! :-D
<hdima> I thought it was yours :-)
<bialix> vila: wait a sec
<bialix> my branching just finished without errors
<jml> glyph: hello :)
<bialix> here is mine: http://paste.pocoo.org/show/122164/
<jml> vila: re: your previous question: http://paste.ubuntu.com/192280/
<bialix> vila: they both looks suspiciously similar :-D
<hdima> bialix: except the first line ;-))
<bialix> yeah
<hdima> So it works
<bialix> vila, spiv: so what now?
<bialix> it works for us
<bialix> and we both using official bzr 1.15 and we both have write privileges for this branch
<vila> write privileges shouldn't have an impact here
<bialix> as you wish
<vila> apart from that, no idea
<vila> trying with 1.15.1 from here
<bialix> I don;t have 1.15.1 yet
<vila> fails in the same way
<vila> as is 1.14.1
<bialix> hdima: we just discovered Russian-only feature in LP. Yay!
<bialix> I guess this is because Mark was in Russian
<hdima> It's I18N feature ;-)
<vila> also fails with 1.15
<hdima> Now I'm branching read-only with http://...
<vila> I wonder if windows has some... thing... that has the same effect as adding nosmart+...
<bialix> vila: hdima using ubuntu
<hdima> vila: Maybe you need to run it in some sort of sandbox?
<bialix> with --no-plugins flag may be?
<vila> bialix: yeah --no-plugins and a lp: URL, I love that combo :-)
<bialix> :-DDDDDD
<hdima> :-)
<bialix> you have bzr+ssh URL ;-)
<hdima> bialix: Maybe we just need to branch it to a different site for vila?
<glyph> hello!  I have a question about branch etiquette.
<bialix> no, http:// or nosmart+ prefix works
<bialix> cool
<bialix> yesterday I've asked about another etiquette
<vila> hdima: Don't worry, I have been able to branch by adding nosmart+, I'm just trying to better diagnose the problem, but really I should leave it to spiv as obviously I'm going nowhere
<bialix> it seems bzr users is very noble people
<hdima> vila: Ah, OK
<bialix> glyph: please, ask
<glyph> If you're working on a feature in a branch, and it takes a long time, sometimes you have to integrate changes from trunk.
<jml> yep.
<glyph> It seems like the convention is to do 'bzr merge trunk' in your branch, and just keep working.
<bialix> yes
<jml> glyph: yes. that's what most people I know do.
<glyph> If a lot of work has gone into trunk, that seems to create something I find confusing as a reviewer.
<glyph> the revision has a giant diff of unrelated changes, which may involve some changes to resolve conflicts
<glyph> the changes which resolve conflicts are relevant to the branch, but all the other stuff from trunk (which can be a lot) isn't
<vila> glyph: time to use 'bzr diff -rsubmit:' ?
<bialix> glyph: you can use `bzr merge --preview` or `bzr send -o-` to preview actual changes
<jml> glyph: why is the diff in that revision relevant to the review?
<glyph> jml: well, this is one of the things that I like about bzr as opposed to svn
<BasicOSX> This cuz I'm using bzr.dev? KnitPackRepository('lp-hosted:///~tanner/mactrek/trunk/.bzr/repository') is not compatible with KnitPackRepository('lp-hosted:///~tanner/mactrek/osxtrek.1.4.0/.bzr/repository') different rich-root support
<jml> bialix: 'send -o-' is equivalent to 'diff -rsubmit:', isn't it?
<bialix> I never think about this
<bialix> may be
<glyph> jml: If I look at the revision history, I can see how the branch came to be much more easily
<vila> jml: 85% sure yes
<glyph> jml: If people integrate changes from trunk, it's easier to read if they do the re-branch thing
<glyph> jml: If I'm just reading the end-of-branch diff, the experience isn't much different from svn :)
<jml> glyph: except that the re-branch thing loses all changes from before then.
<bialix> re-branch? I guess you need rebase
<glyph> jml: it does?
<vila> BasicOSX: lp-hosted ?
<BasicOSX> yes
<jml> glyph: the history of those changes, yes.
<vila> BasicOSX: you scare me there is is 3h11 AM your time ?
<bialix> jml: not if you're using rebase
<vila> s/is is/is it/
<BasicOSX> vila:  I need to keep up with you
<glyph> jml: if you do re-branching by 'bzr branch trunk my-branch-2; cd my-branch-2; bzr merge ../my-branch', what history is lost?
<vila> BasicOSX: what is lp-hosted ? (was my badly expressed question)
<jml> glyph: oh, right. none.
<jml> glyph: it's just weird :)
<jml> glyph: I was thinking of Combinator-style "merging forward"
<jml> my mistake.
<glyph> jml: well, the thing I just said is the bzr non-history-losing translation of that idiom ;)
<BasicOSX> vila:  https://code.launchpad.net/mactrek I just took some upstream code, gotten via bzr svn-import and push to LP (bzr push lp:~tanner)
<jml> glyph: a lot of the time when I do reviews, I look at the mainline history of that branch.
<jml> glyph: not diff-by-diff, just the log messages.
 * igc dinner
<glyph> jml: so yeah
<glyph> jml: what I want to know is, why is it weird?
<vila> BasicOSX: I think jml may know better about which branch stacks on which and what formats are used in thoses branches. Especially since some vcs-imports are involved and I don't know if you used that or did your ow import 8-}
<BasicOSX> k
<BasicOSX> I think it's cuz I locally did a bzr branch --stacked upstream my-branch
<vila> BasicOSX: but https://code.edge.launchpad.net/mactrek also show branches with "This branch has not been pushed to yet. " warnings which may indicate yet another kind of problem
<BasicOSX> then did a bzr push lp:~tanner/my-branch
<jml> glyph: have a look at https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/+merge/7269 for an example
<jml> (sorry I couldn't find one of my own)
<jml> glyph: I look at something like that almost every time I review a branch.
<jml> glyph: I get to see the history, but rarely look at the line
<jml> at the diff for each revision.
<jml> glyph: doing the re-branching thing you describe is weird because it disrupts the idea of a branch as a line of development.
<jml> glyph: also, the initial commit that merges in your changes isn't particularly meaningful.
<jml> glyph: at least to me, the operation I'm performing is "integrate changes from trunk with my work"
<jml> not "start a new line of work and bring in everything from my last try at it"
<jml> glyph: I guess that's not such a compelling answer.
<BasicOSX> isn't the bug that was fixed in 1.15.1?
<BasicOSX> Source format does not support stacking, using format: '1.6.1-rich-root'
<BasicOSX>   Packs 5 rich-root (adds stacking support, requires bzr 1.6.1)
<jml> BasicOSX: don't think so.
<BasicOSX> ok, I'll stop the panic attack and re-read bug report
<jml> BasicOSX: the issue is that one branch is 1.6.1-rich-root and the other is 1.6.1, I think.
<jml> BasicOSX: you can't stack rich-root on non-rich-root & vice verse
<jml> versa, rather.
<jml> *so* glad that mess is going away
<bialix> vila, spiv: so outcome of the problem with doc-ru branch should be filed as bug?
<jml> wish emacs had annotate integration.
<jml> mwhudson: pls rewrite loggerhead in elisp kthxbye.
<vila> bialix: I think so yes
<glyph> jml: Well, it might not be super compelling, but it makes sense
<jml> glyph: the other reason is that most merges really are boring.
<bialix> vila: my gut feeling -- it's related to write permissions. but I have no facts
<jml> glyph: even most of the ones that resolve conflicts.
<vila> bialix: There is a way to check that: give me the write permissions (and remove them after the test)
<bialix> join ru-bzr group then
<glyph> jml: it does make the history more readable as a list of changes, rather than as a tree of diffs
<hdima> bialix: maybe you remove write permission for me and give it back after the test?
<glyph> I think I still prefer my way of doing it, but it explains why that isn't the default way
<vila> bialix: done
<bialix> hdima, vila: I do both
<hdima> bialix: Don't forget to give it back ;-))
<bialix> you know how to PING me :-)
<jml> glyph: as long as you don't make it compulsory for Twisted development, let's leave it there :)
<hdima> bialix: yeah :-)
<bialix> vila, hdima: done
 * hdima test branching
<vila> bialix: you were right ! I can branch with 1.15 !
<bialix> wait for hdima
<vila> bialix: well, still in progress with 1.15, will try bzr.dev then
<hdima> bialix: you are right: I see the error :-))
<bialix> yahoo!
<hdima> But what about fix_branch.py then?
<bialix> vila: ^
<hdima> It seems it doesn't fix anything? :-)
<vila> there is a bug there, I suspect spiv didn't test with such a config, I don't know off-hand what difference write privileges imply, but obviously something :) jml ? Any idea about what lp does differently here ?
<jml> yes.
<jml> (nyah-ah-ah)
<vila> great, I'm so relieved :)
<hdima> bialix: give me my rights back! :-))
<jml> Launchpad has two different branch storage areas.
<jml> an upload area and the mirrored area
<bialix> ok :-P
<bialix> done
<jml> via the SSH server, if you get a branch that you've got write access to, you always get the version in the upload area
<jml> that gets pulled to the mirrored area with bzrlib, so the version in the mirrored area (which you get if you don't have write access) is always a working bzr branch.
<hdima> bialix: thanks :-)
<bialix> vila: you can leave the group yourself, I guess?
<vila> bialix: branch ok with bzr.dev, you can toss my rights :)
<vila> bialix: I'll try, wait
 * fullermd tosses vila a left, just when he wasn't expecting it.
<bialix> happy to help
 * vila watch the wreckage on the floor....
<jml> spiv: you still around?
 * hdima happy to help catch the bug
<vila> bialix: done
<vila> jml: you mean the branch in the mirrored aread is *not* working
<hdima> vila: now you're lost a chance to help with the translation :-)
<jml> vila: working as far as bzrlib can tell :)
<vila> jml: but exhibiting the bug right ? Oooooh, the script has fixed the uploaded branch, but the puller didn't realize it should update the mirrored one because the tip didn't change right ?
<jml> spiv: in r4126.1.1, you add a test that doesn't have an assertion, test_default_stacking_with_stackable_branch_unstackable_repo -- is this deliberate.
<jml> vila: bingo
<vila> pfew... thanks bialix, that one could have stay hidden for a looooong time
<bialix> vila: so now you can finally look at the patch :-)
<vila> bialix: If you didn't interrupt me that much the review will have been finished at least 1h30 ago :-D
<vila> bialix: nearly done
 * hdima thinks the patch need to be approved at least
 * bialix shuts up and hides somewhere
<vila> bialix: doe
<vila> bialix: done
<vila> I only ask for a minor tweak: adding a comment, other than that, congrats for that work
<glyph> jml: so do you think you'd ever have call to do my backwards-trunk-merge thing?
<hdima> bialix: Agreed with vila. I think we need to write something like this: "The following docs was translated to Russian: ..."
<jml> glyph: I don't think so.
<jml> glyph: two possible circumstances that I can think of --
<jml> glyph: first, if I was resuming a long-dormant branch, then in a sense I am starting a whole new line of work. I might do that sort of thing (then again, I might not)
<jml> glyph: the other case, when I have a really interesting conflict, I think I would instead do my normal thing and put in a detailed commit message.
<glyph> jml: if you found a branch where someone (me) had done it a bunch of times, would it annoy you?
<jml> glyph: I don't know -- it's never happened that I've noticed :)
<jml> glyph: probably not. (I wonder what it would look like in bzr viz or bzr qlog)
<bialix> hdima: can you adjust it, please?
<bialix> vila: many thanks
<hdima> bialix: yes
<vila> bialix: thanks to you and your mates for doing that ! For so long (first revisions are from last August right ?)
<bialix> yes, it was started by Alexey Shtokalo actually. But even before there was another attempt that failed
<bialix> it's not easy job to do
<hdima> vila: I believe we'll address duplication in the Makefile in the next patch because I don't like it too
<vila> hdima: great !
<hdima> Yes, and now we want to do it more officially :-)
<vila> hdima, bialix : that's one more reason to land that patch quickly :)
<jml> but let's not forget the other reason: if it's not in soon, it misses 1.16 :)
<bialix> vila: I know it's too much for one day, but.. can you help us with PQM?
 * jml admires the shine on the RM trousers.
<hdima> Actually I have some thoughts about i18n but I think it's too early for now
<bialix> hdima: please! not now
<jml> lifeless: you around?
 * bialix envies to jml
<hdima> bialix: it's only thoughts :-)))
<vila> bialix: no problem, I was thinking about that, but you'll need to push a new branch in lp:~bialix/bzr/whatever-as-long-as-you-tell-me so we avoid the bug
<fullermd> jml: That's dried blood sweat and tears from previous RM's.  No cleaner in the world has managed to get it out...
<vila> err lp:~bzr/bzr/whatever even
<jml> fullermd: heh :)
<vila> jml: did you get the updated notes from BasicOSX ?
<bialix> vila: I have no access to ~bzr
<bialix> perhaps hdima has?
<vila> bialix: bah, use lp:~bialix then, that should be fine as long as you do that with a recent enough bzr (1.15 should be fine)
<hdima> bialix: no I'm not
<bialix> vila: perhaps we should get you to ru-bzr group back :-)
<vila> bialix: :-) Naah, no time to learn Russian :-)
<jml> vila: no, not yet.
<bialix> vila: we can teach you some love words in russian...
<vila> :-D
<bialix> :-D
<hdima> and some slang of course ;-)
<bialix> vila: new branch with the tweak: lp:~ru-bzr/bzr/doc-ru-1.16
<jml> Ð Ð¾Ð³Ð¾ÑÐ¾ÌÐ´Ðµ Ð±ÑÐ·Ð¸Ð½Ð°Ì, Ð° Ð² ÐÐ¸ÌÐµÐ²Ðµ Ð´ÑÌÐ´ÑÐºÐ°.
<bialix> :-D
<jml> (from http://en.wikiquote.org/wiki/Russian_proverbs -- I speak no Russian)
<hdima> Looks like unreadable UTF-8 for me :-)
<bialix> hdima: I see it right
<bialix> v ogorode buzina a v kieve dyadka
<hdima> bialix: Other guys still use KOI8-R on IRC :-)
<vila> looks like perfect cyrillic for me :-)
<hdima> Wow, Russian day on #bzr :-)))
<jml> I can't figure out where this test is supposed to go.
<jml> also, I suspect that TestSmartServerRequestBzrDirInitializeEx's docstring lies.
<lifeless> jml: yes
<jml> lifeless: hi
<mwhudson> jml: no
<jml> lifeless: I can't figure out which tests I'm supposed to be looking at here.
<jml> mwhudson: awwwwwww, c'mon, be a sport.
<lifeless> ok
<lifeless> lets make a date; tomorrow say, and I'll look deeply with you
<lifeless> I'm wellpast EOD
<jml> lifeless: sounds like a plan.
<mwhudson> jml: no
<aquarius> I bzr branched a launchpad project, using my access credentials (it's a project that I can write to). Since then, I've changed my launchpad username, so "bzr pull" says "Using saved parent location: bzr+ssh://OLDUSERNAME@bazaar.launchpad.net/" and then "No such Launchpad account". Can I tell bzr to change the saved location?
<james_w> aquarius: bzr pull --remember URL
<aquarius> james_w: and lo it works. Good shout, fella
<jml> gosh, it's been a while since I've seen 'fella' used colloquially.
<aquarius> it's due for a revival, I think. Like "codswallop"
<jml> codswallop I can see.
<jml> aquarius: are you going to EuroPython?
<aquarius> jml: probably not, but since I'm only 10 miles away I may drop in for an evening or two of beer
<jml> aquarius: cool. I'll be attending -- would be cool to catch up.
<jml> aquarius: also, there's a Bazaar sprint on the Fri & Sat, which you're welcome to gatecrash. (See http://wiki.europython.eu/Sprints)
<aquarius> I might be able to do that, I'm not sure
<vila> bialix, hdima: landed
<igc> bialix: I've resubmited that patch for qversion as requested
<hdima> vila-lunch: Cool! Thank you!
<spiv> jml: hmm, regarding that test, probably was intentional, but that was *ages* ago ;)
<spiv> jml: It looks rather like a test that is of the "...and then this last step doesn't blow up" variety.
<spiv> jml: although it doesn't seem like it would be hard to sprinkle some assertions afterwards, for clarity.
<spiv> Also, I've got "bzr pull -r N" from a stacked repo (into an empty repo), where "N" is in the stacked-on repo, down to 18 RPCs, none VFS.
<spiv> glyph: so, what you describe generates a nearly identical history to the standard "bzr merge trunk".  The only difference is that the order of the parents of the merge revision is swapped.
<spiv> glyph: so one thought that occurs to me is that there's probably an easier way do that than actually constructing a new branch on disk ;)
<spiv> glyph: but more importantly, I don't see why that makes the history any clearer.  Either way there's a big honking merge in the middle of your feature development history that you want to land.
<rocky> hey the release notes url linked on the main page for 1.15.1 is 404
<poolie> hi rocky
<rocky> hello
<poolie> fixed
<poolie> rocky: thanks for reporting it
<rocky> np
<Milo-> hey, is there a way of setting up 'default' permissions for newly created branches and uploaded files using bzr?
<Milo-> my vsftp server's settings are completely ignored, and all new branches are created with 700 permissions, even though I want 755
<Spabby> hi folks, can anyone give me some advice what model is best for me to use for collaborative working using bzr please?
<Spabby> We will be working on a zf based php project as a duo, with the development being done on a central LAMP server
<Spabby> I'm not sure how and if we can achieve this with bzr
<sevenseeker> ping vila
<vila> sevenseeker: pong ?
<sevenseeker> good morning, I was told you were knowledgeable about bzr+ssh
<vila> sevenseeker: who said that ? :-)
<sevenseeker> I want to use a pub key to connect to a machine but it is not named in the default way (I have many)
<sevenseeker> ummm, lemme check
<sevenseeker> bueno :)
<vila> sevenseeker: what os are you using ?
<sevenseeker> client is mac 10.5 and server is ubuntu 9.04
<vila> good, we are in civilized world then :)
<vila> man sshd_config
<sevenseeker> hahaha
<sevenseeker> well I have ssh working fine
<LarstiQ> sevenseeker: is ssh-add feasible?
<sevenseeker> how do I make bzr use a specific key?
<LarstiQ> sevenseeker: if not, you could specify the key to use in ~/.ssh/config
<sevenseeker> oh, well... lemme check
<sevenseeker> oh, I see... never done that (LarstiQ)
<vila> sevenseeker: As Larstiq said, no need to involve bzr hence: man sshd_config, I thought the variable was Identity but I can't find it anymore :-/
<LarstiQ> vila: think so
<vila> IdentifyFile ! man ssh_config not sshd you id...entity seeker :)
<sevenseeker> vila: I see, lemme check... had no idea that would help me until you mentioned it :)
<vila> sevenseeker: so the idea is that you define IdentifyFile in some host section (I tested that weeks ago but I did it manually :-/ Time to start TDA test driven administration :-D)
<sevenseeker> sweet
<visik7> ok I used bazaar for 1 year alone :)
<visik7> now I'm using it in a team
<visik7> few questions:
<Milo-> he's been writing those questions for 10 minutes
<Milo-> I bet it's something huge
<visik7> this is my workflow A and B has rev1 and A commit and push (rev2) to a shared branch, now B commit and push too (its own rev2) and got a diverged error it, B runs merge and a commit and push
<visik7> Milo-: no I'm working and chatting and surfing and calling to the phone and a bunch of other things
<sevenseeker> howdy again, thanks everyone for your help and feedback
<sevenseeker> using ssh-agent I am able to push and branch remotely but I can't seem to get it working right, both push and branch TO the remote location only result in a dir with .bzr in it, and when I try and run 'bzr update' on it, it complains that it is NOT a working copy :(
<LarstiQ> sevenseeker: that is intended behaviour
<Peng_> sevenseeker: Why do you want a working copy?
<LarstiQ> visik7: go on :)
<sevenseeker> well all I want to do is push a branch to the remote server for development, the constraint is that my dev box I am pushing from is not reachable by the remote servers
<LarstiQ> sevenseeker: develpment in what sense? The .bzr control directory is everything bzr needs for publishing purposes
<LarstiQ> Peng_: I vote for inclusion of this question in http://bazaar-vcs.org/FAQ
<sevenseeker> so say locally I branch foo to bar, make my changes and commit, now I want to push 'bar' to actually work on it in my test envrionment remotely
<sevenseeker> yes, a FAQ on this would rock!
<visik7> LarstiQ: so the question is before the push of B
<Peng_> LarstiQ: That's a good idea. I'm not gonna write it, though. I'm a terrible writer.
<visik7> how to handle the if A had push something ?
 * LarstiQ nods at Peng_ 
<sevenseeker> right now I am tarballing it all up and throwing it on the remote location, but I figured there was a better way
<LarstiQ> sevenseeker: usually, one pushes a branch to a remote location, to then bzr pull/branch/merge from that location somewhere else
<visik7> B -> 1 pull -> 2 on error-> merge ->3 commit ->4pull (goto 2)-> push ?
<LarstiQ> sevenseeker: is the remote location actually a workstation of yours, and not a central server?
<sevenseeker> yes, it is a test machine (or dev on our production environment --> EC2)
<j_baker> I'm having a bit of trouble downloading anything at https://launchpad.net/bzr/+download ... Is it just my network connection, or is anyone else having the same problem?
<sevenseeker> so no, not central server
<sevenseeker> although I will need that soon
<LarstiQ> sevenseeker: you can create a working tree by using `bzr co`
<sevenseeker> just for using Trac
<LarstiQ> sevenseeker: and then `bzr update` to update the working tree
<LarstiQ> (after subsequent pushes)
<sevenseeker> oic, I wrongly thought co would 'pull' from another location, not use what is in the .bzr info
<sevenseeker> dang, you guys rock
<visik7> is my workflow complete ? or did I miss somethng ?
<sevenseeker> I really appreciate it
<LarstiQ> sevenseeker: to see that clearer `bzr co .`
<sevenseeker> I am still coming from svn, so used to that way, lol
<LarstiQ> visik7: I'd do: `cd trunk; bzr pull; bzr pull ../feature-branch; (if that failed, bzr merge ../feature-branch); bzr commit; bzr push`
<LarstiQ> visik7: alternatively, you could make use of checkouts and their lock-step development mode
<luks> sevenseeker: hm, I wonder what are you used to with svn
<luks> sevenseeker: because svn doesn't allow creating and managing working copies on remote servers
<LarstiQ> luks: `svn co` vs `bzr co .`
<visik7> but on the last 2 commands between commit and push do you check if new changes are in ?
<sevenseeker> I know, I meant that svn co pulled data from a remote source
<sevenseeker> not pushing :)
<luks> ah
<LarstiQ> visik7: no, because you had already pulled trunk to mirror remote
<visik7> but how could you know if someone update the remote ?
<LarstiQ> visik7: you would know if push said they diverged
<visik7> oh ok
<visik7> thanks
<LarstiQ> visik7: as I said, checkout with it's check at commit time might suit you better
<visik7> what's the difference between push/pull and checkout/commit a part that the branch is bound ?
<LarstiQ> visik7: ehm, that's not the relevant grouping
<visik7> ok I miss something
<visik7> could you explain me please ?
<LarstiQ> visik7: push/pull/checkout/commit are useable in both situations
<LarstiQ> visik7: in fully distributed mode, making a new revision (commit) and publishin that revision (push) are decoupled
<LarstiQ> visik7: in a central style (bound branch), commit will also make your revision available in the branch you are bound to.
<LarstiQ> visik7: however, that doesn't diminish the use of push to publish revisions in other locations.
<LarstiQ> visik7: commit will also check that you're not diverged, and suggest you run update if you are.
<LarstiQ> visik7: in the fully distributed mode, update is used to bring the working tree at the same revision as the branch, as seen in sevenseeker's situation
<visik7> so I don't understand how to use what you call "checkouts and their lock-step development mode"?
<LarstiQ> visik7: for bound, update will bring the working tree (and local branch) up to date with the master branch
<LarstiQ> visik7: if you're more familiar with a bound branch, use that term instead of a checkout
<visik7> I suggest my team to unbound their own branck
<LarstiQ> visik7: in that case, B can not commit to a state where he'd diverge from the shared trunk
<visik7> I don't really like bounded branches
<visik7> oh for that
<LarstiQ> yes
<stbuehler> I'm having fun with bzr-svn again... bzr push takes ages (discovering branches [...]), bzr dpush doesn't work, and i still don't get the svn rev ids for the commits i pushed in the bzr log
<LarstiQ> visik7: if you don't want to use them, that's fine.
<LarstiQ> visik7: you'll get diverged branches from time to time, and you'll have to merge
<LarstiQ> visik7: if trunk is diverged yet again after you do that, you'll have to merge again
<visik7> LarstiQ: I like unbound but I think that for other developers bounded branches are better
<LarstiQ> visik7: depends on what they're comfortable with
<visik7> they have never used VCS nor DVCS
<Milo-> I don't want to run "bzr serve" as root, what kind of permissions do I have to set for my server's users in order to my 'bazaar' -user to have access to the branches?
<Peng_> Milo-: That depends entirely on the permissions on your branches...
<Milo-> the branches are automatically created with 700, which I can't seem to change
<LarstiQ> visik7: that can mean they'll accept any new way of thinking :)
<Milo-> haven't found a way to create them with some other permissions instead
<LarstiQ> Milo-: how are they created?
<Milo-> when running bzr init ftp://my-ftp.my-domain.myTLD/branch
<visik7> LarstiQ: yes but it's already difficult to explain a VCS I can't afford to explain DVCS they probably starts to running around screaming
<LarstiQ> Milo-: I'll mention `setfacl` and POSIX acls before I know what the situation is
<LarstiQ> Milo-: if you can, using something that is not ftp will be better
<visik7> LarstiQ: so for B -> update -> merge if errors -> commit ->merge if errors ?
<LarstiQ> visik7: right, then checkouts might be better for them
<Milo-> ssh would be create, but chrooting it is harder
<Milo-> erm
<Milo-> great*
<Milo-> not create, hah
<visik7> B is my fellow developer :)
<LarstiQ> visik7: commit -> update if mentions -> commit -> update if mentions, etc
<visik7> so no steps before starts coding ?
<LarstiQ> visik7: `bzr checkout url/to/master; cd new-checkout; *hack*; bzr diff; bzr commit;`
<Milo-> setfacl -m u:myBazaarUser:rx hmm, I'll try that
<LarstiQ> Milo-: either I mistunderstand your question, or you're looking for group instead
<Milo-> the users are in the bazaar group
<Milo-> but the dedicated bazaar-user still can't access the files :/
<visik7> LarstiQ: yes the checkout part is already done, I mean ... in the morning ... before everything take place a bzr update is suggested right ?
<Milo-> and I need to find a way for bazaar to set up permissions for the group when ever it creates new files.
<LarstiQ> Milo-: paste from my situation:
<LarstiQ> setfacl -m group:developer:rwx /bzr
<Milo-> I don't want to setup dedicated bazaar server as root
<LarstiQ> setfacl -m default:group:developer:rwx /bzr
<LarstiQ> visik7: not needed, but doesn't hurt to get new revisions before you start working
<Milo-> LarstiQ I get "operation not supported" when I run that
<LarstiQ> Milo-: feh, then your fs doesn't have POSIX acl support (turned on)
<Milo-> ah
<LarstiQ> Milo-: in that case, you'll need to fall back to plain old unix permissions
<LarstiQ> Milo-: with setgid
<Milo->   ? ?    [*]     Ext3 POSIX Access Control Lists                           ? ?
<LarstiQ> Milo-: and appropriate umasks
<Milo-> it's definitely there
<LarstiQ> Milo-: and the fs in question is ext3? :)
<Milo-> indeed
<LarstiQ> mkay
<LarstiQ> Milo-: they really are the most convenient way of solving this problem
<LarstiQ> Milo-: could you pastebin the exact sequence?
<Milo-> exact sequence?
<Milo-> I rather ask something stupid than paste something stupid
<LarstiQ> Milo-: a transcript of the commands you typed in and their output
<LarstiQ> Milo-: the one that gave ris to 'operation not supported'
<Milo-> http://codepad.org/9L366Wmt
<LarstiQ> Milo-: ok, and `mount | grep home` just to make sure?
 * LarstiQ googles the error
<Milo-> /dev/sda2 on /usr type ext3 (rw,noatime)
<Milo-> no 'home'
<LarstiQ> Milo-: ah, you might be missing some user-land utilities
<visik7> thanks LarstiQ
<LarstiQ> Milo-: got libacl1 ?
<visik7> see you later
<Milo-> no such thing in the portage :o
<LarstiQ> Milo-: luckily you did a human grep for the information I was after anyway ;)
<Milo-> I do have sys-apps/acl
<LarstiQ> Milo-: sounds about right
<Milo-> which has access control list utilities, libraries and headers
<Milo-> well, I do know around my setup
<Milo-> but creating this dedicated user for bzr server is giving me a lot of trouble
<LarstiQ> Milo-: a dedicated user doesn't sound too sensible
<Milo-> well, I don't want to run the server as root
<LarstiQ> that sounds even less sensible :)
<Milo-> not wanting, or running it as root?
<LarstiQ> running it as root
<LarstiQ> it has no business near root
<Milo-> that's what I thought
<LarstiQ> Milo-: maybe we should take a step back and discuss what your desired outcome is?
<Milo-> I've plenty of users on my server, which are there to use bzr, share their projects and such
<LarstiQ> right
<Milo-> the users have their own accounts to do the changes, commits, etc
<Milo-> and the bzr serve is there to let them share their projects as readonly (bzr branch bzr://..../branch
<Milo-> )
<LarstiQ> ok
<Milo-> first I tried to do that with anonymous ftp user, but it hit the brick wall since bzr kept creating all the .bzr folders with 700 permissions
<Milo-> and now I think this one is hitting the same brick wall as well.
<LarstiQ> Milo-: you don't want to provide readonly access via http?
<LarstiQ> Milo-: or even bzr+ssh:// to other users branches?
<Milo-> that should also have the same issue, no permissions to the folders.
<LarstiQ> because they're using ftp to push their branches, and that results in 700 permissions?
<Milo-> bzr+ssh would be okay, but that'd require a lot of configuring for my ssh settings and ensuring that ssh is still chrooted (for which, I haven't found a working tutorial yet)
<LarstiQ> Milo-: what umask is the ftpd employing?
<Milo-> 0022
<LarstiQ> hmmm
<LarstiQ> Milo-: could you try a push with bzr+ssh:// or sftp:// to see if it has the same permissions?
<Milo-> I don't want those users to have actual shell-access
<Milo-> sftp:// only seems to work with default port
<LarstiQ> Milo-: regardeless of that, I'd like for you to test out and see what happens
<Milo-> oh and sftp doesn't work if I'm blocking them from logging in
<LarstiQ> Milo-: if those _also_ get to 700, we have a problem somewhere else
<Milo-> bzr: ERROR: No such file: '/test': [Errno 2] No such file
<Milo-> that was with bzr init
<Milo-> oh yeah
<Milo-> sftp takes absolute path
<Milo-> sftp created the repo with the right mask
<Milo-> so it's an ftp issue
<LarstiQ> yeah
 * LarstiQ hates hates ftp
<Milo-> But I can't let my users to use sftp, since I don't want to use default ssh port and I don't want them to be able to have ssh login rights
<LarstiQ> Milo-: that's fixable, but let's see what we can do with ftp
<Peng_> I thought OpenSSH's sftp is known for screwing up masks.
<Peng_> Or maybe it's group ownership. Anyway, it's something!
<LarstiQ> Peng_: fixed in a 5.x release
<Peng_> LarstiQ: Oh, cool.
<LarstiQ> afaik istr
<Peng_> ...I'm pretty sure I'm not crazy enough to build my own OpenSSH, though. :D
<LarstiQ> Peng_: 5.1 is in sid and testing
<Milo-> bzr+ssh:// also worked well
<Peng_> LarstiQ: Well, I don't run sid and testing.
<Milo-> so how to fix ftp
<LarstiQ> Milo-: if you could provide more debugging information on https://bugs.edge.launchpad.net/bzr/+bug/326543 that might help
<ubottu> Launchpad bug 326543 in bzr "Broken permissions over FTP for .bzr/repository (and others)" [Undecided,New]
<LarstiQ> Milo-: maybe run bzr with -Dtransport
<LarstiQ> Milo-: ie, `bzr -Dtransport push/init foo` etc
<Milo-> -Dtransport does what?
<LarstiQ> Milo-: server logs of your ftpd might also help debug this
<LarstiQ> Milo-: add verbose prints for transport (sftp/ftp/ssh/http) activity to .bzr.log
<Milo-> ok
<LarstiQ> Milo-: as well as information on which ftp server you're using
<Milo-> vsftpd
<LarstiQ> standard enough at least
<Milo-> oh forgot, I never received my launchpad confirmation
<Milo-> something wrong with my mail-box. It decides to ignore some weird places
<Milo-> probably something wrong with my own domain settings
<jseabold> Was wondering if someone could help me out.  I've found some help here on this problem a few weeks ago, but it persists.
<jseabold> I work on one branch on launchpad from two computers and even though I've committed and pushed visible changes to lp from one computer.
<LarstiQ> Milo-: if you do the debugging work, I can attach it to the bugreport :)
<jseabold> When I run bzr status on my other computer it says up to date with revision 1728 when the newest revision on the branch is 1730.
<LarstiQ> jseabold: `bzr status` compares your working tree with your local branch data. It does not check remotely.
<jseabold> sorry bzr update gives tree is up to date
<Milo-> LarstiQ could you tell me exactly what you want for that report?
<jseabold> but what it reports as up to date and what is on launchpad as the newest revisions is different
<LarstiQ> Milo-: sure. `bzr init ftp://` goes wrong, right? I'd like to see results of `bzr -Dtransport init ftp://` from ~/.bzr.log
<Milo-> ok
<LarstiQ> jseabold: what does `bzr info` say your branch type is?
<jseabold> Standalone tree (format: pack-0.92)
<jseabold> Location:
<jseabold>   branch root: .
<Milo-> woah currently I just keep getting this with all ftp-operations. http://codepad.org/1LhPZobe
<Milo-> I might have broken my ftp
<LarstiQ> jseabold: right, standalone tree, not a checkout.
<LarstiQ> jseabold: you want `bzr pull`, not `bzr update`
<jseabold> LarstiQ: that was my next question.  thanks! So I should only use update on a checkout and pull on a standalone tree?
<LarstiQ> jseabold: for this usecase, yes
<jseabold> LarstiQ: wonderful thank you very much
<eydaimon> bzr serve seems to not give me anything good when I run it. and by not good, I mean "erroreneric bzr smart protocol error: bad request 'GET / HTTP/1.1\r'".   I'm starting with `bzr serve`. Am I doing something wrong?
<eydaimon> oh, it's not an http serve :/
<eydaimon> is there a webserver type thing?
<LarstiQ> eydaimon: if you have a recent loggerhead installed, you can `bzr serve --http`
<eydaimon> loggerhead?
<Milo-> LarstiQ interestingly, everything else but the ".bzr" is created with the right permissions :/
<Milo-> everything else but .bzr (and lock) is created with 755
<LarstiQ> Milo-: you mean, other uses of ftp besides bzr?
<Milo-> no, when doing bzr init
<LarstiQ> Milo-: or, do you mean .bzr/repository is fine, but .bzr/ is not?
<eydaimon> LarstiQ: is it sufficient just to get the latest bzr ?
<Milo-> yes
<LarstiQ> Milo-: now that is weird
<LarstiQ> eydaimon: no, loggerhead is a seperate project
<Milo-> but 'other' needs to have access to the .bzr if 'other' wants to checkout or create its own branch out of it
<LarstiQ> eydaimon: ie, as a loggerhead package in your distribution, or launchpad.net/loggerhead
<eydaimon> ok
<eydaimon> thanks
<eydaimon> no such option --httlp so I have to upgrade bzr anyway
<LarstiQ> Milo-: I'll note it on the bug, it seems relevant
<LarstiQ> eydaimon: no, you have to install loggerhead :)
<LarstiQ> eydaimon: the --http option is provided by loggerhead, not by bzr
<LarstiQ> eydaimon: have a look at the `bzr plugins` output
<LarstiQ> eydaimon: loggerhead 1.11    Loggerhead web viewer for Bazaar branches.
<eydaimon> got it :)
<LarstiQ> eydaimon: that is included in my output
<eydaimon> thanks much
<LarstiQ> Milo-: ah, a previous reporter also mentioned it
<eydaimon> would be nice if plugins were integrated in bzr like packages.. bzr plugin install loggerhead
<Milo-> so there is hardly anything new coming from me
<Milo-> I'm also using bzr 1.14.1
<Milo-> with python 2.5.4
<LarstiQ> Milo-: can you try older versions to see if we can pinpoint when this change happened?
<eydaimon> no port for loggerhead. hm
<Milo-> I can only go back to 1.9
<Milo-> but I'll try 1.9, 1.10, 1.11, 1.12, 1.13.2 and the latest 1.15
<LarstiQ> Milo-: I'm hoping it's more recent than 1.9
<LarstiQ> Milo-: updated the bug
<eydaimon> LarstiQ: where would I make such a suggestion for feature besides here?
<LarstiQ> eydaimon: talk to bialix, iirc he did something like that in the past
<LarstiQ> eydaimon: I just do `cd ~/.bazaar/plugins; bzr branch lp:loggerhead loggerhead`
<eydaimon> good advise, thank you
<Milo-> bzr-1.9 inited .bzr with 700 :/ but it also created everything else with 700 permissions
<Milo-> same result with 1.10, 1.11, 1.12 (.bzr and its subfolders and files are created with 700 permissions)
<LarstiQ> Milo-: ok
<LarstiQ> Milo-: it did change between 1.9 and 1.10 though?
<Milo-> no
<LarstiQ> the subfolders permissions?
<Milo-> 19:01:02   Milo- >> bzr-1.9 inited .bzr with 700 :/ but it also created everything else with 700 permissions
<Milo-> so they're same as 1.10, 1.11, 1.12
<LarstiQ> vila: ^^ do you have an idea why ftp permissions on .bzr might be broken since at least 1.9? bug 326543
<ubottu> Launchpad bug 326543 in bzr "Broken permissions over FTP for .bzr/repository (and others)" [Undecided,New] https://launchpad.net/bugs/326543
<Milo-> and 1.13.2
<LarstiQ> Milo-: doh, didn't look at the correct end of the interval
<Milo-> I'll try the 1.15 as well
<LarstiQ> Milo-: 1.9 through 1.13.2 differ from 1.14.1 in the permissions of the subfolders?
<Milo-> yes
<LarstiQ> ok
<Milo-> 1.14.1 created subfolders and files with right permissions
<vila> LarstiQ: hmm, strange, all file/directories should have the same permission, that bug wasn't on my radar, I'm sure there was at least one bug, but I was convinced it has been fixed
<Milo-> hmm
<LarstiQ> vila: note, ftp, not sftp
<Milo-> actually
<Milo-> I
<Milo-> nope
<vila> yes ftp
<LarstiQ> ok
<Milo-> I'll paste you the permissions
<vila> oh wait !
<Milo-> I re-did my tests :/
<vila> ftp need server side support !
<vila> isn't there an option for that in vsftpd ?
 * vila refreshing memory a bit
<Milo-> http://codepad.org/2WQbwSQp there you have it :/
<Milo-> and those actually applies to all versions between 1.9 - 1.5 :/
<Milo-> erm
<Milo-> 1.9 - 1.15
<Milo-> so LarstiQ no, there wasn't any changes between 1.9 and 1.14.1, except I made a bad test.
<vila> chmod on ftp is implemented via the SITE CHMOD command
<vila> Milo-: Do you have *one* bzr version that produces the right permissions ?
<Milo-> no
<Milo-> portage only goes down to version 1.9
<Milo-> file_open_mode=0777
<Milo-> local_umask=0022
<Milo-> those are my vsftpd.conf's settings
<vila> Milo-: Ha, ok, then I'd say vsftpd may not respect our commands, can do a single test and look at your .bzr.log
<vila> all _setmode commands should display the permissions asked
 * LarstiQ heads to jitsu training
<Milo-> 1.826  FTP site chmod: setting permissions to 0600 on /test06/.bzr/README
<Milo-> :o
<Milo-> that's from the logs
<vila> weird
<Milo-> I'll paste it
<vila> Milo-: to the bug report ?
<Milo-> http://codepad.org/yZ9Q8HYs
<Milo-> I'm not receiving the confirmation mail :/
<Milo-> so I can't create a bug-report
<Milo-> something wrong with my email-configs
<vila> Milo-: ok, I've marked the bug as confirmed so we'll better track it from there
<vila> beuno: whoohoo, first time I update a tag in place :0)
<Milo-> something weird is happening with my domain's email settings, launchpad is the second confirmed host that doesn't send mails through my domain, microsoft is the first one.
<jam> hey vila, what are you still doing around :)
<vila> jam: hey jam ! Fixing bzr-gtk pb :-)
<jam> vila: I was curious if you had a chance to peek at the 'better_heads' code
<jam> I'm guessing not
<jam> anyway, I did an interesting check today
<jam> about how many nodes we "access" to determine heads()
<jam> and it seems that GDFO isn't helping a lot there.
<jam> It helps a little
<vila> jam: :-/ But I will spend ~4hours in the train tomorrow, your nudge came at the right momemnt :)
<jam> as we access ~86% the total nodes
<jam> (well the same number of nodes = _nodes[key] versus get_parent_map([keys]) sort of thing)
<jam> on the flip side, w/ "linear dominator"
<jam> we access only 57%,
<vadi2> Is it ok to have to commit after you do bzr merge each time?
<vila> which graph ? bzr ?
<jam> vila: right bzr.dev
<jam> when doing a "heads()" check
<jam> at merge revisions
<jam> (comparing the two merge parents
<jam> )
<jam> I'd be interested to see the effect for stuff like per-file graphs, etc
<jam> But I figured this was a reasonable start at a real-world case
<jam> I would guess that per-file graphs will be even more linear, and 'linear-dominator' will have a larger effect
<jam> vila: what happened to your patch to change GC.annotate() to use a graph on the parent_map() rather than the VF itself?
<jam> It doesn't seem to be present in my bzr.dev
<vila> huh
<jam> vila: actually, it could just be an old branch
<jam> let me check
<jam> vila: old branch, sorry
<jam> vila: anyway, linear_dominators is probably even harder to cache than GDFO
<jam> inserting a new merge child needs to invalidate any entries that were referencing the parents, etc.
<vila> jam: same complexity I'd say, and I think we need *both* anyway
<jam> vila: not at all. GDFO is only mutated by ghosts
<jam> 'linear dominator' can be invalidated by a new child
<jam> http://paste.ubuntu.com/192751/
<vila> jam: oops. yes of course, too many eggs at once
<jam> anyway, I won't distract you more
<vila> jam: let me finish my submission for bug #385191
<ubottu> Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed] https://launchpad.net/bugs/385191
<vila> jam: as a side note, either you should start writing your graphs upside-down or we should ask qlog and bzr-gtk to write theirs upside-down :-D
<jam> vila: time always flows down for me. "bzr log --forward"
<jam> I don't really care what qlog does :)
<jam> it is also a heck of a lot easier to write by adding more text below
<vila> --forward.... vade retro performance satanas !
<jam> bzr log --short --forward -r -10..-1 is perfectly fast
<vila> jam: I know your rationale :-) Just mentioning the fact that I sometimes mix things when switching my wet parser :)
<jam> vila: I suppose we just need to teach vim how to 'invert' a graph :)
<jam>  / => \ etc
<jam> and swaps the lines around
<vila> ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...
<jam> :)
<jam> I had the same problem with ^L for a while
<jam> On my Ubuntu machine, Vim had problems displaying all the text, and ^L was refresh
<vila> jam: or find the right way to inject your ascii art in dot
<jam> but in Pidgin, ^L is "clear history"
<jam> which... is painful when talking
<vila> I'm pretty at swapping ctrl and apple when switching from ubuntu to OSX but sometimes...
<vila> At least I don't mixup ctrl-backspace with ctrl-alt-backspace anymore....
<jam> :0
<vila> so, what I had in mind is caching the first children with more than one children for each revision, and yes, this may have to be updated differently, but it will also help a lot for loading graph chunks
<vila> or avoid loading them
<jam> vila: do you mean "first ancestor with more than one child"?
<vila> jam: gee, time to stop, obviously I can't think or write clearly anymore :-/
<jam> for my work, I'm tracking "oldest ancestor with only one parent and one child"
<jam> which is slightly different
<jam> but fairly important for what I'm doing
<jam> for http://paste.ubuntu.com/192784/
<jam> yours would have all of them point to A
<jam> mine has the left point to B, and the right point to C
<jam> Because heads(B, C) == heads(F, G)
<jam> (sort of)
<jam> but if you went back to A, you don't know enough
<jam> anyway, I'm willing to be flexible if we find things that work better
<jam> that seems to be working for me
<jam> I think your version could also be interesting
<jam> I would just need to think more about the implications
<vila> jam: same here (about flexibility), I need to play a bit with a couple of ideas to better *feel* the implications :-)
<vila> jam: EOD for me I need still ned to pack for tomorrow
<jam> vila: interestingly, caching the heads() for linear dominators seems to make "bzr annotate" about 38=>28s
<vila> a ga bo zu even still need to pack damn :)
<vila> in the OOo case ?
<jam> vila: in the "time bzr annotate NEWS" case
<jam> I'm sure it depends on the structure of the file
<jam> but NEWS has a lot of history, and a lot of "common introduced" lines to resolve
<jam> I'm getting 2.3M calls to heads()
<jam> hmm... only because I was accidentally combining the number of heads() calls with the number of parents stepped...
<jam> so out of 135k calls to heads(), 126k are exact repeats (calls to revisions we've already resolved), and 7.8k are calls where we already know the dominator resolution
<jam> leaving only 1.4k times that we actually need to walk the graph
<jam> which then takes 5s out of 28.5s total time...
<vadi2> How do I resolve a conflict where a file with the same name was moved into a folder with another file with the same name? content-wise, they're similar, so I merged content from one into another manually, and deleted the .moved file. however bzr still thinks there is an issue
<LarstiQ> vadi2: have you called `bzr resolve <file in question>`?
<vadi2> Think that did it. Thanks, was just using bzr resolve before
<AnAnt> Hello, I got a question
<hmeland> Are anyone else seeing "bzr pull" output like "http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/ is permanently redirected to file:///home/hmeland/.bazaar/plugins/bzrtools/" when using the current development version og bzr-svn?
<AnAnt> let's say I want to make changes to some branch lp:~user1/project
<AnAnt> so I do bzr branch lp:~user1/project
<AnAnt> which say downloads 60 MB
<AnAnt> then I do my little changes, and commit, then I want to push to my own branch: bzr push lp:~me/project
<AnAnt> will that push 60 MB to launchpad ?!
<Peng_> AnAnt: With a recent version of bzr and (maybe) a recent branch format, no.
<AnAnt> Peng_: is 1.13.1 recent ?
<AnAnt> Peng_: and what format is recent ?
<AnAnt> Peng_: is pack-0.92 a recent format ?
<AnAnt> hmmm
<Peng_> AnAnt: The feature is called stacking, and it has been supported since bzr 1.6, and the 1.6 disk formats. Newer versions will automatically upgrade the disk format. I don't know if 1.13.1 is new enough.
<Peng_> AnAnt: It probably is. Try it and see!
<AnAnt> ok
<AnAnt> thanks
<The_User> Hi!
<The_User> I think my repository is broken: bzr co file:///myrepo/mybranch
<The_User> Message:
<The_User> bzr: ERROR: Revision {<email>-<date>-<charsequence>} not present in "<file or folder>-<date>-<other charsequence>".
<The_User> When I create a new repository it works.
<The_User> The error occures in 1.14 and 1.16 (bzr snapshot)
<The_User> What could I do?
<Peng_> The_User: The developers may be able to help you, if you provide them with non-anonymized information. :P
<jelmer> mwhudson: hi
<garyvdm> Can a file id contain unicode chars - or will it all ways be ascii?
<jelmer> garyvdm: they should always be plain string objects, and afaiu they can only contain ascii characters
<jelmer> but I'm not entirely sure about that last bit
<garyvdm> jelmer - so if I have to cast from a QString - I can use str()?
<garyvdm> or should I use unicode()?
<jelmer> garyvdm: you'd want str()
<garyvdm> jelmer: Ok thanks
<jelmer> there shouldn't be a reason for file ids to ever be in a unicode object
<LarstiQ> garyvdm: you might even need to encode from a QString
<garyvdm> jelmer: I did test adding a file with unicode chars in its name - and it excluded all the unicode chars from the file-id.
<garyvdm> no - str(QString) works fine.
<LarstiQ> garyvdm: hmmm
<abentley> jelmer, garyvdm: file-ids may have unicode characters in them.
<garyvdm> abentley - oh
<jelmer> abentley: ah, ok
<The_User> @Peng_ I could provide any information but I don't think that you could read the char-sequences, it's the same with different branches but with different filenames and charsequences
<abentley> garyvdm: If you want to test what's *possible*, rather than default behaviour, use bzrlib.
<LarstiQ> garyvdm: ah, it seems str(QString) will already encode
<jelmer> abentley: but always utf8 then?
<abentley> jelmer: No, unicode.
<jelmer> abentley: I can't remember ever running across actual unicode objects for file ids in Bazaar API's
<LarstiQ> garyvdm: str(QString(u"tÃ¤hti")) â UnicodeEncodeError: 'ascii' codec can't encode characters in position 1-2: ordinal not in range(128)
<jelmer> abentley: where is that used?
<garyvdm> LarstiQ: yes
<The_User> Peng_: bzr log crashes, should I print the backtrace?
<abentley> jelmer, garyvdm: http://paste.ubuntu.com/192914/
<LarstiQ> The_User: pastebin it please
<The_User> okay
<abentley> jelmer: I don't claim it's used anywhere.
<jelmer> abentley: \u doesn't get expanded in a plain string afaik
<mwhudson> jelmer: yo
<jelmer> abentley: if I use a unicode object I get an exception about it not being a utf8 string
<jelmer> mwhudson: you were looking for me earlier, or was that about the qemu-kvm git repo?
<abentley> jelmer: Cool.  I guess they're utf-8 strings these days.
<mwhudson> jelmer: the ping was before i started sending you email
<jelmer> mwhudson: ah
<The_User> LarstiQ: Peng_: I've just removed the email, http://config.fsf.org/trac/public/pastebin/26
<LarstiQ> The_User: you missed it at the bottom of the backtrace
<The_User> LarstiQ: No, it ends with "were doing when the error eccurred"
<The_User> LarstiQ: Oh sorry, unimportant
<LarstiQ> The_User: check the KeyError
<LarstiQ> The_User: you sniped off the actual command, was it a plain `bzr log`, no other arguments?
<The_User> LarstiQ: No other arguments
<LarstiQ> ok
<The_User> all information is displayed correctly
<LarstiQ> The_User: and if you `bzr log -r revid:<that revision>` ?
<The_User> but then there is the crash
<The_User> also the checkout is executed (files get copied) but then it aborts
<The_User> same error with -r revid:
<The_User> okay the checkout just creates a .bzr directory with some empty files and directories
<The_User> I think that's interesting: bzr log -p: "bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///repo/.bzr/repository') has no revision"
<The_User> what could be broken?
<The_User> it's exactly the same with bzr branch
<LarstiQ> The_User: I'm a bit low on energy after training, sorry. Could you try `bzr reconcile`?
<The_User> what does this do?
<The_User> should I create a backup?
<The_User> reconcile works in the repo but not in the branch
<The_User> same keyerror with reconcile, check and log
<The_User> after reconcile there is only one pack-file in repository/packs
<The_User> add and commit work without any problems
<LarstiQ> The_User: meh
<LarstiQ> The_User: reconcile fixes some inconsistencies and problems like such, but apparently not this one
<The_User> :(
<The_User> thanks
<The_User> learned a new command :D
<The_User> could bzr updates be a problem?
<The_User> i mean 1.16 instead of 1.14 or something like that
<LarstiQ> The_User: shouldn't be
<LarstiQ> The_User: does it look like https://bugs.edge.launchpad.net/bzr/+bug/355951 ?
<ubottu> Launchpad bug 355951 in bzr "KeyError when getting revision history" [Undecided,New]
<LarstiQ> The_User: part of the backtrace looks similar
<poolie> good morning
<LarstiQ> hello poolie
<LarstiQ> poolie: do you maybe have time to help The_User with  http://config.fsf.org/trac/public/pastebin/26 (perhaps bug 355951 ?)
<ubottu> Launchpad bug 355951 in bzr "KeyError when getting revision history" [Undecided,New] https://launchpad.net/bugs/355951
<LarstiQ> getting things rolling atleast
<poolie> The_User: I think it is a dupe of bug 355951
<ubottu> Launchpad bug 355951 in bzr "KeyError when getting revision history" [Undecided,New] https://launchpad.net/bugs/355951
<poolie> or rather you are hitting that bug
<poolie> The_User: could you please paste your traceback onto that bug
<poolie> and probably subscribe yourself
<poolie> and then also the output from 'bzr info' on that branch
<poolie> jml: today it's all about https://bugs.edge.launchpad.net/bzr/+milestone/1.16
* poolie changed the topic of #bzr to: Bazaar version control system | 1.15.1 released 09
<poolie>           June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ |
<poolie>           http://planet.bazaar-vcs.org/
<jml> poolie: yes. :)
<poolie>           June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | today's focus: https://bugs.edge.launchpad.net/bzr/+milestone/1.16
<poolie> silly irssi
<jml> poolie: once I get out of Launchpad meetings :)
<poolie> and i filed bug 385719 :)
<ubottu> Launchpad bug 385719 in malone "hard to navigate to milestone bug page" [Undecided,New] https://launchpad.net/bugs/385719
<jml> hard. pshaw.
<jml> I do it all the time :)
 * mwhudson does it by editing the url :/
<poolie> by typing?
<mwhudson> yeah
<mwhudson> well, for launchpad-code, i have lots of launchpad-code milestones in the history
<mwhudson> so find one and change the version
<poolie> jam, are you still around? just wanted to say hi
<poolie> oh i was asking jml
<jml> poolie: front page of project -> click the link
<jml> poolie: but also URL hacking
<poolie> yeah, it's actually fairly obvious from the project homepage, but i tend to think of it as an aspect of bugs
<poolie> and from bug pages it's hard to reach
<jml> poolie: so, I'm out of LP meetings now :)
<jml> poolie: maybe we should have a call in an hour or so?
<jml> (gives me a chance to handle email etc)
#bzr 2009-06-11
<kenichi> LarstiQ: hey there, do you remember my weird negative revno issue from yesterday?  interesting fix: edit .bzr/branch/last-revision and fix the revno.  so far, that seems fix a copy of my borked repo, without taking nearly as long as 'bzr reconcile'
<igc> morning
<garyvdm> Morning igc - how did it go on Tuesday?
<garyvdm> poolie: Hi - The channel topic is still not right?
<igc> hi garyvdm. OK thanks. Tired though.
<lifeless> garyvdm: you can fix it :)
<garyvdm> Ok
* garyvdm changed the topic of #bzr to: Bazaar version control system | 1.15.1 released 09 June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | today's focus: https://bugs.edge.launchpad.net/bzr/+milestone/1.16
<poolie> hello jml
<poolie> sounds good
<poolie> jetlag-induced second breakfast has been served and eaten :)
<poolie> hello gary
<poolie> spiv, hello, do you know much about bug 385132?
<ubottu> Launchpad bug 385132 in bzr "bzr uses inaccessible, internal URL when pushing to server with host-relative default_stack_on url" [Critical,Triaged] https://launchpad.net/bugs/385132
<jml> poolie: :D
<jml> poolie: I could use a first breakfast :)
<poolie> you can do that first if you want :)
<spiv> poolie: not a huge amount
<spiv> poolie: I don't have any insights to add that aren't already in the bug comments
<jml> poolie: hi
<jml> poolie: let's talk :)
<lifeless> poolie: I love it when people comment on many year old bugs of mine ;)
<poolie> lifeless: which one?
<lifeless> 1837
<lifeless> product/bugs target to milestones page shows fixed bugs
<lifeless> at least, I think I filed it
<poolie> oh, yeah
<poolie> you did
<poolie> jml: is that really 5s lag!
<poolie> or call me at home
<jml> poolie: sure.
<jml> igc: does the branch that's in pqm now fix a particular 1.16 bug?
<igc> jml: I'm making the requested tweaks from jam's review now
<jml> igc: sweet
<igc> jml: there's a catch though ...
<jml> igc: but I'm actually just wondering if "Thu Jun 11 00:42:04 2009 UTC: Ian Clatworthy <ian.clatworthy@canonical.com>, '(igc) fix rule handling so that eol is optional' " is associated with a bug report...
<jml> igc: oh, what is it?
<igc> I'm due at the hospital in 25 minutes
<jml> :(
<igc> and I'm not going to get the tweaks finished by then
<igc> so I'll push what I can do by then but not land it yet
<jml> igc: ok. I'll see what we can do to get it landed.
<jml> (no promises though, sorry).
<jml> igc: for the record, is this for bug 362030 or bug 379370?
<ubottu> Launchpad bug 362030 in bzr "files whose content changed after EOL filtering erroneously marked as modified" [High,In progress] https://launchpad.net/bugs/362030
<ubottu> Launchpad bug 379370 in bzr "bzr: ERROR: Unknown eol value 'None'" [Medium,Fix committed] https://launchpad.net/bugs/379370
<igc> jml: it still needs a test jam has requested added.
<igc> 362030
<jml> ok.
<igc> the other one has been sent to pqm
<jml> igc: thanks.
<igc> jml, poolie: see https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/+merge/7269
<igc> the first tweak has been pushed to https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/
<igc> jml: the second tweak is an additional test which jam has basically written in his review
<igc> jml: but it needs some work because the "set rules" bit isn't quite right
<igc> jml: poolie might be able to assist you in tweaking it
<jml> igc: ahh cool.
<igc> jml: we *could* land the branch without the additional test (for now) but please don't do that unless jam or poolie agrees
<jml> igc: of course :)
<igc> jml: bzrlib/tests/workingtree_implementations/test_eol_conversion.py shows how to patch in custom rules
<igc> you can't use absolute paths but that doesn't matter
<igc> the important point is that the rules change at all
<igc> jml: ok, got to run - back in a few hours
<jml> igc: np. thanks for the help :)
<lifeless> poolie: bubg 241170
<lifeless> poolie: bug 241170. Why did you remove the milestone for when it was fixed?
<ubottu> Launchpad bug 241170 in bzr "Assertion error when trying to push" [High,Confirmed] https://launchpad.net/bugs/241170
<poolie> lifeless: the bug doesn't say it's fixed
<poolie> it says it's still open
<lifeless> oh. I'm pretty sure its lying
<lifeless> because we adjusted get_parent_map in the manner proposed
<poolie> it's not in NEWS eithr
<jml> did the Russian doc patch land?
<lifeless> true, but if you look at remote.py
<poolie> jml: i sent to pqm for the zdll fix and the smaller images
<jml> poolie: thank you.
<jml> yes, the russian doc patch landed :)
<lifeless> poolie: lets ask spiv
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> see scrollback
<spiv> I vaguely recall seeing that bug get fixed, but I'm not 100% sure.
<spiv> It only affects/ed branch format 5.
<poolie> i'll mark it fixed then
<poolie> spiv, what was the other bug you were working on on tuesday? is that now landed?
<spiv> No, although I'm about to submit a cheap fix for that.  I have a followup that removes all VFS RPCs from the "pull -r 123" case (done in an empty repo, where 123 is a revision found only in the stacked-on repo of a stacked branch).
<spiv> (18 RPCs total, down from >40)
<spiv> poolie: ah, I believe 241170 may be a dupe of 214894, which is fixed.
<spiv> Oh, although the 241170 reporter said they were using 1.5, which apparently had the 214894 fix...
<jml> I just sent a status update email for the 1.16 releaese.
<jml> would greatly appreciate it if you had a look (particularly spiv & lifeless)
<spiv> jml: is it possible to submit a lp merge directive for a specific revision (i.e. not tip) of a branch?
<jml> spiv: not through the UI.
<spiv> jml: if I do it through email will it DTRT?
<jml> spiv: it's possible that emailing a merge directive might do it.
<spiv> Ok, experiment time!
<jml> spiv: I couldn't say for sure though.
<lifeless> spiv: I think that lp is a subset of merge directives.
<lifeless> spiv: I'm not sure where the subset lines are drawn though
<jml> lifeless: I've got a few questions about this final_stack_pwd.
<jml> lifeless: where should I add the tests?
<jml> lifeless: TestSmartServerRequestBzrDirInitializeEx seems to suggest that test_bzrdir is the right place.
<jml> but in test_bzrdir, I can't see any sign of using the smart server (particularly in TestRepositoryAcquisitionPolicy)
<lifeless> are you going to be writing implementation or interface
<lifeless> tests
<lifeless> ?
<jml> lifeless: I don't know.
<lifeless> so, I don't know where the tests should go then
<jml> lifeless: I was under the impression that there were already tests for this area of functionality
<jml> lifeless: where do they live?
<lifeless> if you think you've found a misbehaving implementation where tests for the behaviour are either broadly irrelevant or hard to exercise on other implementations, then I'd write implementation tests
<lifeless> if you can write the tests as generic exercise-of-interface then interface tests
<spiv> jml: hah, the answer is both yes and no: https://code.edge.launchpad.net/~spiv/bzr/stacking-friendly-revision-history-verb/+merge/7314
<spiv> jml: the diff in my email is included and shows the intended content (only 4 revs worth)
<spiv> jml: but there's a generated diff from lp linked on that page with too much history, and lp is listing all the revs in that branch as unmerged in this proposal.
<jml> spiv: good to know :)
<lifeless> bzrlib/tests/bzrdir_implementations/test_bzrdir.py +1166
<lifeless> jml: the interface is 'initialize_on_transport_ex'
<jml> lifeless: thanks. I gather those tests run against every implementation?
<lifeless> yes
<lifeless> they run against a current and an older protocol version of the smart server too
<jml> cool.
<jml> so if the bug is actually in SmartServerRequestBzrDirInitializeEx then a properly written test ought to trigger it?
<lifeless> well
<lifeless> I think we should pin down the contract
<lifeless> so yes
<lifeless> unit tests for smart server verbs are in
<lifeless> bzrlib/tests/test_remote.py +744
<jml> test_smart
<jml> oh, test_remote
<lifeless> there's history here. Don't look under the curtain
<jml> ok.
<spiv> Well, test_smart.py is unit tests for the server-side.  test_remote.py is unit tests for how the client-side Remote* classes interact with the network.
<jml> looking at BzrDir.initialize_on_transport_ex...
<jml> the docstring says that stacked_on=None implies following the target's stacking policy.
<jml> I guess that means that stack_on_pwd is ignored in that case.
<lifeless> spiv: and server side unit tests.
<lifeless> spiv: they are there, existence proof :P
<lifeless> jml: look at bzrlib/bzrdir.py +3150
<lifeless> jml: did that help?
<jml> lifeless: probably :)
<jml> lifeless: still paging all of this stuff in.
<spiv> lifeless: hmm, some tests there do create actual servers rather than using test doubles, but AFAICT the primary purpose of all the tests in test_remote is to test client-side behaviour.
<lifeless> spiv: you're likely right
<eydaimon> i've done a bzr revert to an earlier revision... how can I do a diff against the latest revision if I didn't know what the rev number is? I was thinking something like bzr diff -r head file
<poolie> diff runs against the branch's tip
<poolie> so just 'bzr diff' will show the difference
<eydaimon> so bzr diff -r tip head?
<eydaimon> oh ok
<eydaimon> out of curiousity, is there a way to specify tip?
<poolie> -r head: i think
<spiv> Or -r -1
<poolie> jml, i think i'ts ok to slep bug 284038 though i also think it's a mysql bug and deserves a little extra effort
<ubottu> Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038
<poolie> oh of course
<eydaimon> -1 works
<poolie> jml, bug 380314 i think is critical to use with launchpad?
<ubottu> Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,In progress] https://launchpad.net/bugs/380314
<spiv> It breaks "bzr pull -r 123"
<poolie> i may try bug 385453
<ubottu> Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453
<spiv> (on stacked branches)
<spiv> Which is pretty serious, I think.  The fix is up for review now.
<jml> poolie: re 284038, it'd definitely be great to get it in, yes.
<jml> poolie: likewise for the 'make dist' bug, but imo format bump & reviewing existing patches (like spiv's) take precedence.
<spiv> jml: fwiw I don't have anything to add to your status update email (other than pointing out that my fix is now up for review, which you already know)
<poolie> jml, spiv, how about bug 381329 - is that in trunk? in 1.15 (where it's targetted)
<ubottu> Launchpad bug 381329 in bzr "Some expected smart server errors cause client tracebacks" [Critical,Fix committed] https://launchpad.net/bugs/381329
<spiv> poolie: yes, the 1.15 patch was a direct cherrypick off trunk.
<poolie> so i'll mark it released in 1.16 too?
<poolie> done
<igc> jml: back. I'll keep working on that tweak assuming no-one has picked it up
<jml> igc: cool :) as far as I know, no one has.
<poolie> jml: format added, am going to do some adhoc testing
<poolie> including upgrading to it from dev7
<poolie> will put it up soon
<jml> poolie: thanks.
<lifeless> poolie http://cworth.org/intel/driver_stability/
<igc> poolie: be sure to check upgrading from dev6 too
<poolie> yeah, and on a small one upgrading from something earlier
<lifeless> jml: so tell me when you're  looking at stacking
<igc> poolie: there were some problems with that a few days ago
<igc> which I think jelmer or jam might have fixed since
<poolie> i might get some lunch first though
<jml> lifeless: now :) http://paste.ubuntu.com/193156/ -- that's the test I just finished.
<lifeless> poolie: I've lost the bazaar-announce moderator password again.
<jml> lifeless: any comments on that validity of that test?
<lifeless> bad:  except errors.BzrError:
<lifeless> jml: asking for 1.9 is problematic
<lifeless> jml: I suggest being a little bit more complex:
<lifeless>  - make a control dir without specifying format, which will use the parameterised format
<lifeless>  - if that is a bzrdirmeta1 then hard code 1.9
<lifeless>  - otherwise use whatever branch format that the test makes by default
<lifeless> it looks broadly fine though
<jml> lifeless: you mean a control dir at the 'stack-on' location?
<lifeless> jml: or even a third location
<jml> ok.
<jml> I'm not sure how to avoid the BzrError.
<lifeless> its too generic
<lifeless> its like catching Exception
<jml> three of the formats simply raise a BzrError when calling set_default_stack_on.
<lifeless> mmm
<jml> BzrError: Cannot set configuration in <bzrlib.bzrdir.BzrDir5 object at 0x6bb7350>
<lifeless> oh
<jml> I guess I can check the str() of the exception.
<lifeless> then its fine
<lifeless> but please make it more specific
<lifeless> don't chain the calls so deep
<lifeless> config = self.make_bzrdir('.').get_config()
<lifeless> try:
<lifeless>     ...
<jml> *nod*
<lifeless> except BzrError:
 * spiv -> food
<GPHemsley> Ugh... who do I have to poke to get an up-to-date Mac OS X package?
<GPHemsley> Preferably, a package that works
<GPHemsley> Because my lack of a working subvertpy seems to be causing trouble
<GPHemsley> Not to mention that rebase is apparently out of date, too
<GPHemsley> Looking for 1.13.0 when 1.15.0 is required
<GPHemsley> Well, downgrading to 1.14.1 at least gets rid of the rebase error
<poolie> lifeless: you can call me about format naming if you want
<poolie> or we can talk here
<lifeless> poolie: either is fine
<poolie> if we're miscommunicating
<lifeless> poolie: I'm filing the bugs we talked about at the moment, just takes a while to make sure htey aren't dups
<poolie> there's no super rush
<poolie> i am going to put this patch up in a bit, taking teh approach i outlined
<lifeless> I think if we're making it supported in 1.16, we should put 1.16 in the version string
<lifeless> my key point is that I *know* have a code change which requires a string bump but no disk changes
<lifeless> s/no disk/no other disk/
<poolie> what is that change?
<lifeless> fixing the rich root additions the streaming fetch code sends
<lifeless> Its the one I mentioned in the thread
<poolie> jml, both the smaller images and the zdll fix landed
<mwhudson> .oO(will brisbane-core make a difference to how much i exceed my download cap each month...)
<lifeless> poolie: house phone is out of juice
<jml> poolie: thanks.
<jml> lifeless: fwiw, I'm now stumped on the actual fix to the stacking bug. I'm off to get lunch, should be back in ~20mins.
<jml> poolie: I just have you down for the format name thing -- is that your understanding too?
<poolie> yes
<jml> cool.
<lifeless> poolie: I'm assuming that was you ringing
<poolie> lifeless: so to me it doesn't make any sense to say it's the same format on disk but it needs a new number
<poolie> it was
<lifeless> poolie: other suggestions to stop broken code writing to this format appreciated
<poolie> is there a bug for this?
<lifeless> 13:41 < lifeless> poolie: I'm filing the bugs we talked about at the moment, just takes a while to make sure htey aren't dups
<lifeless> (no not yet)
<poolie> by which i mean, what broken code are you talking about?
<lifeless> there was but I think it got closed when 1/2 the code got fixed
<lifeless> because the test suite will fail when we fix the dependent issues
<poolie> if using 1.16 to fetch into this format will lose data then that's a blocker for doing this release at all
<poolie> if this release is ok, but you want to change the way things are represented in future, then i'd say that really is a change to the ondisk format
<lifeless> It won't, because IDS will take over. It will just take hours to pull over the network.
<lifeless> poolie: its neither of those cases.
<igc> jml: those tweaks are now done. Just running the test suite and I'll submit it to pqm
<jml> igc: thanks.
<GPHemsley> How do you change repo formats?
<GPHemsley> I forget the command
<jml> bzr upgrade
<GPHemsley> hmm... I should've thought of that
<GPHemsley> but thanks :)
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374735
<ubottu> Launchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [Critical,Triaged]
<jml> :(
<poolie> jml, lifeless : https://code.edge.launchpad.net/~mbp/bzr/385103-format-name/+merge/7321
<poolie> comments on NEWS especially welcome
 * jml waits for the diff to generate
<lifeless> poolie: 2a - not 2s-rich-root?
<lifeless> s/s/a
<lifeless> poolie: not every format is listed by bzr init --help IIRC
<lifeless> poolie: its controlled by data on the formats
<lifeless> poolie: IMBW
<poolie> s/every/lots of/ :)
<bob2> is there some way to get a full diff of a merge req on lp?
<poolie> and i think we need to get away from having -rich-root  in the name
<poolie> we need to do it sometime
<poolie> now's a good time
<poolie> bob2 there's a link to download it
<lifeless> poolie: I think we should for 2.0 release
<lifeless> poolie: I think you should try working with a bzr tree in 2.0 and see what users get told about the incompatibilities before deciding that we're ready to make it less scary
<poolie> i'm upgrading now
<lifeless> in particular interacting with the rest of the community
<poolie> i'm happy to tweak that text to make it more constructively scarey
<lifeless> I don't think people will read the text
<poolie> or the short format description
<lifeless> indeed
<lifeless> often people will just see 'run bzr upgrade --FOO'
<lifeless> based on previous observation.
<lifeless> Its safer to say 'this is safe to do with [x] conditions' when the string is scary, than is is to say 'this is scary unless [x] conditions' when the string looks safe.
<poolie> jml, thumper, do either of you want to talk?
<poolie> lifeless: possibly we should say interactively "do you really want an experimental format"?
<poolie> we could print a warning but if you just did an upgrade it may be too late
<jml> poolie: yes. :)
<poolie> i'm open to changing the ui name to say 2a-beta
<bialix> garyvdm: still here?
<garyvdm> bialix: Yhea - but not for long - I've been up all night :-)
<lifeless> poolie: I don't think that is enough. Also showing a interactive question would seem to me to be further away from what you seem to want than 2.0-rich-root would be.
<lifeless> poolie: I'm not sayin the disk format needs to mention rich roots.
<bialix> garyvdm: almost the same
<bialix> Gary, I'm planning to make release today
<bialix> it's ok to using current trunk?
<lifeless> poolie: fwiw bug 368921 was the IDS version of the bug with the network server
<ubottu> Launchpad bug 368921 in bzr "rich root upgrade adds inconsistent parents/rich root parents are not evaluated correctly." [Critical,Triaged] https://launchpad.net/bugs/368921
<garyvdm> bialix: Cool - I did see you mail. Yhea - there are no bugs/regressions I'm am aware of.
<garyvdm> bialix: I've got some stuff I'm holding off till you release.
<bialix> gayvdm: I have one question about next one release. It seems we will release next release in sync with bzr 2.0
<bialix> garyvdm: I can use separate release branch, so you don't need to hold off
<poolie> hello gary, bialix
<bialix> I need only finish new Inno Setup based installer
<bialix> poolie: good day
<garyvdm> bialix: Don't worry - It probably not even ready for trunk yet.
<garyvdm> Hi poolie
<bialix> garyvdm, poolie, luks, igc: I'm thinking about calling next qbzr release as 1.0
<bialix> this is very interesting opportunity
<igc> bialix: as in the one after today's?
<bialix> igc: the one in next month
<igc> bialix: right, so qbzr 1.0 ships with bzr 2.0
<bialix> yes, exactly
<bialix> recently jelmer asked about releasing bzr-svn as 1.0
<igc> bialix: that would be good I think
<garyvdm> bialix: I think we should wait untill qmain is finished.
<bialix> garyvdm: do you see bzr-explorer?
<igc> bialix: Javier will hopefully be adding some more q* commands in coming weeks, e.g. qsend, qexport
<garyvdm> bialix: yes - and I have to chatting alot to igc about it.
<bialix> Gary, I know we have a lot of unfinished stuff
<igc> bialix: and I have plans for putting some together over nights/weekends too, e.g. qbind
<garyvdm> bialix: we should probably test if bug 385550 also affects the bzr installer.
<ubottu> Launchpad bug 385550 in qbzr "Unexpected error when uninstalling QBZR " [Critical,Confirmed] https://launchpad.net/bugs/385550
<bialix> garyvdm: no
<bialix> bzr.exe installer uses Inno Setup.
<bialix> I wrote it
<bialix> qbzr installer wrote luks
<igc> bialix: any chance qversion will make the cut this time around?
<bialix> I never used NSIS myself
<garyvdm> bialix: Ok then it really makes sense to use Inno.
<bialix> igc: there is some layout problems with your dialog
<bialix> I'll plan to fix it after 0.11
<bialix> maybe tomorrow
<igc> bialix: ok
<igc> bialix: also, thanks for the qview to qviewer change
<igc> bialix: do we need to tweak TortoiseBzr accordingly?
<bialix> igc: what's your vision of annotate in explorer? this command require filename as argument
<bialix> igc: I've checked tbzr trunk: qviewer is not used there
<igc> bialix: I'll probably drop it from the menu in the short term ...
<bialix> it seems last time Mark Hammond touches the tbzr this winter. and then disaooear
<igc> and expect people to reach it via qbrowse say
<bialix> poolie: does Mark was contractor?
<pygi> bialix: yes, he was a contractor
<garyvdm> igc, bialix: or qlog
<pygi> but he's god a full time job now afaik, so he isn't as available
<igc> garyvdm: right
<garyvdm> igc: My 2c about qversion: it would be nice if bzrlib could give us rst which we could convert to html and display in a QTextDocument
<bialix> garyvdm: browse see,s more appropriate
<bialix> seems
<garyvdm> igc: and bzr cli should also use the rst converted into plain text?
<bialix> garyvdm: no
<pygi> oh noes, garyvdm with his qlog :P
<bialix> no need for rst right now
<garyvdm> Hi pygi
<garyvdm> bialix, igc: Ok but I would like to see qbzr more common with bzr cli.
<bialix> so, without Mark it seems like tbzr will stalled
<garyvdm> just my 2c..
<bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/273847
<ubottu> Launchpad bug 273847 in qbzr "[todo] simple and lightweight rst2html engine needed for qhelp" [Low,Confirmed]
<bialix> have not ime for this
<garyvdm> bialix: I did start doing some work on tbzr - but you convinced me to refocus on qmain :-)
<bialix> garyvdm: there is a lot of hard work for tbzr, especially because it affects entire windows performance
<garyvdm> Yhea
<bialix> we can implement qmain much faster
<garyvdm> And we can do much more interesting things with qmain...
<bialix> but I see bzr-explorer as qmain 0.5 ;-)
<bialix> exactly
<bialix> I'd like to implement projects support
<igc> bialix, garyvdm: my main desire for tbzr is to tweak the menu to reflect the one we're using in Explorer & qbzr-eclipse
<bialix> ok, so today it's too early think about 1.0 date
<bialix> np
<bialix> pygi: what's wrong with either gary or qlog? ;-)
<garyvdm> I think so
<poolie> i think it would be cool to do a 1.0 at the same time
<poolie> i'm using it a bit; i haven't dived straight in as much as ian has
<poolie> i probably should
<fullermd> Hm.  I like how selftest has a --parallel option that takes various values, and doesn't give any hint as to what the possible values are.
<garyvdm> Gary will show anybody that give him 2sec qlog's features :-)
<poolie> speaking of which, hopefully he'll be around moer in future
<igc> poolie: have you tried explorer yet?
<poolie> no, good idea though
<bialix> igc, btw we have nice working tree widget that could be used in bzr-explorer to show status
<lifeless> poolie: so actual review comment added
<igc> poolie: it's making progress most weekends
<lifeless> poolie: but my prior comments still stand
<bialix> garyvdm: maybe if explorer will be pretty usable we can talk about calling qbzr+explorer as qbzr 1.0
<bialix> garyvdm: one more question, if you can
 * igc returns to reviewing jam's iter-nodes patch before he falls aslepp
 * igc afk
<garyvdm> bialix ?
<pygi> bialix: nothing, I like joking with him xD
<poolie> jml, filex bug 381814
<ubottu> Launchpad bug 381814 in netbeans "Netbeans 6.7 in Karmic" [Undecided,New] https://launchpad.net/bugs/381814
<bialix> garyvdm: can we chat one day when we both will have enough free time and not be up all the night about alog internals? maybe on some weekend? I have troubles to understand all details, but I'd like to. I have some ideas about adding unit tests to qlog internal engine
<poolie> or not
<poolie> bug 385814
<ubottu> Launchpad bug 385814 in launchpad-code "it would be nice to show targeted bugs in code review listing" [Undecided,New] https://launchpad.net/bugs/385814
<poolie> only wishlist i think
<jml> poolie: yeah, except for reasons I don't understand, we don't use wishlist, just low.
<bialix> garyvdm: I'm mostly asking beforehand because it's hard for me to catch you in IRC
<poolie> i didn't file it
<poolie> i mean i didn't rank it, i'll let that team do it
<jml> oh thanks :)
<garyvdm> bialix: Ok - I started with tests for qlog at uds - there is just so much to test.
<bialix> I need to understand your design first
<garyvdm> I'll keep chipping away at it.
<bialix> there is too little comments
<garyvdm> :-(
<AfC> Am I correct in understanding that there's no release of bzr-gtk that works with bzr 1.15.1?
<AfC> (if so, pity)
<bialix> garyvdm: mostly it's my problem, in my head
<bialix> so I need some initial guidance
<bialix> e.g. what is msri means, etc.
<garyvdm> bialix: ok - questions at the moment?
<bialix> perhaps it's very obvious for you
<bialix> no
<garyvdm> Ok - there is a comment for that - I think
 * garyvdm checks
<bialix> one more question:
<bialix> you recently changed signals for finsihed/failed/errors
<bialix> but all dialogs now require uodate to use new signals
<bialix> update
<bialix> IMO there is need for another refactoring
<bialix> GAry, we need to chat more often
<bialix> ok, this was last question
<garyvdm> Hmm - can't find a comment about msri.
<bialix> me too
<lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/385815
<ubottu> Launchpad bug 385815 in launchpad-code "need a way to upgrade a project past the rich root border" [Undecided,New]
<lifeless> poolie: ^
<garyvdm> Ok it stands for merge_sorted_revisions_index
 * bialix notes
<garyvdm> There are 2 types of indexes - before its filtered - msri and after - just called index
<bialix> so msri represent a graph?
<poolie> jml, igc points out that i also need to specially test upgrading dev6 to dev7
<poolie> jelmer may have a patch for this
<garyvdm> an index for a revision in merge_sorted_revisions
<AfC> I guess we'll have to downgrade to bzr 1.14.1. Again.
<bialix> AfC: qbzr has compatible releases
<AfC> bialix: that is profoundly fascinating.
<poolie> igc could you read just the news in https://code.edge.launchpad.net/~mbp/bzr/385103-format-name/+merge/7321
<bialix> :-P
<poolie> oeuthaouth
<hchen59> Hi, one question: I downloaded .tar.gz file from one project in http://bzr.linuxfoundation.org/unofficial/, extracted to local disk, I found no files except .bzr directory. I tried several bzr commands, while failed to extract version from local bzr repository( some big files in .bzr/repository/indices, I think they are local repository). So which command I should use to extract files? Thanks
<bialix> bzr co
<hchen59> [root@hchen59 ispras-moblin-misc-test]# bzr co
<hchen59> bzr: ERROR: File exists: u'/home/git/ispras-lsb/ispras-moblin-misc-test/.bzr': [Errno 17] File exists: '/home/git/ispras-lsb/ispras-moblin-misc-test/.bzr'
<bialix> what tell you `bzr info`?
<hchen59> [root@hchen59 ispras-moblin-misc-test]# bzr info
<hchen59> Standalone tree (format: pack-0.92)
<hchen59> Location: branch root: .
<lifeless> hchen59: run 'bzr checkout .'
<hchen59> Related branches: parent branch: /home/git/ispras-lsb/misc-test
<jml> spiv: btw, what's the status of that RPC bug?
<hchen59> [root@hchen59 ispras-moblin-misc-test]# bzr checkout .
<hchen59> bzr: ERROR: File exists: u'/home/git/tmp/ispras-moblin-misc-test/.bzr': [Errno 17] File exists: '/home/git/tmp/ispras-moblin-misc-test/.bzr'
<bialix> hchen59: what `bzr status` say?
<spiv> jml: it's a small patch (100 line diff), still waiting for review.
<jml> spiv: ta.
<hchen59> bzr status => list a lot of files: " removed: ....."
<jml> spiv: poolie offered to review it on our recent phone call.
<jml> hchen59: 'bzr revert'
<poolie> igc, wow, that's pretty cool!!
<poolie> igc: what does 'settings/ignores' do?
<poolie> i thought it'd change the .bzrignore file but apparently not?
<igc> poolie: edits the per-user ignore file
<lifeless> totally freezing cold
<igc> poolie: editing of branch-specific config files is coming this weekend
<poolie> :)
<jml> lifeless: I've got further, but I'm now blocked again.
<igc> poolie: along with a nicer status display
<lifeless> jml: talk to me
<hchen59> great... bzr revert works, files extracted. While it would revert to version before ? how to check current bzr version?
<poolie> it'd be nice to be able to see unmodified files too
<poolie> as a way to kick off editing them
<igc> poolie: right
<jml> lifeless: fetch lp:~jml/bzr/default-stacking-bug-385132 and take a look at the diff.
<lifeless> hchen59: it looks like whoever made the tarball was a little unused to bzr
<jml> (or give me a moment to do paste shenanigans)
<lifeless> I have it
<jml> http://paste.ubuntu.com/193242/ -- the failure I now get
<jml> I've made one of the two blackbox tests pass.
<igc> poolie: try https://code.edge.launchpad.net/~jameinel/bzr/1.16-chkmap-updates for a preview of the status display coming
<igc> bialix: ^^^
<bialix> igc ?
<igc> poolie: sorry, wrong paste ...
<hchen59> ok, i see, for current bzr revision, I just bzr log, and check top one, right?
<lifeless>              final_stack_pwd = response[9] or None
<lifeless> +            if final_stack_pwd:
<lifeless> +                final_stack_pwd = transport.abspath(final_stack_pwd)
<lifeless>              remote_repo = remote.RemoteRepository(repo_bzr, repo_format)
<igc> bialix, poolie: lp:~ian-clatworthy/bzr-explorer/better-wt-view
<jml> yeah, that won't work if final_stack_pwd is an absolute url, IIUC.
<lifeless> abspath('') != '', I think
<bialix> ok!
<jml> lifeless: that's why it's guarded?
<igc> bialix: ui not hooked up to a model yet
<fullermd> What's the difference between a selftest FAIL and ERROR?
<jml> fullermd: FAIL = failed assertion
<jml> fullermd: ERROR = unexpected error
<lifeless> jml: paging in
<jml> lifeless: ta
<lifeless> jml: I think we serialise None as '', so thats why
<fullermd> So either one is bad.  Lovely.
<hchen59> Thanks guys
<jml> lifeless: bool('') is False, so the line above will guarantee it's None, and the if will make sure abspath is called only if it's a non-empty string.
<lifeless> jml: so
<lifeless> Is 'extra' well, extra?
<jml> lifeless: I'm not sure what extra is there for. It's part of the smart server test fixture, afaict.
<lifeless> right
<lifeless> so the path shouldn't be showing
<igc> poolie: so the most important part of explorer so far is the "Bazaar" menu - that's what's going in qbzr-eclipse and (hopefully) TortoiseBzr soon
<jml> it's in the test because the external URL is bzr://localhost:NNNN/extra/stack-on
<igc> poolie: and one other thing, if you have bzr-gtk installed, try ...
<igc> bzr explorer --gtk
<lifeless> jml: no
<igc> that runs the gtk applets instead of the qbzr ones
<lifeless> +        self.make_branch('stack-on', format='1.9')
<spiv> The smart server test support intentionally sets up a server with 'extra' as part of the path the flush out some path translation issues.
<lifeless> The set_default_stack_on is setting a bad path
<lifeless> it should set '/stack-on'
<lifeless> jml: or listen to spiv :)
<lifeless> jml: specifically, "chroot-93074512:///extra/stack-on/"  is not valid in the chroot
<jml> http://paste.ubuntu.com/193245/
<jml> there's the error without it.
<lifeless> jml: thats better; thats a client side issue
<lifeless> jml: so lp sets abs paths?
<spiv> jml: you may find -Dhpss -Eallow_debug makes the test output more helpful (or merely more verbose)
<lifeless> spiv: IIRC server/extra == '/' in the chroot ?
<spiv> lifeless: right
<lifeless> jml: so the http://paste.ubuntu.com/193245/ case is more correct
<jml> http://paste.ubuntu.com/193248/ -- more debug output
<lifeless> jml: it means that path translation is not being done correctly.
<jml> lifeless: ok.
<lifeless> jml: specifically, '/foo/bar/' in the chroot needs to be turned into '../foo/bar' or something similar
<bialix> igc: nice
<lifeless> server side
<lifeless> because / is not really an absolute url
<bialix> igc: new wt view is nice
<igc> bialix: thanks
<lifeless> jml: there is code to do this, let me dig a sec
<jml> lifeless: at the moment I'm doing:
<jml>             final_stack_pwd = urlutils.relative_url(
<jml>                 target_transport.base, repository_policy._stack_on_pwd)
<spiv> So the server says the final_stack_pwd in the result is /stack-on, where the right answer would be /extra/stack-on (or perhaps a path relative to the path of the request).
<lifeless> spiv: extra isn't known by the server
<lifeless> spiv: has to be relative
<spiv> Sure.
<lifeless> spiv: its an aspect /of/ the server. Think http mapped servers
<spiv> Btw, SmartServerRequest.translate_client_path has one direction of this.
<lifeless> repo_relpath
<jml> spiv: how do I dump stuff into the debug log?
<lifeless> bzrlib/smart/bzrdir.py +84
<lifeless> jml: debug(...)
<lifeless> or mutter I think
<spiv> Requests actually know the /extra, IIRC, it's stashed in self._root_client_path or somesuch.  But as lifeless is saying you can only adjust for paths inside requests, if the request itself was addressed to one HTTP URL by the client then the HTTP server did magic before handing it off to bzr we don't necessarily know about that...
<spiv> (Although I believe HTTP servers can pass that info along to the bzr-wsgi glue, perhaps not heavily tested though)
<spiv> jml: I generally use (bzrlib.trace.) mutter
<fullermd> Last time I looked at setting up bzr+http, it occured to me that I was gonna need a crappile more path translation smarts than I had the slightest idea how to put in place   :|
<lifeless> fullermd: it is documented
<fullermd> Only AIR in a way that makes sense if all requests are rooted at the same place.
<lifeless> spiv: wsgi can do it but its fragile and best to avoid IMO
<jml> 2.896  target_transport.base: chroot-96675856:///to/
<jml> 2.896  repository_policy._stack_on_pwd:chroot-96675856:///
<jml> 2.897     result:   ('.', 'no', 'no', 'yes', 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n', 'Bazaar-NG meta directory, format 1\n', 'Bazaar-NG meta directory, format 1\n', 'True', '/stack-on', '..', '')
<spiv> lifeless: I meant specifically the bzrlib's wsgi app, rather than wsgi intrisically.
<lifeless> spiv: so did I
<lifeless> spiv: :P
<fullermd> But when /x and /y aren't peers...
 * fullermd watches selftest wind down.
<lifeless> fullermd: there is a limit to magic, obviously.
<jml> lifeless: so you can see that's returning a relative stack_on_pwd
<fullermd> Yah.  But withotu breaking that limit, it won't do what I want, so it doesn't run.
<lifeless> jml: no
<lifeless> jml: the leading / is the problem
<jml> but the stack_on.startswith('/)
<lifeless> jml: you need the code from _repo_relpath
<lifeless> jml: oh yes, indexed variables suck yada yada
<fullermd> Well, that was "fun"...
<fullermd> FAILED (failures=12, errors=84, known_failure_count=12)
<fullermd> 2039 tests skipped
<lifeless> jml: anyhow; the way those two variables interact isn't something I totally get. I didn't write it ;)
<jml> lifeless: me neither. ISTR that 'stack_on' is what's actually in the config file & 'stack_on_pwd' is how it should be interpreted.
<lifeless> jml: I think so
<lifeless> anyway
<lifeless> with a smart server a non-abs url isn't usable
<lifeless> and a root relpath fragment isn't usable either
<lifeless> so I think
<lifeless> if stack_on and stack_on[0] == '/': # fix up
<lifeless>     segments = ['..' * len(stack_on.split('/'))
<lifeless>     stack_on = '/'.join(segments + stack_on.split('/'))
<lifeless> vaguely
<jml> and what for stack_on_pwd?
<lifeless> dunno
<lifeless> see what happens first
<jml> snrk
<jml> ok
<lifeless> my emulator is too small
<jml> http://paste.ubuntu.com/193256/
<jml> I think maybe all of the ../ should go into stack_on_pwd
<lifeless> jml: looks like we need to say that if stack_on == '/', stack_on_pwd should be ''
<lifeless> or '.'
<lifeless> jml: no, because if stack_on == '/'+ anyything, stack_on_pwd is ignored
<jml> lifeless: stack_on_pwd = '' -> http://paste.ubuntu.com/193258/
<jml> stack_on_pwd = '.' -> http://paste.ubuntu.com/193259/
<lifeless> stack_on has too many ..'s
<lifeless> uhm
<igc> jml, jelmer: see http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090605165828.GA4605%40vernstok.nl%3E
<lifeless> perhaps stack_on_pwd should be used to normalise stack_on somewhat
<lifeless> that is, the ..'s from stack_on_pwd shrink stack_on
<jml> lifeless: something like this? http://paste.ubuntu.com/193260/
<jml> (it doesn't work of course. sanity checking)
<lifeless> no
<lifeless> you're replacing the pwd with the ..'s from the stack_on
<lifeless> I mean adjust by
<lifeless> so segments = ['..'] * (len() - stack_on_pwd.count('..')) #sketch
<lifeless> thats clearly wrong; presumably we have a path joining function somewhere
<spiv> (not following closely, but there's urlutils.pathjoin)
<lifeless> jml: or the stack_on version we had before
<lifeless> jml: with stack_on = pathjoin(stack_on_pwd, stack_on)
<lifeless> and stack_on_pwd = '.'
<jml> so, stack_on_pwd = '.', and then calculate how to get from target_transport.base to /foo/bar/baz as a relative path.
<lifeless> jml: no. I think you've gottenconfused.
<lifeless> jml: we have two inputs
<lifeless> stack_on and stack_on_pwd
<lifeless> we know that combining them in the server chroot works
<lifeless> we want two outputs
<jml> so far I am with you.
<lifeless> such that combining those two and the clients url for the bzrdir we created will will work from the client
<lifeless> there are several options here
<lifeless> I need to call it 'done' for the day; possibly the most simple thing is to say
<lifeless> '/' stack_on paths are not usable in the smart server. When we see one we will take the transport to the thing we stacked on and transform it as per _repo_relpath
<lifeless> so toss out all the data
<poolie> jml, are you referring to spiv's patch for bug 380314?
<ubottu> Launchpad bug 380314 in bzr "Branch.revision_history RPC fails on a stacked branch" [High,In progress] https://launchpad.net/bugs/380314
<jml> poolie: that one, yes.
<spiv> poolie: diff viewable at https://code.edge.launchpad.net/~spiv/bzr/stacking-friendly-revision-history-verb/+merge/7314
<jml> igc: did you end up doing your eol tweak?
<lifeless> jml: anyhow, there are several ways you could do it. I don't have a preference.
<jml> lifeless: ok, thanks.
<jml> lifeless: I'll figure something out.
<igc> jml: yes. It's landed I believe
 * igc checks
 * jml checks too
<mwhudson> jml: how do you get -D hpss like stuff in the selftest's .bzr.log ?
<mwhudson> i thought it was -E hpss
<jml> igc: should I mark https://bugs.edge.launchpad.net/bzr/+bug/362030 as Fix Released then?
<mwhudson> but that doesn't seem to be it
<ubottu> Launchpad bug 362030 in bzr "files whose content changed after EOL filtering erroneously marked as modified" [High,In progress]
<jml> mwhudson: -Dhpss selftest -Eallow_debug
<mwhudson> ah
<mwhudson> ta
<igc> jml: just did it - thanks for reminding me
<jml> igc: cheers.
<poolie> jml, spiv, review done
<poolie> and S says "get ready!"
<poolie> so i will
<spiv> poolie: thanks
<jml> poolie: thanks!
<jml> poolie: have a good evening :)
<jml> just requested bzr branch be mirrored immediately
<jml> yay
<poolie> 2a format sent to pqm
<igc> night all - good luck jml with the release
<jml> igc: g'night.
<jml> igc: thanks for your help :)
<poolie> the launchpad workflow for bugs and code reviews is getting really nice
<poolie> it could be even better but it's pretty helpful
<jml> yeah.
<spiv> jml: have replied to poolie's review, will do the minor tweaks and send to PQM
<jml> spiv: music to my frosty ears
<lifeless> poolie: I'm still really concerned that people will try 2 and then be wedged irrecoverably
<lifeless> vila: jml: re bialix's reported problem can you clarify.
<jml> lifeless: running the script client side only affects the upload copy of the branch
<spm> spiv: pqm is still working for you then?
<jml> lifeless: it won't affect the mirrored copy.
<lifeless> jml: but the mirrored copy is only accessed over http right?
<spiv> spm: we will find out shortly!
<jml> lifeless: it's also accessible over bzr+ssh & sftp
<lifeless> sftp like http is VFS anyway
<jml> lifeless: where you'll get the mirrored copy iff you lack write access to the branch.
<lifeless> ok
<lifeless> so this raises the 'when is lp bulk fixing things'
<lifeless> question
<jml> yes.
<lifeless> ok
<lifeless> well, i'm going to ring poolie quickly and then -> gone
<jml> ok.
<jml> thanks for the help w/ the release.
<lifeless> np
<lifeless> jml: are you cuttting the release tonight?
<jml> lifeless: yes.
<lifeless> jml: or do you think it will be tomorrow? I have a change I want to make that poolie and I don't quite agree on.
<spiv> spm: my merge request just came and went in a flash...
<jml> lifeless: it's got to be tonight, I'm afraid.
<jml> or rather.
<jml> it's got to be the 11th.
<lifeless> what happens on the 12th?
<lifeless> anyhow, you're doing rc1 right?
<fullermd> A plague of locusts o'er the land.
<lifeless> jml: ^
<jml> lifeless: yes, rc1
<lifeless> we can always change it between rc and release
<lifeless> so don't block on this
<jml> lifeless: great news :)
<tmetro> What's the best way to get in touch with the maintainer of the bzr packages on backports.org? I suspect the Debian packaging tools view version 1.5 as newer than 1.13. Although it looks like 1.13 has been around since April, so I would have expected someone to notice this before now.
<lifeless> tmetro: dpkg considers 1.5 < 1.13
<lifeless> tmetro: there used to be contact details on backports.org
<lifeless> a bug tracker of some sort
<tmetro> Hmmm...I have 1.5 installed, even though I have backports as a repository. It doesn't think there is a newer version. Trying to explicitly install bzr=1.13.1-1~bpo50+1 results in:
<tmetro> bzrtools: Depends: bzr (< 1.6~) but 1.13.1-1~bpo50+1 is to be installed.
<tmetro> OK, I can check backports.org, if they're the responsible party for creating the builds, and not just hosting them.
<lifeless> tmetro: they certainly are.
<tmetro> ok, thanks.
<fullermd> tmetro: Er, that's telling you your installed bzrtools won't work with 1.13.1
<lifeless> you will need to install bzrtools *and* bzr at the same time because bzrtools is version locked to a specific bzr release.
<tmetro> But it should pull in bzrtools automatically...regardless, something is broken if I have to specify an explicit version. (Unless I added an apt config that I'm forgetting about.)
<lifeless> tmetro: IIRC with backports you have to list each thing you want
<lifeless> so you'd need to add bzr and bzrtools to your config
<tmetro> Ah, I see, they only have 1.5 of bzrtools on backports.org.
<tmetro> http://backports.org/debian/pool/main/b/bzrtools/
<tmetro> I'll send them an email...thanks.
<spiv> spm: yep, lp: URL in merge request still vanishing without a trace.  I'm going to workaround it with http:// again.
<jml> ok. I think I've got this critical bug sorted.
<jml> now checking that it fixes the original problem.
<awilkins> Does .bzrrules work for in-tree content filtering rules?
<awilkins> And I'm having "trouble" with eol filtering
<spiv> jml: my branch landed, btw
<jml> spiv: cool!
 * jml updates the bug 
<jml> spiv: I have a patch you can review. I'm blocked on testing it against Launchpad though. :(
<jml> vila: hello
<awilkins> Ok, correct me if I'm wrong .. If I have a folder that contains a mix of LF-ended and CRLF-ended (*.cs) files, and I add a rule [name *.cs], then after a touch, on a Windows working tree, the result should be that i) bzr reports that LF files created as LF and saved as CRLF since checkout (but no other change) are unchanged 2) LF files that have not been re-EOLed have been changed
<awilkins> Not sure about the inverse though.
<awilkins> Dammit, I hate tools that switch EOLs on you
<awilkins> On linux shouldn't it take files that were created CRLF, check them out as LF.. then what. The file hasn't changed (according to the filter rule, if it's "Native") but should the stored version get flipped to LFs or stay as CRLF?
<jml> awilkins: sorry, I don't really have a clue about that.
<awilkins> (the hating-tools-that switch EOl is directed at SharpDevelop, not Bazaar)
<jml> spiv: so this fix affects both the client and the server.
<awilkins> jml: I'm trying to figure it out
<jml> spiv: 1.15 is completely broken wrt Launchpad's use of stacking.
<stbuehler> bzr needed nearly 30 seconds to push one commit to svn; imho that is not really acceptable: http://paste.lighttpd.net/187
<stbuehler> any chances this will be fixed?
<jml> spiv: https://code.launchpad.net/~jml/bzr/default-stacking-bug-385132/+merge/7330
<jml> (or any other bzr-core member)
<bialix> hi, anybody can suggest me the way to find unused imports in python code?
<bialix> will be great if this method will look into bzr lazy_imports too
<spiv> jml: glancing now
<jml> spiv: ta.
<jml> bialix: pyflakes
<jml> bialix: there's a branch of pyflakes that is bzr lazy_imports aware
<spiv> jml: It's not immediately clear to me that given "full_path = self._root_client_path + final_stack[1:]", that calculating the relative_url of that against target_transport.base is sane.
<spiv> jml: it certainly feels odd...
<jml> bialix: if you use emacs, you can also hook things up so that pyflakes runs all the time (using flymake).
<jml> spiv: what did you expect?
<spiv> jml: hmm, so s/full_path/client_path/ for clarity, I think
<bialix> no, I'm not emacs user
<spiv> jml: but, the target_transport.base is presumably ignorant of any _root_client_path
<spiv> jml: and may be pointing at a chroot or something, right?
<spiv> jml: I would understand relative_url(_root_client_path, client_path)
<bialix> I guess this is the branch you mentioned https://code.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
<jml> bialix: yeah, I guess so too :)
<jml> bialix: I don't actually use that one.
<jml> spiv: changed.
<spiv> jml: but I don't see why relative_url([backing_transport_url], [a_path_adjusted_for_clients_view]) makes sense.
<spiv> This is potentially a failing of me rather than the code, but you'll need to convince me :)
<jml> I've changed it to  relative_url(_root_client_path, client_path)
<spiv> jml: cool.  does it still work? :)
<awilkins> Erm, I think eol support is broken, but that could just be me
<jml> yes.
<spiv> Even better!
<jml> awilkins: it's possible. We landed some patches about that today.
<awilkins> Files that you commit on Linux with LF endings don't expand to CRLF on windows, even with eol=naitve
<jml> awilkins: bug 362030 and bug 379370
<ubottu> Launchpad bug 362030 in bzr "files whose content changed after EOL filtering erroneously marked as modified" [High,Fix released] https://launchpad.net/bugs/362030
<ubottu> Launchpad bug 379370 in bzr "bzr: ERROR: Unknown eol value 'None'" [Medium,Fix released] https://launchpad.net/bugs/379370
<awilkins> But files with CRLF on Windows with eol = native do collapse to LF
<spiv> jml: omit self.reset_smart_call_log() calls if you aren't going to inspect the call log in the test
<jml> spiv: done.
<bialix> pyflakes has no help?
<bialix> I need just to run it and specify modules? or I can pass the entire package
<jml> bialix: you pass it filenames, I believe.
<spiv> jml: reviewed (approve; no other issues)
<jml> spiv: thanks. any thoughts on the fact that bzr 1.15 will break on pushing new branches to Launchpad?
<spiv> jml: I don't have any great ideas about what to do for old clients.
<lifeless> jml: are there client side changes needed?
<jml> lifeless: yes.
<bialix> cool
<lifeless> jml: thats surprising to me.
<lifeless> if 1.15 is broken, 1.15.2
<bialix> pyflakes even suggest modules to make them lazy
<bialix> wow
<lifeless> or bump the server verbs if needed.
<lifeless> I'm not here.
 * lifeless hides
<jml> bialix: #divmod if ever you have detailed pyflakes questions.
<spiv> Launchpad (and potentially bzr core) could peek at the 'Software version' header and reply with UnknownMethod for that verb...
<bialix> jml: I guess suggestions about lazy makes sense only for bzr code
<bialix> e.g.
<jml> lifeless, spiv: I think this is something that we can resolve over the next week before the final release.
<spiv> jml: +1
<bialix> C:\work\Bazaar\repos\qbzr-repo-1.9\trunk\lib>pyflakes commands.py
<bialix> commands.py:21: import of 'os' could be lazy
<bialix> commands.py:22: import of 'sys' could be lazy
<bialix> commands.py:23: import of 'ui' could be lazy
<bialix> commands.py:25: 'get_cmd_object' imported but unused
<bialix> commands.py:25: 'register_command' imported but unused
<bialix> commands.py:32: 'QtCore' imported but unused
<bialix> mwhudson: hi
<lifeless> heh. note that making things lazy that will be needed for most commands is unneeded overhead.
<jml> bialix: the lazy branch might actually be up for review on divmod's tracker.
 * jml shrugs
<bialix> so twisted uses lazy imports too?
<spiv> No.
<spiv> (But maybe they should!)
<bialix> jml: pyflakes even works for the packages! wow
<bialix> thx!!!
<spiv> bialix: pyflakes is pretty excellent :)
<bialix> yeah!
<bialix> this is what I need for so long
<jml> bialix: also, since it's really fast, it's something that you might be able to always have running & integrate with your editor.
<bialix> or as part of test suite
<jml> I guess.
<jml> it still has false positives.
<jml> for Launchpad, we have a wrapper around bzr send that does a pyflakes check on all changed files & includes that in the body of the email.
<jml> so they can be caught at review time.
<jml> that seems to work ok.
<awilkins> Hmm, the eol filtering applies to initial checkouts, but not to subsequent updates
<awilkins> Plus I've now noticed the "you checked it out fresh but everything is changed" bug
<fullermd> awilkins: That (initial but not update) behavior is one of the things I noticed playing with keywords that just stopped it dead.
<awilkins> Is there a bug for that?
<fullermd> Dunno.
<awilkins> It's also not clear to me what retro-active behaviour should be on e.g. - files that were created CRLF but are now content filtered and should be LF in storage
<awilkins> (created with no filter)
<fullermd> I didn't file one.  It seems like such an absolute showstopper that I assumed it had to be "incomplete", not "unknown bug".
<awilkins> igc: Ping?
<fullermd> He left about 3 hours ago.
<awilkins> Darn
 * awilkins forsees an "eol" tag for the bug tracker
<fullermd> Well, since I saw it with keywords, I'd assume it's more "filter" than "eol".
<bialix> mere mortals most likely find eol, though
<awilkins> And EOL and ignore are the only filters as yet
<awilkins> Well, in the default
<spiv> fullermd, awilkins: I think igc would appreciate bug reports
 * awilkins is filling out one and also composing overall mail of all bugs he is aware of with feature
<fullermd> My experience (and memory of it, come to that) is stale.  Bug reports of "I sorta remember way back when X happened" are rarely appreciated   :p
<jml> noooo, one test fails.
<jml> http://paste.ubuntu.com/193374/
<GPHemsley> Is there a way to uninit?
<jml> GPHemsley: what precisely do you mean?
<GPHemsley> I did an init
<GPHemsley> and now I want to undo it
<jml> GPHemsley: remove the .bzr file from the directory inited.
<jml> GPHemsley: beware, you'll lose any history you've made.
<GPHemsley> no command, then?
<GPHemsley> no history
<jml> GPHemsley: no command.
<GPHemsley> now, would you recommand creating a trunk/ directory?
<jml> bzr init trunk
<GPHemsley> OK, but I'm asking if you think that's a good idea?
<jml> GPHemsley: it really depends on the broader context.
<jml> GPHemsley: a lot of the time I do this:
<jml> bzr init-repo <project-name>
<jml> bzr init <project-name>/trunk
<GPHemsley> any way to directly convert an init to an init-repo?
<fullermd> No more than there are ways to directly convert a submarine to a skyscraper.
<GPHemsley> fair enough
<jml> GPHemsley: there are things you can do, but they are all a pain, and rarely worth it.
<jml> Certainly not if this is for a new project.
<GPHemsley> k
<fullermd> They're totally different things; it doesn't make sense to convert something that you'd init into something that you'd init-repo.
<GPHemsley> cd <project-name>; bzr init-repo .
<GPHemsley> is this same thing, right?
<GPHemsley> (as the first command above)
<jml> yep.
<GPHemsley> and then I can cd trunk and bzr init .
<GPHemsley> ?
<jml> for reference, when you do 'init-repo', you're saying "this directory is going to be a shared repository; a bucket where all of the branches beneath it store their data"
<GPHemsley> right
<jml> GPHemsley: or just bzr init trunk
<GPHemsley> I get this straight eventually
<GPHemsley> s/I/I'll/
<GPHemsley> well, trunk already exists
<GPHemsley> but no matter, it's done
<jml> GPHemsley: when you say "bzr init foo", you're saying "I'm starting a new branch -- a new line of development --called 'foo'"
<GPHemsley> oh
<GPHemsley> hmm
<jml> you tend to need at least one of these per project :)
<GPHemsley> yeah
<GPHemsley> :)
<GPHemsley> can bzr store symlinks
<GPHemsley> ?
<spiv> GPHemsley: yes
<GPHemsley> cool
<Peng_> But can it handle them decently when you try to check out on a platform that doesn't support them?
 * Peng_ goes /away again.
<jml> poolie: looks like your format rename branch didn't land.
<awilkins> Peng_: You need a plugin for them on Win32
<Peng_> awilkins: Oh, nice.
<awilkins> Peng_: But AFAIK NTFS does support symlinks with varying degrees of support
<awilkins> Peng_: I think the support gets a bit better in Vista and 7
<awilkins> Peng_: On XP it's limited to "juncton points" which only link folders on the same physical volume
<awilkins> Vista and up support file links, cross volume links, and network symlinks (but only on servers that also support them)
<awilkins> And by default non-admin users can't create them... nice
<Peng_> I see. Thanks for the information. -- Eh, non-admin users can't create any symlinks, or just weird ones?
<awilkins> Peng_: If you are a non-admin or non-elevated admin you can't create a symlink in the default config
<awilkins> But you can change the policy
<Peng_> ...That's dumb.
<Peng_> Maybe it's to prevent symlink attacks?
<awilkins> Peng_: Who knows why... perhaps only the ACL for the link is considered when accessing the file, so it could be a potential hack to create links to system files and write viruses into them
<awilkins> Peng_: But without testing it....
<fullermd> It's tough to get right.  They only had, what, 25 years of prior art to look at for it...
<awilkins> Shouldn't be too hard to write into the Python library to use it though (but you'd have to throw an error about setting the policy)
 * awilkins requires tea
 * jml halts
<awilkins> Does the py2exe build process strip the libraries it puts in library.zip?
<ddaa> mostly, library.zip contains pyc files, so stripping does not aplly
<ddaa> if there are any .dll, they'll (presumably) be in whatever state they were found on the system.
<awilkins> ddaa: I don't mean it in the "strip stuff out of libraries" sense, sorry, I meant, does it ignore libraries for which their are no dependencies on the code
<awilkins> E.g. - if it doesn't depend on SimpleXMLRPCServer, it won't be in library.zip
<awilkins> (I think this may be the case)
<ddaa> yes it does
<awilkins> Aha
<awilkins> That explains why bzr-eclipse doesn't work anymore
<awilkins> CAn you just plonk the .py file in the lib folder and have it work?
<ddaa> you need to specify some badly documented option to have setup.py include the libs you want in the zip
 * awilkins tries the plonk-the-lib-in method
<ddaa> that will work
<ddaa> but it's ugly
<awilkins> I'm not sure it does.. unless SimpleXMLRPCServer now has missing dependencies
<bialix> you can put missing py files into library.zip
<awilkins> bialix: Ah, but not straight into /lib ?
<bialix> nope
<ddaa> oh, misread what you meant :)
<bialix> awilkins: we using another approach in QBzr
<awilkins> the _lib folder?
<bialix> yes
<awilkins> Oh wait, that's gtk
<awilkins> Ah, as well
<bialix> so any plugin can support all required but missing libs
<bialix> although it's a bit boring
<awilkins> I'm jsut trying again, I don't think it killed the process that it had previously spawned
<bialix> awilkins: are you using bzr-svn?
<awilkins> Yes
<bialix> then you can't rebuild bzr.exe without all svn dlls
<awilkins> bialix: Yes, I had a win32 build env for bzr going before and it was a real pain to set up
<bialix> or may be can
<awilkins> bialix: Since then it's all gone kaput
<bialix> I'm build bzr.exe for myself w/o bzr-svn
<awilkins> bialix: You should be able to rebuild the exe as long as you have the built extensions (with a little finagling and judicious touching)
<bialix> awilikins: in fact I think one can use compiled bzr-svn from official installer
<awilkins> bialix: Does the python-flavoured one have the bzr-svn extensions in it yet or does it just not bundle them at all now?
<bialix> python-based installer installs only bzr+bzrlib+docs, nothing more
<bialix> so you agin have to install bzr-svn separately
 * bialix never had enough patience to learn bzr-svn build process
<awilkins> It's not fun
<awilkins> Well, not on windows
<bialix> one man gave me instructions
<awilkins> On Linux it's doss easy
<bialix> apt-get
<bialix> ?
<awilkins> Even building from scratch
<awilkins> You just apt-get a few dev packages
<bialix> I'm not sure it's entirely Windows problem. Some credits should go to svn developers
<awilkins> Well, there is that
<awilkins> I'm sure glad they have those prebuilt dev libs for Windows because the thought of actually building it makes the blood run cold
 * bialix nods
<tedg> Is there a way to regenerate the indicies?
<tedg> I'm getting this error: bzr: ERROR: Error in data for index GraphIndex('file:///home/ted/Development/inkscape.newbzr/.bzr/repository/indices/1d2b8fb37e32a1e94a733fbc3d195756.tix').
<awilkins> Does py2exe deliberately not compress the content of library.zip ?
<bialix> awilkins: it's controlled by options in setup.py
<bialix> when I wrote py2exe support in 2006 I've decided to not compress it
<awilkins> I wonder if it might improve startup time to compress it (reduced disk IO vs CPU time)  .. I wouldn't like to guess without testing it
<bialix> as I vaguely remembered Mark Hammond suggest to actually compress it.
<bialix> I see what you mean
<bialix> the difference will be really small
<awilkins> Oh yes indeed
<bialix> tens of milliseconds
<bialix> in the end windows has to read 1 file
<bialix> and will ikely this file could be cached by disk subsystem
<awilkins> Would pyflakes tell me what bzr-elcipse is dependant on
<bialix> no
<bialix> but you can use modulefinder.py module from bzr.dev/tools
<awilkins> Groovy
<bialix> err
<bialix> package_mf.py
<awilkins> Ah, it's all java
<awilkins> And makes XMLRPC calls
<bialix> bang
<awilkins> So I guess I just need to check what xmloutput and SimpleXMLRPCServer use
<bialix> at least
<bialix> yes,
<bialix> you don't have python traceback from java, do you?
<awilkins> bialix: It spawns a process and talks to it over a socket, so no
<awilkins> bialix: Unless you trapped the xml server to do it
<bialix> it was half/joke
 * bialix tried to run eclipse and look at qbzr-eclipse. it looks very decent
<bialix> perhaps not too serious like bzr-eclipse
<awilkins> It's probably best I stick with it, all my users are on it
<awilkins> For some reason, people get antsy about having new software installed
<bialix> I'm trying to imagine "ansty"
 * bialix cannot
<awilkins> I think it's "the feeling of discomfort ones gets from having ants in ones pants"
<bialix> it was second half/joke
<bialix> don't mind
<awilkins> Don't know how Russian you are :-)
<bialix> may be I'm just need to sleep a bit more
<bialix> but yes, I'm
<Spabby> hi guys anyone awake?
 * bialix half awake
<Spabby> :D
<Spabby> I'm wondering if it's possible to use bazaar to run the  way I want, my friend Google hasn't been much help
<bialix> you want asking about bzr-svn?
<bialix> well, bzr can't make sandwich for you
<bialix> so it's hard to suggest you something without more details
<Spabby> I want to have a central repo that myself and a colleague can merge to, but I want what I merge to be visible as a proper website, Ie I want to checkout a branch, edit the files, then merge back to the central server, at which point the changes are reflected on the website
<Spabby> sorry I was typing a long sentence ;)
<Spabby> I'm not particularly concerned about the sandwiches
<bialix> it depends how you configure your server and bzr repo
<bialix> look at plugins: push-and-update andd/or upload
<bialix> or use hook on smart server
<Spabby> there are plugins that will push and upload to a server?
<bialix> 2 all: this question asked very frequently. Does bzr has some sort of FAQ?
<Spabby> I've read the FAQ
<pygi> bialix: lies, it can make a sandwich :(
<bialix> push-and-update IMO
<pygi> the book claims it can :(
<Spabby> and i've googled like mad
<Spabby> I'm not looking for easy answers, I'm just looking for some help and direction
<pygi> Spabby: loggerhead perhaps?
<bialix> push-and-update:
<pygi> if I got your requirements right
<bialix> Provide the "push-and-update" command to automate the running of 'ssh remote bzr update path' after pushing to sftp://remote/path. This allows us to keep a remote working tree up to date.
 * pygi just came in :p
<bialix> Spabby: does it relevant for you?
<Spabby> yes I think so
<Spabby> if I'm reading it correctly, after the changes have been pushed, I can trigger an update on another path
<bialix> or, if you really need webbrowser for your repository -- loggerhead
<Spabby> so if I checkout the bzr branch to the webroot
<Spabby> when I push I can trigger an update on that branch?
<bialix> if you have smart server running on your server (e.g. bzr+ssh)
<Spabby> I'm not stupid, honest :D
<bialix> me too
<bialix> I'm trying to help
<bialix> I'm just bad in English
<Spabby> no you are helping
<Spabby> and for that I thank you
<Spabby> I'm reading on the push-update plugin
<bialix> I mean bzr FAQ need more love
<Spabby> ok
<Spabby> I think I need to buy a good book :D
<bialix> or just ask here
 * awilkins should write the Bazaar book and make oodles of cash
<awilkins> Not that I'm especially knowledgeable, just especially fond of cash
<Spabby> I need to understand the basics I think
<awilkins> Are you experienced with SVN or CVS?
<awilkins> (or other VCS systems with central repo)?
<Spabby> for someone who is fairly knowledgable in a wide sphere of IT based stuff, revision control evades me
<Spabby> I used svn for about a year but I kept breaking it
<Spabby> and I never really understood it
<Spabby> well
<Spabby> I understood how to update my working copy, and checkin changes
<Spabby> but not how it all worked
<awilkins> SVN is just another filesystem with the time dimension included
<awilkins> You can go back, create absurb paradoxes, etc
 * bialix likes paradoxes
<Spabby> my problem with svn is that if I deleted a local file I seemed to completely break the repository
<awilkins> That is oddd
<Spabby> or at least my ability to checkin to the repo
<ddaa> I would like to be able not to make it sound like a putdown, but you are clearly confused about something.
<ddaa> But we'd need a lot more information to able to identify what you are confused about.
<Spabby> I'm confused about a lot, it's not a criticsm
<Spabby> I guess that the bzr repo is a database of files, and how those files have changed (at a broad level)
<Spabby> and I understand how I can use bzr to manage my revisions on  local level by using commit
<Spabby> but  I struggle to understand how it works in a centralized environment
<awilkins> Spabby: In a centralized environment you would use bound branches
<awilkins> Spabby: The commit occurs either locally_and_centrally or just centrally
<Spabby> right
<Spabby> I guess the process we want to use is to commit locally during development of a branch, and then centrally when you are ready to publish your changes to the project
<awilkins> Spabby: The Bazaar development branch method is an excellent example
<Spabby> and I guess not understanding it makes that very difficult for me to visualise how bzr would handle that
<awilkins> Spabby: All commits to the main trunk of development are made by the patch queue manager
<awilkins> Spabby: And only after they pass testing.
<Spabby> is that the "Gatekeeper" from the bzr manual?
<awilkins> One manifestation of a Gatekeeper, yes
<Spabby> ok
<bialix> the great and terrific one
<awilkins> Do you have qbzr?
<awilkins> Or bzr-gtk?
<Spabby> I'm going to read the development branch method
<awilkins> Just looking at the revision graph for bzr.dev would be very informative
<Spabby> im using cl bzr on Centos ATM to try and setup the central location
<awilkins> cl bzr ?
<Spabby> I seem to have created the branch and commited the initial files to it
<Spabby> command line
<awilkins> Ah
<awilkins> Right, what serving methods do you have available?
<Spabby> http, sftp, ftp, or any other that can be installed if it is better
<awilkins> (and which bzr version are you using? Last I looked the CentOS packages were quite old)
<mattl> hey, what does this mean?
<mattl> bzr: ERROR: Revision {daniel@daniel-watkins.co.uk-20090412154020-0fk0vbvg644oe8zo} not present in "254@1c61c228-c9dc-448a-9a81-c9cbcf67beca:trunk%2Fweb%2Fdata%2FServer.php".
<awilkins> If you and all users have ssh access to server than that would work well
<Tak> mattl: bzr-svn?
<awilkins> Otherwise, http only works both ways with effort
<Spabby> yes we have ssh access
<mattl> Tak: this was an svn that was converted to bzr.
<Spabby> this is a development server hosted on our lan
<Spabby> so ssh would be fine
<awilkins> Spabby: Use bzr+ssh then, that's probably the least-setup way to do it
<Spabby> how do I find out version number sorry awilkins
<awilkins> `bzr version`
<ddaa> mattl: that means some revision in the svn repo was committed with bzr, but it's missing from your bzr repo (because bzr commit on svn repo do not store the parent revisions of a merge in the svn repo)
<Spabby> ah
<Spabby> you'd think they would include that in the default command list
<Spabby> im running 1.3.1
<mattl> ddaa: so, how do we fix this?
<awilkins> Spabby: That's the old version I was referring to
<Spabby> ok
<ddaa> mattl: bzr is normally about to deal with this, they are called ghost revisions
<Spabby> i'll try and get an update
<ddaa> mattl: so this is a bug that this is causing a crash
<awilkins> Spabby: If you have root it's not hard to build from sources
<mattl> ddaa: is there a way i can skip these revisions?
<Spabby> ok
<Spabby> I will do that now :D
<awilkins> Spabby: But things will still work at the moment
<ddaa> mattl: as I told you, it's a bug that the presence of ghost revisions is causing any problem at all.
<Spabby> ah ok
<Spabby> so I have a repo setup
<awilkins> Your client machine should be able to `bzr checkout bzr+ssh://server/full/path/to/branch
<ddaa> mattl: you cannot "skip them", it's just not the way bzr-svn works.
<Spabby> at least if I do "bzr info" I see the branch
<mattl> ddaa: right, so... should i try a later version of bzr, or is my project repo screwed?
<Spabby> how do I check that out to my local pc?
<awilkins> `bzr checkout bzr+ssh://server/full/path/to/branch`
<ddaa> mattl: if you can identify the bzr branch that was merged into svn prior to the import you are using, you can fill the ghost revisions using "bzr fetch-ghosts"
<ddaa> mattl: you should ALWAYS try the latest version of bzr and bzr-svn when you have any sort of problem.
<awilkins> Spabby: That produces a bound checkout - commits will be mirrored to the server
<awilkins> Spabby: But all the revisions are also held locally
<Spabby> and if there are conflicts I will be prompted to merge?
<awilkins> Spabby: Yes
<Spabby> excellent
<awilkins> Spabby: Or update
<Spabby> I thank you
<ddaa> mattl: as I told you, your repo is not screwed, the presence of ghosts revision is not a problem, bzr and bzr-svn SHOULD be able to deal with them. If you still have this problem using the latest bzr, you should file a bug so bzr can be fixed.
<ddaa> actually, ghost revisions is a feature
<ddaa> as it allows round-tripping of bzr commits through a svn repo.
<Spabby> awilkins that checked out great
<Spabby> thanks again
<awilkins> Spabby: You're welcome. Soon you'll progress to multiple branches in a no-trees repo and switch between them like a gazelle
<Spabby> that worked great
<Spabby> but when I commit my changes to the central, is there any way I can force an update on the branch there?
<awilkins> Spabby: THere are plugins
<awilkins> Spabby: Or you could use a server side hook
<Spabby> server side hook sounds intriging
<bialix> but anyway you need plugin on server side to hook it in
<Spabby> I'm guessing push and commit are not the same thing
<awilkins> Nope
<Spabby> sorry to perster you awilkins, im using tortoiseBzr on my local machine, any idea how I can get it to use the plugin automirror?
<bialix> Spabby: so now you're on Windows? great
<Spabby> :D
<Spabby> only temporarily
<Spabby> actaully scratch that
<Spabby> both of us will be working on linux boxes
<bialix> you need to get the copy of this plugin
<bialix> so why you using tvzr?
<Spabby> I'm working on my windows box atm because I have 1m other things going on
<Spabby> but when we start developing this app it will be coded on linux boxes
<bialix> get the plugin with command: bzr get lp:bzr-automirror automirror
<Spabby> I think that's a job for tomorrow :D thanks for all your help again
<bialix> put automirror directory (with plugin) to ~/.bazaar/plugins on Linux or %APPDATA%\bazaar\2.0\plugins on Windows
<bialix> and read the help on this plugin
<Spabby> thanks all, have a good evening
<bialix> that's basically all
<bialix> bzr need magic button to automagically install plugins
<awilkins> I find that `bzr branch lp:<plugin-name> <plugin>`  usually works nicely
<bialix> how you're explain usually where one should put <plugin> on Windows?
<awilkins> In powershell $env:appdata\bazaar\2.0\plugins
<awilkins> In cmd.exe  %appdata$\bazaar\2.0\plugins instead
<awilkins> Ack %appdata%
<awilkins> Not $
<bialix> anyway ~/.bazaar/plugin is way too much shorter
<awilkins> Yes
<awilkins> Hey, powershell supports ~ for %userprofile%
<awilkins> Why did they put BZR_HOME in %appdata% ?
<awilkins>  I didn't know it supported ~
<awilkins> Dammit, that would be much easier
<awilkins> And why the fricking 2.0
<bialix> hehe
<bialix> I know it's jam invent it
<bialix> but now it's too late to change
<bialix> but hey!
<bialix> we should have bzr 2.0 next month!
<bialix> so
<awilkins> I'd write a change-the-location-of-BZR_HOME plugin
<bialix> jam invented time mechine in 2006
<awilkins> But it wouldn't be able to load itself
<bialix> so you need to write it virus-like
<bialix> so it will reborn itself after total windows reinstall
<bialix> :-)
<bialix> more seriously: I'm always using BZR_PLUGIN_PATH settings
<RockyRoad> Hi :)
<RockyRoad> Would someone know what would happen (I mean, would it be safe) if I deleted, from the repository, a branch taking part in the history of another ?
<Peng_> RockyRoad: Don't go deleting .bzr/repository data that's necessary. .bzr/branch doesn't matter.
<Peng_> RockyRoad: (Unless you're using stacked branches, obviously.)
<RockyRoad> I didn't yet understand stacked branches
<Peng_> RockyRoad: When using stacking, it says "look at branch X for all the other data" instead of storing it all locally.
<RockyRoad> How can I check it is safe
<Peng_> RockyRoad: "bzr info", I suppose.
<hsn_> is there SLES prebuilt package?
 * Peng_ /away!
<Peng_> RockyRoad: On disk, branches (.bzr/branch) are simply pointers to data in the repository (.bzr/repository). Deleting them is perfectly safe. However, when using stacked branches, you may have several different repositories holding a few revisions each, so it may not be safe.
<RockyRoad> I'm working on lp:planet-drupal
<Peng_> Soo?
<RockyRoad> (just to let you check picture if you wanted) I think lp:~m-baert/planet-drupal/planet-6x is left behind after a sequence of merges
<RockyRoad> but if the others refer to it, they would break
<RockyRoad> I've rebuilt all the bzr history from multiple branches
<RockyRoad> I think I'd better check ids in bzr log xmloutput
<LarstiQ> hsn_: I think there have been, I don't know who is responsible for them
<jam> awilkins, bialix: We used "APPDATA" because that is where you are "supposed" to put application specific information on Windows
<jam> We used "Bazaar\X.X" because that is also what you are recommended to do
<jam> And we used 2.0 because at that time
<jam> bzr was likely to be released as Bazaar 2.0 rather than our final choice of releasing it as bzr 1.0
<jam> But as Alexander says, it will be there in another month or so :)
<beuno> so
<beuno> after upgrading about 30 branches at the office
<beuno> all of them upgraded fine
<beuno> they're all faster
<beuno> but about half of them are the same size in bbc than in 1.9
<visik7> is there a way to get mail notification on commit ?
<visik7> I want to develop a protocol for bazaar
 * SamB wonders why aptitude can't show changelogs for packages from PPAs
<SamB> hmm ... "bzr trees http://libarchive.googlecode.com/svn/" is failing for me using bzr 1.15+4422+110 ...
<SamB>  bzr trees http://libarchive.googlecode.com/svn/
<SamB> bzr: ERROR: Transport operation not possible: Transport <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://libarchive.googlecode.com/svn/> has not implemented list_dir (but must claim to be listable to trigger this error).
<SamB> ... oops, I missed the "%"
<wlawless> Is there a good site to visit if I am having problems with bzr-svn on Windows?
<SamB> wlawless: talk to jelmer
<SamB> ... who is conveniently missing
<SamB> what kind of problems?
<wlawless> a bunch of 'procedure entry point missing' errors when I try to do anything that involves the svn repository (checkout, update, commit)
<SamB> ("talk to jelmer" is my advice for most situations where a bzr-svn bug is suspected ;-)
<SamB> wlawless: could you paste one ?
<wlawless> "The procedure entry point svn_client_revprop_set2 could not be located in the dynamic link library libsvn_client-1.dll"
<wlawless> plus about 8 more, every time I run a command
<SamB> how'd you instal bzr-svn ?
<SamB> did libsvn_client come with it ?
<wlawless> I used the default installer for windows from here: http://bazaar-vcs.org/Download
<wlawless> the instructions says bzr-svn is included
<SamB> did you try googling for the error message yet/
<SamB> er, ?
<SamB> hmm, well, I can't find a thing
<schmichael> is there any reason not to always use bzr merge --pull?
<wlawless> I did, not much luck
<SamB> ... next question: search for files named "libsvn_client-1.dll"
<SamB> on your hard drive
<wlawless> not that I know of, I'm new to bazaar, so was just following the tutorials I could find
<wlawless> the only instance I could find was in c:\program files\Subversion
<wlawless> actually, nevermind, there is one in c:\program files\bazaar as well
<wlawless> would bzr-svn care what version of the svn client I have on my machine?
<bialix> garyvdm: good evening
<garyvdm> Hi bialix
<bialix> I'm packaging release right now
<bialix> garyvdm: done, trunk is open for 0.12
<garyvdm> Cool
<garyvdm> I'm adding some comments to loggraphprovider
<bialix> thank you
<bialix> now the most boring part:mark bugs as fix released
<wlawless> does the latest bzr-svn work against subversion 1.6 repositories?
<garyvdm> bialix: let me help with that.
<bialix> ok
<bialix> garyvdm: we talked about bug statuses some months ago. you can use fix released when you push your fix to trunk
<bialix> I've got too much karma from closing bugs
<bialix> thanks, done now
<garyvdm> Do you get karma for changing from fix committed to fix released?
<bialix> yep
<zu22> can someone please help me with bzr import
<zu22> this is driving me crazy!
<bialix> and I don't think it's quite rigt
<zu22> i followed all documented steps i could find and it still fails
<zu22> anyone here familiar with bzr's fast-import?
<garyvdm> bialix: I think the bug assigne should get the karma
<bialix> me a bit
<zu22> i am using darcs fast-export and then bzr fast-import
<zu22> bialix: ok cool one sec i will get a pastebin for you to see
<garyvdm> zu22 - can you pastebin some code.
<zu22> sure one sec
<zu22> gotta fire up firefox, slow computer :)
<bialix> garyvdm: after each release I see karma jump
<bialix> you can simply explain
<garyvdm> It's rewarding you greatly for a boring job ;-)
<bialix> ha ha
<bialix> IIUC bzr 1.16 will release brisbane-core
<bialix> we need to try conversion of our trunk to bbc (locally)
<bialix> garyvdm: you don't have a chance to test brisbane core yet?
<garyvdm> I've got a bbc branch of bzr.dev that I have been using to test some parts of qbzr against. But I have not tested upgrading the qbzr branch.
<garyvdm> I'll brb
<zu22> ok got it
<zu22> bialix and garyvdm you guys still here?
<zu22> sorry for the delay!
<zu22> http://zu22.pastebin.com/f145ddea9
<zu22> that shows what is going on
<bialix> cool, you have your own pastebin
<zu22> heh ya
<bialix> zu22: bzr: ERROR: No WorkingTree exists for
<bialix> you should run command: bzr co .
<zu22> bialix: so what am i doing wrong?
<bialix> or simply bzr co
<bialix> rtfm?
<bialix> run bzr co
<zu22> i am converting a darcs repo to a bzr
<zu22> ok
<zu22> i just did "bzr co" in /var/www/darcs/netrek-client-brmh.bzr and it said:
<zu22> bzr: ERROR: Not a branch: "/var/www/darcs/netrek-client-brmh.bzr/.bzr/branch/".
<zu22> it seems either darcs export is failing or bzr import or both :(
<zu22> any more ideas?
 * bialix re-read paste one more time
<zu22> lines 31 and 32 is where conversion should happen
<bialix> ok, let's try that without cd to .bzr dir and ls it, there is nothing very interesting
<bialix> cd trunk
<bialix> bzr info -v
<bialix> I need output of info command
<bialix> zu22: bzr info -v in trunk after import
<zu22> ok i will get that
<zu22> http://zu22.pastebin.com/f6f26e4c5
<bialix> zu22: now: cd trunk; bzr info -v
<bialix> does your darcs repo has only 2 commits?
<zu22> ok
<zu22> there is no trunk directory
<zu22> there is "branch-lock" and "repository" directories
<zu22> my darcs repo should have 8 patches in it
<zu22> but the bzr conversion should import ALL my source code
<bialix> don't don't don't don't cd to .bzr/ dir please
<zu22> the original code + my code in the darcs repo
<zu22> it doesn't import any code at all
<zu22> ok
<bialix> I see 2 revisions in your trunk
<zu22> you can pull my darcs repo and see yourself:
<bialix> C:\work\Bazaar\repos>bzr log http://www.jesujuva.org/darcs/netrek-client-brmh.bzr/trunk/ --line
<bialix> 2: netrek 2009-06-10 decimal precision conformance patch + compile fixes + updated ChangeLog
<bialix> 1: netrek 2009-06-10 Import old source code.
<zu22> darcs get http://www.jesujuva.org/darcs/netrek-client-brmh/
<bialix> I don't have darcs installed, sorry
<zu22> yes
<zu22> ok that is correct 2 big patches
<bialix> can you do following:
<bialix> bzr info -v /var/www/darcs/netrek-client-brmh.bzr/trunk
<zu22> i will do it now nad pastebin
<zu22> one second
<zu22> http://zu22.pastebin.com/f1b21995
<bialix> does location /var/www/darcs/netrek-client-brmh.bzr/trunk writable for you?
<bialix> this is valid branch. you need to run in /var/www/darcs/netrek-client-brmh.bzr/trunk either `bz revert` or `bzr update`
<zu22> it has permissions: drwxr-xr-x
<bialix> one of these comands will restore your working files
<zu22> oh ok
<bialix> so it's read-only for you
<zu22> then i will be able see all my code good
<bialix> do you have writable location in your session
<bialix> ?
<zu22> but i run all my commands as root
<zu22> yes root can write it :)
<zu22> let me try bzr revert
<bialix> you can get a fresh copy
<zu22> ok how do i do that?
<bialix> bzr branch /var/www/darcs/netrek-client-brmh.bzr/trunk ~/trunk.bzr
<bialix> last part of command -- is path where new copy will be created
<bialix> bzr branch -h | less
<bialix> this say you more
<bialix> you can browse your trunk with command: bzr log /var/www/darcs/netrek-client-brmh.bzr/trunk
<zu22> ah
<bialix> check your patches with command: bzr diff /var/www/darcs/netrek-client-brmh.bzr/trunk -c1
<bialix> bzr diff /var/www/darcs/netrek-client-brmh.bzr/trunk -c2
<zu22> cool bzr has diff!
<bialix> so, I;d say conversion was successful
<bialix> run this: bzr help command|less
<bialix> I recommend you to read this: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
<zu22> bialix: the 'bzr update' worked, now i must find out how to get my bzr repo to import into launchpad.net :)
<bialix> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html#publishing-your-branch-with-launchpad
<zu22> thank you bialix
<bialix> np
<zu22> bialix: you are Ukraine?
<bialix> but it seems you need to read this mini-tutorial
<zu22> yes
<bialix> yes, from Ukraine
<zu22> good
<zu22> i remember your leader
<zu22> he was poisoned :(
<zu22> is he ok now?
<bialix> don't worry about him
<bialix> he's not very good leader
<bialix> why you migrate from darcs?
<zu22> our project switch to bzr
<zu22> but i prefer darcs :)0
<zu22> so i will keep using darcs and import to project using bzr
<bialix> I guess fast-import/fast-export should work for you
<zu22> yeah i just wish is a nice GUI to do all this
<zu22> so i must not fiddle with so many command line options, too easy to make mistake hehe
<bialix> GUI for fast-import?
<zu22> for both :)
<bialix> I'd write a simple script or Makefile
<zu22> good idea
<zu22> bialix: do you have your own website?
<bialix> more or less
<bialix> why you asking?
<mib_2l987k8u> How do I completely remove a file from history?
<mib_2l987k8u> A colleague added a directory of temp files by mistake, and they waste space.
<Peng_> mib_2l987k8u: Mostly you don't.
<bialix> how many revisions you have after this mistake?
<mib_2l987k8u> About two
<mib_2l987k8u> >1, if that's what you mean :)
<bialix> then create fresh copy of your branch before mistake
<bialix> and replay all good commits in new branch
<bialix> then kill old branch
<mib_2l987k8u> But I cannot (as in Git) just remove the files from each commit?
<bialix> you can try this with fastexport/fast-import
<mib_2l987k8u> OK, thanks
<bialix> but if you have only one revision on top, I'd better replay
<mib_2l987k8u> With uncommit?
<bialix> no
<bialix> with rebase plugin
<bialix> like in git
<bialix> rebase plugin has handy command: replay
<mib_2l987k8u> Ah
<mib_2l987k8u> OK, I'll RTFM for the plugin
<mib_2l987k8u> Thanks
<bialix> np
<bialix> but to save the space you need to get fresh copy and delete old branch
<bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/328598
<ubottu> Launchpad bug 328598 in qbzr "Create a revisions selector widget. Use in commands like push/pull." [Medium,In progress]
<mib_2l987k8u> Ah
<mib_2l987k8u> That's the main thing I'm trying to gain: space
<mib_2l987k8u> Since the temp files are just text, but lots of them
<bialix> bzr has no garbage collector
<mib_2l987k8u> Hmm
<garyvdm> bialix: There are 2 out standing issues that I ran into - that would need lots of codeing
<mib_2l987k8u> If I revert, just make the final changes, then commit and repack, would I regain the space?
<bialix> mib_.... no
<mib_2l987k8u> Damn
<bialix> uncommitted revisions is not garbage collected
<mib_2l987k8u> Maybe I should just bend over and take the wasted space, and hope bzr packs well enough as it is
<bialix> garyvdm: :-(
<garyvdm> <mib_2l987k8u: if you uncommit, and then push somewhere - that uncommitted rev won't be pushed.
<mib_2l987k8u> That would be possible.
<bialix> is there short path? may be to limit its functionality a bit?
<hsn_> you know if bzr-trac works with Trac 0.11.4? i am getting some exceptions
<garyvdm> bialix: I'ts usable as it is. May be we should look at merging it as it is.
<bialix> how to test it?
<garyvdm> bialix: qpull
<garyvdm> qpush
<bialix> ok, will look now
<garyvdm> qmerge - i think
<bialix> hsn_: jelmer or ddaa might know
<garyvdm> bialix: One of the issues is that you can't select a revision range, to say do a cherry pick merge.
<bialix> this is bearable
<bialix> known bug is not bug anymore, but feature
<bialix> haaa!
<bialix> ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'g
<bialix> et_bytes_as'")
<bialix> from your branch
<bialix> can you try to fix it?
<garyvdm> bialix: how?
<bialix> wait a sec
<bialix> https://bugs.launchpad.net/launchpad-code/+bug/354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed]
<bialix> run the script from this bug report as described
<garyvdm> on local branch, and then push?
<bialix> no
<bialix> Run it as 'fix-branch.py bzr+ssh://bazaar.launchpad.net/~user/project/branch'.
<garyvdm> ok
<meoblast001> hi
<meoblast001> i'm trying to help someone set up his new computer with his old bzr email line
<meoblast001> how can  be sure i have the exact same line as the old
<bialix> bzr whoami
<mib_2l987k8u> bzr whoami on his machine to set the new one
<mib_2l987k8u> check the old logs for his old one
<mib_2l987k8u> bzr whoami "Sam Adams <good@beer.com>"
<mib_2l987k8u> Or whichever beer your friend prefers
<meoblast001> i don't know what his old one was though
<meoblast001> how can i find the logs
<mib_2l987k8u> Run bzr log on the old repo
<mib_2l987k8u> On any machine with bzr installed
<rockstar> meoblast001, bzr log on the old branches
<meoblast001> ok
<garyvdm> bialix: I ran it and got http://paste.ubuntu.com/193697/
<garyvdm> I don't know if that is good or bad?
<meoblast001> rockstar: thanks
<bialix> garyvdm: I guess now it fixed
 * bialix checking
<bialix> garyvdm: now this branch is ok, thanks
<garyvdm> cool
<bialix> garyvdm: so.. your widget works
<bialix> it's strange it highlight only one column instead of all row
<garyvdm> That the other issue that I can't fix.
<bialix> may be we really need to land it and start dogfoding
<garyvdm> Going offline for 1 min
<tmetro> FYI, it looks like the Ubuntu Intrepid PPA:
<tmetro> deb http://ppa.launchpad.net/bzr/ppa/ubuntu intrepid main
<tmetro> will successfully work as a stand-in for backports.org, which currently is missing bzrtools, for Debian stable.
<bialix> garyvdm: but it produce tracebacks sometime
<bialix> e.g. in qtag
<bialix> or in qpush when branch is not selected (empty string)
<garyvdm> bialix: Yes are rough edges like that
<garyvdm> But the big issue is the it sometimes selects only one column
<bialix> it's not sometimes for me
<bialix> it's all the time
<garyvdm> And I can't enable multiple selection.
<garyvdm> Yes - i't all the time on windows - some time on linux
<bialix> you don't need multiple selection for pull/push
<garyvdm> The fix for both issues is the same.
<bialix> for qmerge -- maybe just provide 2 revision selectors?
<garyvdm> I need to rewrite large bits of QComboBox
<bialix> maybe bug with column somehow related to custom painting?
<bialix> I assume you draw entire widget
<garyvdm> No - QComboBox insists that you can select cels
<garyvdm> And insists that you can only select 1 item
 * Nafallo wonders if bzr import have changed recently
<garyvdm> I've tried all sorts of hacks to get around that to no avail.
<Nafallo> it's either that or my memory not working anymore :-P
<bialix> garyvdm: ar eyou using "highlighted" signal?
<garyvdm> brb
<bialix> garyvdm: it fails in strange way when I've tried to invoke qdiff from qlog
<bialix> so, it seems is not ready yet to land
<garyvdm> bialix: sorry - some unknown process keeps downloading something  - and I work out what it is.
<bialix> you hunting on virus?
<garyvdm> bialix: Yhea - I need to go through it with a fine comb. There have been a number of merges with trunk that were quite confusing.
<garyvdm> I don't know
<garyvdm> And netstat is confusing
<bialix> are you on Windows right now?
<garyvdm> No - ubuntu
<bialix> oh, ok
<garyvdm> Ok - going to restart to see if that helps.
<bialix> garyvdm: I'm going offline. Do you have questions for me?
<garyvdm> Seems to be fixed now
<garyvdm> bialix: No - I'm working on making one widget for browse, commit, add, revert and qmain
<bialix> cool
<bialix> I will start to review patches from igc and javier
<bialix> tomorrow
<garyvdm> Will have better performance and will fix bug 258929
<ubottu> Launchpad bug 258929 in qbzr "Commit dialog does not show contents of directory that is not versioned only the directory itself" [Low,Confirmed] https://launchpad.net/bugs/258929
<garyvdm> cool
<bialix> I guess this is need to be done at wt_list level?
<bialix> btw
<garyvdm> Yes
<bialix> today I've tested pyflakes
<garyvdm> but I have not get there today
<garyvdm> Sorry - I have not got there yet
<bialix> we have a lot of unused imports
<bialix> may be we need from time to time clean it
<bialix> https://code.launchpad.net/~mwhudson/pyflakes/lazy-import-support
<bialix> garyvdm: ^
<garyvdm> cool
<bialix> no
<bialix> this one https://code.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
<bialix> jml/spiv can advertise it
<garyvdm> Ok - I'll give that a try - I allways forget to check for unnecessary imports.
<bialix> me too
<bialix> but this tool is damn good
<bialix> the branch from mwhudson knows about bzr lazy imports
<bialix> it's incredible
<mwhudson> :)
<bialix> :-)
<mwhudson> it's a bit trigger-happy about suggesting imports be lazy
<bialix> yeah, I'm talking about pyflakes
<bialix> yeah, it was so incredible cool
<bialix> the best thing about pyflakes: it does not have extra dependencies
<bialix> e.g. I don;t need to install twisted to run pyflakes
<bialix> I like it
<bialix> btw Gary, sometimes it's interesting to see unversioned (but to be added file) in the qdiff
<bialix> e.g. if we select it to add before commit
<mwhudson> it's really fast too, that's important
<mwhudson> you can just run it all the time
<bialix> mwhudson: yeah, it's really fast
<mwhudson> (unlike pylint)
<bialix> it's even faster than bzr
 * Tak head explode
 * bialix z-z-z
<jdub> anyone about who can help with a weird merging problem with bzr-svn?
<kenichi> hello, i'm trying to understand the way post_change_branch_tip hooks get called.  if i'm committing from a checkout to a local filesystem branch, would it make sense for this hook to be called twice?
<SamB> who should I talk to about bzr-bisect? it apparantly doesn't use launchpad for bugs ...
<garyvdm> kenichi: I think if you commit to a heavyweight checkout - it changes the tip of the local branch (the checkout), and the bound branch.
<garyvdm> So post_change_branch_tip probably gets called for each of the branches
<garyvdm> *I think*
<kenichi> garyvdm: ah i see, i think that makes sense.  i will try with a lightweight to verify.  thanks!
<kenichi> garyvdm: yes, verified only one call with a lightweight.
<kirkland> doesn't seem that i can add an "-sa" on the end of a "bzr bd -S"
<kirkland> suggestions?
<kirkland> i found:   bzr bd --builder "debuild -S -sa" --source
<kirkland> that might do it for me
<lifeless> I think that is what I used for a similar thing
<lifeless> I can dig up my scripts if that doesn't work (I was building in a pbuilder myself)
<kirkland> lifeless: cheers
<Gnx-> still the same question, is there a way to teach bzr that something is a binary file and should not be merged?
<james_w> kirkland: "bzr bd -S -- -sa"
<james_w> anything after "--" is passed through to debuild verbatim
<james_w> anything that starts with a "-" at least
<james_w> I'd like to improve that a bit, but I'm not sure what the best plan of action is
<lifeless> Gnx-: no; in fact some binaries can be merged very well, and there are text files that don't merge properly. So it is something we would like to address.
<Gnx-> lifeless: well, I have an sqlite.db and it currently goes wonk from bzr
<lifeless> what do you mean by wonk?
<Gnx-> well bzr makes it .THIS .OTHER
<Gnx-> the behaviour I'd want would be that it would overwrite to whatever is in the last commit
<lifeless> Gnx-: just run 'bzr revert sqlitedbfilename'
<lifeless> Gnx-: I realise its not fully automatic, but it should work.
<Gnx-> I meant like bzr update -> database gets overwritten from the update source
<lifeless> Gnx-: yes
<lifeless> Gnx-: bzr update + bzr revert databasefilename == database is overwritten from the update source
<Gnx-> ah
<Gnx-> okay
<lifeless> Gnx-: isn't that what you are asking for?
<Gnx-> but I thought revert after update gets you the version from before the update
<lifeless> revert gets you the current basis
<lifeless> update changes the basis
<lifeless> after a *merge* revert would get you what you had before the merge
<Gnx-> ah okay, thanks, bzr is kind of MyFirstVCS ;)
<lifeless> for a merge you would do 'bzr revert -r branch:mergesource databasefilename'
<lifeless> or, more simply
<lifeless> cp dbfilename.OTHER dbfilename
#bzr 2009-06-12
<Gnx-> well yeah you're right, actually it'd be pretty simple to just alias a command to do that after the update
<jml> good morning
<Gnx-> still..beats versioning mysql db
<bob2> should the sqlite db even be in bzr?
<Gnx-> well it doesn't need to be, but then you'd have to move it around separately with each update
<lifeless> bob2: no particular reason not do
<lifeless> bob2: and if it is tied to source code, good reasons to do so
<Gnx-> I could also just move the fixtures, but that creates some more tedium then for each rev
<Gnx-> and tedium is ..tedious;)
<jml> poolie: ping
<poolie> hello
<poolie> perfect timing, hi jml
<poolie> and james_w and ilfeless
<jml> poolie: hi :)
<lifeless> hi poolie jmll AfC  etc ;)
<jml> lifeless: hi :)
<poolie> so, jml, do you want to talk about my breakfast? (brocolini and eggs) or something else?
<jml> poolie: your format naming patch didn't land.
<lifeless> we're looking for an adjective that says 'do not use unless you have read the docs'
<lifeless> for the 2.0 format command line option name
<lifeless> [this is not why it failed to land]
<jml> :)
<jml> I offer "runcible".
<lifeless> I think 2a won't provoke this because users are not /used/ to dealing with distributed databases
<lifeless> [and those users that are are probably in the 'clueful' set already]
<jml> alternatively, "alpha".
<poolie> rubicund
<jelmer> moin *.{au,nz}
<jml> "A runcible spoon is a utensil suitable for runciation. This of course is in contrast to an irruncible spoon, which one runciates at one's peril"
<fullermd> Hm, 'zat mean I'm on {au,nz} time today?
<jml> jelmer: hello.
<jml> fullermd: no idea :)
 * fullermd feels so cosmopolitan.
<AfC> lifeless: Good morning Robert
<poolie> jml, lifeless, so let's think about this in updating a document about how formats work
<fullermd> Obviously, the correct answer is "Schrodinger's 2"  :p
<poolie> for now, i'll resubmit that branch
<jml> poolie: with the syntax error fixed, yes?
<poolie> :)
<jelmer> james_w: have you seen this before:
<jelmer> tar: ./usr/bin/smbtorture: file changed as we read it
<james_w> ouch
<james_w> no
<james_w> what operation was that?
<jelmer> I keep getting that from bzr builddeb now all of a sudden
<james_w> could you pastebin the output please?
<jelmer> http://pastebin.ubuntu.com/193851/
<jelmer> that's the tail of the output
<jelmer> it seems to work sometimes, in particular if I haven't run bzr builddeb in a while
<james_w> ouch
<jelmer> but if I run it, fix something and then run it again it seems to always feel this way
<james_w> I wonder if something isn't getting killed or similar
<jelmer> s/feel/fail/ :-)
<james_w> heh
<james_w> you ^C it?
<jelmer> no
<jelmer> I'll try outside of bzr-builddeb, perhaps it's unrelated
<jml> lifeless: yesterday you said you were surprised that the fix I did needed a client-side change.
<lifeless> jml: I am
<jml> lifeless: would you be able to look at the patch and tell me if you spot a way to avoid it?
<lifeless> jml: is your branch up to date, I'm pulling
<rchady> Hopefully a quick question: Is it possible to do a branch or checkout in to the current directory ?  Providing '.' as the target to branch resulted in an error that the directory already existed (bzr: ERROR: Target directory "." already exists. |)
<lifeless> rchady: you can 'bzr checkout .' to create a tree where a branch already is
<lifeless> rchady: but you can't make a branch where one already is
<jml> lifeless: it is. r4433 in trunk.
<SamB> but why does it complain about "." rather than ".bzr/branch"
<SamB> ?
<rchady> I'm not super familiar with bzr so please bear with me -- I have a remote repo I want to check out to my current directory.
<lifeless> SamB: because .bzr/branch is internals and not useful
<rchady> I was trying: bzr branch <remote repo> .
<lifeless> rchady: is the current directly already bzr controlled?
<SamB> well, in that case, it could complain "you already have a branch here"
<rchady> no
<SamB> not complain about "."
<lifeless> SamB: you could file a bug or a patch perhaps
<SamB> it specifically complains about the directory "." already existing, see?
<lifeless> rchady: so bzr branch does a mkdir of the output directory
<SamB> personally, I suspect the error message corresponds with why it's failing
<lifeless> rchady: is there any reason you can't just remove the directory you're in and do bzr branch <dirname> ?
<rchady> it is my home directory... so yeah
<lifeless> rchady: ok. In that case you're probably best off doing 'bzr init' then 'bzr pull'
<rchady> Ok
<rchady> I'm hoping to be able to manage my home dir with bzr.. we'll see, heh.
<rchady> I have way too many logins on way too many disjoint, remote systems.. hoping to be able to make that a bit easier.
<rchady> I had made a rpm for my home directory, but that is rather rigid for making changes on the fly
<jdub> yo jelmer, can i bother you with a weird bzr-svn merging problem?
<jelmer> jdub: hey
<jelmer> sure
<jdub> jelmer: merging two branches of the same svn tree results in conflicts on some files
<jdub> i can either describe how to do it
<jdub> or upload an example somewhere ;)
<jdub> (i have a number of branches of wordpress svn in a bzr repo, trying to merge 2.8 into 2.7...)
<jelmer> jdub: Are those branches public?
<SamB> I think they're public if he was gonna describe how to do it?
<jdub> i haven't put htem anywhere useful yet, but i can make a tarball of my freshly-reproduced repo for download
<jdub> 38M bz2
<jelmer> jdub: That'd probably be the easiest way for me to reproduce it.
<jdub> msged you a download location
<jdub> in that repo there's branches fro "trunk", svn branches "2.7" and "2.8", and the attemped "merge" of 2.8 into 2.7
<jdub> (with resultant conflicts)
<jdub> i thought this could have been messy long-lived branches, but i reproduced it immediately with fresh repo+branches
<jelmer> jdub: the merge was created simply by "bzr branch 2.7 merge; cd merge; bzr merge ../2.8" ?
<jdub> yeah
<jdub> oh, and those were done with bzr stable ppa packages on hardon
<jdub> but i got the same result with bzr beta ppa packages on jaunty
<jelmer> it looks like there are a lot of cherry picks between those two branches
<jelmer> yeah, that seems to be the main source of the conflicts
<jelmer> bzr doesn't recognize that some of the commits in the two branches actually contain the same changes, and if there were other independent changes to that area of code as well that causes conflicts
<GungaJin> Are there any merge tools for Bazaar?
<jelmer> jdub: We can't do much about this unfortunately until Bazaar starts supporting cherrypick tracking.
<jdub> jelmer: boh!
<lifeless> jdub: are you getting huge conflicts?
<lifeless> jdub: try --reprocess
<jdub> lifeless: not huge ones, just lots
<poolie> hello jdub
<jdub> yeah, tried --reprocess and some of the other merge strategies
<lifeless> jdub: are they jen-u-wine?
<poolie> jml, what happened with bug 284038?
<ubottu> Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038
<jdub> difference of between 50 and 44ish conflicts
<jdub> yo poolie
<jml> poolie: there's an outstanding review
<poolie> regand regarding bug 385453, i think it's ok to slip it, but we should be extra careful that the files are included in the tarball and deb
<ubottu> Launchpad bug 385453 in bzr "make dist should fail if C files don't exist or can't be built" [Medium,Triaged] https://launchpad.net/bugs/385453
<poolie> vila didn't do it overnight?
<poolie> ok
<jml> poolie: yeah. extra care will be taken.
<jdub> lifeless: they do look like the kinds of things that would be cherry-picked
<lifeless> jdub: and they are different on both sides?
<jml> poolie: btw, I'll get the release going as soon as your format patch lands, or as soon as you tell me you're not going to land it.
<poolie> i'm distracted by other bugs
<poolie> which are less important
 * poolie gets undistracted
<poolie> it's in pqm now
<jdub> jelmer: thanks, i feel comfier knowing i'm not an idiot, and that this is not an unknown condition (the bug, not my idiocy, which is legend)
<jml> poolie: thanks.
<lifeless> jdub: crikey mate!
<lifeless> jdub: fwiw if these are cherrypicks, merging more often may reduce their impact.
<lifeless> jdub: also, you could try merge --weave
<jdub> lifeless: tried weave and lca
<jdub> yeah, trouble is that this is wp 2.7.1 -> 2.8
<jdub> even merging trunk had the same issue
<jdub> would rebase trickery help at all?
<poolie> jml, i submitted it to trunk, i can send it to 1.16 too
<lifeless> jdub: I don't think so.
<jdub> (btw, this is all theoretical now, as i worked around it -> my changes were usefully separate from the core code)
<lifeless> jdub: in theory this is whats happened
<poolie> also, jam suggested just dropping development7 now
<jml> poolie: I reckon I'll just merge trunk into 1.16 once that lands.
<lifeless> left side: ... patch A
<lifeless> right side: ... patch A(cherrypicky) .... change to B
<lifeless> per file merge bases might help
<lifeless> but we don't track per file cherrypicks either yet even when the file ends up fully merged
<jml> poolie: r4435 and r4436 are simple and valuable.
<jdub> clearly the wordpress dudes need to be encouraged to shift away from svn ;-)
<lifeless> anyhow, lca etc don't see the patchA's as the same, so the change from A-cherrypicked to B doesn't supercede the other side ending up on A
<lifeless> jdub: using a loom could help though by keeping your changes logically distinct
<lifeless> jdub: and if you where using a solely rebase workflow where your patches 'float' on top of trunk then that too would permit bzr to not conflict
<poolie> spiv, hi, good morning
<spiv> poolie: good morning
<poolie> jml, ok, just merging trunk makes sense
<jml> cool.
<poolie> hm what do i do now then? read vila's patch probably?
<poolie> spiv, what are you up to today?
<jml> poolie: I'm looking at ways to work around the "Launchpad won't work with Bazaar 1.15" issue.
<fullermd> poolie: Well, I'd appreciate eyes over that revno/rev-id stuff    :)
<jml> lifeless: have you had a chance to look at it yet? http://paste.ubuntu.com/193874/ has the relevant diff.
<lifeless> jml: I was updating local copies and context switched
<jml> lifeless: understood :)
<lifeless> what is that pastebin for?
<jml> it's the patch that I landed w/ both client- & server-side changes.
<lifeless> http://paste.ubuntu.com/193874/ ? is not.
<jml> lifeless: oh, my bad.
<lifeless> You may have wanted it to be.
<spiv> poolie: finishing my patch for VFS-free "bzr pull -r123 $stacked_smart_url"
<spiv> poolie: after that... not sure, probably reviewing.
<jml> lifeless: I meant '-c' not '-r'
<fullermd> (if there's approval-in-concept of both patches, I may have time this weekend to try resolving jam's changes to both and make one combined patch)
<spiv> poolie: also, filing a bug against LP code reviews :)
<poolie> spiv, you have heaps of approved patches
<poolie> small heaps at least :)
<poolie> jml, it passed all tests in non-ascii mode
<poolie> so it should be ok now
<jml> \o/
<poolie> spiv, what do you think about just landing the patch you originally put up for bug 109143
<ubottu> Launchpad bug 109143 in bzr "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://" [High,In progress] https://launchpad.net/bugs/109143
<spiv> poolie: I don't think it'll be very hard to do it better (i.e. your way), just a matter of finding a half-day or so... perhaps I should JFDI today or Monday?
<poolie> probably
<poolie> i really think we should finish up outstanding stuff
<poolie> one way or the other
<SamB> so ... anyone have any idea why bzr-bisect doesn't have a "skip" subcommand?
<jml> spiv: if I wanted to disable the InitializeEx verb for 1.15 clients, could I somehow register a new request handler in its place that checks the 'Software version' header and then either forwards to the real or raises some sort of exception?
<jml> spiv: by which I mean, what's the best approach for disabling the InitializeEx verb for 1.15 clients? :)
<GungaJin> Why does bzr ask me to merge when I do 'bzr up'?
<SamB> GungaJin: you have locall commits
<GungaJin> I just want to move to a different revision.
<SamB> you didn't get them merged upstream
<spiv> jml: I'm not sure if the header is being passed along to the request-handler
<GungaJin> hmmm... not that I'm aware of.
<GungaJin> How do I check where they are?
<SamB> bzr missing
<jml> spiv: ahh, suck.
<GungaJin> bzr status?
<spiv> jml: probably not hard to fix, but
<SamB> should show you commits on both sides
<jml> spiv: where would I have to hook in then?
<spiv> jml: maybe we ought to remove the verb entirely and replace it with a new one with a slightly different name?
<jml> spiv: you mean in 1.16?
<spiv> e.g. BzrDirFormat.initialize_ex_1.16 or something.
<spiv> Right.
<jml> rather than an LP compatibility kludge
<SamB> GungaJin: there's also a slight possibility that upstream rebased, though they really shouldn't ...
<GungaJin> bzr missing didn't work.
<jml> I can see that working.
<spiv> It seems a shame to penalise clients when there's no stacking involved, but on the other hand the offending verb has only been in one release.
<SamB> GungaJin: what'd it say?
<GungaJin> "bzr: ERROR: No peer location known or specified."
<jml> spiv: could you please do that for me? I'd wager you'll be able to do the right thing much faster than I.
<spiv> jml: which one?  I don't have a strong feeling on which solution to take...
<jml> spiv: out of the concrete solutions I've heard so far, I think renaming the verb sounds the least bad.
<poolie> ok, so i think i'll take over bug 284038 and try to finish vila's changes
<jml> spiv: do you agree?
<ubottu> Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038
<lifeless> jml: so were you going to paste the actual diff?
<poolie> it would be nice to do for this release but imo it should not stall the release
<mwhudson> renaming the verb sounds fairly clea
<mwhudson> n
<jml> lifeless: I pastebinned it, but forgot the url -- sorry. http://paste.ubuntu.com/193877/
<spiv> jml: I guess I do lean that way.  I wonder if lifeless will have any insights now that he's got your diff...
<lifeless> jml: what happens if you don't change bzrlib/bzrdir.py
<lifeless> jml: it looks to me like that was a first approximation fix and likely unneeded
<jml> lifeless: it tries to evaluate the stack_on as local path
<lifeless> jml: what are the tests to run
<jdub> lifeless: yeah, i should start using looms
<jml> ./bzr -Dhpss --no-plugins selftest -Eallow_debug -s bb.test_push push_smart_with_default_stacking
<jml> $ ./bzr -Dhpss --no-plugins selftest -Eallow_debug format_initialize_on_transport_ex
<lifeless> ok
<lifeless> stack_on_pwd in UseExistingRepository is essentially required to be an abspath
<lifeless> if its a relpath its considered relative to .
<lifeless> I don't see any way around it
<lifeless> I'm inclined to issue a 1.15.2
<lifeless> what did intrepid ship?
<jml>     * 1.6.1-1: amd64 i386
<spiv> lifeless: jaunty has 1.13.1
<spiv> (https://launchpad.net/ubuntu/+source/bzr)
<lifeless> oh right, i, J, k
<lifeless> yeah. I'd ship a 1.15.2 with this patch cherrypicked
<jml> rather than renaming the verb?
<lifeless> or version the verb
<lifeless> jml: one or other; whoever is doing the work can choose IMO
<jml> cool.
<spiv> It's a great opportunity to s/_ex/1.16/ , which must be a good thing ;)
<lifeless> spiv: Don't drop the _ex please
<lifeless> spiv: because the method is _ex
<spiv> lifeless: yeah, I know, just trolling.
<spiv> lifeless: see above where I suggested "BzrDirFormat.initialize_ex_1.16"
<jml> spiv: would you mind doing the version bump then?
<spiv> jml: sure, I'll put that together for you now.  I should do it on the 1.16 branch I suppose...
<jml> spiv: actually against trunk is still fine
<spiv> jml: oh, they are the same?
<spiv> Convenient.
<jml> spiv: trunk has a revision or two that I'm going to pull in :)
<spiv> (Also, lp:bzr/1.16 doesn't work yet)
<jml> ta
<jml> I knew I forgot something last night.
<lifeless> oh, isn't 1.16 hosted on lp?
<lifeless> that was a goal for it
<lifeless> spm: ping
<spm> lifeless: pong
<jml> lifeless: we arranged the PQM set up in the dead of night.
<lifeless> jml: oh
<lifeless> jml: I thought the branch was made a while back... shrug
<lifeless> spm: I _really_ want to get pqm and lp talking
<spm> lifeless: they are, aren't they?
<lifeless> spm: its very important. RT was filed. I know you are poking at it from time to time, but how can we get it into 'poke until it works' mode?
<lifeless> 18:09 < spiv> spm: yep, lp: URL in merge request still vanishing without a trace.  I'm going to workaround it with http:// again.
<poolie> jml, on consideration i don't see bug 284038 as sufficiently urgent for me to steal it from vila
<ubottu> Launchpad bug 284038 in bzr "push should warn about uncommitted changes" [Medium,Fix committed] https://launchpad.net/bugs/284038
<poolie> so i suggest we just slip it
<poolie> and let him finish it tomorrow or watever
<jml> poolie: cool. :)
<poolie> whatever*
<lifeless> spiv: I'm not sure that lp: urls will be opened through the right codepath to do resolution; bzr+ssh please
<spm> lifeless: ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHH! /me expresses mild frustration
<lifeless> spiv: or did you mean bzr+ssh failed?
<lifeless> spiv: and if it fails please don't change to http, lets debug and fix. small red button time.
<spm> lifeless: last time we fixed, was due to the authentication.conf getting a busticated version. *somehow* - unknown as yet, that old and busted was put back. I'd since added a ro file to stop the behaviour from repeating.
<lifeless> spm: *interesting*
<lifeless> spm: did you document it last time, to avoid other sysadmins running lp-login?
<spiv> lifeless: I meant what I said; I tried an lp: URL, I wasn't aware I should avoid them.
<lifeless> spiv: I'm not sure that you should.
<spm> lifeless: emailed them of the issue/solution, but not the lp-login - is that what creates that file? cause that's a Big Clue to me.
<lifeless> spiv: but lets start with bzr+ssh
<lifeless> spm: lp-login creates it. (I did in fact detail this for you at the time).
<spm> 'k
<spm> given the values that go in there, that helps me narrow it down to possibilities. something in that other (unused) build/setup going awry.
<spiv> lifeless: I'm typically in favour of stop-and-fix, but delaying the release for my patch seemed like a worse option...
<lifeless> I hear its traumatic when one starts
<lifeless> jml: bug 76616 did you look into the claim of a bad merge?
<ubottu> Launchpad bug 76616 in bzr "confusing message about ignored files on add" [Low,Fix released] https://launchpad.net/bugs/76616
<jml> no, I didn't.
<lifeless> jml: I think you should, or change the status down to fix committed
<spiv> jml: rename patch submitted
<spiv> jml: (for review)
<jml> spiv: thanks.
<spiv> jml: I haven't run the full test suite, but relevant subsets seem happy, and the grep output looks sane.
<lifeless> poolie: http://www.overcomingbias.com/2009/06/why-yes-men.html
<lifeless> I'm going into deep hack mode on check
<lifeless> two days of bugs and writing have driven me battty
<lifeless> SMS or ring to get my attention
<jml> poolie: can you please review https://code.edge.launchpad.net/~spiv/bzr/rename-init_ex-verb/+merge/7366
<jml> poolie: I've had a look & I think it's good, but would appreciate the double check.
<poolie> wilco
<poolie> done
<jml> poolie: thanks
<spiv> poolie: yeah, it seems to work fine against an older server (lp, which is in fact 1.14 I think?)
<jml> yep.
<jml> the other check is 1.15 client vs dev server
<spiv> jml: that'll fallback in precisely the same way that 1.15 does against 1.14 (i.e. LP) now
<jml> oh of course :)
<spiv> spm: so, should I try lp: or bzr+ssh: URLs on PQM again?
<spm> spiv: I would yes. the fix from last time is still in place so *hopefully* it'll all work...
<spiv> spm: ok, will let you know shortly :)
<spm> heh
<spiv> spm: ok, it's on PQM now... let's see what happens.
 * jml afk for a bit.
<spiv> spm: and at 02:23:04 it disappeared.
 * spm swears, sighs, and starts looking
<spiv> spm: that was with a lp: URL.
<spm> I think I'm gunna cry.
<spm> [Errno 13] Permission denied: '/home/pqm/.bazaar/authentication.conf'
<spiv> \o/
<lifeless> [machine crashed] spiv please try bzr+ssh
<lifeless> spiv: and don't try lp: until bzr+ssh are working
<spiv> lifeless: given the above error, I don't think bzr+ssh would help :)
<lifeless> spiv: if lp: is trying to write to it, bzr+ssh probably won't
<spm> I'd agree. I need to find out what's doing the lp-login and terminate with prejudice.
<lifeless> spiv: specifically I *do* think it will help.
<spiv> lifeless: well, spm is the one driving the debugging, so I'll happily do what he asks.
<spm> spiv: ha! if lifeless reckons it'll work, I'm happy to let you try? :-)
<lifeless> here are my thoughts
<lifeless> lp: is special. pqm might not use the right apis. it might need firewall ports opened.
<lifeless> bzr+ssh will let us be sure that the ssh aspect is working
<lifeless> we should get bzr+ssh working for source branches before trying lp at all.
<spiv> Submitting bzr+ssh merge request.
<lifeless> that way, if lp: requires more stuff, or indeed is even breaking things, we'll be able to diagnose that directly.
<spm> spiv: that looks to be working!
<spiv> Yeah.
<lifeless> another data point
<spm> so what is it about the LS pqm stuffo that causes the auth stuff to foobar bzr pqm. /rhetorical
<lifeless> as we won't be doing lp-login with the current plan, and http:// doesn't have a smart server, using lp; urls will be slower.
<lifeless> so even if lp urls work, we shouldn't use them.
<spm> well it's warmed up to a balmy 2degC here, so time to get outside and have some lunch in the sunshine! bbs.
<spiv> lifeless: that's a shame, because I'd prefer to have lp URLs as my public_location in locations.conf.
<lifeless> spiv: I agree, and I think we should work up to that
<spiv> Also, I don't care much about the speed of HTTP within the data centre.
<lifeless> :P
<spiv> Especially compared to the speed of running the test suite twice ;)
<lifeless> well
<lifeless> parallel++
<spiv> Yeah, using more cores if they're there is certainly a good idea.
<lifeless> the C check has saved my bacon way too often
<lifeless> ok lappie seems stable again. -> deep hacking.
<spiv> It would be interesting to have stats on the tests that PQM most commonly trips on.
<lifeless> oh, one lsat thing
<lifeless> igc: I think my command hooks patch is blocked on your replying to my reply to your review.
<tedg> lifeless: Hey, is there a way to regenerate the indices?
<tedg> I'm getting an odd error: bzr: ERROR: Error in data for index GraphIndex('file:///home/ted/Development/inkscape.newbzr/.bzr/repository/indices/1d2b8fb37e32a1e94a733fbc3d195756.tix').
<spiv> tedg: I haven't seen that error before...
 * tedg seems to have special skills in breaking bazaar :(
<spiv> tedg: off the top of my head I don't think it's possible to regenerate a .tix.  I certainly don't know of any convenient tools to do it.
<spiv> tedg: which repo format?  pack-0.92?
<tedg> spiv: What ever is default in the nightlies plus rich-root-pack.
 * spiv nods
<lifeless> tedg: file a bug; we'll need to write a repair tool to regen the index for you.
<lifeless> tedg: the index is zlib'd data
<tedg> lifeless: What should be in the bug, just that single tix file or the whole repo?
<lifeless> tedg: its mostly (but not entirely) derivable from what you have on disk
<lifeless> tedg: the one tix which may let us repair it depending on the damage.
<lifeless> tedg: and this conversation probably
<tedg> I mean, I'm just trying to get a checkout from SF SVN -- but that takes days and this happened in the middle.
<tedg> I can start the process over, I don't need that tix specifically.
<tedg> I'm just trying to avoid starting over.
<lifeless> the way we could repair is to read the leaf pages only to get back the kys and values and then reoutput it.
<lifeless> tedg: if this occured during a fresh branch from svn, well check your hardware - you may have a disk or memory problem
<spiv> lifeless: a little bit odd to get BadIndexError rather than a zlib error if it's bad hardware, though.
<lifeless> spiv: depends on the try's.
<lifeless> also we can look at the index once the bug is filed.
<tedg> So, I guess I'm not 100% clear what I should attach to the bug.
<lifeless> 13:19 < lifeless> tedg: the one tix which may let us repair it depending on the damage.
<lifeless> 13:19 < lifeless> tedg: and this conversation probably
<tedg> lifeless: Okay.
<AfC> Why in God's name does Launchpad not understand a bzr:// URL?!?
<tedg> Info attached to bug 386203
<ubottu> Launchpad bug 386203 in bzr "bzr: ERROR: Error in data for index GraphIndex" [Undecided,New] https://launchpad.net/bugs/386203
<igc> hi all
<igc> lifeless: it probably is blocked on that sorry
<jml> back
<jml> hi igc
<jml> AfC: God doesn't pay us.
<igc> lifeless: I've just woken up and feel like absolute crap so ...
<igc> I'll take a look Monday
<igc> jml: anything you need from me wrt the release?
<jml> igc: nope, you're all good.
<jml> igc: thanks.
<lifeless> igc: go rest
<lifeless> igc: health++
<igc> jml, lifeless: shall do.
<AfC> jml: ok, I'll try again
<AfC> Why in bog's name does Launchpad not understand a bzr:// URL?!?
<AfC> :)
<AfC> [bonus points if you get the Heinlein reference]
<jml> I counter with "tanstaafl"
<igc> poolie: I'm taking today off. Call me if there's anything urgent please
<jml> AfC: because we think it's less important than the next twenty things we want to do.
<jml> spiv: is your PQM job still running, or is that a resubmit?
<spiv> jml: still running.
<jml> AfC: I know that's an unsatisfying answer, but I'm afraid I don't have any others.
<spiv> jml: you can tell it's on the latter half of the run by the [ascii] prefix on the output...
<jml> spiv: ahh ok.
<jml> how long does it take to land a branch these days?
<spiv> jml: (you can see from the scrollback that the submission was delayed a little by PQM + lp: URL debuggery)
<lifeless> back to hacking
<spiv> jml: over an hour :(
<mwhudson> wow
<mwhudson> the launchpad pqm was that fast at one point :)
<spiv> jml: judging from the times on PQM (including that my job's time seems to be 1 hour in the future vs. the clock), at least.
<spiv> mwhudson: to be fair, we run our test suite twice :P
<mwhudson> who cares about fair!
<spiv> jml: ah, I think it just finished.
 * mwhudson is waiting for make schema, grumpily
<jml> poolie: thoughts? http://paste.ubuntu.com/193945/
<poolie> jml: i think it's the easiest pastebin question someone's asked me for a while :)
<poolie> there is a typo 'on run on huge'
<jml> poolie: dropped 'on run'
<spiv> jml: perhaps add "to it" on the last sentence of the first para, to try disambiguate that users should be cautious about upgrading formats, not about upgrading to 1.16?
<poolie> i think it's great
<jml> spiv: good call.
<poolie> it's good to have some fresh blood writing it too
<poolie> also you can pick a code name if you want!
<jml> "to the new format"
<spiv> jml: yeah, good call.  "it" should be banned ;)
<jml> poolie: where would I put that?
<poolie> i think it now goes in the rest keyvalue thing with the dates
<poolie> there is another example
<poolie> that syntax is a little ugly
<poolie> oh maybe also run make html-docs and check the syntax of news is all ok
<jml> good idea
<jml> also, say I misguidedly tagged an earlier revision as 1.16rc1...
<poolie> tag --force i think
<jml> ta
<jml> am waiting for a couple of PQM landings before actually rolling out the release.
<lifeless> ~
<lifeless> less useful exceptions #45
<lifeless> ValueError: Mismatched revision id and expected: 'robertc@lifeless-64-20090612055804-efc1rzfonn6ue0fq', 'robertc@lifeless-64-20090612055804-efc1rzfonn6ue0fq'
 * lifeless goes back to it
<bialix> nice
<AfC> Those Zero Width Non Breaking spaces (U+FEFF) will get you every time :)
<jml> wuuu
<bialix> jml?
<bialix> it means you had good sleep?
<jml> no, sadly.
<bialix> and ready to fire 1.16?
<jml> it means it's release time :)
<bialix> let's rock!
<jml> running make check_dist_tarball
<jml> I'm getting failures running blackbox.test_merge
<spiv> jml: anything I can help with?
<jml> spiv: looks like it might be a plugin...
<jml> spiv: http://paste.ubuntu.com/194053/
<jml> that's the failure.
<spiv> jml: unexpected success, almost!
<spiv> jml: weird
<spiv> jml: I can't reproduce locally, unsurprisingly
<jml> it's one of my installed plugins -- renaming .bazaar/plugins to .bazaar/vogons leaves me with the errors.
<spiv> jml: which plugins do you have?
<jml> bzrtools, launchpad 1.16dev, netrc_credential_store 1.16dev, pqm 1.3, qbzr 0.9.2, search 1.7dev
<spiv> jml: (I take it that that test passes for you with --no-plugins)
<jml> yes.
<spiv> None of those jump out at me as a likely culprit.
<jml> me neither
<jml> removing search, then qbzr.
<spiv> Interestingly, the merge is still producing conflicts, as it should, so it's just the retcode that's wrong.
<jml> looks to be qbzr
<spiv> I will speculate -- I was about to say that :)
<jml> hmm. bialix & gary are both gone.
<spiv> jml: qbzr trunk seems to work for me...
<jml> it's probably my ubuntu package then.
<lifeless> I'm about to call it a day
<lifeless> poolie: You may hate me for this, but I just found a design problem in bbc that makes check significantly more complex and that we can fix with a small amount of work... but its a format bump.
<spiv> jml: that qbzr version is almost certainly broken w.r.t. to 1.15 too.
<lifeless> bug 386227
<ubottu> Launchpad bug 386227 in bzr "chk_bytes not self describing" [High,Triaged] https://launchpad.net/bugs/386227
<lifeless> poolie: I'd like you to look at it and think about it and let me know if you think its worth doing; fornow I'm going to use a[n unreliable] heuristic in check to let me finish the check work.
<jml> pulling in latest subunit.
<spiv> jml: (wow, qbzr 0.9.2 is pretty ancient)
<lifeless> jml: apt-get install should be all you need
<jml> lifeless: http://paste.ubuntu.com/194067/
<jml> and I have no subunit or python-subunit package installable.
<lifeless> https://edge.launchpad.net/~subunit/+archive/ppa
<lifeless> or run karmic
<jml> ffs.
<lifeless> jml: or remove subunit
<lifeless> jml: as the test skips if subunit isn't present
<lifeless> jml: of course, it should work with subunit too, done() was landed in subunit
<jml> I'll remove subunit & see what happens.
<lifeless> ok, EODing. jml - ring ifyou're stuck on the release
<jml> lifeless: will do, thanks.
<jml> lifeless: have a good weekend.
<vila> hi all, have a nice week-end lifeless
<jml> vila: hello
<lifeless> vila: oh vila cool. poolie said to remind you of 2.0 targeted, and generally critical bugs as a priority to ocus ons
<vila> lifeless: ok
<vila> lifeless: any specific ones ?
<lifeless> https://edge.launchpad.net/bzr/+milestone/2.0
<lifeless> just the general thing of keeping our eye on the prize
<lifeless> it doesn't have to be all consuming
<lifeless> but we shouldn't get too distracted with other things
<lifeless> anyhow, family time now
<jml> woot, new failure.
<jml> http://paste.ubuntu.com/194100/
<jml> is that Python 2.6?
<jml> looks like
<vila> jml: it's a warning from 2.6 yes
<jml> vila: ok, so how do I proceed? -- I'm doing a make check-dist-tarball
 * jml hacks the makefile to use python2.5 and proceeds from there.
<vila> hmm, that needs to be addressed :-/
<vila> jml: that should work :-)
<vila> jml: can you keep notes or file a bug so that it's not forgotten ?
<jml> the deprecated usage is in the stdlib itself.
<jml> vila: sure thing
<jml> (I should have been doing that from the start.)
<fullermd> vila: BTW, I did try a selftest run on that new system.  Unfortunately, I couldn't --parallel.  So it still took like 20+ minutes   :(
<fullermd> (and ended up with a big ole pile of failures of various sorts too  :()
<fullermd> I've got python 2.6 on that box too...   the bleating about SHA/MD5 at the beginning of selftest from 2.6 is kinda grumy-making...
<vila> fullermd: 1) Why couldn't you use --parallel, 2) File a bug with all failures (when time permits, I'll add bsd to my test farm and from there...)
<vila> fullermd: related to 2, it's generally to much pain do diagnose test failures without being able to reproduce it on a real (or virtual) system
<fullermd> A lot of them were of the form "xyz has no revision [some id that looks like it was just created]".  Not sure what's up with that.  But a few spottests showed it on my current py2.5 system too.  Weird.
<fullermd> Couldn't --parallel because it wanted testtools, which I don't seem to have an OS package for (and I work hard to not step outside those bounds when avoidable)
<jml> we should fix that.
<fullermd> I was planning to throw together a mail with the test failures sometime when I had a chance to run it, log it, and dig through the annoyingly verbose output of selftest...
<fullermd> BTW, it's kinda annoying how there's no documentation about what the options for --parallel are...
<vila> fullermd: about '--parallel', your right, patch welcome ? :-/ Basically you need testtools and subunit, I understand you desire to stay inside well maintained bounds.
<vila> fullermd: about test failures: a bug with the full log is perfectly appropriate, don't bother analysing, collecting the data is the most important thing
<fullermd> FAILED (failures=12, errors=84, known_failure_count=12)
<fullermd> That would be a big log   :p
<vila> fullermd: I've seen worse :)
<fullermd> I would guess that all the "has no revision XYZ"'s have the same root cause, so it'd worth collating those out at least.  That's the big bulk of the 'errors' ones.
<fullermd> At least 3 of the failures are the fails I've previously noted on whatever it was...
<fullermd> 2009-06-09:01:27 <fullermd> test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7.
<fullermd> (NFC what possible impact the OS could make on that one...)
<poolie> hi, i'm back
<vila> fullermd: NFC as in utf-8 encoding ?
<fullermd> vila: no, as in No <profane> Clue.
<poolie> hello vila
<vila> poolie: hi :)
<poolie> jml, are you still here? how did you go?
<jml> poolie: some problems with make check_dist_tarball & python 2.6
<jml> uploading the files to Launchpad now though
<fullermd> (they all fail upset about getting '2 unreferenced text versions' instead of 0.  What the heck does the OS have to do with that?)
<vila> fullermd: haaa. that's the funniest part in diagnosing the bug ! I don't to spoil it by telling you now :)
 * vila thinks: nice one, should reuse it some day...
<poolie> jml, make check is dodgy wrt plugins
<poolie> i think it should run with --no-plugins probably
<jml> poolie: I was thinking about that.
<jml> and I wrote some of my thoughts down for later elucidation :)
<poolie> oh jolly good
<vila> jml. poolie: --on-plugins is a too big hammer, it excludes our own internal plugins
<vila> hehe nice typo :-) I meant --no-plugins of course
<vila> jelmer: pinh
<vila> jelmer: ping
 * vila remove his boxing gloves
<poolie> vila, so i'm not sure we should have shipped plugins
<poolie> occam's razor
<poolie> it's kind of a freak
<poolie> maybe we should look at what problems if any there would be with just merging that code
<poolie> i'm not assuming there would be none
<vila> poolie: I'm talking about the launchpad plugin and friends here, the ones inside bzrlib/plugins, you want to get rid of them or include more there ?
<vila> I thaught we didn't want to merge the lp plugin for licensing reasons (will soon be moot though)
<vila> On the other hand, the plugins are a good starting point for other plugins and as such, there is value keeping them plugins if only to ensure the mechanisms they use are well tested
<vila> I'm thinking about the gnu plugin or the python plugins which have been discussed here and there (providing the same server specific URL handling)
<poolie> vila, yes i was talking about the lp plugin too
<poolie> i'm not aware of any live licencing reason to keep it separate
<poolie> it just makes web requests to a public service, no problems there
<jml> poolie: can you please update freshmeat for me: http://freshmeat.net/projects/bzr/
* jml changed the topic of #bzr to: Bazaar version control system | 1.16rc1 released 12 June, 2009 -- please test it! | 1.15.1 released 09 June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<poolie> and i think in reality, there is no testing benefit
<jml> also, if you could approve my post to bzr-announce, that'd be ace.
<poolie> it just adds another case
<poolie> jml: just post and i'll approve it
<poolie> do you have a fm account?
<vila> poolie: by "licensing" I meant discussions around bzr "pushing" lp which isn't open sourced. Keeping it as a plugin allows *not* distributing the plugin to whoever feels the need.
<jml> poolie: no, I don't.
<poolie> ok
<poolie> i'll do that then
<poolie> i would have made you a coadmin if you did
<jml> poolie: I have posted to bzr-announce already -- waiting for approval :)
<poolie> jml, actually to save time next time, please just create one
<poolie> won't take long
<jml> poolie: will do.
<vila> poolie: I think the underlying problem is a lack of a better mechanism to select/activate/desactivate plugins
<vila> I'd prefer having more plugins than less :-)
<jml> poolie: can you please give me whatever permissions I need to register on PyPI? my username is jml
<poolie> list post approved-
<jml> danke
<poolie> pypi done
<jml> I assume I don't merge released code back into trunk until the final release, right?
<poolie> if there are new fixes there you can do it now
<jml> there aren't, I don't think. just the news file changes.
<jml> hmm. I think I have a very, very old freshmeat account linked to a defunct email address.
<poolie> so, um
<poolie> are you looking for that?
<poolie> or maybe i should just do this one
<wgrant> jml: Did you mean to create the 1.16 release on LP, rather than 1.16rc1?
<jml> wgrant: I think I meant to create 1.16rc1.
<jml> poolie: I do have a 'jmlTas' account.
<jml> wgrant: the instructions on the wiki page & the instructions on Launchpad itself combined for a lack of clarity
<jml> wgrant: can I do anything about it now?
<lifeless> jml:  you should merge back now as part of fixing up NEWS
<wgrant> jml: You could unrelease it, but that might not be possible now you've added files.
<lifeless> jml: the docs should be clear about this
<wgrant> (there's normally a (-) icon next to the release date, IIRC)
<jml> lifeless: well, they aren't to me.
 * jml makes a note
<poolie> jml ok you should have access on freshmeat now
<poolie> thanks for doing all this
<jml> poolie: np
<poolie> it's both a lot of work, and also more work than it should be
<jml> I guess I need to change the version numbers again when merging back :\
<poolie> lifeless: i saw your bug about check and chk keys
<poolie> maybe we should talk on the list
<lifeless> poolie: sure. essentially I'm closing in on having check overhauled.
<lifeless> some moderately tricksy stuff remaining but all monday should see it done
<wgrant> jml: Ah - since you can delete project release files on Launchpad, you can in fact fix it all up.
<poolie> you can also ask a duck to rename it
<poolie> but that may take a while
<fullermd> Why a duck?
<jml> wgrant: cool. I'll sort that out.
<jml> hmm.... before I register on freshmeat, it seems.
<wgrant> poolie: You don't even need a duck.
<wgrant> poolie: But that won't work really well, because stuff is milestoned to 1.16, and it would become milestoned to 1.16rc1.
<poolie> oh i see, yeah
<wgrant> but just unreleasing it, creating a new 1.16rc1 milestone, and then releasing that should work. And this UI was just redone to make it simpler...
<poolie> jml: i gave jmlTas access
<poolie> ok so now i really need to go
<poolie> bye
<jml> poolie: thanks.
<jml> what do I advance the version numbers too?
 * jml looks in __init__.py history
<lifeless> jml: 1 17 0 dev IIRC
<lifeless> and in NEWS it stays IN DEVELOPMENT but the released sections get the header they were released under
<lifeless> *really going*
<jml> :)
<strk> how do I get a checkout into a specific revision ?
<strk> 'update' has no --revision switch
<jml> g'night all.
<strk> and checkout complains about already existing something (.bzr)
<jml> thanks so much everybody for making 1.16rc1!
<lifeless> strk: what do you need a specific revision for? is it for testing, or committing on?
<strk> testing (looking for the commit which introduced a regression)
<lifeless> bzr revert -r revision
<lifeless> also consider using bzr bisect
<strk> how to get out of that afterwards ?
<lifeless> though it can be a bit confusion
<lifeless> bzr revert
<strk> k, thanks (I'll leave bisect out for now, I tried it once but I'm not ready for it yet - I bisect "manually")
<strk> oh, but 'revno' keeps telling me the new revno, not the one I reverted to
<lifeless> yes
<strk> how do I know the revision I reverted-to ?
<lifeless> well this is why bisect is better ;). but for now, your bash history ?
<fullermd> You don't, nothing is stored about that.
<lifeless> sorry I'm being brief, really gotta run
<fullermd> Well, it's why update -r is better, really.  But that's bug 45719 still.
<ubottu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress] https://launchpad.net/bugs/45719
 * lifeless closes irc ssh session
<fullermd> Past its third birthday now, too.  We forgot to throw it a party...
<strk> indeed I tried update -r
<strk> +1 for that bug !
<Spabby> good morning my version control loving friends
<Spabby> awilkins are you around please?
<awilkins> Yes
<Spabby> have you got 2 minutes?
<awilkins> Don't ask to ask, just ask
<Spabby> I just need a little help re: linux permissions if you are ok
<awilkins> :-)
<awilkins> Hah, I'm no expert on that but I can comment
<Spabby> i've created a new user for myself to use to checkout over ssh, as using root is bad puppy
<Spabby> but when I try to bzr update on the server while logged in as the new user I get permission error
<awilkins> You did the initial checkout as root?
<bialix> vila: hi
<Spabby> ah
<Spabby> i did the inital checkin as root
<Spabby> the files where already on the server
<awilkins> Something is probably owned by root that you haven't got rights for as your new user
<Spabby> I htink I need to make a new group
<awilkins> Either change the ownership to the new user, or create a group for commit rights and change the group ownership to that
<Spabby> add the users to that group and give ownership to that group
<Spabby> lol
<Spabby> thanks
<vila> bialix: hi !
<bialix> I'm glad you're back
<awilkins> I still haven't figured out the setuid bit
<bialix> or at least you're here
<awilkins> But that's probably not relevant
<bialix> vila: lifeless asked about filing the bug re broken read-only access
<bialix> to lp
<bialix> I dunno maybe you already filed it
<vila> bialix: nope, I was off-line yesterday (well more like 36hours), lots of backlog
<vila> I thought jml said he will talk to spiv about it
<vila> if not, I'll file the bug, but the description may be a bit vague
<vila> or we may just copy the irc discussion about it
<bialix> if the doc-ru branch is still has this bug you can use it as example
<vila> It's unclear to me if it's a bzr bug or really a launchpad-code bug though as a bzr client has no way to know whether it is talking to the writable version or the read-only version, and for the fixer script in bug #354036 just *can't* update the read-only branch
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<vila> jelmer: ping
<spiv> jml: (wow, qbzr 0.9.2 is pretty ancient)
<spiv> jml: (d'oh, thanks for combination of suspend+resume and TCP for making me bang random keys into IRC...)
<LarstiQ> james_w: ho hum. bzr deb:package doesn't work. I add a 'sources.Lookup(name)' in front of the while, and it does
<james_w> LarstiQ: oops
<LarstiQ> james_w: so for some reason apt_pkg returns different values for sources.Lookup(name) on the two runs
<LarstiQ> james_w: (it does work in one go on packages in the main archive, but this one is in /etc/apt/sources.list.d/company.list)
<james_w> weird
<LarstiQ> quite
<james_w> it seems like adding an extra call would make the first case fail?
 * LarstiQ thinks the apt_pkg interface is weird anyway
<LarstiQ> james_w: correct
<james_w> definitely weird
<bialix> vila: am I understand correctly you're author of netrc std plugin?
<LarstiQ> bialix: he is
<bialix> does this plugin really needed on Windows?
<LarstiQ> james_w: ah, I see.
<james_w> bialix: I doubt it is
<LarstiQ> james_w: it can return None on any call, so the while loop won't work
<LarstiQ> bialix: needed? No. does `python -c 'import netrc'` work?
<bialix> import itself works
<bialix> does netrc itself works -- I dunno
<bialix> I don't think netrc is somehow related to vanilla Windows
<LarstiQ> bialix: right. I don't know if people use it on windows, if it can work, that would be ok.
<LarstiQ> but if it doesn't work, ditch it
<bialix> I know I'm not using netrc, so I'm just deleting this plugin every time
<bialix> why this support lives in a plugin?
<LarstiQ> bialix: afaik the main goal is to provide a reference implementation of a credential provider
<bialix> ok
<bialix> but it could be great example even if it will be in the core
<bialix> loading more plugins -> more delay at startup
<bialix> @win32
<LarstiQ> bialix: more of a delay then when netrc would be in core?
<bialix> well, I know the difference is negligible small
<bialix> but it is
<LarstiQ> bialix: interesting. I'm not opposed to moving it to core, if you'd like to suggest that.
 * bialix just ramblings
<bialix> I've tested converison of qbzr trunk to bbc
<bialix> everything seems ok
<LarstiQ> james_w: no claims that I understand apt_pkg, but: cache = apt_pkg.GetCache(); package = cache[name]; package.VersionList
<vila> bialix: I doubt netrc is of any use on windows
<LarstiQ> james_w: scratch that, doesn't seem to relate directly to the sources.Lookup either, meh
 * bialix does not like unused things
<bialix> as jam reported he found any file operations on win32 is much slower than on linux
 * vila thinks bialix should suffer like hell when looking the dlls on windows :)
<bialix> so any unused plugin leads to slow down at start
<vila> bialix: hmm, I see
<vila> But I don't see an obvious way to avoid that either :-/
<bialix> why it should be a plugin and not in the core?
<vila> Funny you ask, poolie raise a similar issue this morning. Larstiq is right though, I intended it to be an *example* plugin people could copy/paste
<bialix> wow! qbzr repo shrinks after upgrade 4M -> 1M
<bialix> vila: if this is a pure example, can it be placed in the folder "examples" ;-)
 * LarstiQ does actually use the netrc plugin
<vila> bialix: it;s not pure, it is meant to be useful too :-)
<bialix> but not for windows user?
<vila> bialix: not for the average windows user. I'm sure some of them have managed to use some exotic ftp client that use the '.netrc' file :-D
<bialix> yep
<vila> ',netrc' is one of those "standard" files from the 70's
<bialix> is this known effect for bbc: it works much faster when there is only one pack in the repo?
<spiv> bialix: it is known that it helps a lot to pack after upgrade to bbc.
 * bialix will keep building custom bzr.exe without this plugin
<bialix> spiv: it was already packed
<bialix> I'm testing format 2a in temp dir
<sodoku> hey, we are doing c prrogramming homework every week at university. Some parts should evolve durings the homeworks. Any suggestions how to manage this with bzr?
<bialix> spiv: but after upgrade repo has 4 or 5 packs
<spiv> sodoku: possibly a branch per assignment
<vila> spiv: are you aware of the strange bug related to #354036: when the fixer script updates the lp branch, its read-only mirror is not updated ?
<spiv> vila: that's a LP issue rather than a core bzr issue, essentially.
<james_w> LarstiQ: it could just be a bug in apt_pkg of course
<vila> spiv: I agree, but that wasn't the question :-) Though I understand the answer to it is yes, right ?
<spiv> I am aware as of today or maybe yesterday, yeah.
<bialix> that bug is also about lp
<sodoku1> spiv: can i remove or add files to branches? as some files don't need to be kept for all assignments
<vila> jelmer: ping :-)
<spiv> sodoku1: you can always add or remove files from a branch.  I'm guessing you won't be merging much between assignments so you probably don't need to worry about a merge from a later assignment deleting files in an earlier one, for instance.
<vila> ha, no, I meant jelmer: Ping
<spiv> sodoku1: the other obvious option is just one branch, maybe just tag each assignment when you submit it if you want to refer back to the old assignments easily.
<sodoku1> spiv: ok, thanks
<bialix> guys, 2a format is slower for branching standalone branchers
<bialix> do you aware of this?
<sodoku1> spiv: ok, thanks
<sodoku1> yeah, thats what i thought og
<spiv> bialix: I think so, igc has been doing a fair bit of benchmarking with the "usertest" tool with large branches.
<spiv> bialix: ISTR that being one of the known weaknesses still to be fixed.
<bialix> ISTR?
<spiv> I Seem To Recall
<spiv> It might be interesting to know the numbers on Windows though, I don't think there's been much benchmarking done there with the new format yet.
<sodoku1> spiv: which option would you prefer?
<spiv> Probably the results are proportionately the same as other platforms, but it's always worth checking...
<bialix> on kerguelen maybe?
<spiv> bialix: yeah, that's probably a good option
<spiv> sodoku1: I dunno, it'd depend on what how it turned out :)
<bialix> I don't have enough channel to download really BIG repo to test
<sodoku1> spiv: branches would keep different folders for every branch? that would be better, as my dumb teacher doesn't understand bzr ;)
<spiv> sodoku1: I'd start with a branch for the first assignment, then when the next assignment starts decide then if it makes sense as a continuation of that branch, or a branch of that original assignment, or an entirely new branch.
<spiv> Right, there would be a folder for each branch.
<spiv> (But you could still use a shared repository, see the init-repo command, to save disk-space)
<sodoku1> spiv: ok, i will do it that way. Big thanks
<spiv> bialix: yeah.  Maybe mail igc with your observations, and ask if he wants to try testing on kerguelen?
<spiv> bialix: or volunteer yourself if you aren't busy enough ;)
<bialix> no, thanks
<spiv> Certainly it might be good for igc to post an update with his latest numbers so we known where the known issues are.
<spiv> bialix: :)
<bialix> I've sent some numbers to bz ML
<bialix> spiv: I'm no more bzr dev
<spiv> bialix: cool, thanks
<spiv> bialix: I appreciate your input and efforts regardless of team membership :)
<spiv> bialix: btw, qbzr is pretty neat!
<bialix> thx
<spiv> It and kcachegrind are why I have qt installed on my system :)
<bialix> unfortunately me and Gary have too little time to make it really cool
<bialix> spiv: I can't push 2a branch to LP yet?
<bialix> so
<spiv> bialix: Hmm, I don't think so, but I think they are planning on upgrading their bzr to 1.16 basically at the same time as it releases.
<bialix> ok, I've tried to test time of push
<bialix> will wait then
<fullermd> What the frell?
<fullermd> I can't upgrade from dev6 to 2a because "Does not support nested trees"??
<jelmer> fullermd: patch pending
<fullermd> Or dev7...   I thought 2a _was_ dev7, just with a different string...
<LarstiQ> james_w: http://apt.alioth.debian.org/python-apt-doc/apt_pkg/cache.html#pkgsrcrecords Lookup docs seems to imply you need to call it once per version.
<james_w> that's what the while loop does isn't it?
<LarstiQ> james_w: except the first version can return None, and the second will return 1
<LarstiQ> james_w: in which case, the while loop will not call Lookup for the second version
<LarstiQ> james_w: also,  Lookup seems to cycle between versions, so you can't count on StopIteration or the like..
<james_w> weird
<LarstiQ> yeah
 * LarstiQ will go bother mvo with it
<sven_> hi! is it normal that bzr gives conflicts after uncommit + revert on a fresh branch?
<sven_> specifically, i did: bzr branch lp:mysql-server ; cd mysql-server ; bzr uncommit -r date:2008-12-01 ; bzr revert
<sven_> that gave conflicts like "Conflict: can't delete mysql-test/collections because it is not empty.  Not deleting."
<sven_> and also one conflict like "Conflict adding file mysql-test/include/diff_tables.inc.  Moved existing file to mysql-test/include/diff_tables.inc.moved."
<sven_> is this a bug?
<fullermd> I can certainly imagine cases where conflicts would be caused.  I'm not sure whether they apply here though.
<sven_> fullermd, shouldn't branch+uncommit -r date:2008-12-01+revert be the same as branch -r date:2008-12-01?
<fullermd> No, not really.
<fullermd> `branch + pull --overwrite -rdate:2008-12-01 .` would be more equivalent.
<fullermd> Prior to the revert you have a pile of uncommitted changes sitting around, which may conflict with going to the base state.
<sven_> fullermd, ok, thanks for explaining! i'll try pull --overwrite instead.
<fullermd> Well, really using branch -r would be the best choice if that's what you want to end up with   :p
<fullermd> Saves a lot of steps (and copying a fair hunk of data, if you're crossing repos)
<sven_> fullermd, right, of course :-) i just wanted to know why branch+uncommit+revert didn't work the way i expected
<sven_> when i run bzr gci, i get this stack trace: http://pastebin.com/m40b8163a . i'm using the latest bzr from http://bazaar-vcs.org/bzr/bzr.dev/ and the latest gtk plugins from http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/
<spiv> sven_: I think bzr-gtk is a little behind recent changes in bzrlib's API.
<pygi> it is, yes spiv
<vila> sven_: a patch is under review
<sven_> spiv, vila, ok, thanks. any idea which revision of bzr i can revert to?
<vila> sven_: not from the top of my head, search for a progress bar related commit by martin pool
<spiv> sven_: tag:bzr-1.15.1 is probably simplest.
<sven_> vila, spiv, thank you!
<pygi> hi vila btw
<vila> pygi: hi :)
<rchady> Is it possible to change the name of the repo?  i.e. configure bzr to use .mybzr or similar?
<fullermd> Not without hacking bzr.
<gioele> hello
<rchady> bummer ok
<rchady> hoped there was a config option
<gioele> playing with bzr fast-import I messed up a branch. Give that I cannot remove the working tree because it contains some valuable but ignored files,
<gioele> I was thinking about copying the .bzr directory from the push location over the mangled .bzr directory in the branch. Are the two bzr directories compatible or are they different?
<fullermd> Fortunately, the answer to that is simplicity itself.
<fullermd> "It depends"   :)
<gioele> fullermd: on what?
<fullermd> Well, pretty much on details of what each location is/has/etc.
<vila> gioele: why don't you try the opposite instead ?
<fullermd> Either or both have internal repos?  Branch heads at the same revision?  WT state the same?  etc.
<vila> copy the working tree over a freshly pulled branch
<gioele> fullermd: each one is a standalone branch (well, one was before having its .bzr corrupted)
<gioele> is it possible to branch into/over a directory that is not empty?
<gioele> I can then remove the corrupted .bzr and "bzr branch $pushed_branch $old_wt"
<vila> gioele: bzr branch --no-tree
<vila> gioele: and then copy your WT (except .bzr) over there
<guilhembi> vila: hello! more and more colleagues are hitting https://bugs.launchpad.net/bzr/+bug/385191 just by upgrading to the latest bzr.dev; could this be prioritized, please?
<ubottu> Launchpad bug 385191 in bzr-gtk "removal of ProgressBarStack has broken bzr-gtk" [Critical,Confirmed]
<guilhembi> vila: they can't commit anymore :(
<gioele> vila: that could be a good solution
<vila> gioele: doing it that way will provide you with a sandbox where you can experiment over and over again
<guilhembi> vila: is there a quick fix that could be pushed ?
<vila> guilhembi: the fix *is* available at lp:~vila/bzr-gtk/385191-new-pb
<vila> guilhembi: it is under review for inclusion in bzr-gtk trunk
<guilhembi> vila: thanks! The faster it goes in the trunk, the least colleagues hit it and have to temporarily downgrade.
<vila> guilhembi: hopefully bzr-gtk-0.96 will be released soon after
<vila> guilhembi: your preaching the choir !!!
<vila> guilhembi: why do you think I marked it critical ? :-D
<guilhembi> vila: the problem is that colleagues are upgrading now, as they have learnt that gcommit saves commit messages when cancelled, in the latest bzr-gtk.
<vila> guilhembi: I know, I'm sorry about that :(
<vila> jelmer: PING
<vila> jelmer: :-)
<guilhembi> vila: Looking to the future: given that bzr-gtk is so critical, would it be possible that, before there is a push in bzr.dev, this somehow automatically runs bzr-gtk tests to verify that the push it not breaking it (even though the fault is more on bzr-gtk here)?
<guilhembi> (fault by not changing code though class was deprecated)
<vila> guilhembi: 1) Not enough tests in bzr-gtk so far, 2) the class has been deprecated since 1.12
<Spabby> awilkins how do I checkout a branch from a central server onto my linux box, it has bzr + olive branch installed
<Spabby> hmm
<Spabby> do I need to create a local branch first before updating it from the central server?
<Spabby> also is the bzr website down for everyone or just me ;)
<spiv> Hmm, it's down for me too.
<Spabby> bah!
<vila> sven_: let's try to go forward instead of backward, how about trying bzr.dev and lp:~vila/bzr-gtk/385191-new-pb ?
<spiv> Spabby: it's back
<Spabby> yep thanks
<Spabby> :)
<sven_> vila, i still get the same crash :-(
<vila> sven_: this one http://pastebin.com/m40b8163a ?
<vila> sven_: then you didn't update bzr-gtk, double-check
<sven_> vila, yes, the same one. i just tried again with the same result: 'cd ~/.bazaar/plugins ; rm -rf gtk ; bzr branch lp:~vila/bzr-gtk/385191-new-pb gtk'
<sven_> vila, bzr version and bzr plugins say this: http://pastebin.com/m2a9b7b11
<vila> sven_: bzr plugins -v
<sven_> vila, http://pastebin.com/m4a4ee23b
<vila> sven_: also, lp:~vila/bzr-gtk/385191-new-pb was missing a minor cosmetic change, try updating your branch and do 'bzr revno' there it should say 648
<vila> sven_: hey, that's a different traceback !
<sven_> vila, ok, i got revno 648, but it still crashes...
<sven_> oh, is it?
<vila> #
<vila> AttributeError: 'gtksourceview2.LanguageManager' object has no attribute 'guess_language'
<vila> #
<vila>  
<vila> no idea about that one though :-(
<vila> sven_: but it doesn't happen here
<sven_> vila, very strange
<sven_> vila, i can repeat it every time. it doesn't matter which repo i'm in when i issue bzr gci
<sven_> vila, shall i report a bug or is this an unsupported branch of bzr-gtk?
<vila> sven_: I'm pretty sure it hasn't been introduced by that branch but by a previous modification in bzr-gtk, additionnally it may be specific to your config, what OS/version are you using ?
<sven_> vila, Linux riska 2.6.24-24-generic #1 SMP Wed Apr 15 15:54:25 UTC 2009 i686 GNU/Linux
<vila> sven_: what distro ?
<sven_> vila, ubuntu
<vila> hardy, intrepid, jaunty ?
<sven_> vila, hmm, how do i tell?
<vila> sven_: Man ! You just *know* it :-D
<sven_> vila, :-)
 * vila shouting: Damn, how do you know which ubuntu version you're using ?
<sven_> vila, ok, cat /etc/lsb-release says it's hardy
<vila> sven_: easy then upgrade !
<vila> oooops
<vila> ok, so bzr-gtk@639 says: Merge GtkSourceView2 migration patch.
<sven_> vila, ok, i guess it was time to upgrade anyways...
<vila> sven_: ha, the README says: In order to see syntax highlighted diffs:
<vila>   * GtkSourceView2 Python bindings (on Debian and Ubuntu systems, these
<vila>     are in the python-gtksourceview2 package)
<sven_> vila, so you mean it's not supposed to work on hardy?
<vila> sven_: wait, I was joking, try the above first !
<vila> a crash is a bug if hardy is not supported traceback is not a good way to tell you
<sven_> vila, ok :-)
<sven_> vila, i have python-gtksourceview2 installed already
<vila> sven_: and it's still crashing ?
<bengee> hi, not sure if this is an faq: I have a project with a couple of modules (in sub-directories) and I'd like to allow checkouts of individuals modules, is that possible or do I need a separate branch for each module?
<sven_> vila, yes
<vila> sven_: argh, so either I install a VM with hardy or you upgrade to jaunty :-/
<vila> in any case, please file a bug while you can reproduce it
<sven_> vila, ok, i filed https://bugs.launchpad.net/bzr/+bug/386359
<ubottu> Launchpad bug 386359 in bzr "bzr gci crashes on Hardy w gtk from lp:~vila/bzr-gtk/385191-new-pb" [Undecided,New]
<vila> thanks
<vila> sven_: Can you try http://paste.ubuntu.com/194407/
<bialix> vila: can we talk a bit about SavedCommitMessageManager from bzr-gtk?
<vila> bialix: EOVERFLOW :-/
<sven_> vila, yes, that works!
<vila> bialix: ha, wait :D
<vila> sven_: great ! At least you're unblocked !
 * bialix explodes
<bialix> and wait
<sven_> vila, yes, thanks!
<vila> bialix: I still have a huge mail backlog so if thins have been discussed further on the qbzr ML I may not be up to date
<bialix> no, it was not discussed yet
<bialix> but if you're busy with your mails, maybe I need to wait couple of days
<bialix> I just have couple of questions about design of that class
<bialix> it seems you've touched it
<bialix> but may be not you wrote it
<vila> guilhembi: ping
<davidstrauss> How does bzr detect whether something is a line-mergable text file?
<davidstrauss> bzr gave me a "contents" conflict on a .test file that's actually just php
<Peng_> davidstrauss: It just checks for the presence of NUL bytes.
<davidstrauss> hmm
<LarstiQ> davidstrauss: was there a file-kind change involved?
<davidstrauss> no
<davidstrauss> But there are people editing on Windows and other funky platforms
<davidstrauss> thought line endings are consistent
<ronny> sup
<ronny> LarstiQ: aware of anyone here toyed with the idea of tracking changes instead of snapshoots
<LarstiQ> ronny: darcs
<LarstiQ> ronny: in essence it is a dual problem
<ronny> LarstiQ: that one is not exactly usable out of its user-oriented cli
<LarstiQ> ronny: right. Coudld you elaborate on what you're looking for?
<ronny> LarstiQ: well, im looking for more things that allow version controll in terms of related changes instead of snapshoots
<ronny> kills the need for rebase and the most kinds of merges
<LarstiQ> ronny: quilt, mq, looms, that sort of thing?
<ronny> LarstiQ: those are at best workarounds, changes are not first class members of the history there
<ronny> LarstiQ: bascially darcs and camp are the only ones that do at least the basic structure reasonable
<fullermd> There are just as many problems that come from states being derived as there are from changes being derived.  They're just different problem.
<ronny> fullermd: i want something that can deal with heavy cherrypicking propperly
<jelmer> ronny: subversion >= 1.5 does that to some extent
<jelmer> ronny: better than bzr/hg/git afaik
<ronny> jelmer: svn is not distributed, and i doubt they have a sane ui
<LarstiQ> ronny: svk? ;)
<ronny> LarstiQ: whenever i tried that one it was epic fail
 * LarstiQ nods
<fjlacoste> my gpg env seems screwed
<fjlacoste> gpg: problem with the agent - disabling agent use
<fjlacoste> aborting commit write group: SigningFailed(Failed to gpg sign data with command "[u'/usr/bin/gpg', '--clearsign']")
<fjlacoste> bzr: ERROR: Failed to gpg sign data with command "[u'/usr/bin/gpg', '--clearsign']"
<flacoste> anybody way i could get more info out of this failure
<LarstiQ> flacoste: is gpg agent usable outside bzr?
<LarstiQ> flacoste: wild guess, GPG_TTY?
<flacoste> LarstiQ: it is running, but kmail doesn't seem to be able to use it either, so i guess not
<flacoste> but BZR does prompt me for my passphrase
<flacoste> hmm, $GPG_TTY is not set
<flacoste> but GPG_AGENT_INFO is
<LarstiQ> flacoste: in my case, when that happens, I take out the openpgp card from the reader and reinsert it
<flacoste> and running gpg from a terminal works (but the agent doesn't there either)
<flacoste> lol
<flacoste> i don't have a card
<LarstiQ> flacoste: GPG_TTY need not be, but in some cases the agent can't find the tty to acquire the passphrase from. Doesn't seem to be this case.
<LarstiQ> flacoste: right :)
<flacoste> i've reinstalled on another computer
<flacoste> in my other working setup, pinentry-qt4 is used
 * LarstiQ uses pinentry-curses
<flacoste> if i run gpg-agent by itself in the terminal
<flacoste> i get
<flacoste> gpg-agent: gpg-agent running and available
<LarstiQ> flacoste: right
<LarstiQ> flacoste: try gpg -d some-encrypted-file
<LarstiQ> flacoste: or ssh-add -L if you've started gpg-agent with --enable-ssh-support
<flacoste> nope, the default ubuntu setup is used
<flacoste> and gpg-agent is run inside ssh-agent
<LarstiQ> ok
<flacoste> [francis@Casteneda testfix]$ gpg -d zdaemon.conf.asc
<flacoste> You need a passphrase to unlock the secret key for
<flacoste> user: "Francis J. Lacoste <francis.lacoste@Contre.COM>"
<flacoste> 1024-bit ELG-E key, ID 96196F76, created 2001-01-18 (main key ID 2CB3F937)
<flacoste> gpg: problem with the agent - disabling agent use
<flacoste> gpg: encrypted with 1024-bit ELG-E key, ID 96196F76, created 2001-01-18
<flacoste>       "Francis J. Lacoste <francis.lacoste@Contre.COM>"
<LarstiQ> right
<flacoste> entering the passphrase on the terminal decrypts the file
<LarstiQ> flacoste: this may be a case of bzr paying attention to the gpg exit code, even though signing succeeded
<flacoste> ah right
<flacoste> [francis@Casteneda testfix]$ echo $?
<flacoste> 2
<flacoste> that's after a succesful clearsign
<flacoste> but with agent problem
 * LarstiQ nods
<flacoste> should I file a bug about that?
<flacoste> i guess so...
 * LarstiQ is checking if there is one
<LarstiQ> why is my battery empty _yet again_â½ :(
<flacoste> #44755 bzr commit fails when GPG agent is unavailable
<flacoste> fix released
<flacoste> i guess not
<flacoste> (low)   	
<flacoste> #54468 sign-my-commits fails when gpg-agent and pinentry-curses are being used
<LarstiQ> flacoste: from the comments I don't see why #44755 would be fixed
<flacoste> i'm reoping with a suggestion to use Won't Fix :-)
<flacoste> any idea of where i should go to get help with my gpg-agent problem?
<LarstiQ> flacoste: did you try the GPG_TTY suggestion?
<LarstiQ> flacoste: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322932
<ubottu> Debian bug 322932 in gnupg-agent "gpg-agent does not play well with other programmes" [Normal,Open]
<flacoste> well, i suspect a deeper issue, since ideally, i'd like also to get it working with kmail
<flacoste> i mean, it's not even working for the gpg command line itself
<flacoste> ah:
<flacoste> ah:
<flacoste> write(8, "GET_PASSPHRASE A2B3F83DE11E0C7247"..., 223) = 223
<flacoste> write(8, "\n"..., 1)                    = 1
<flacoste> read(8, "ERR 67108949 No pinentry <GPG Age"..., 1002) = 37
<flacoste> write(2, "gpg: "..., 5gpg: )                 = 5
<flacoste> seems that gpg-agent thinks there is no pinentry configured
<flacoste> do you happen to know how this is usually configured?
<flacoste> ah!
<LarstiQ> flacoste: my ~/.gnugp/gpg-agent.conf has: pinentry-program /usr/bin/pinentry-curses
<flacoste> yep, just found that
<flacoste> it seems it points to a now non-existent program
<flacoste> that's what happens when you copy config files voer
<LarstiQ> doh :)
<flacoste> LarstiQ: all sorted out now, thanks for the support!
<LarstiQ> flacoste: gladly :)
#bzr 2009-06-13
<lifeless> jelmer: ping
<lifeless> jelmer: whats a good, small, example of using tdb from C?
<dash> Hmm
<lifeless> mmmm
<lifeless> bacon!
<lifeless> So dash, whats your bacon number?
<dash> I just merged from trunk into my feature branch and now it wants to undo all the changes I made
<dash> maybe not all, but enough for me to feel like I did something wrong
<dash> should I remerge? should I merge from my feature branch into a copy of the mainline?
<lifeless> dash: the merge command undid your changes?
<Peng_> 1.) What command did you run? 2.) You're not using anything weird like bzr-svn, are you?
<dash> yes, bzr-svn =/
<dash> oh, you know what
<lifeless> Peng_: I bet its a backout merge from trunk; but we should track it down
<dash> yeah this is probably my fault
<lifeless> dash: was it the merge command that undid your changes?
<dash> so I did "bzr merge http://svn-server/..../"
<jelmer> lifeless: I think tdbdump might be a good example
<lifeless> jelmer: point me at the src?
<dash> 'bzr diff' now shows a diff that will remove a bunch of my changes
<lifeless> dash: ok.
<jelmer> lifeless: apt-get source tdb && $VISUAL tdb-*/tools/tdbdump.c
<lifeless> dash: next question. Had you on trunk, *or on a branch merged into trunk* undone those same changes
<dash> yes
<lifeless> dash: then bzr is correctly propogating those undoes.
<jelmer> lifeless: and tdbtool for an example of writes
<dash> yeah, i figured
<dash> hence saying it was my fault :)
<lifeless> dash: :)
<lifeless> dash: just being sure
<lifeless> dash: you should just reject the undo here.
<dash> i checked this code into svn, then later reverted it
<dash> lifeless: right
<lifeless> I loves it when tools DTRT
<dash> i love it when they don't surprise me :)
<dash> i guess i should do the merge in 2 stages then
<dash> one to reject the rollback done earlier
<dash> and one to pull in the rest of the changes
<lifeless> dash: no, you should merge, reject, commit
<lifeless> one step
<lifeless> dash: that will mean that the next merge from this branch to trunk will reinstate these changes
<dash> hm! ok
<lifeless> and [correctly] show that you wanted them present on this branch at every point.
 * dash  makes a copy of his branch to make sure he didn't misunderstand :)
<dash> lifeless: the difficulty is that the mainline contains changes I _do_ want
<lifeless> dash: thats fine
<lifeless> dash: the way you reject could be to use 'bzr shelve'
<dash> true.
<lifeless> dash: another way to reject is
<lifeless> bzr merge -r [revert-in-trunk]..[revert-in-trunk-1] $trunk
<lifeless> oh
<lifeless> bzr merge -r [revert-in-trunk]..[revert-in-trunk-1] $trunk --force
<lifeless> (because you already have a merge in your tree)
<dash> that's what i meant by doing it in two steps
<lifeless> dash: with only one commit
<lifeless> ?
<dash> oh, didn't know you could do multiple merges with a single commit.
<lifeless> so
<lifeless> specifically
<lifeless> 1) merge trunk
<lifeless> 2) merge -r X..X-1 trunk --force
<lifeless> 3) commit
<lifeless> so 2) == reject
<dash> hah.
<dash> even nicer than what i was trying to do.
<dash> that makes more sense too
<dash> okay! other than having to resolve the same conflicts twice, that seems to have done the job
<dash> lifeless: thanks for the help.
<lifeless> dash: odd that you had to resolve any conflicts
<lifeless> dash: but I'm glad you are happy
<dash> yeah well, i should just know better than to check stuff in and revert it like that. :)
<johnf> could someone please try out 1.16rc1 packages I just buit in the bzr-beta-ppa. I've split out the docs into a -doc package. Need someone to make sure that the upgrade is smooth
<GPHemsley> jelmer: Are you around?
<wgrant> johnf: It seems you accidentally clobbered the Jaunty 1.16rc1 in bzr-beta-ppa with the third Dapper attempt. You also don't have the luxury of python-support or python-central on Dapper, so I wouldn't even try backporting bzr to it...
<johnf> wgrant: there were already dapper packages but they don't seem to want to build after I split out bzr-doc. I think I'll just revert all the changes for it and it can just have one package
<wgrant> johnf: Ah, there is indeed a prehistoric python-support in dapper universe that isn't used for anything. Oops.
<johnf> and I've royally mucked up the version numbers. I should have been changing ~bazaar not the rc :(
<wgrant> johnf: You didn't do too badly - you just incremented the Debian revision, not the RC number.
<johnf> ahh I did do the right thing. Well close enough anyway
<wgrant> ~bazaar[23] would be correct, but what you did isn't world-burning.
<LarstiQ> johnf: och, you didn't muck up like me introducing a wrong version (-bazaar instead of ~bazaar) that ranks higher than all debian versions we'd want to use
<johnf> wgrant: so when would you up -[23]? That is something I've never been quite clear on
<wgrant> johnf: The first number after the last - is the Debian version.
<wgrant> As in Debian the distribution, not Debian the package format.
<wgrant> Debian's first 1.16 version would be 1.16-1.
<wgrant> If they make a change, 1.16-2.
<wgrant> When Ubuntu makes a change to a package, we append 'ubuntu1'. The 1 there is the ubuntu version - we'll increment that as we make subsequent changes.
<johnf> what about in the case where it is say a native ubuntu package do you still always leave at -1 in case it makes it intu debian?
<wgrant> We'll use -0ubuntu1
<johnf> ahh ok makes sense
<wgrant> That way when it makes it into Debian, it'll be -1, and -1 > -0ubuntu1
<wgrant> So upgrades will work when -1 is synced into Ubuntu.
<johnf> ok new packages should be syncing shortly
<wgrant> Have you test-built the Dapper on locally?
<wgrant> s/on/one/
<wgrant> You can reasonably drop Dapper packages in a couple of weeks, too (Dapper loses desktop support RSN)
<LarstiQ> wgrant: ah, I've been looking forward to that
<fullermd> Mmm.  These DeprecationWarning's on py2.6 are gonna get real old real fast...
<wgrant> fullermd: In bzr, or in general?
<fullermd> Well, from pycrypto technically, but since I see it running bzr...
<pthulin> is there a way to merge one project into another? I have two python projects, and now I want them to be the same without loosing history
<wgrant> fullermd: That's fixed in Jaunty and Karmic, at least.
<fullermd> Neither of which is much help to people who run neither Jaunty, Karmic, Ubuntu, or Linux  ;)
<wgrant> http://launchpadlibrarian.net/23631444/python-crypto-2.6-337073.diff is useful, in those strange cases.
<fullermd> Inneresting.
<visik7> ok I'm in a strange situation:
<visik7> I've my working tree out of date
<visik7> how could I know at which version is it ?
<fullermd> Well, you can poke around manually in .bzr/.  At one time, info gave you something you could do some math on.
<fullermd> Or you could use revno/revision-info --tree, but you have to do that in the future.
<lifeless> or just run bzr update
<fullermd> Well, that doesn't make it known.  Just moot   :p
<lifeless> sureit does.
<lifeless> it would be -1
<jelmer> GPHemsley: hi
<fcorrea> hello there. Aw...using bzr 1.13.1 here and working against subversion on the server. Does anyone know why it takes forever to push changes to back to svn? I looked up and found that it used to happen with bzr 0.5-
<fcorrea> btw it also happens when doing bzr co
<jelmer> fcorrea: newer versions of bzr-svn should be a bit better in that regard
<fcorrea> jelmer: will try
<jelmer> fcorrea: also, the first time you do a push/pull it'll be a fair bit slower because it has to analyse the repository, after that it should be significantly faster
<fcorrea> jelmer: yeah, but it also happens when pushing it back to svn, so I assume all the analysis were already done, but I may be wrong
<jelmer> fcorrea: also, how slow is slow?
<Mez> Out of curiosity, any of the bzr people heading to EuroPython?
<Mez> other than you, lifeless
<Mez> (wait, 2 talks? someone with dedication!)
<visik7> I've my working tree out of date
<visik7> how could I know at which version is it ?
#bzr 2009-06-14
<vadi2> Hi, I have a question about bzr-git. My project is using bzr, but I'd like to embed another one in it that uses git. Would it be best to store the git one in another folder outside and just copy over the contents periodically, or can something be fancy done with bzr-git to help with this?
<james_w> vadi2: you would be able to do that with bzr-git
<james_w> it requires nested tree support in bzr, which isn't quite there yet
<james_w> so trying to do it right now would be a bit tricky
<vadi2> alright. I can wait
<vadi2> is there any report I can subscribe to?
<james_w> I don't think so
<james_w> I think there's a wiki page though
<james_w> and there's been plenty of discussion on the mailing list in the last couple of months
<vadi2> https://blueprints.launchpad.net/bzr/+spec/nested-tree-support ?
<vadi2> yep, looks like what I need
<james_w> so, there't the "join" command that can join two trees together
<james_w> but I'm guessing that you're not really joining them, the git project is still external, you just want to embed a copy of it?
<vadi2> yeah.
<james_w> yeah, then you need that nested tree support unfortunately
<vadi2> alright. I've subscribed to the blueprint, so we'll switch as soon as that's in
<james_w> cool
<vadi2> thanks for your time
<visik7> hi guys
<visik7> I'm thinking of implementing a new protocol for bazaar
<visik7> where should I start ?
<Peng_> Just out of curiousity, what kind of protocol? Wh?
<Peng_> Err, why*?
<Peng_> Apparently I'm curious enough to ask, but not enough to stay around for the answer. See you later! :D
 * Peng_ /away!
<AfC> visik7: I assume you're current with all the discussion, analysis, and work that is currently being done with the existing smart server protocol. What do you want to do that is different?
<visik7> I want to implement bazaar over an IM protocol
<KX> ... well that's a novel concept
<visik7> so I could push and pull from my collaborators without an intermediate server and without forcing others to install servers or anything harder than a plugin :)
<visik7> wouldn't be cool if you could just say hey pull from me my latest changes
<visik7> something like bzr avahi but over IM
<Peng_> avahi isn't actually a transport, just a discovery mechanism.
<Peng_> Can IM networks do multiple Mbps of traffic?
<Peng_> Seems like a doable, though terribly inefficient, idea.
 * Peng_ shrugs.
 * Peng_ goes back to being /away.
<visik7> I think is great
<visik7> you'll not discourage me
<visik7> :)
<AfC> visik7: well, if you can "send files" between you and your buddies, then just use `bzr bundle` to create patch bundles and send those across. It's not quite push and pull, but once you receive a bundle you just merge (or pull) as you would normally.
<AfC> (we do that all the time)
<AfC> Otherwise, yes, I imagine the bzr dbus/avahi work that Robert did a few years ago might be a place to start.
<lifeless> fullermd: around?
<lifeless> fullermd: https://edge.launchpad.net/libcpuinfo/ needs a BSD module
<fullermd> lifeless: Hm.  I'll take a look...
<lifeless> fullermd: only if you care ;)
<fullermd> Well, see, I'm thinking of the work I should be doing tonite...   it's tempting to care about classifying toenail clippings instead of that, so...   ;p
<fullermd> Hm.  "the University" is listed in the 3rd clause of the license?
<lifeless> oh foo
<lifeless> I'll correct that
<fullermd> Not to get into a license discussion, but why 3-clause instead of 2?
<lifeless> Isn't 3-0clause the modified? 4-clause was evil
<lifeless> 3-clause is what debian carries as the 'stock BSD'
<fullermd> I tend to use a 2-clause.
<lifeless> so just 1 and 2?
<fullermd> Yah.  It ends up being isomorphic to the MIT/X license.
<lifeless> I'll look into that later
 * fullermd nods.
<lifeless> for now the obvious change is sufficient
<fullermd> How'd you have in mind handling the OS choice?
<fullermd> Just #ifdef's?
<lifeless> if trying to read /proc/cpuinfo will segfault or something
<lifeless> but just chaining the ifs should be simple and easy
<lifeless> if it won't compile a particular check on other platforms then yes ifdefs are solid
<fullermd> Probably won't link, I'd use sysctl(3) (not (1)) on BSD, so...
<lifeless> specifically change
<lifeless> if (result < 1) goto fail;
<lifeless> insert before that
<lifeless> if (result < 1) result = cpuinfo_MODULE_processor_count();
<fullermd> But chaining the if would work OK, there's nothing in /proc but pid's and a curproc symlink (if it's even mounted)
<fullermd> Oh, I was thinking in cpuinfo_proc_cpuinfo_proccessor_count()
<lifeless> I prefer to build as much as possible because it avoids things bitrotting as much
<lifeless> adding a bsd module should be as simple as adding a new .c and .h
<lifeless> and changing cpuinfo_processor_count to call your new function
<lifeless> which itself would return -1 on 'cant tell' or otherwise a count
 * fullermd nods.
<lifeless> proc_cpuinfo is a specific module
<fullermd> Gotcha.
<fullermd> I'll take a poke after I get some coffee...
<lifeless> sweet
<fullermd> lifeless: Push up a branch and figure out how to send a review request?
<lifeless> sure
<fullermd> 'k, sent.
<lifeless> lol copy n paste :)
<fullermd> I don't have any convenient non-BSD systems to check it on, but it should build cleanly I think.
<lifeless> +/* Probe proc/cpuinfo */
<lifeless> testing it
<fullermd> Darn network corruption!
<fullermd> Why did that show up in my bzr mailbox...
<fullermd> Oh, frell.  Freakin' LP...
<lifeless> ta!
<fta> I have a *local* svn repo. how can i import it to bzr? it's huge (> 4GB) so i'd prefer to not to do it over the network, but it's not a svn:// url..
<hsn_> bazaar supports just one .bzrignore file per tree?
 * AfC wonders if there is a fast-export that takes a svn-dump as an import?
<AfC> fta: (I know that Jc2k used svn dumps to import all of GNOME into bzr)
<AfC> oh, wait... can't you use file:/// URLs with Subversion? If so, that should Just Work with $whichever bzr conversion tool you're using (maybe)?
<fta> well, my 1st try was with bzr branch svn://
<AfC> My first use of Subversion was with a file:/// repo, but that was *long* ago.
<fta> ok, i figured out how to start my svn import from my local copy, but for some reason, it's doing a lot of http :(
<fta> [\                   ] http   268885KB   1270KB/s | copying revision 17/14146
<fta> will take a while :(
<fta> it died after 2000 revisions :(
<visik7> is there a way to get a mail on commit ?
<ronny> hmm, where is jelmer?
<davidstrauss> There's a story behind the code name for 1.16, isn't there?
<thumper> davidstrauss: yes
<thumper> jml was wanting to get it out on Thursday
<davidstrauss> thumper: Makes sense now :-)
<thumper> but it ended out being Friday (Sydney time) which was still Thursday on the west coast of the us
<thumper> US
<davidstrauss> I figured it was a time zone thing
<davidstrauss> :-)
<visik7> anyone using buildout ?
<Basic> bzr.dev revision:4439 seems really slow, just a local issue or others notice this too?
<Peng_> I haven't noticed any issues, not that I've used it much.
<Basic> looking at check-ins
<jml> good morning #bzr
<james_w> morning jml
<lifeless> moin
<RAOF> Morning jml.
<jml> RAOF, lifeless, james_w: g'day
<james_w> spot the odd one out
<poolie> hello all
<all> hi
<jelmer> ronny: hi
<poolie> hello ronny
<poolie> and jelmer
<jelmer> fta: hi
<jelmer> moin poolie
<Peng_> Hmmm, all of you here? I smell productivity! :D
<lifeless> nooooooooo
<jml> poolie: hi
<jml> james_w: :)
#bzr 2010-06-14
<magcius> Is there any way to undo a commit?
<lifeless> bzr uncommit
<magcius> lifeless: thanks
<magcius> uh
<magcius> 1) are there any loggerhead maintainers in here? (or should I ask in #lp or #lp-dev)
<magcius> I filed about 2-3 bugs and they're still filed "NEW"
<lifeless> loggerhead is a little light on maintainers at the moment
<magcius> ok
<lifeless> here is as good as any place
<magcius> uh, I also filed a bug on LP and a bug on bzr.
<lifeless> how long ago ?
<magcius> uh
<magcius> lifeless: April
<lifeless> and they're still new ? thats unusual
<lifeless> url?
<magcius> lifeless: er whoops, thought it was new
<magcius> lifeless: er, the bzr one has had progress
<magcius> lifeless: the LP one I believe is "New"
<lifeless> do you know the number?
<magcius> lifeless: er, it's Triaged. There's been a tag, but that's it
<lifeless> there are lots of lp bugs :)
<magcius> https://bugs.launchpad.net/launchpad-registry/+bug/569356
<ubot5> Launchpad bug 569356 in Launchpad Registry "The download background "sliding door" needs more width. (affected: 1, heat: 3)" [Low,Triaged]
<magcius> This one seems a very, very easy one to fix
<magcius> But yeah, the two Loggerhead ones are the ones that I hate the most
<lifeless> I wish loggerhead had more devs
<lifeless> :)
<thumper> lifeless: me too
<lifeless> thumper: do you have any ideas about where we can find them?
<lifeless> thumper: could lp-code start owning it again, perhaps?
<thumper> lifeless: while I'd love to, we don't have any development time to invest
<thumper> lifeless: we're already letting things slip
<lifeless> thumper: is that because your team size changed, or your accepted too much work, or something else?
<thumper> lifeless: primarily team size
<lifeless> sounds like something that should, in principle, be fixed.
<lifeless> eventually.
<thumper> maybe
<thumper> parly it requires someone who cares about the project
<lifeless> definitely
<lifeless> I guess I see the lp-code team as that in the sense that its deployed  in LP :)
<lifeless> maybe thats not enough.
<thumper> no it is not enough
<thumper> we don't really use loggerhead
<thumper> sure, we have it deployed on LP
<thumper> but I really don't use it that often
<willmarshall> Git user's question about BZR: I want to branch my current branch, then commit that new branch back to my server while I work on an experimental feature
<willmarshall> How would I do this?
<lifeless> bzr branch . ../new; cd new; bzr push $server_url
<lifeless> or just bzr push $server_url, and then keep working
<lifeless> if you want to let trunk move on for a while, you might instead do
<lifeless> bzr branch . ../new; $work_in_new_for_a_while
<lifeless> bzr merge ../new; bzr commit -m "merge in some progress"; bzr push
<willmarshall> That worked! Thanks :)
<lifeless> anytime
<lifeless> jelmer: ping
<BlindWolf8> Hello?
<lifeless> hi
<BlindWolf8> Hey lifeless
<BlindWolf8> I wasn't paying attention to the chat. You still here?
<lifeless> passing through from time to time
<lifeless> its roughly dinnertime here
<BlindWolf8> Gothca. About 1:45 AM here (US EST/EDT)
<BlindWolf8> I do have a quick question for you if you have a moment.
<lifeless> sure; in general just ask your questions
<lifeless> in this medium, someone will usually answer eventually
<BlindWolf8> Would I easily be able to change my repository style once it's made?
<lifeless> what do you mean by style ?
<BlindWolf8> feature branch, colocated, shared repo, etc.
<lifeless> sure
<lifeless> the only thing that isn't easy to change is the /format/ - which you shouldn't need to be concerned with at this point
<BlindWolf8> If I need to, I'm confused on how to do this as...
<lifeless> so just go ahead and play
<BlindWolf8> 1) I forgot what I chose when setting it up...
<BlindWolf8> ...and 2) not files are listed on the seerver. I am not sure if this is normal.
<lifeless> bzr branches and repositories store their files in .bzr/
<BlindWolf8> *no files
<BlindWolf8> yeah, I looked in the .bzr folder on the server
<lifeless> its a form of database. So your source code is only present on your workstation
<lifeless> this is normal
<BlindWolf8> no files are readable...I'm assuming they're all compressed/packed
<BlindWolf8> ah, OK.
<BlindWolf8> what would I do in a case in which I wanted the files to be accessible?
<lifeless> well it depends on why
<lifeless> for instance
<lifeless> if you want to deploy to a web server; use the bzr-upload plugin
<lifeless> if you want to browse the files and history with a web browser, use loggerhead
<BlindWolf8> ah, I'm assuming that would update the bzr db and upload the file as well?
<lifeless> bzr-upload works without the .bzr database
<lifeless> for security
<lifeless> it uses a very small record of whats been uploaded so that it can only upload changed files
<BlindWolf8> right, but where would it keep revisions?
<lifeless> bzr-upload ? it has them on your source branch, wherever that is - normally your workstation.
<BlindWolf8> ah, OK, so it won't make a .bzr dir on the server for security reasosn, only locally...OK, that makes sense
<lifeless> collaborating on your source code, and deploying it to a webserver are very different tasks
<BlindWolf8> agreed
<lifeless> does this help? I realise I haven't answered the direct question :)
<BlindWolf8> yeah, it helps...I was just shocked as I didn't see any files on the server...just a bit concerned about things being compressed
<BlindWolf8> figured that I would need to do something different for webdev, but the doc explains it about 80%...I may have missed something
<lifeless> if you ssh into your server
<lifeless> and run 'bzr log -p' you'll see all your patches going back to the start of your history
<lifeless> (run that in a branch on the server)
<BlindWolf8> Also, I'm assuming that all revisions are copied to clients as well?
<BlindWolf8> in their .bzr dirs?
<lifeless> when you do 'bzr branch server localdir' , it copies all the history by default
<BlindWolf8> My main concern was that if the server got hacked/fubared, I'd be SOL
<lifeless> there are options that you can pass to copy less than everything (--stacked, specifically) - but its not the default.
<BlindWolf8> I do Pull via the GUI, so I'm assuming it gets all the revs
<lifeless> yes
<BlindWolf8> Good, everyone's up to date and can do a restore if needed
<lifeless> (unless you made the branch stacked - but I don't think bzr explorer has an option to do that)
<BlindWolf8> and the restore will rebuild all the revisions...sweet
<BlindWolf8> so Bazaar == RAID, lol
<fullermd> RAIR.  Blood RAIR.
 * fullermd licks his lips.
<BlindWolf8> 0_\
<BlindWolf8> Anyway, thanks again lifeless
<BlindWolf8> I'd be happy to write some docs/tutorials
<BlindWolf8> Still here?
<lifeless> yes
<BlindWolf8> OK. When I was having my teammate setup bzr, I had him pull our branch from the repo I setup.
<BlindWolf8> bzr prompted him to turn the dir he was putting the files into a repo. I told him to select No, as there seems to be issues with doing that.
<BlindWolf8> Why would you want to turn the local dir into a shared repo?
<BlindWolf8> Whoops, back.
<vila> hi all !
<BlindWolf8> hey vila
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
<lifeless> BlindWolf8: 'shared' in shared repo refers to 'between branches' not 'between users'
<lifeless> BlindWolf8: so you want that to make switching between branches fast and efficient
<vila> BlindWolf8: The repo is where revisions are stored. Once you start having multiple branche of the same project, using a shared repo means all common revisions are stored only once
<BlindWolf8> in a common .bzr dir?
<vila> BlindWolf8: yes
<lifeless> one .bzr dir for the history, one .bzr per branch, but without history
<lifeless> the branch ones get their history from the repository .bzr dir
<BlindWolf8> then what does each .bzr dir store for each branch?
<lifeless> the branch configuration, the revision id of the branch's most recent commit and the tags for the branch
<BlindWolf8> Before, you mentioned that if I wanted to do webdev, it wouldn't upload the revsision history. What if I wanted to regardless?
<BlindWolf8> vila: you've been credited, btw.
<vila> BlindWolf8: Me ? Credited ? Argh, what did I do wrong again ? :)
<BlindWolf8> lol
<vila> BlindWolf8: bzr-upload aim is to maintain a remote working tree *without* its history, if you want to update a remote working tree whenever its history change, you want the bzr-push-and-update plugin (which requires bzr on the server and an ssh access IIRC)
<vila> the two plugins work from a different set of constraints and address different needs
<BlindWolf8> Thanks for that info. All of this is very helpful.
<BlindWolf8> By the way, why would someone want a checkout when they can just bind a branch?
<vila> BlindWolf8: Don't summon fullermd ....
<vila> BlindWolf8: a checkout *can* be configured to use a branch on a remote server without any history stored locally
<fullermd> Who dares invoke the Great and Powerful fullermd??
<vila> fullermd: someone wanting clarifications about checkouts and bound branches :-P
<BlindWolf8> :-P
<fullermd> First, you must pass the Seven Trials of Courage.
<BlindWolf8> Hey Matt, we're going to incur your wrath
<BlindWolf8> so anyways....
<BlindWolf8> binding a branch to a dir makes bzr more like Perforce, which is the first VCS/SCM I used
<BlindWolf8> As far as I know, I've got this: http://wiki.bazaar.canonical.com/StandaloneTree
<BlindWolf8> on the server, anyways
<BlindWolf8> the clients/workers have the same thing, but they have a full revision history (Heavyweight Checkout)
<BlindWolf8> the files are also viewable/changable on their machines, and not sotred in the .bzr dir
<BlindWolf8> (not sure what to call that...Working Tree?)
<vila> yes, see http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief
<BlindWolf8> Thanks! If you guys need helps in organizing docs or making things clearer, I have a knack for that
<vila> BlindWolf8: help is always welcome, have a look at https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=doc, or clarify anything you didn't understand in the actual docs :)
<BlindWolf8> You guys rock! :-D
<lifeless> vila: https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27473
<vila> lifeless: Updating diff... :-)
<lifeless> vila: pull it :)
<lifeless> vila: I'm going to cook dinner
<lifeless> vila: but I'd *love* to get this landed
<lifeless> vila: so if you can pp it for me, that would be most awesome
<lifeless> I'll pop back in a bit
<vila> lifeless: enjoy your cooking and don't worry, I *need* this patch
<vila> lifeless: (I even thought it has already landed :)
<BlindWolf8> I'm out. Thanks again you guys!
<vila> lifeless: 4 tests erroring out, see mp
<lifeless> thank you
<lifeless> vila: that will be shallow
<vila> lifeless: certainly
<vila> well, hopefully :)
<saxicek> hello everybody
<lifeless> vila: they work for me
<lifeless> vila: disable your non-core plugins
<vila> lifeless: already done, I've kept only loom...
<lifeless> :!bzr selftest --no-plugins bzrlib.tests.blackbox.test_push.TestPush.test_push_smart_tags_streaming_acceptance test_switch_lightweight_directory bzrlib.tests.blackbox.test_tags.TestTagging.test_branch_push_pull_merge_copies_tags bzrlib.tes
<lifeless> ts.blackbox.test_tags.TestTagging.test_list_tags
<lifeless> bzr selftest: /home/robertc/source/baz/bzr-test-fixes/bzr
<lifeless>    /home/robertc/source/baz/bzr-test-fixes/bzrlib
<lifeless>    bzr-2.2.0dev1 python-2.6.5 Linux-2.6.32-22-generic-x86_64-with-Ubuntu-10.04-lucid
<lifeless> ----------------------------------------------------------------------
<lifeless> Ran 4 tests in 1.207s
<lifeless> OK
<vila> !paste
<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.
<vila> http://paste.ubuntu.com/449550/
<lool> vila: Heya
<lool> vila: With whom should I discuss performance of the gcc-linaro branches?
<vila> lifeless: and even without loom:  running 5(?) tests, failed 3 :-/
<vila> lool: here should be fine, filing a bug report tagged udd, about the slow checkouts will be even better
<vila> lool: not finished replying to your emails, but you can try --hardlink too for branch and checkout
<lool> vila: Would you think it's something fixable, or will we always suffer from the size of history + size of the tree?
<lool> vila: In my experience, the CPU was maxed for long periods of time during the lenghty operations, not I/O
<vila> lool: I suspect it's more a tree size bug than an history size one
<lool> (I'm on SSD BTW)
<saxicek> Can you guys please help me with setting custom merge app in bazaar explorer? I tried "d:/Program Files/Beyond Compare 3/BComp.exe" %r %b %t %o but I am getting "Error while running merge tool (code 0)" but did not see what it is actually trying to run in the log
<vila> I got worse performances for massive IO on SSD than on 7200rpm HDs
<vila> lool: ^
<lool> vila: BTW what is the udd tag for?  Does it cover code imports or is it just for package imports?  Cause here it's a code import branch, not a package import one
<vila> lool: it's for Ubuntu Distributed Dev
<lool> vila: Ok; I have a relatively unreliable I/O indicator in my panel which showed modest amount of I/O, and CPU maxed out, so I didn't blame it on I/O but it's not 100% out of the picture I guess
<vila> lool: if you use the stock performance monitor, setting Red as the color for IOWait instead of the default black will show you some interesting side-effects
<lool> vila: Yes, one CPU ws 100% busy with both IO wait and actual work
<vila> lool: try on a regular disk or use a better SSD ;-) The CPU@100% needs to be investigated, filing a bug is the best way to ensure it's not forgotten
<lifeless> vila: lets let pqm decide ;)
<vila> lifeless: AttributeError: 'GenericInterBranch' object has no attribute 'tags' looks unambiguous to me
<jelmer> lifeless: pong
<lool> vila: bug #593560
<ubot5> Launchpad bug 593560 in Bazaar "Slow performance for many operations on the gcc code import branches (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/593560
<vila> lifeless: plus you should be running 5 tests not 4, the 5th one is bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags_revision_filtering caught by bzrlib.tests.blackbox.test_tags.TestTagging.test_list_tags, are you sure !bzr use the right bzr ?
<vila> lool: first comment, I didn't noticed it earlier but using *different* projects for gcc-linaro and gcc, defeats the stacking scheme defined on lp, you'd better use the 'gcc' project itself
<lool> vila: Does it matter for the project series branches, or for the actual branches or both?
<lifeless> vila: when only two people are speaking pastebin is a nuisance :P
<lool> vila: I mean, I can have gcc-linaro/4.4 point at ~gcc-linaro-dev/gcc/linaro-4.4 or something like that
<lifeless> vila: did you pull my branch, or merge it ?
<vila> lifeless: pull
<lifeless> vila: aah, yes, ./bzr :P
<lifeless> ok will fix
<vila> lool: one stacked-on branch is defined by project on lp AFAIR
<vila> lool: it's called the devlopment focus on lp I think
<lool> vila: How would I setup my branches to tell LP that they are stacked on multiple branches of the gcc project
<lifeless> jelmer: it was InterBranch.pull I was pinging about
<lifeless> jelmer: its rather odd in trunk
<lool> vila: IOW that ~gcc-linaro-dev/gcc/linaro-4.4 is stacked on lp:gcc/4.4 and same for 4.5
<lifeless> lool: you wouldn't, why do you want to do that ?
<lool> vila: the gcc development focus is the trunk vcs-import
<lool> lifeless: Well, gcc development results in yearly releases with relatively lots of changes in 4.4 and 4.5 branches, we're mostly going to work on 4.4 and 4.5 branches as a baseline, maintaining forks basically
<vila> lool: I don't think you want to do that on lp (nor that you can), either you define branches in the gcc project or you define a development focus in gcc-linaro (the former sounds better to me)
<lool> the gcc focus of development correctly points at trunk which is always where most development is going on
<lifeless> lool: sure, but you can have all the history in lp:gcc, so that stacking is always efficient
<lool> vila: Oh I did define a development focus on gcc-linaro
<lool> vila: I had to chose a branch, so I picked the 4.4 one
<lool> lifeless: You don't have history of the 4.4.x and 4.5.x commits surely?
<vila> lool: wrong :) Then your push for 4.5 needs to carry all the missing revisions
<lool> lifeless: They are backports at the patch / SVN level upstream, but from bzr pov, they are entirely separate branches
<vila> lool: no, all the imports are from the same master svn repo, the revisions are shared
<lifeless> lool: nevertheless, we can, with cron, get all the content into one branch.
<lool> vila: It's true, but 4.4 and 4.5 will differ significantly, and most of the work will happen in 4.4 right now; if I setup 4.5 as dev focus, I will miss the 4.4 revs when pushing 4.4 based branches
<lifeless> lool: its 3 lines of python and a pear tree
<lool> lifeless: awesome, that sounds like something we would want
<lifeless> lool: stacking is an approximate thing, don't aim for perfection.
<lifeless> lool: 1 years dev on a 25 year old tree is peanuts
<lifeless> you'll have many more issues that aren't related to how much is/isn't shared in stacking.
<lifeless> we're working on that at the moment.
<lifeless> vila: fixed
<lifeless> vila: missing .source
<lool> lifeless: So how would I ask for this cron to be setup, or are you saying that it's probably not going to gain much?
<lool> vila: I've changed development focus to gcc-linaro/4.5 now
<lifeless> lool: r1 = bzrlib.repository.Repository.open('lp:gcc-linaro/devfocus'); r2=bzrlib.repository.Repository.open('lp:gcc-linaro/4.4'); r1.fetch(r2)
<lifeless> lool: repeat as needed
<lifeless> you need to import bzrlib.repository
<lifeless> and bzrlib.plugin
<lifeless> and do bzrlib.plugin.load_plugins()
<lool> cute
<lifeless> separated concerns ftw
<vila> lool: yup, lifeless proposal is the best solution for your case, this way you can load your devfocus branch with whatever you want and pushes will benefit
<lool> vila: So you were arguing earlier that we should use the gcc project for this stuff instead of the gcc-linaro one, is this still useful if we push revisions like above?
<vila> lool: and you won't have to think about which of trunk, 4.4 or 4.5 is the best starting point
<lifeless> lool: it woud model it more accurately in launchpad
<lool> vila: I should probably load the devfocus branch of gcc-linaro with the gcc/trunk /4.4 and /4.5 revs too, shouldn't I?
<lifeless> lool: but really, do what makes sense to you
<vila> lool: no, doesn't matter anymore
<vila> lool: if you start with trunk, the later ones should be almost covered
<lool> vila: So the trunk vcs-import contains all the 4.4 and 4.5 revisions because it's the way bzr svn operates?
<vila> lool: I don't thin kit's related to svn or vcs-import but most of the history of these branches is the same one
<vila> lifeless: still one failure if I use the loom plugin: ERROR: blackbox.test_switch.TestSwitch.test_switch_lightweight_directory -> TypeError: run() got an unexpected keyword argument 'directory' most probably on loom itself ;)
<lifeless> vila: yes, trunk breakage with decorated command
<lifeless> vila: please review, its nearly bedtime
<lifeless> vila: my problem to have tests passing
<lifeless> vila: also, a suggestion for lool's bug: ask for data, always ask for data ;)
<vila> lifeless: .bzr.log ? I was typing an additional comment ;)
<lifeless> calgrind
<lifeless> logs are nice
<lifeless> callgrind is heaven
<vila> lifeless: tests pass without the loom plugin, review time
<lifeless> vila: a meta comment for you: I think your priorities are the wrong way around there; its up to the submitter and PQM to care about tests.
<lifeless> vila: better to review, and *then* note that its got issues, than to put the review back - it breaks the flow up more.
<vila> lifeless: sure, especially when the submitter run the full test suite before submitting ;-)
<lool> lifeless: I have flexibility on the naming of the real branches; I chose to create a gcc-linaro project to host tarballs in the future, then it seemed logical to have gcc-linaro/xxx branches
<lifeless> lool: I think lp would traditionally model that as gcc/linaro-4.5 as the series, which can host tarballs just fine.
<lool> IIUC, the fact I pushed the "series" branches to /gcc-linaro namespace means they were not stacked on gcc and I payed a price for that, however because I've set the focus of dev to one of these branches, people pushing to gcc-linaro branches wont pay much
<lifeless> lool: OTOH if you want to be able to say on a bug, 'fixed in linaro gcc 4.5, still open in fsf gcc 4.5' then you must have a separate project at the moment.
<lool> lifeless: Don't I need ownership of the gcc project for that?
<lifeless> lool: no
<lifeless> lool: anyone can create series, or at least they are meant to be able to.
<lool> Yes, we want to track the bugs separately
<lool> the fsf bugs are not tracked in Launchpad though
<lool> Well they are tracked by Launchpad as remote bugs in upstream bugzilla
<lifeless> right
<vila> lifeless: Why can you remove InterToBranch5 now ? Did something change or was it an error to introduce it at the time ?
<lool> vila, lifeless: Hmm one thing I'm thinking could impact performance very badly is ecryptfs
<lool> I'm using ecryptfs on my whole $HOME; it caused issues in the past with things such as sparse files, but performance was overall comparable to before using that in my experience
<lool> I should try on another system
<vila> lifeless: ha, bug #593515, but why didn't your mp reference that ??
<ubot5> Launchpad bug 593515 in Bazaar "InterToBranch5 not used? (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/593515
<vila> lifeless: approved
<lifeless> vila: thanks
<lifeless> lool: just get callgrind stats
<lifeless> they should show up stat() if stat time is relevant
<lifeless> or sha1time, if ecryptfs breaks stat fingerprinting
<lifeless> vila: you haven't set merge:approve ;)
<vila> lifeless: pff, patch pilot noob...
<lifeless> vila: no worries, I shall train you :)
<vila> hehe, cool
<lool> lifeless: I ran an "enrich-gcc-linaro-repo" script, took 6mn41s on the first run and 18s on the second run, seems to have done some useful stuff on the first run, so was definitely a good idea, thanks
<lool> Will cron it now
<lool> Hmm I should create a separate account with a separate bzr key
<lool> I wonder how to tell bzr to use a separate launchpad login + ssh key for a single run
<lool> Overriding BZR_HOME is fine, but ssh won't use $HOME, and I can't find a way to pass random args to ssh from bzr
<lifeless> ln -s .ssh somewhere ?
<lifeless> lool: ssh can handle multiple ssh keys to offer, you know :)
<lifeless> lool: just have the right one on your keyright/passwordless/whatever
<lool> lifeless: Hmm right, I can just offer the key all the time
<lool> problem is user name actually, not key
<lool> it's the unix user I should be using
<rumbert> Is there GUI(s) which let you browse repositories without branching/checking out? (not counting HTTP/WWWeb)
<lamont> bzr branch bzr+ssh://example.com/
<lamont> bzr: ERROR: gnomekeyring.IOError:
<lamont> W.T.F...
<servilio> hi! can someone please point me out to a documentation on BranchReference's?
<TresEquis> jelmer: anything I can do to help with lp:480102?
<TresEquis> I saw you had marked it 'inprogress' over the weekend
<jelmer> bug 480102?
<ubot5> Launchpad bug 480102 in Bazaar Subversion Plugin "assert len(tview) == tview_len (affected: 12, heat: 98)" [High,In progress] https://launchpad.net/bugs/480102
<jelmer> TresEquis: one thing that would really help is a trivial python script that reproduced the issue so we can put that into the bzr-svn testsauite
<TresEquis> jelmer: ugh, I really don't understand how to provoke the error in a nice testcase-ish way
<jelmer> TresEquis: well, any help reproducing that error in the simplest way possible would be appreciated
<TresEquis> I know that it appeared to be true that the "blob loader ID" for the failing file in the failing revision was somehow pointing to the older revision
<TresEquis> so that when the patch was applied, the resulting file didn't match the checksum for the current transaction
<TresEquis> I just don't know the mechanics well enough to guess how that might occur
<jelmer> right
<jelmer> so I know it has something to do with merges
<TresEquis> I don't know if it is significant, but there is a 'bzr:ancestry:v4' property which shows up in the tree at the point of the apparently-successful merge
<TresEquis> the one after which the later transaction touching the same files blows up
<TresEquis> also, svn:mergeinfo shows up at that point
<jam> mkanat: I pushed a possible fix for bug 586122 for you
<ubot5> Launchpad bug 586122 in Meliae "scanner core dumps on loggerhead trunk + python 2.6.2 (affected: 1, heat: 5)" [Undecided,New] https://launchpad.net/bugs/586122
<jam> Can you test it out and let me know?
<mkanat> jam: Awesome! Yes, I will check it out.
<mkanat> jam: It might be a bit later today; the Bugzilla freeze is tomorrow, so I'm a little busy.
<jam> mkanat: No rush on my part, everything works here :)
<mkanat> jam: Okay. :-)
<lifeless> hi jam
<jam> hi lifeless
<assad> i did a merge, but i am getting : 6 conflicts encountered. at the end
<assad> is the merge done?
<TresEquis> assad: you need to fix the conficts, 'bzr resolve' them, and commit
<TresEquis> assad: you need to fix the conficts, 'bzr resolve' them, and commit
<jam> lifeless: somehow you managed to gather more resources than me, even though I'm fully capped (on all resources right now).
<jam> I guess you managed to upgrade something faster than me? (and thus spend more resources?)
<jam> anyway, you now outrank me in bym
<assad> TresEquis, to fix the conflicts i have to copy the code from the "to be merged with" branch?
<TresEquis> assad:  it's a judgement call
<TresEquis> you have to figure out what the right course is for each case where there are conflict markers
<TresEquis> and then riun all your tests to be sure you didn't blow it
<TresEquis> resolving conflicts in the test code is for extra bonus points
<lifeless> jam: I don't know - how do I tell that?
<jam> lifeless: on the bottom, your toon comes before mine, indicating you outrank me
<lifeless> jam: I have 3/6 lvl 10 goos; and been having a back n forth war with some naively defended person who attacks me and gets 3/4 twigs max
<lifeless> then I go wipe their entire base out ;P
<TresEquis> lifeless: you in Kiwiland now?
<lifeless> TresEquis: Yup
<jam> lifeless: hmm, maybe it is the extra twigs
<jam> I've got 6 lvl 10 goos, and a couple other lvl 10 items
<jam> but I haven't been warring as much :)
<lifeless> jam: it might be the fighting giving xp
<jam> also, it takes 3x the build time before a resource repays itself
<jam> (so a 3-day build time takes 9-days before it produces more)
<jam> could be
<jam> I've fought a little, but not a lot
<mtaylor> mordred@camelot:~/src$ bzr whoami
<mtaylor> bzr: ERROR: Connection closed:
<TresEquis> lol
<jam> mtaylor: I assume you are in a checkout?
<mtaylor> jam: nope
<mtaylor> just in a normal directory
<lifeless> jam: TresEquis I'm in chch, if you're familiar with nz
<jam> mtaylor: is $HOME a checkout?
<mtaylor> jam: nope
<lifeless> mtaylor: are you lying ?
<jam> you could run with -Derror
<mtaylor> lifeless: not to my knowledge
<TresEquis> lifeless: not except from reading maps
<lifeless> mtaylor: bzr info -v
<mtaylor> lifeless: mordred@camelot:~/src$ bzr info -v
<mtaylor> bzr: ERROR: Connection closed:
<lifeless> file a bug - we need a way to help people debug this.
<lifeless> secondly, look in .bzr/branch, ../.bzr/branch etc
<mtaylor> lifeless: searched all the way up the tree - no .bzr dirs anywhere
<lifeless> mtaylor: that is extremely odd
<lifeless> mtaylor: strace bzr
<mtaylor> lifeless: found it - there is an .svn dir
<mtaylor> lifeless: which is causing bzr-svn to vomit
<lifeless> mtaylor: oh right, of course
<lifeless> mtaylor: so, the bug is 'connection errors don't signal why we were making them'
<lifeless> or something
<mtaylor> lifeless: ok.
<lifeless> assuming that that is actually the entire output you've been pasting
<mtaylor> lifeless: or also - bzr whoami should perhaps not need to connect to anything?
<mtaylor> lifeless: yes
<lifeless> whoami can be configured by the branch
<lifeless> checkouts can reference an external branch
<lifeless> so no, whoami was doing the right thing
<lifeless> we could add a whoami --global or something
<lifeless> but you'd still not be able to commit where you were ;P
<mtaylor> lifeless: nah - I think you were right before - hinting at the bzr-svn cause would be the right thing here
<mgz> lifeless: any objection to just backing out testtools r70 when the unicode traceback work is finished?
<lifeless> mgz: why? it seems clearly less broken than it was
<lifeless> mgz: I'd be happy to have something less broken than it wsa and is
<mgz> well, because you're enhancing wrong code there
<mgz> actually, I think it's worse than that
<mgz> Python 3 does the right thing (the exceptions are always unicode), and Python 2 needs the input fixing, not a per-str()-call fixup
<mgz> hardcoding UTF-8 there is the wrong place at any rate, needs to happen in subunit if you want it, otherwise you break the normal output with say, unittest
<lifeless> so, subunit with multipart attachments already generates unicode exception objects
<lifeless> r70 in testtools is to *handle* that
<mgz> okay, I know it was to fix a current issue
<mgz> but I'm interested in what needs to change when testtools is only creating _StringException objects with unicode args
<lifeless> as long as we're using a fixed traceback module
<lifeless> and a subunit with the patch to make unicode string exceptions for non-multipart attachments
<lifeless> and the matching XXX fixed to encode in utf8 explicitly for non-multipart serialising
<lifeless> then we shouldn't ever be calling __str__ on a StringException
<mgz> okay, great, that's what I'm aiming for
<lifeless> and if we're not calling __str__, then it shouldn't matter
<lifeless> uhm
<lifeless> actually, it will matter
<lifeless> if someone with a different TestResult uses the standard traceback module.
<mgz> right, this is the case I worry about
<lifeless> they will run into precisely the same brokenness, unless __str__ *works*
<mgz> I currently am testing testtools internals with the unittest runner
<mgz> r70 will break those tests
<lifeless> and this is the upstream Exception.__str__ bug in python2.x
<lifeless> mgz: no, r70 will fix it.
<mgz> no, this is er... the second pass
<mgz> testtools is formatting the exception
<lifeless> hmm, I've two uk people timesharing me
<mgz> and unittest is stringifying the _StringException for the output
<mgz> I'll retire, this can wait.
<lifeless> which is broken. It should be unicodifying
<mgz> right, but it's a broken case that comes up, bzr currently does the same I believe
<lifeless> the question is, when someone asks for an insane thing, do we: break; encode to their default; encode to utf8; something else
<mgz> yup.
<poolie> hi there mgz, lifeless
<mgz> hey poolie
<lifeless> mgz: I'm happy to change it to 'use their console encoding' or something, once your patch lands and that is feasible.
<mgz> so, looked at like that, it boils down to r70 picking "always utf-8" and my compat one doing "ascii and questionmarks"
<lifeless> hi poolie
<mgz> where the right thing will be to change it to use unicode till it actually hits the console/whatever other output method
<lifeless> mgz: right
<lifeless> mgz: back in 2 minutes
<BitSprocket> How does one remove a folder from bazaar control?
<lifeless> mgz: back
<BitSprocket> How does one remove a folder from bazaar control?
<poolie> BitSprocket, 'bzr rm --keep'
<poolie> note that this will propagate to other checkouts as a deletion of that folder
<BitSprocket> Thanks poolie.  It's a private project so no worries.  That won't delete any of my files right?
<BitSprocket> Said differently, I want to keep the files, just remove version control.
<poolie> that's what --keep does
<BitSprocket> Sweet, thanks!
<poolie> you might then want to do 'bzr ignore THING' to avoid it being re-added in future
<poolie> np
<BitSprocket> Does that apply to subdirectories/files as well?
<BitSprocket> Or do I have to do them manually?
<BitSprocket> ...looks like it took care of it recursively for me...
<BitSprocket> Well, it doesn't look like it worked after all.  What am I missing?
#bzr 2010-06-15
<poolie> BitSprocket, which bit didn't work?
<poolie> what's going wrong?
<BitSprocket> It seems that it removed something called 'tree' *unsure* but the files are still marked with the versioning status as if nothing changed.  I tried to export the files but that didn't seem to work either...
<poolie> what does 'bzr status' show?
<BitSprocket> '... Modified'
<poolie> so you did 'bzr rm --keep THING'
<poolie> and now 'bzr st' still shows some files under that directory as modified?
<poolie> really?
<BitSprocket> Yes, but it may be after I've done some more tinkering.  I just tried the bzr rm --keep and now the status says:
<BitSprocket> bzr: ERROR: No WorkingTree exists for "file:///home/scott/pytivo/.bzr/checkout/".
<poolie> !
<poolie> maybe you're in the wrong directory?
<BitSprocket> I thought so too so I tried the same steps moving down the directory structure to where the actual files were and did the same thing with the same results.
<poolie> in which directory is your actual working tree?
<BitSprocket> not sure what you mean by working tree ... sorry
<poolie> do you have ~pytivo/trunk or something?
<poolie> i mean ~/pytivo/trunk ?
<BitSprocket> Ah, yes, its exactly that.
<poolie> ok, cd there
<BitSprocket> done
<poolie> now which directory did you want to un-version?
<BitSprocket> trunk and everything below
<poolie> !!
<poolie> hm
<poolie> i think i misunderstood your question
<poolie> why do you want to do this?
<BitSprocket> Well, I'm learning how to use bzr and I discovered that I created the repository in the wrong directory.  My files are actually located in pytivo/trunk/TheBayer and I don't need version control configured for anything above theBayer.  I figured if I removed the whole thing and started over I would be better off.
<poolie> oh i see
<poolie> so what is TheBayer?
<poolie> all the source is inside that?
<BitSprocket> Its a python project that allows me to stream videos to my tivo box from the network.  And yes, that's where the source files are.
<poolie> when someone else gets a checkout, do you want them to get a directory called TheBayer, or do you want them to just get the files that you have inside that directory?
<BitSprocket> Well, for now, it's a project that I'm using to learn python so for the immediate future it won't be a public repo.  I just wanted to be able to roll back changes if I really fouled things up.
<BitSprocket> I suppose that directory and everything below as one package
<poolie> ok so really TheBayer is the name of your branch?
<poolie> as opposed to trunk?
<poolie> that's the codename for the feature or something?
<BitSprocket> TheBayer is the name of the project that I downloaded from the web.  It's not really my project, its someone elses work that I'm using to cut my teeth.  No codenames, nothing special.  I believe that's what he named his fork from another project.
<BitSprocket> I untarred it and got a directory called TheBayer with all the source in it.
<BitSprocket> the pytivo and trunk folders I created myself.
<poolie> ok
<poolie> so i suggest you do
<poolie> cd ~/pytivo/trunk/
<poolie> mv TheBayer ../
<poolie> cd ../TheBayer
<poolie> bzr init; bzr add; bzr commit
<BitSprocket> Okay, so if I understand you, you are suggesting I move the folder and create a new repo right?
<poolie> yes
<BitSprocket> got it...
<spiv> Morning.
<mneptok> spiv: ahoyhoy
<BitSprocket> Hi spiv;GugaDin
<meoblast001> if any of you are familiar with TracBzr, i'm getting "Warning:  Error with navigation contributor 'BrowserModule' "
<meoblast001> that is, in the Admin/Repositories page
<poolie> hi spiv
<poolie> spiv, lifeless, one of us should look at https://bugs.launchpad.net/bugs/594275 fairly soon
<ubot5> Launchpad bug 594275 in Ubuntu Distributed Development "sphinx automatic import is broken (affected: 1, heat: 6)" [Critical,New]
<lifeless> what makes that one critical?
<lifeless> (vs other automated imports failing)
<lifeless> we need to move the package importer from its current machine too
<lifeless> and find a team to own it
<lifeless> fixing that particular bug may fix 15 or so imports
<lifeless> which would be nice
<poolie> lifeless, it makes it critical that it's blocking barry's attempt to do udd
<poolie> on inspection a downgrade might be appropriate
<lifeless> man, I hate spam
<lifeless> and gmail is failing at catching all these twitter 'we've reset your password' mails.
<lifeless> It appears that the spammers are bcc'ing all of canonical on each personalised mail!
<fullermd> "... twitter ..."   <--- Found your problem.
<lifeless> hah
<lifeless> vila: btw
<lifeless> SYN_SENT2 minutes
<lifeless> http://www.dd-wrt.com/wiki/index.php/Router_Slowdown was a quickly found reference for this
<lifeless> vila: which suggests to me that the server thread isn't actually accepting when it starts, but has presumably open the socket so it doesn't get rejected either. Or something.
<chx> i have created a launchpad branch stacked on top of an earlier tag of another lp branch. i have a local checkout of both for speedy work. I would like to merge all revisions affecting a certain directory. How can I do that? Just doing the merge does the file changes but does not actually merge revisions.
<lifeless> thats right, merging only part of a patch is a cherrypick and cannot show up as a full merge.
<chx> as said, i would like to merge full revisions, affecting a file / directory ... does that involve lots of scripting trickery :) ?
<lifeless> you want to merge a revision, but not its parents, right ?
<lifeless> chx: ^?
<chx> reading
<chx> hrm
<chx> i think the answer is yes :)
<lifeless> so, thats not a complete merge
<chx> oh?
<chx> well, yes, it's cherry picking
<lifeless> a complete merge merges a revision *and its parents*, recursively
<chx> but it's revisions that it merges
<lifeless> all the way back to the revisions that your branch already has
<chx> which would bring in changes to ohter wiles.
<chx> *files
<chx> so a) i need to find which revisions affected a file b) merge in just those revisions
<chx> right?
<lifeless> lets start over
<lifeless> what are you doing at the moment, and what is going wrong
<chx> heh
<chx> let's go step by step
<chx> a)  i have created a launchpad branch (sandbox) stacked on top of an earlier tag of another lp branch (trunk)
<chx> b) i have checked out both
<chx> c) cd sandbox/sites
<chx> d) bzr merge ~/examiner/trunk/sites/parc/
<chx> e) bzr ci -m 'merged in parc changes to sandbox'
<chx> f) check with bzr log -n0 -- oopsie no revisions!
<chx> g) bzr uncommit
<chx> h) /join #bzr
<chx> makes sense?
<lifeless> what does bzr root ~/examiner/trunk/sites/parc/
<lifeless> print out
 * spiv guesses the root is ~/examiner/trunk
<chx>  /home/chx/examiner/trunk
<lifeless> ok
<chx> it's a checkout of lp:~examiner-dev/examiner/trunk
<lifeless> chx: that has happened because you merged a subdirectory.
<chx> I created the sandbox branch with bzr branch -r tag:Perugina --stacked lp:~examiner-dev/examiner/trunk lp:~examiner-dev/examiner/sandbox if that matters
<lifeless> chx: doing that makes it a cherrypick
<chx> i see.
<lifeless> chx: and cherrypicks *are not recorded in log*
<chx> hm
<lifeless> you have two options
<lifeless> a) don't worry about it not being in log
<lifeless> b) don't merge a subdirectory
<chx> and if i do bzr merge -c 15932 ../trunk then it'll show up?
<lifeless> no
<chx> only bzr merge ../trunk will?
<lifeless> because -c does a cherrypick in the graph as well, a different sort of cherrypick but still a cherrypick
<lifeless> thats right.
<chx> ok, so then i might pick a
<chx> and hope that when i later do just bzr merge trunk then it will simply figure out that some differences are already in.
<chx> it looks like i have no other choice
<spiv> Right.  bzr merge can record "revision X (and all parents of X) has been merged", but not "revision X without parents" or "just some subdirectories changed in revision X", or other variations.
<spiv> 'bzr merge' will generally avoid reporting conflicts if the exact change to merge already seems to have been applied.
<chx> but then bzr merge is awesome and will figure out that some changes are already in.
<chx> right.
<chx> my heart still aches for darcs but it is so slow :(
<poolie> lifeless, oh did i mention that we talked a bit about user models
<poolie> there's a file in devnotes about this
<poolie> http://doc.bazaar.canonical.com/devnotes/bzr3-user-stories.html
<lifeless> cool
<spiv> way
<spiv> ...that was an odd typing mistake, but let's pretend I meant to say "way cool" :)
<poolie> hey spiv :)
<poolie> spiv, https://code.edge.launchpad.net/~mbp/bzr/590638-buffering/+merge/27578 is the issue of excessive buffering from last monday
<poolie> not urgent
<spiv> poolie: thanks!
<assad> how to confirm that merge is done and all conflicts resolved?
<poolie> assad, 'bzr st'
<assad> poolie, i am getting this: pending merge tips: (use -v to see all merge revisions)
<poolie> ok
<assad> poolie, is the merge over and conflicts resolved?
<poolie> try 'bzr conflicts'
<poolie> if there are none you're ready for 'bzr commit'
<assad> none, thanks
<assad> :)
<vila> hi all
<poolie> hi there vila
<poolie> i have a ScriptRunner patch for you
<vila> poolie: hey !
<poolie> and i guess you already know you're lotzman this week
<vila> hmm, looks like I missed a joke somewhere, that's the second time I see 'lotzman' used and I have no idea what it means :) Well, except some relation with patch pilot  that is :)
<poolie> it's the Russian word for "pilot" in the sense of someone who helps a ship into a harbor
<poolie> bialix told us that when he asked what 'patch pilot' means
<vila> haaa, yeah, the first reference was from bialix indeed :)
<vila> 'pilote' is the French word for that
<poolie> heh
<poolie> so https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/27581 is the one i was thinking of
<poolie> and then https://code.edge.launchpad.net/~mbp/bzr/externalbase/+merge/27583 uses scripts quite a lot and to good effect
<vila> ok, I'll look into it today
<poolie> i don't mean to harrass you there :)
<vila> hehe, no harassment taken :)
 * mneptok arrives on cue
<mneptok> did someone order some harrassment?
<assad> poolie, how can i update one branch on launchpad with another branch on launchpad? so that i dont have to first merge my branch and then push the changes to the other branch.
<poolie> can you explain more?
<vila> assad: A merge requires a working tree, lp have no WT, I'm pretty sure you can't achieve what you want there
<spiv> assad: If I'm understanding your question correctly (what exactly do you mean by "update"?), you can't.  What's the problem with pushing the changes?
<assad> poolie, i intend to update/push changes to my branch from the parent branch via lp itself. so that i dont have to move files through my machine.
<poolie> assad, just for curiousity which project is this?
<poolie> assad, no, you can't really do that, you need to push from your machine into the other branch
<assad> poolie, ok
<poolie> it might be nice if lp let you do the merge remotely but we don't atm
<assad> ok
<vila> lifeless, spm: How did your pqm fixes went ?
<vila> poolie: geee ! No harassment but nothing less than *7* mps !!! :)
<spm> hey vila, sadly no progress *yet*, but I am right now about to attempt to apply lifeless' patch and get the package(s) rebuilt. which is step A in this one.
<vila> spm: hi ! No harassment, no harassment :) Thanks for the feedback !
<spm> :-) np
<lifeless> vila: did you see my web link for you in backlog ?
<vila> lifeless: yup, thanks
<vila> I don't know how to check that on windows though, but I'm about to try to address it anyway by finishing what I started on SmartServer_for_testing first and see from there
<lifeless> vila: try changing the timeout in the registry, if the behaviour changes to match, thats what it is
<vila> regis..what ? :)
<bialix> heya
<bialix> bonjour vila !
<wgrant> \/win 5
<vila> bialix: privet Sacha !
<bialix> cool
<bialix> privet
<bialix> vila: just want to say that I've read your comment to leaking merge proposal and I very impressed
<vila> by what ? The number of dormant bugs ? :-) The 22 hours on windows ? :-P I'll get them pass on windows, I tell you ;)
<bialix> by the problem and analysis
<bialix> did not realized hidden problems
<bialix> vila: and yes, 22 hours is a bit tooooooooooooooooooooooooooo much
<vila> bialix: ha, yeah, tricky stuff :-/
<vila> hehe, don't worry, I'll fix that :)
<bialix> cool :-)
<vila> but the nice thing is that it should help use more threads in the future (outside of the test servers) while still keeping a python-ish way to describe the processing, still a long way to get there though :-/
<bialix> vila: I don't understand though your remark about slicing test suite to keep number of opened sockets below th elimit
<vila> bialix: when using --parallel=fork, we spawn several processes, each of them with only a slice of the whole test suite
<vila> bialix: so each process see less leaks and is able to finish
<bialix> I think limit for opened sockets is limit for all running processes
<vila> bialix: Well, it could be on windows but --parallel=fork doesn't work on windows anyway
<bialix> hehe, nice
<vila> :-/
<Lo-lan-do> Hi all :-)
<Lo-lan-do> jelmer: Do you know if anyone is planning to bring recent versions of bzr, bzr-svn and loggerhead to backports.org?
<jelmer> Lo-lan-do: not that I'm aware of
<Lo-lan-do> Thanks. I guess I'll try that myself then.
<Kamping_Kaiser> the bzr versions reasonably recent, 'just' all the packages which depend on it are broken as a result :
<Kamping_Kaiser> :/
<Lo-lan-do> http://bzr.debian.org/loggerhead/pkg-python/python-defaults-debian/annotate/head:/dh_python2? seems to crash somewhere in bzrlib
<Lo-lan-do> bzr 2.0.3, loggerhead 1.10 or so
<jelmer> Lo-lan-do: I know at least two other people who are interested in bzr and bzrtools in backports
<Lo-lan-do> jelmer: Let's see if anyone shouts at my email :-)
<Kamping_Kaiser> Lo-lan-do: re your email for bzr backports, one of my last messages to bpo users was about doing bzr package backporst. iirc it contains a list of packages which need rebuilding/changing. i can probably find it if you think it'll help
<maxb> Is there really much of a performance penalty in fetching between pack-0.92 and 1.9 formats?
<maxb> Or is bzr being a bit over-eager at warning me about format mismatches?
<jelmer> maxb: between pack-0.92 and 1.9 it shouldn't be very expensive
<maxb> Do you think it's expensive to justify bzr issueing a warning on pull?
<parthm> jam: ping
<jam> hi parthm
<parthm> hi jam.
<parthm> i was hoping to complete the lock-url patch. does the 5 sec timeout for LockContention seem ok to you?
<jam> so we've certainly gone around on it a lot :)
<jam> IMO, the timeout should be on the order of how long it takes to take and release the lock
<parthm> jam: yes :) .. i suppose anything is better than 300.
<jam> so that 2 people who are doing things that *can* be done won't block eachother
<jam> for example, updating branch.conf
<jam> also, updating pack-names is done with a physical lock
<jam> so we should look at how long it takes to get the lock, update pack-names, and then release the lock
<jam> That, I think, is the key thing to watch out for
<jam> because if 2 people push to a shared repo, but to different branches
<jam> we want that to succeed
<parthm> jam: that makes sense.
<jam> now *if* that is being performed (not with SFTP requests, for example), then 5s is probably reasonable
<parthm> jam: i could do a quick check of doing a push from two terminals into one repo at the same time (with 5s timeout). i suppose that should cover it.
<parthm> separate branches.
<jam> the ordering is... take the name lock, read the current content, compare it with your own content, write up new pack-names content to a temporary file, and then overwrite the existing file (either with simple POSIX rename, or 'fancy-rename'), unlock
<jam> parthm: well, there is a bit more 'exact timing' issues than just manually testing
<jam> unless you stress test it with a lot of pushes, etc.
<parthm> jam: maybe i can just set the timeout to 10s and set the url patch to 'needs review'. these two are actually separate. i can open a bug on getting a better estimate for timeout.
<parthm> i agree that a stress test is probably a good way to tune the timeout.
<jam> let me think for a sec
<jam> I think I can do a simple test
<jam> and have it run against a remove bzr
<jam> and just see how things go
<jam> and hopefully have you/someone in AU run it
<parthm> jam: ok.
<MTecknology> I'm trying to run  yes yes
<MTecknology> I'm trying to run  yes yes | bzr pull  but it's not being picked up by the ssh agent "Are you sure you want to continue connecting (yes/no)? " any ideas how to get around this?
<Lo-lan-do> Run bzr pull by hand and say yes to ssh?
<MTecknology> Lo-lan-do: scripting this
<Lo-lan-do> SSH should then remember your answer
<MTecknology> I need to answer it from a script
<Lo-lan-do> Set the StrictHostKeyChecking option to false in your SSHÂ config file?
<MTecknology> :D
<MTecknology> thanks
<Lo-lan-do> (I didn't suggest that, and you found about it yourself, and don't complain if you mess up your security)
<MTecknology> :P
<MTecknology> I can easily comprehend the issues with it
<MTecknology> wide open to man-in-the-middle
<bendj> I've got a local branch with a parent of "/repos/pf6".  i want to switch the local banch to use, and be in-sync with, a different parent, "/repos/pf6-617".
<bendj>   i entered my local branch, and issued a "bzr switch /repos/pf6-617", and got: bzr: ERROR: Cannot switch a branch, only a checkout.
<bendj> hm.  so, how do I make the switch?
<lifeless> bendj: I think you have two concepts conflated
<lifeless> bendj: 'parent' is used for the 'pull' and 'merge' commands.
<lifeless> bendj: switch is used to change a checkout to be a checkout of a different branch
<lifeless> bendj: can you describe differerntly what you want to happen, maybe I can suggest a way
<bendj> lifeless: I did -- (1) bzr init-repo --no-trees /repos (2) cd /repos (3) bzr branch --no-trees source1 (4) bzr branch --no-trees source2  (5) cd /home (6) bzr branch /repos/source1 mysite (7) cd mysite (8) hack, hack, hack ...
<bendj>  so, in my language, /home/mysite has a 'parent' of /repos/source1
<bendj> i want to switch it to a 'parent' of /repos/source2
<bendj> description make sense?
<lifeless> bendj: I think what you wanted to do in step 6 was 'bzr checkout --lightweight /repos/source1 mysite'
<lifeless> bendj: I can help you make it like that
<lifeless> bendj: first, cd to mysite
<bendj> i THINK i may need to convert the /home/mysite branch to a checkout (via bind?), then i can do the switch ...
<lifeless> and do 'bzr push :parent'
<bendj> lifeless push --> "update a mirror of this branch".  sorry, which mirror gets updated?
<lifeless> :parent is an alias for 'the parent of this branch'
<lifeless> which according to your commands is /repos/source1
<lifeless> by  (6) bzr branch /repos/source1 mysite
<bendj> lifeless: yup.  but, isn't that going to attempt to 'make changes' to the parent, aka /repos/source1?
<lifeless> bendj: isn't that what you wanted ?
<bendj> nope.
<lifeless> bendj: Do you want to discard the work you've donein mysite ?
<bendj> lifeless context -> i'm attempting to update /home/mysite (a pressflow/drupal site, based off the 'release' trunk @ /repos/source1).
<bendj> i want to switch /home/mysite to be bbased off newer 'test' branch source of pressflow @ /repos/source2.
<lifeless> have you made changes in mysite itself ?
<bendj> scads!
<lifeless> then you have the following situation
<lifeless> branchA (trunk), branchB(test) and branchC(mysite)
<lifeless> these all have unique content
<bendj> pls keep typing.  brb .... minor emer
<lifeless> switch is a command to well, 'switch out' or totally replace a working area with some other branch - it says (for instance), 'I have mysite, but I really want test.'
<lifeless> this isn't what you want to do.
<lifeless> What I think you want to do is 'bring in the changes that test made so that I have both the work from test and the work from mysite'
<lifeless> the way to do that is 'bzr merge /repos/source2; bzr commit -m "Merge in test"'
<bendj> lifeless: thanks.  emer wasn't so minor ...  sorry bout that
<mgz> man, I keep breaking things
<mgz> should have a precommit hook that runs the tests against all four python implementations
<lifeless> :)
<lifeless> mgz: that would be nice
<lifeless> mgz: I thought about a check-all or something
<lifeless> but didn't get the activation energy up
<mgz> okay, my list of things to do in the branch is at least diminishing
<mgz> only hard thing left is decision about moving/renaming some of this 'utils' stuff
<mgz> it's a little annoying currently as now testtools.run and testtools.testresult need utils, which pulls in a bunch of code most of which is only needed for Python 2, and some of it only for the test suite
<mgz> I think iterate_tests should move anyway as it's part of the base public api
<lifeless> agree
<lifeless> mgz: so I think iterate_tests should move; we should leave a forwarder behind
<lifeless> mgz: we should split 'end users want' and 'only selftest wants' - but for testtools anything generic end users may still want, because of its rather introspective nature
<mgz> yup. there's no fancy deprecater as in bzrlib though, right?
<mgz> some of this end users indirectly want, but should only be accessible via say, method on testresult
<mgz> otherwise they'd need all this horrible version checking in their code as well
<lifeless> that seems to be a swings and roundabout distinction
<lifeless> unless its already on unittest.TestResult
<lifeless> and if it is, they may want to be able to monkeypatch their own - say twisted.trial.TestResult - so a helper function may be nice anway
<mgz> ah, I see.
<lifeless> I don't see that they would need version checking
<lifeless> it can be in our helper, or in our module or whatever
<poolie> hi there jam?
<thumper> will bzr run as bzrlib within google appengine?
<lifeless> it should
<lifeless> obviously without the C extensions
<lifeless> I don't think anyone has tried.
<mgz> would be interesting to see.
<lifeless> GAE is a classic example of why we have a no-C-requirement policy
<lifeless> even though I waver on that from time to time
<lifeless> I think we could be _so_ much faster if we went pure C, with a python version as a port rather than the primary environment.
<davidstrauss> I'm helping a person who's getting "bzr: ERROR: Unsupported protocol for url "ancestor:lp:~pressflow/pressflow/merge-drupal-6.17" when running "bzr diff --old=ancestor:lp:~pressflow/pressflow/merge-drupal-6.17"
<thumper> lifeless: having a main function in C with a python fallback seems OK to me...
<thumper> lifeless: is this not allowed?
#bzr 2010-06-16
<lifeless> davidstrauss: probably a bug in directory resolution lookup, if lp:~pressflow/pressflow/merge-drupal-6.17 works
 * thumper is thinking of wikkid in GAE
<davidstrauss> lifeless: correct
<davidstrauss> lifeless: the plain url work
<lifeless> davidstrauss: you can replace lp: with bzr+ssh://bazaar.launchpad.net/ - and please file a bug
<lifeless> thumper: I mean the entire stack in C
<lifeless> thumper: plugins, UI, the lot.
<thumper> oh
<thumper> yeah, I agree that the runtime would be faseter
<thumper> lifeless: do you know the policy of hg in this area?
<lifeless> thumper: it used to be C only for some stuff; I know someone buitl python versions, but I don't know if they have a 'keep up to date' policy on them.
<davidstrauss> lifeless: bzr: ERROR: Unsupported protocol for url "ancestor:http://bazaar.launchpad.net/~pressflow/pressflow/merge-drupal-6.17"
<jelmer> davidstrauss: ancestor only works for -r
<davidstrauss> jelmer: it doesn't work for --old?
<lifeless> oh, of course.
<davidstrauss> oh
<spiv> Good morning
<lifeless> hola
<MrKeuner> hi, is bzr completely integrated with nautilus? will I see which files are up2date recursively?
<poolie> i think so
<MrKeuner> something like tortoise svn?
<poolie> right
<poolie> if you're on ubuntu you may want to install groundconttrol
<MrKeuner> yes, Lucid here
<MrKeuner> poolie, I used rabbitvcs but it is awfully slow when the number of files is large
<MrKeuner> do you know if bzr is better handling massive number of files?
<poolie> i'm not sure
<poolie> i would probably not recommend using it with nautilus if you have a huge number of files
<MrKeuner> 20GB
<lifeless> any pipeline users around?
<lifeless> thumper: ?
<thumper> yes?
<lifeless> how do you go forward/back a single pipe ?
<lifeless> and all the way to the start/all the way to the end
<lifeless> I have a loom patch from Aaron which changes up-thread to do --auto by default
<thumper> bzr switch-pipe :first, :next, :prev, :last
<lifeless> I'm guessing pipeline is similar ... ah
<thumper> or bzr switch
<lifeless> without knowing the names
<thumper> switch-pipe shelves and switches
<lifeless> what about pump
<lifeless> or whatever its called
<thumper> pump doesn't change the current pipe
<lifeless> no ?
<thumper> but pushes the change from the current pipe down the pipeline
<thumper> it only switches if it finds conflicts
<lifeless> do you use pump a lot ?
<thumper> it depends what I'm doing
<lifeless> ok
<lifeless> hmm, I'll merge it, can see whether folk like it.
 * thumper nods
<thumper> I've not used pipelines in the last several months
<thumper> not needed them
<thumper> all my recent work has been simple
<thumper> but I find them great for bigger chunks
<thumper> or to break out refactorings into a different branch
<lifeless> oh yes
<lifeless> totally appreciate the use case
<lifeless> I'm trying to learn about the common bits of their use with looms to make looms good too
<lifeless> and asking happy users is a great way to do that, I think :)
<thumper> :)
<lifeless> spiv: how are you finding finding udd tasks at the moment?
<lifeless> spiv: you were, IIRC, going to attempt a udd import -> loom converter
<lifeless> spiv: and I have just finished a slightly painful merge so if you wanted to talk about such a thing, now would be a most excellent time for me
 * lifeless takes a break
<spiv> lifeless: sorry, was at lunch and then focussed in finishing my patch for bug 590637
<ubot5> Launchpad bug 590637 in Bazaar "use a socketpair to talk to the ssh client process (affected: 1, heat: 23)" [Medium,Confirmed] https://launchpad.net/bugs/590637
<lifeless> spiv: no worries
<lifeless> spiv: why do we expect that to behave differently ?
<spiv> lifeless: it's easier to do short reads on sockets
<lifeless> so the theory is that ssh is filling up its tcp buffer because it can't hand off data to us in small chunks ?
<spiv> lifeless: something like that.  We aren't expecting miracles, but it seemed like a cheap thing to try, and in general less syscalls is a good idea.
<lifeless> spiv: were we reading 1 byte at a time before, or something?
<spiv> lifeless: right (sometimes, depending on how much we could be sure should be on the pipe)
<lifeless> kk
<spiv> It turned out that the patch was a little bit fiddlier than I thought it would be, but it has helped me clean up a few messy corners of the code, so I'm happy with it on general principles :)
<GaryvdM> Hi all.
<GaryvdM> Public holiday today - So I can work on bzr \o/
<lifeless> \o/
<lifeless> righto, break over, back to lums
<lifeless> actually, caffeine supply. then looms
<spiv> And the patch lets us use the nicer socket code paths with paramiko now too.
<vila> hi all
<vila> spiv: Is there an impact on the test servers ?
<spiv> vila: no, it's all client-side
<vila> spiv: ok
<vila> spiv: Quick chat about the smart server ?
<vila> spiv: It's running in the main thread when started with 'bzr serve' but in a background thread for tests right ?
<spiv> Typically, yes.
<spiv> (It's possible there's a test or two that runs it in the main thread, I don't recall for sure.)
<vila> it's ok I can check for details there
<vila> spiv: How is it stopped ? (From a user point of view)
<vila> More precisely, can it be asked to stop serving new connections while letting the current requests finish ?
<spiv> vila: How is "bzr serve" stopped?  Ctrl-C, or SIGTERM.
<spiv> And no, it doesn't yet have a "stop serving new but let current connections finish" feature yet.
<vila> ha, ok, so the connection threads are just aborted then ?
<spiv> Hmm, depends on if they are setDaemon(True) I guess, I don't remember.
<vila> yes, they are daemonic
<spiv> So, yes :)
<spiv> I think clean shutdown is a nice-to-have feature for a server, but you need to figure out what to do with very long lived connections/requests... in the end you probably just kill them anyway.
<spiv> And no-one has asked for it, so it's not a high-priority :)
<vila> Yeah, I don't want to dive into that now :) I was just making sure I was understanding the current design
<spiv> *nod*
<vila> I'm still wondering if I should use my new TestServerInAThread for SmartServer_for_testing or for the real thing, the former smells a bit like cheating (i.e. use a different code for tests as far as threads/sockets are concerned)
<vila> but since there is no big constraints on the real smart server I may postpone some parts and just focus on the tests
<vila> spiv: One more thing: digging the history didn't really explain why TCP_NODELAY is used for both the server socket and the connection ones and also why SO_REUSEADDR is used on windows
<vila> spiv: I ask more for curiosity than anything else and to ensure I don't need to care about it
<spiv> TCP_NODELAY because HPSS messages are currently written in a bunch of small writes
<vila> Should I do that unconditionally for all our tests servers ? This shouldn't hurt doesn't it ?
<spiv> i.e. the code has points at which it knows it is going to do multiple (probably small) writes with no delay between them
<vila> Or is there a risk to hide bugs doing that ?
<spiv> It would probably be a little nicer to use TCP_CORK instead to buffer those, and then flush that buffer at the end of those sequences of writes.
<spiv> I forget exactly why we use SO_REUSEADDR on windows, but I do recall it means something subtly different on win32 to posix
<vila> Yeah, too bad the comment is only: '# SO_REUSERADDR has a different meaning on Windows' :)
<vila> nm, thanks for the tips
<vila> have a good evening, who knows, may be a dream will pop up with the explanation ;-)
<spiv> vila: https://bugs.edge.launchpad.net/bzr/+bug/164288
<ubot5> Launchpad bug 164288 in Bazaar "bzr serve leaves connections in CLOSE_WAIT a *long* time (affected: 0, heat: 0)" [High,Fix released]
<spiv> vila: see also the NEWS entry for that bug
<vila> spiv: excellent !
<vila> verrrrry interesting
<spiv> vila: I would expect that's fairly uninteresting for tests, because tests should generally be careful to listen on free ports (via asking for port 0), so if the TCP stack thinks the old ports are still busy shouldn't matter...
<spiv> Unless of course the system has a very small transient port range, or something.
<vila> unless we start smart servers on port 4155... worth checking as this would explain the delays on windows
<vila> not holding my breath though
<lifeless> we do 2 I think
<lifeless> possibly not even that
<vila> lifeless: ECANTPARSE 2: too ? two ?
<lifeless> 2
<vila> as in 2 tests are doing that ?
<lifeless> yes
<lifeless> vila: we may not, but I think we have one or two smoke tests for it
<spiv> Hmm, IIRC none of our tests rely on port 4155 being free.
<vila> ok, I will run into them eventually anyway, but if there are only two that's not enough to explain the delays (which of course doesn't occur when a single test is run...)
<lifeless> vila: that was my point ;)
<vila> lifeless: ok, thanks
<spiv> (even blackbox.test_serve uses localhost:0 as the host:port, and then finds out the actual port number via the server-started hook)
<vila> spiv: thanks for checking :) Oh, and sorry for the noise, I misread the code: we *don't* use SO_REUSEADDR on windows, never :)
 * vila hides
<lifeless> spiv: win32 has socketpairs ?
<spiv> lifeless: no
<lifeless> how is it catered for here
<lifeless> spiv: also the docstring on SSHParams is both ugly (PEP8 may mandate that double empty line; its wrong) but also inaccurate
<spiv> a) it falls back to subprocess.PIPE for stdin/stdout, and the old pipe-medium code path, b) many windows users will be using paramiko rather than subprocesses anyway
<lifeless> spiv: I'm worried about the hunk @@ -737,26 +733,42 @@
<lifeless> +        # XXX: Perhaps should use accept_bytes rather than _accept_bytes?
<lifeless> would like a little more context
<spiv> The double-empty line is just a leftover from a earlier edit, thanks for spotting.  I'm tempted to just delete that docstring entirely, but maybe add one to the class instead of __init__
<spiv> Fair enough.
<lifeless> +        # XXX: perhaps should delegate to read_bytes, not _read_bytes?
<lifeless> likewise
<spiv> The short answer is: it's ok to call _accept_bytes, at least with the current implementations of things, and avoids some (probably minor) overhead the public function.
<spiv> I'll just call the public methods I think.
<lifeless> spiv: I meant in the code, for poor folk like you coming back in 3 months
<lifeless> ;)
<spiv> lifeless: well, deleting XXX > elaborating XXX :)
<lifeless> :)
<lifeless> I'm happy any which way
<lifeless> the _real_medium thing is a little unclear
<lifeless> its not clear what makes a medium really a medium, or not a medium,
<lifeless> I think that that should be clarified
<spiv> If it's not big and not small it's medium ;)
<lifeless> :P
<spiv> "A medium is something that implements the contract of SmartMedium", or is that too circular for you?
<lifeless> spiv: your NEWS entry should list all the publicish functions you are destroying, please.
<spiv> Ok.
<lifeless> spiv: I don't understand why a MediumX would delegate to a MediumY
<spiv> Well, as a separate NEWS entry under API Changese, I guess.
<lifeless> when it previously was implementing Medium itself
<lifeless> spiv: NEWS: naturally )
<spiv> For ease of implementation
<lifeless> what isn't clear is what is in SmartSSHClientMedium that isn't in SmartClientSocketMedium | SmartClientAlreadyConnectedSocketMedium
<vila> mediums are most useful to communicate with dead things, which is why we need them :)
<lifeless> for instance, looking at the diff
<lifeless> +    def _flush(self):
<lifeless> +        """See SmartClientStreamMedium._flush().
<lifeless> +
<lifeless> +        For TCP we do no flushing. We may want to turn off TCP_NODELAY and
<lifeless> ...
<lifeless> is on SmartClientSocketMedium
<lifeless> but the docstring is relevant to a subclass
<spiv> Well, sometimes this medium will have a pipe, and sometimes you will have a socket, and the SSHClientMedium doesn't know which in advance.
<lifeless> so perhaps - you've rearranged things
<mgz> morning all
<spiv> I have rearranged things, and possibly some docstrings didn't quite land in the best spots.
<lifeless> but it needs a read-over to make sure that the pulled-up/pushed-down methods still refer to their actual classes
<GaryvdM> hi mgz
<lifeless> overall it looks good
<spiv> Ok, will do.
<lifeless> I'm still concerned about the
<lifeless> @@ -737,26 +733,42 @@
<lifeless>     def _read_bytes(self, count):
<lifeless>         """See SmartClientStreamMedium._read_bytes."""
<lifeless> -        bytes = osutils.until_no_eintr(self._readable_pipe.read, count)
<lifeless> hunk
<spiv> Heh, thanks for pointing that out just as mgz joined the channel ;)
<vila> mgz, GaryvdM : \o_
<lifeless> I don't see, if we keep the ability to use pipes, that we can delete that protection.
<lifeless> hi mgz
<lifeless> spiv: am I wrong ?
<spiv> The SimplePipes medium that line was from was only ever used by the test suite, note real code.
<mgz> ah, I see the topic is more socket joy
<spiv> Because the SSHClient medium was actually doing its own pipe IO logic
<lifeless> spiv: won't the test suite, on windows, still use pipes ?
<spiv> EINTR is irrelevant on windows, windows doesn't have it.
<lifeless> ok
<vila> bbib
<lifeless> in which case, with all the questions I've asked, if you make the docs shiny and NEWS, +1
<spiv> (Also, we've been forced to fix EINTR the crude way: by not using signal handlers, so it's a bit academic anyhow :/)
<poolie> hi vila, lifeless, spiv
<vila> poolie: hi
<lifeless> hi poolie
<lifeless> poolie: I have good news and bad news for you
<lifeless> the good news is that the pqm test run successfully formatted and collated a broken test
<lifeless> the bad news is that it had a 43M attachment and choked on the MTA limit on the box.
<lifeless> poolie: I'd like to just raise the limit and supply a small follow on patch to gzip the stdout and stderr logs
<lifeless> poolie: but if you'd prefer I can also turn subunit off in bzr trunk, as agreed.
<poolie> hi there
<poolie> thanks for letting me know
<poolie> i wonder if those large attachments will also be annoying to recipients of failing test runs?
<poolie> that's quite a lot to download on a pre-adsl2 link
<poolie> but i'm ok to persist until it starts actually hurting someone
<spiv> You have to give spamassassin and amavis something to do ;)
<poolie> lifeless: i wonder if we should eventually perhaps strip non-failing test output?
<lifeless> poolie: We used too
<lifeless> poolie: its a contibuting factor to the test results being sometimes rather useless
<poolie> stripping them is, or leaving them in is?
<lifeless> I think its safer, given the requirements, to include everything
<lifeless> poolie: stripping them - the failure mode can include stripping too much
<lifeless> poolie: the body of the sent email has pyunit formatted errors
<poolie> right
<poolie> if eg there's extra output in the streaom
<lifeless> poolie: so in principle you can just ignore the attached stdout file.
<spiv> Not stripping them has the failure mode of being too large for someone to receive ;)
<poolie> well, we can leave that for later
<poolie> :)
<poolie> vila did you see my pm?
<lifeless> poolie: so tribunal
<vila> I don't generally like partial outputs... on the other hand, I also generally *need* to reproduce locally...
<poolie> hraspace is ruining my day
<lifeless> poolie: looks like you hadn't pushed to trunk in a while, for the merge proposal you commented on the other day
<lifeless> poolie: hraspace? allhands.c.c?
<poolie> mm
<poolie> and i have now pushed what you need?
<poolie> or i still need to push?
<lifeless> poolie: trunk appears broken -
<lifeless>      def on_test_started(self, test_id):
<lifeless> +        pass
<lifeless> poolie: I think you have what I pushed, I'm doing double-checking now and will mark the mp as merged if it is the case.
<poolie> oops
<poolie> i may look at it after this
<lifeless> poolie: so you know, I've been hitting up on loom most of the day
<lifeless> mgz: I'll be very happy to fix
<lifeless> mgz: testtools and unicode
<mgz> I'm still not caught up on the log...
<mgz> what's that re:?
<mgz> (^I gzip testrun output, bzr has a lot of tests, and a lot of output)
<poolie> lifeless: thanks
<spiv> In NEWS, is the convention for (Some Person, #1234) to be on its own line, or at the end of the line if it fits on one line, or just wrapped any old how?
<spiv> Or rather, the at the moment we seem to be a bit inconsistent, so what should the convention be? :)
<poolie> it does seem inconsistent
<lifeless> I vote on the end if it fits, otherwise a dedicated line.
<poolie> avoiding wrapping within the names sounds good
<lifeless> because
<lifeless> xxxxxxxxxxxxxxx
<lifeless> xx
<lifeless> (xxxxx)
<lifeless> looks really odd to me
<spiv> Avoiding wrapping seems nice for helping grep.  No-one (out of the three of us so far) have spoken in favour of always making a separate line, so I'll go with "on the end if it fits".
<spiv> I suppose we should document that, although it's the sort of docs no-one would read.  I guess the way to enforce that sort of thing is by adding a NEWS linter to the test suite...
<spiv> (No, I'm not planning to shave that yak)
<lifeless> spiv: why lint when you can merge.
<spiv> lifeless: a merge hook that rewrites sections that we're conflicting in the first place isn't totally optimal either :/
<spiv> s/we're/weren't/
<lifeless> spiv: I think it would be beautiful :)
<lifeless> vila - more loom love, for your enjoyment - https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27684 btw
<poolie> spiv nobody will read the docs _except_ that in N months time it will make this conversation a bit shorter
<lifeless> whats the bet its in there already
<lifeless> no, its not
<lifeless> I'll send a mp in tomorrow
<poolie> for things where we don't care strongly but we do want it consistent i think it really helps
<lifeless> poolie: mail limit for pqm is now raised to 50MB pending a gzip patch
<poolie> k
<poolie> this is an interesting case for supporting multiple mime encodings
<poolie> you want it to be not too much bigger for text
<lifeless> I'm going to see about getting that patch tucked away tonight
<poolie> and not too bad for binaries
<poolie> so perhaps having the option for either qp or base64 is good
<poolie> which one?
<lifeless> it might be nice for text to just be gzipped
<poolie> the tribunal thing?
<lifeless> gzip for pqm
<lifeless> tribunal I'm nearly done checking
<poolie> the problem in tribunal is probably that i was profiling by selectively cutting things out
<vila> Oh, I thought the convention was to have the (author, #nnn) on its own line
<vila> I'm ok for smart-wrapping
<poolie> i think i dropped off
<lifeless> 20:26 < poolie> the problem in tribunal is probably that i was profiling by selectively cutting things out
<lifeless> 20:28 < vila> Oh, I thought the convention was to have the (author, #nnn) on its own line
<lifeless> 20:28 < vila> I'm ok for smart-wrapping
<lifeless> 20:31 -!- poolie [9665702c@canonical/launchpad/poolie] has quit [Ping timeout: 252 seconds]
<lifeless> 20:32 -!- poolie [9665702c@canonical/launchpad/poolie] has joined #bzr
<lifeless> 20:32 < poolie> i think i dropped off
<vila> hmm, there is a good French joke about that but perfectly untranslatable :-/
<lifeless> ce la vie
<vila> You'll have to trust me on this one :)
<vila> c'est la vie :)
<lifeless> gotcha
<lifeless> I know you couldn't resist :)
<poolie> ok good night all
<lifeless> ciao
<GaryvdM> lifeless: you said when reviewing my diff --using branch that test such as this one: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/bzrlib/tests/test_diff.py#L1310  should use sys.executable rather than 'python'.
<GaryvdM> (may be it was jam - I can't remember
<lifeless> both of us, I think
<GaryvdM> lifeless: Would it be ok if i rather used  'echo'
<GaryvdM> ?
<lifeless> doesn't exist on windows
<GaryvdM> I think it does.
<lifeless> I don't understand something though, we have glue for all this in bzrlib.tests.TestCase already
<lifeless> don't we ?
<GaryvdM> lifeless: oh - ok - let me look at that.
<GaryvdM> lifeless: I don't think so.
<GaryvdM> lifeless: that test is trying to assert that a arbitrary diff command was executed, and that the file paths were passed to it, and that the output from the command is read.
<GaryvdM> lifeless: In real life, the command maybe something like diff, or meld, but in the test, we can't rely on those being availible, so it currently uses python -c print...
<GaryvdM> which could just be echo
<GaryvdM> I'm going to dbl check on echo on windows
<lifeless> GaryvdM: so
<lifeless> we have the following things available
<lifeless> : - os stuff
<lifeless> - bzr itself, including test commands (we have some already)
<lifeless> - mocking, were we pretend we ran something - see the fake gpg support, for instance
<lifeless> I don't see a great deal of value in actually running something, for your test, if we have a known interface for doing it in general.
<GaryvdM> lifeless: btw - this is an existing test that I did not write. I just copied the style of it for additional tests.
<GaryvdM> (I would like to try make it better though)
<lifeless> ok
<lifeless> so perhaps:
<lifeless>  - make sure you don't increase whatever sin is there :) - refactor to use the existing style, good or bad, via a helper function rather than via copying
<lifeless> then, we can decouple your test from improving things that were already there
<lifeless> vila: did you propose my broken branch to pqm ?
<vila> lifeless: yes, to test mail
<lifeless> kk
<vila> lifeless: is that a problem ?
<vila> kk
<vila> :)
<lifeless> I thought PQM had done something very naughty
<vila> lifeless: sorry about that, it's only after sending it that I saw you just did
<lifeless> de nada, only way for you to find out
<spiv> GaryvdM: there's no "echo" executable on windows -- but it is a builtin command in cmd.exe (and command.com for that matter)
<GaryvdM> spiv: oh - I see
<spiv> (or at least, that used to be the case when I used windows)
<spiv> So I'd expect that subprocess.Popen(['echo', 'foo'], shell=False) would fail
<kostja_osipov> hello.
<kostja_osipov> does bzr gtk tools such as gcommit work on mac?
<kostja_osipov> it says here
<kostja_osipov> bzr: ERROR: PyGTK not installed.
<vila> lifeless: bzrlib.version_info should be (2, 2, 0, 'beta', 4) not (2, 2, 0, 'beta', 3) right ?
<kostja_osipov> even though it is installed (with fink)
<kostja_osipov> is there some sort of troubleshooting faq?
<jszakmeister> kostja_osipov: fink installs it's own version of python. :-(
<lifeless> vila: when we release it, yes.
<lifeless> vila: is it released yet ?
<kostja_osipov> jszakmeister: so how does one fix it?
<vila> no, but trunk never is
<vila> lifeless: no, but trunk never is
<lifeless> thats right
<jszakmeister> kostja_osipov: I'm not sure.  But I bet it's a lot of work.  Have you tried using QBzr?
<jszakmeister> It works everywhere.
<kostja_osipov> jszakmeister: qbzr doesn't support per-file comments, a feature we are using here at mysql
<jszakmeister> :-(
<jszakmeister> I wonder if there are prebuilt libs out there...
<lifeless> kostja_osipov: probably your python for bzr and your python for fink are different
<kostja_osipov> lifeless, jszakmeister thanks, I got it
<vila> lifeless: eerk, it should even be  (2, 2, 0, 'dev', 5) i.e not beta but dev, dunno for 5 though
<jszakmeister> kostja_osipov: just used the fink python version, right?
<lifeless> vila: huh ?
<lifeless> vila: put down whatever you are smoking.
<vila> in lp:bzr we use 'dev' not 'beta' right ?
<lifeless> vila: no
<lifeless> vila: read releasing.txt
<lifeless> vila: trunk is absolutely correct
<lifeless> vila: nothing needs changing, its as per poolie's desire with the beta release approach
<vila> how do we distinguish between 2.2b3 released and trunk ?
<lifeless> vila: we don't
<vila> meh
<lifeless> vila: I noticed this when I did the release a couple weeks back
<lifeless> vila: I doesn't seem like a big issue given we're not treating them as we used to treat releases.
<lifeless> vila: although opinions on that might vary :P
 * vila scratches head and goes on...
<lifeless> vila: whats caught your eye ?
<vila> lifeless: I was  merging 2.0 -> 2.1 -> trunk
<lifeless> did we sort out what we were doing with NEWS?
<vila> forgetting 2.2 by the way
<vila> well, the fact that we didn't release 2.0.6 makes things a bit more blurry as it's now unclear what was included in 2.1.2...
<lifeless> vila: I think its clear, with what I did
<lifeless> it wouldn't be with the other proposed approach.
<lifeless> [which is why I don't like the other way :)]
<vila> hold on, I may have missed what you did :)
<lifeless> vila: I duplicated entries
<vila> Did you duplicate the NEWS entries ?
<vila> hmm
<vila> so I should do the same when merging up them
<lifeless> well
<vila> then
<lifeless> if there is disagreement we should resolve it
<lifeless> all I'm saying is that I felt happy with what I did
<lifeless> as it meant you don't need to chase pointers or worry about coherency if (say) 2.0.x (unreleased) gets released etc
<vila> I don't really disagree, I should re-read releasing.txt, it looks like I've missed this detail
<vila> yeah, that's the first time we released 2.1.x without 2.0.y :)
<vila> lifeless: I still had in mind the 'merge 2.0 into 2.1 into bzr.dev freely' policy
<lifeless> vila: right, which I've been doing
<lifeless> vila: I don't think that that policy has changed, has it ?
<vila> well, we need to duplicate the NEWS entries then or the RM will need to check and sort things out which would be a nightmare
<vila> lifeless: I don't want to sound picky, but: releasing.txt doesn't mention 'dev', but the comment in bzrlib.__init__ says: "Additionally we use a # releaselevel of 'dev' for unreleased under-development code."
<vila> lifeless: Also NEWS mentions 2.2b4 but we still have (2, 2, 0, 'beta' , *3*) in version_info
<lifeless> not picky at all
<lifeless> the former is a comment from before things changed; annotate to see :)
<vila> bah, releasing.txt mentions 'dev' when *opening* for a new release :-/
<lifeless> the latter is as per the releasing.txt, which while I tweaked I didn't change process at all
<vila> sure not throwing stones, but this sounds like a good occasion to clarify things
<lifeless> vila: however there is every chance I got it wrong, because releasing.txt was really confusing.txt when I started the release process.
<lifeless> vila: so if it should still be 'dev' according to releasing.txt, thats fine - but its not clear to me whether that is 'starting a new series' or 'starting a new point release'
<lifeless> vila: and new point releases - going back to dev would be wrong sorting wise
<lifeless> wouldn't it ?
<vila> oh my versions sorting... vade retro satanas
<lifeless> vila: though I'm not looking at the tuple right now, so could be misremembering the order of the 'dev' string in it
<lifeless> vila: now, for further entertainment, as per lp-code - pqm has been zapped
<lifeless> vila: I've just sent another failure test.
<lifeless> vila: I'm going to stay up long enough to see whether it goes boom or wins
<lifeless> vila: but things will need resubmitted after that
<mgz> okay, finally caught up with log
<mgz> lots of windows questions, but they all got answered! crazy.
<mgz> lifeless: I'm not sure what you meant specifically earlier with:
<mgz> <lifeless> mgz: I'll be very happy to fix
<mgz> <lifeless> mgz: testtools and unicode
<lifeless> mgz: your patch.
<lifeless> I wants.
<vila> lifeless: so my submission was zapped, no need to chase if the mail was refused or not (irrelevant now anyway if your gzip patch works)
<mgz> ah, right, I'll see if I can resubmit something landable today
<lifeless> vila: right
<lifeless> mgz: what prompted that was, lets see
<vila> lifeless: so let me know where you're at before you quit, thks in advance :)
<lifeless> ======================================================================
<lifeless> FAIL: bzrlib.tests.test_setup.TestSetup.test_build_and_install
<lifeless> ----------------------------------------------------------------------
<lifeless> 'ascii' codec can't encode characters in position 33548-33550: ordinal not in range(128)
<lifeless> vila: naturally
<lifeless> vila: I'm going slightly mad o/~
<mgz> ehe, woho! I see.
<mgz> wonder if testtools could grow some nicer UnicodeError handling as well, might be worth doing later
<mgz> okay, my remaining todo list has:
<mgz> * kill mbcs
<mgz> * isbaseexception
<mgz> I can probably do those before I go out around lunchtime
<lifeless> \o/
<mgz> I'll count * fix unicode wrapper as done, even though it probably needs looking at in review
<mgz> urk, fencepost error, one hour less before I need to go than I thought, will have to wait till the afternoon to finish
<lifeless> no worries
<CaMason> Hi guys. I have a revision (about 5 commits ago) but I want to reverse the changes made at that revision. How can I do this?
<jpds> CaMason: bzr uncommit && bzr revert [--no-backup]
<CaMason> how will that remove the changes from 5 revisions ago?
<jpds> Oh, sorry; I read '5 minutes ago'.
<CaMason> ah seems like I need reverse cherrypicking
<LeoNerd> Hrm.. I think there's a bug in bzr-svn currently. If I modify two files, "bzr st" and "svn st" can both see this. If I use  bzr ci  to commit just one of the files, suddenly both tools lose the ability to see the diff on the other file. bzr st, bzr diff, svn st, svn diff; none of them notice it; even though by manual diff I can see there is a difference
<spiv> CaMason: bzr merge -r -5..-6   (then bzr commit, if you want)
<lifeless> LeoNerd: file a bug pkease, it sounds plausble
<CaMason> spiv, yup just did that :) Thanks
<CaMason> well similar... bzr merge -r 5..4
<spiv> Great :)
<LeoNerd> lifeless: OK... I've also found a "workaround of sorts"
<LeoNerd> lifeless: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586096
<ubot5> Debian bug 586096 in bzr-svn "bzr-svn: Partial commit breaks status/diff of uncommitted files" [Normal,Open]
<ciss_> hi, i'm currently trying to sync a local repo with an older version on a server. problem is, while the server version crlf line endings, the local files all have lf, making a reliable sync close to impossible. what steps are necessary to make bazaar convert the current revision of the local files to crlf?
<ciss_> "local repo" = local revision
<ciss_> the server files aren't versioned
<ciss_> awfully sorry, i meant to say "... while the server version _has_ crlf line endings ..."
<lifeless> vila: ping
<vila> lifeless: pong
<lifeless> vila: status
<lifeless> of pqm
<lifeless>  * the gzip patch worked but
<lifeless>  * mail is 7bit
<lifeless>  * new patch deployed with base64 encoding as well
<lifeless> vila: can you please:
<lifeless>  * test that it works (e.g. with my broken branch)
<lifeless>  * specifically that the pqm-stdout.gz file you can be gunzip'd successfully
<lifeless>  * and piped through subunit-stats happily
<lifeless> if it can't - or put another way, if you don't get a useful diagnostic back from the error, please ask mthaddon to pull --overwrite lp:pqm
<lifeless> however
<vila> yup, broken submission sent, I'll wipe my patch on subunit to test
<lifeless> the body of the email had a fine error in it for me - after all the skips
<lifeless> so even though the gzip file was busted, I could diagnose ok
<lifeless> Its my fond hope that nothing will be wrong at all.
<lifeless> I'll sync() with you in ~ 7 hours. Thanks!
 * vila crosses lifeless fingers
<lifeless> vila: it should be ok; it passed unit tests, does what the code jml used does just less pre-canned (so does not need file on disk) and the formatting of the error into the body worked ok for me.
<lifeless> so all in all I think its in a good place.
<spiv> lifeless: sounds good!
<lifeless> spiv: \o/
<lifeless> spiv: it was particularly fun seeing
<lifeless> en_G:__a* [.utf8-nodocs] ETror 1
<lifeless> pre-t] Rit hook faes)d with UTrorot]de -253 at W)d Jun 16 12:49:05 2010
<lifeless> come out of gzip :)
<vila> lifeless: :)
<vila> lifeless: meh, bzr diff --old lp:bzr/2.2/2.2b2 --new lp:bzr/2.2/2.2b3 outputs nothing, did you forget to push ?
<vila> lifeless: some goes for bzr diff --old lp:bzr/2.2 --new lp:bzr/2.2/2.2b2 and bzr diff --old lp:bzr/2.2 --new lp:bzr/2.2/2.2b3
<lifeless> vila: I didn't touch 2.2
<lifeless> vila: 2.0, 2.1, trunk
<lifeless> because 2.2 isn't interesting till rc's, AIUI
<vila> you didn't release 2.2b3 ?
<lifeless> vila: I did, off trunk.
<vila> hmm, so we don't have a valid lp:bzr/2.2/2.2b3, can live with that, I will merge 2.1 directly to trunk then
<vila> lifeless: I got weird conflicts until I realized the 2.2 branch hasn't been updated
<lifeless> vila: It was my [incorrect?] understanding that that branch was vestigial until rcx
<vila> lifeless: well, my feeling is the same than for the 'dev' in version_info: how do we know what version was used (in a bug report) and how to we reproduce, more specifically I ran into the issue because I use local mirrors of lp:bzr/x.y and use them for my integration branches...
<vila> s/how to/how do/
<lifeless> I may well have done the wrong thing
<vila> nothing serious, but we may as well clarify, I'll try to summarize in a mp
<mthaddon> vila: we seem to have come across a problem (rob thinks it's a bzr 1.17 bug that's manifesting in pqm) - https://pastebin.canonical.com/33521/ - any ideas if we should just bzr pull --overwrite the local version with the version on LP?
<vila> mthaddon: it depends on the environment: is this bzr specific to a given project ? Are there plugins that may need to be updated to ?
<mthaddon> vila: it's currently using bzr 2.1.3dev (recent update)
<vila> mthaddon: plugins aside, it's generally safe to upgrade bzr to stable releases, the latest being 2.1.2
<vila> mthaddon: meh, 2.1.3dev ? What's that ? lp:bzr/2.1 ?
<lifeless> vila: yes it is
<lifeless> vila: easiest way to get it, and no important changes
<lifeless> vila: the thing being pulled would be the funky branch, not the bzr version, for clairty
<lifeless> vila: I'm off to bed, gl
<vila> lifeless: ok, sleep well
<vila> mthaddon: the 'bzr%2Bssh/trunk-2a' looks funny, do you have a path like that locally ?
<mthaddon> vila: it's "bzr+ssh" locally
<vila> mthaddon: my question is whether it's really the path you want to use or some url (point to a smart server) badly interpreted as referring to a local file
<vila> s/point/pointing/
<mthaddon> vila: we just define workdir=/srv/balleny.canonical.com/chroot-ubunet/home/pqm/pqm-ubunet-workdir - pqm does the rest - but it actually seems to be processing for the moment, so not sure if it was a transient error
<vila> mthaddon: maybe a typo in the offending submission ?
<mthaddon> don't think so, but it's possible
<lifeless> vila: the urls are irrelevant
<lifeless> vila: sorry, I really need to crash but you're chasing a ghost
<lifeless> pqm has url escaped stuff to make a file path
<vila> ok
<lifeless> without being subject to .. hacks or other noise
<lifeless> focus on the exception
<vila> mthaddon: what are the branches involved here ?
<lifeless> vila: its the target branch pqm was checking out to
<lifeless> suspected
<lifeless> possibly the whole thing is a random glitch caused by a bzr version upgrade while the old pqm version was working
<lifeless> and we can totally ignore
<lifeless> OTOH possibly its real
<vila> lifeless: but I still have no idea about *which* branches are involved ! Nor even which project it is we are talking about...
<lifeless> I'm suggesting checking known spurious reports of this error - we had a bug like that, and also validating that the master branches can be cleanly branched to e.g. /tmp
<vila> on my keyboard batteries are low !!!
<lifeless> vila: do you need to know to examine an exception like this?
<vila> new batteries
<vila> lifeless: Well, I need to know what bzr version is used and which branches are involved :) Or nothing if it's transient
<lifeless> mthaddon: how long ago was 13:20 bst ?
<lifeless> mthaddon: or utc, or whatever balleny is on
<parthm> if i have a RevisionSpec or rev_id string ... what would be a good way to get a Revision object? i want get rev.parent_ids.
<mthaddon> lifeless: 40 mins
<mthaddon> well, 35
<lifeless> mthaddon: so, the bzrlib change was 6 hours or so back
<lifeless> mthaddon: I don't think its likely that the u1 pqm was uninterruptedly busy for that long ?
<mthaddon> lifeless: this submission by beuno was the first in 15 hours
<lifeless> ok
<lifeless> vila: 2.1.3 from lp:2.1
<lifeless> lp:bzr/2.1
<lifeless> vila: that was the only version involved that we know of
<lifeless> I really have to sleep 1:20am
<lifeless> goodluck
<lifeless> note that the branch no longer exists
<lifeless> its in the pqm work area, so was rm -rf'd about 39m back
<lifeless> but the source branches on the local disk and on lp do exist
<lifeless> and tom can check/branch test etc them for you
<lifeless> using either the system bzr or the bzr pqm uses.
<lifeless> ciao
 * lifeless crashes
<vila> mthaddon: can you find the associated traceback in some .bzr.log ?
<vila> mtaylor: trying to rule out some more ghosts: the local repository is not shared between several projects or pqm instances right ?
<mthaddon> nope, the on disk location is only used by this pqm instance
<parthm> nevermind. got it. repository.get_revision.
<vila> parthm: hi !
<parthm> vila: hi :)
<vila> mtaylor: sorry, xchat tricked me :(
<vila> mthaddon: so,  backtrace and branches or are you waiting to see if it was transient ?
<mthaddon> vila: still waiting to see if it was transient - thx for the help so far, will let you know if it's still a problem
<lifeless> vila: please look back at recent bugs
<lifeless> I'm *sure* there was a bug where we spuriously said NoSuchRevision on new pack files or something like that
<lifeless> I have a nasty suspicion we only fixed it in 2.2
<lifeless> and if thats the case bzr and u1 are going to be hitting it a lot on pqm
<vila> overlapping auto-packs ?
<vila> the other ones I've found are about upgrading
<ciss_> is there a safe way (without committing) to check if bazaar regards the eol rules defined in ~/.bazaar/rules?
<jelmer> ciss_: bzr cat --filters I think
<jam> morning all
<ciss_> jelmer, thanks, works
<ciss_> i have a branch that uses lf for line endings. i've added the rule "crlf-with-crlf-in-repo". how can i convert all files to crlf?
<jelmer> hi jam
<jelmer> ciss_: bzr revert perhaps?
<jelmer> ciss_: (no idea, just guessing)
<jam> ciss_: 'bzr remove-tree ; bzr co .' ?
<ciss_> thanks for the suggestions, i used an export (i need to sync the branch with unversioned files from a production server)
<ciss_> how do i remove all *.pl files from versioning, no matter what sub directory they're in? i tried "./**/*.pl" and "*.pl", but neither worked
<glen__> hello, i'm trying to bzr add a bzr repository within another repository
<jelmer> glen__: I don't think that's possible at the moment
<jelmer> glen__: at least, you can't version the '.bzr' directory
<glen__> when i run bzr add the repository, nothing is output and after that bzr stat still tells me the repository directory is unknown
<glen__> ah, thanks jelmer, i didn't realise that
<glen__> i'll remove .bzr and try again, i've got the other repository versioned elsewhere
<jelmer> glen__: ideally it would add a reference to the other branch - the support for that is partially implemented, but not finished (hence the strange error about it changing to a directory)
<jelmer> glen__: alternatively you can use "bzr join"
<jelmer> that will join the two branches while keeping all the history they had when they were still independent branches
<GaryvdM> jam: I'm finally looking at my diff_using_gui branch. I've fixed some of the problems with the tests. I want to now add a registry of good defaults.
<GaryvdM> jam: Do I need to be using something like bzrlib.registry, or can I just put them in a dict?
<jam> GaryvdM: diff_using_gui? You mean external diff programs?
<jam> You can certainly use a dict, bzrlib.registry is mostly about having key:object pairs
<jam> and allows stuff like lazy definitions of the objcets
<jam> objects
<GaryvdM> jam: which I don't really need.
<jam> GaryvdM: if you know your 'values' are always going to be cheap, then you can probably just use a dict
<jam> the main things you'll want to do is make it somewhere that other people can get to it
<jam> if you want them to be able to extend it easily
<GaryvdM> jam: ok thanks.
<jam> (eg, don't put it as a dict inside of a function, make it a Module level or Class attribute level dict)
<GaryvdM> jam: ok
<GaryvdM> jam: I plan to also all for config file entries
<GaryvdM> and a Module level dict will allow for plugins to add p
<jam> GaryvdM: right. You might also want to consider where you put that dict
<jam> so that plugins can update it without having to import your whole codebase
<jam> (see the current discussion about Hooks in bzrlib)
<GaryvdM> jam: yes
<glen__> jelmer: thanks jelmer, i'll remember bzr join in future :)
<GaryvdM> jam: Thanks for the pointers. It's allways good to discuss be coding. :-)
<GaryvdM> *before
<lifeless> good morning
<lifeless> vila: hi
<vila> lifeless: I got no mail at all for the broken submission :-/
<vila> lifeless: But I got success mails though
<lifeless> vila: did the pqm change get rolled back?
<lifeless> I'll try sending error through again
<vila> lifeless: not that I know of, since they successful submissions worked I just keep using it
<bcurtiswx> any reason why i can't bzr branch lp:empathy ?
<lifeless> no, its just there to tease you
<bcurtiswx> i get a connection error
<lifeless> bcurtiswx: :)
<bcurtiswx> "unexpected end of message"
<lifeless> bcurtiswx: that sounds like a ssh login error
<lifeless> bcurtiswx: what happens if you 'ssh yourusername@bazaar.launchpad.net'
<bcurtiswx> permission denied (publickey)
<bcurtiswx> need to update my ssh key... maybe?
<lifeless> if you've changed it :)
<bcurtiswx> i am using my laptop, so i just need to add this one.. have my desktop one.. that would be it
<lifeless> or
<lifeless> you could have the same private key on both
<lifeless> whatever works for you
<bcurtiswx> yeah i could i guess
<lifeless> vila: still around ?
<lifeless> vila: if so, do you happen to know a pattern like (loom Loom switch) that will get all the tests loom affects with bzr ?
<lifeless> poolie: I realise you're on the phone; queue this for when you're not. Is there a bash/zsh way to say 'the value of variable X if its set, otherwise LITERAL' ?
<lifeless> I don't spend enough time *in* my shell to remember such things
<lifeless> or a ternary operator would do
<fullermd> I think there is for both...
<lifeless> fullermd: I have vague memories
<lifeless> but no details
<fullermd> Looking around some sh scripts I see some stuff like
<fullermd> : ${clamav_clamd_enable="NO"}
 * fullermd glances at the man...
<fullermd> ${parameter:-word}    Use Default Values.  If parameter is unset or null, the expansion of word is substituted; otherwise, the value of parameter is substituted.
<lifeless> fullermd: so a ternary operator would be better
<lifeless> I want to say
<lifeless> PYTHONPATH=$PYTHONPATH *or* don't supply PYTHONPATH=
<fullermd> Well, the above could give you an empty string.  Since it works on an _expansion_ rather than a literal value, it's possible you could somehow finagle an unset in...
<poolie> lifeless, man zshparam
<poolie> there is one but i don't recall off hand
<lifeless> thanks
<fullermd> You could use short circuiting.
<fullermd> $PYTHONPATH && PYTHONPATH=$PYTHONPATH or something
<fullermd> Repetitition is ugly though.
<lifeless> fullermd: also fragile when constructing a command string to execute :)
<lifeless> I suspect it would run '&& bzr'
<lifeless> sorry, '&& PYTHONPATH= bzr'
<fullermd> Well, we want bzr run as many places as possible, right?   :p
<poolie> it's like ${PYTHONPATH:/usr/lib/python}
<lifeless> thanks guys, thats enough for me to go on
<lifeless> I'll stash it in a bug
<poolie> ${name-otherwise}
#bzr 2010-06-17
<davidstrauss> what is the fake shell used for locking down bzr access?
<davidstrauss> i know there's a popular one
<lifeless> savanah use a thing called rsh
<lifeless> not your grandfathers rsh
<lifeless> there is a contrib/ script in bzr's source tree too
<jbowtie> I seem to have an issue where the repository is lying to me about its contents.
<jbowtie> Specifically, repository.has_revisions() is returning a revision that I'm pretty sure is not in the repository.
<jbowtie> This is a probably a result of a bug in my plugin, but I don't know how to debug it.
<lifeless> well
<lifeless> are you accessing the repo via a stacked branch ?
<jbowtie> No, it's a normal branch. Possibly its not correctly reflecting the repository contents however.
<lifeless> can you share a bit more context about what your plugin wants to do and whats going on
<lifeless> ?
<jbowtie> Sure, it's a plugin for using Team Foundation Server as a foreign VCS.
<jbowtie> I've had import working for a while and have been working on getting round-tripping viable.
<jbowtie> So I pushed some revisions into TFS last night, pushed another one this morning.
<jbowtie> In between there were some updates, (about 18 revisions or so)
<lifeless> awesome
<jbowtie> Attempting to pull those revisions however, says "nothing to pull".
<jbowtie> Normally I just call target_repository.has_revisions with the list of revision ids from the source repository.
<jbowtie> But the target is telling me that it has those 'missing' revisions even though that's pretty likely to be false.
<lifeless> so
<lifeless> the target is a bzrlib native repo
<lifeless> the source is TFS accessed via your plugin
<jbowtie> Correct.
<lifeless> the revisions you want to fetch are the new ones in TFS
<jbowtie> Yes.
<lifeless> in the target
<lifeless> you can do
<lifeless> bzr cat-revision -r revid:<revision id>
<lifeless> to quickly get at a revision from the command line
<lifeless> poolie: are you still caring for the kanban board?
<jbowtie> lifeless: Hmm.... ERROR: u'revision' is not present in revision
<lifeless> you have a revision called revision ?
<jbowtie> No, sorry, I ommitted the actual revision id at the end of error message.
<lifeless> so bzr doesn't think its there
<lifeless> if you open up python
<lifeless> and do from bzrlib import repository
<lifeless> target = repository.Repository.open('pathtorepo')
<lifeless> target.lock_read()
<lifeless> target.has_revisions(....)
<lifeless> you can see what is going on a bit more closely
<jbowtie> I suspect that has_revisions might be giving me spurious results. I'll do some more delving and see if I can narrow down the problem a bit more.
<jbowtie> Thanks for pointing out cat-revision, that should help with investigating.
<lifeless> poolie: you might like http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
<jbowtie> lifeless: Heh, I typed "cat revision" earlier instead of 'cat-revision'.
<jbowtie> So the missing revisions are in the bzr repository, but aren't reflected in the corresponding branch.
<lifeless> ok
<jbowtie> So what does that mean?  Has my branch history been corrupted? Has my plugin missed the fact that the branches diverged? Possibly should have caught it at the last push?
<lifeless> well
<lifeless> branches have a single tip
<lifeless> what is the tip revision of your bzr branch
<jbowtie> Is there an easy way to get that from the command line/
<spiv> Branch history is different to the repository.  A revision can be in the repository but not in the branch's ancestry.
<lifeless> bzr revision-info
<lifeless> or
<lifeless> bzr log -r -1 --show-ids
<jbowtie> The tip's what I expect, the last revision that was pushed.
<lifeless> right
<lifeless> so you've pushed something
<lifeless> now
<lifeless> tell me what happens in TFS
<lifeless> if you push something
<lifeless> and someone else pushes stuff after
<lifeless> do they have to merge your thing first
<lifeless> or does the TFS server merge for them
<lifeless> or is TFS not distributed
<lifeless> so it actually just counts new work as new commits
<jbowtie> TFS isn't distributed.
<jbowtie> OK, so my working theory is that the branches diverged after push #1, push #2 should have failed as they were divergent but succeeded anyway.
<lifeless> push 2 probably shouldn't have succeeded
<lifeless> because you haven't incorporated the content of the other changes
<lifeless> what you probably want to happen is to have had bzr give you a diverged branches error, made the user (you) merge TFS, commit, and then push suceed
<jbowtie> lifeless: Exactly.
<lifeless> still
<lifeless> it sounds like you've got an impressively close system there
<jbowtie> Thanks, just waiting on legal to approve putting it on Launchpad.
<lifeless> \o/
<jbowtie> So is there a way to 'fix' my branch history?
<lifeless> well
<lifeless> this is the risk when buliding foreign interfaces :)
<lifeless> the revids are uuids
<lifeless> so their meaning is pretty hard to change
<lifeless> its why svn ones are hashes
<lifeless> (and so are git and hg ones)
<jbowtie> Well, I know that - I was thinking I could reparent the revs to simulate a merge.
<lifeless> (their representation in bzr I mean)
<lifeless> I can think of two routes
<spiv> lifeless: did you get a failure from pqm for the socketpair patch?  Or should I send it myself and receive a failure directly? :)
<lifeless> do a manual merge - 'bzr merge -r revid..revid .' of the things that god skipped over
<lifeless> spiv: oh, we nuked the merge queue
<lifeless> about 11
<lifeless> so please send
<spiv> Ah, I thought I'd seen you say you'd requeue.  Will send.  I assume PQM is all happy now?
<lifeless> I was
<lifeless> then the u1 pqm claimed to have blown up
<lifeless> so I was up to 1:30 getting a handle on that and forgot
<lifeless> sorry
<spiv> That's ok :)
<lifeless> jbowtie: then when you commit that merge you'd end up with what TFS has and after that it would be all ok
<lifeless> jbowtie: alternatively, you could nuke your repo and pull fresh from TFS
<jbowtie> lifeless: OK, I'll try the merge first, I really want to avoid nuking the repo again if I can help it. I've done that often enough developing this thing.  :)
<jbowtie> lifeless: Thanks, the manual merge appears to have done the trick!  I'll probably nuke the repository over the weekend anyway but I feel much more confident about repository integrity using my plugin.
<poolie> lifeless, hi, yes i still care for and about the kanban board
<lifeless> poolie: I was asking because it seemed a little stale
<poolie> any bit in particular?
<lifeless> you and spiv seem to be looking at fetch perf
<lifeless> not jam and I
<lifeless> I've hesitated to take my name off that; I have updated the pqm and loom branching stuff as it progressed
<poolie> mm i don't know if single user assignment is a good match
<poolie> perhaps we should have it unassigned
<lifeless> I think from mary's perspective yes - team accountability
<poolie> also their ui fails unless you have a gravatar attached to your canonical email address
<lifeless> thats odd
<poolie> not fails as in crashes, just fails to be very useful
<lifeless> yes, I got that ;)
<lifeless> its odd that they'd not cater for people wanting private photos ;)
<poolie> mm
<lifeless> anyhow, I like the brevity of kanban
<lifeless> I was hoping it was just a little stale and not given up on
<lifeless> which it was/is - so thats great.
<poolie> i like the brevity too
<poolie> i don't love this specific ui
<poolie> it seems a bit slow and klunky
<lifeless> I'm moving some things that appear stalled into backlog
<lifeless> shout if you think thats wrong, and I'll put em back
<lifeless> done
<poolie> spiv did you manually test the socketpair thing?
<spiv> I did.
<lifeless> does inetd use pipes or socketpairs
<lifeless> and more broadly
<lifeless> should we file a bug on launchpad-code to use socketpairs
<poolie> neither, inetd directly connects the server to the socket
<spiv> inetd uses neither
<lifeless> or less broadly
<lifeless> entirely unrelatedly
<lifeless> should we make sure launchpad-code connects its twisted daemon that is doing ssh with the subprocess bzr via a socketpair
<poolie> bug 595331 classic title :)
<ubot5> Launchpad bug 595331 in QBzr "All button blows up (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/595331
<poolie> see the problem is
<poolie> you should be pushing the Any button
<spiv> Heh :)
<lifeless> I can't find the Any key
<poolie> spiv, lifeless, you can get decent coverage of this kind of thing by running it under wine
<poolie> ah, i guess it would depend on having an external ssh accessible under wine
<poolie> but that should be possible
<poolie> 'this kind of thing' meaning will it blow up without socketpairs on windows
<spiv> Well, in this case you can temporarily hack in "import socket; del socketpair" too
<spiv> er, "del socket.socketpair"
<spiv> (And we already have the BZR_SSH variable for exercising the paramiko code path, which was also changed)
<lifeless> I find it interesting
<lifeless> that all of (me, jam, poolie) have immediately assumed there are going to be issues validating/working on windows ;)
<lifeless> and that spiv seems to have taken them all into consideration
<lifeless> :)
<poolie> mm
<poolie> i was commenting more in response to john's review
<poolie> i don't anticipate there being platforms that have the python module but not the feature
<poolie> though it probably can happen
<lifeless> sure
<lifeless> you may have missed it
<lifeless> but I grilled spiv about windows last night
<lifeless> with a similar sort of angle to the questions
<lifeless> for all that they were different
<lifeless> I'm not offering any conclusion, I just found this an interesting thing
<spiv> Well, it's a good habit to ask "what about Windows", because we don't get as much automatic testing there.
<poolie> anyhow
<poolie> winepython++
<poolie> if in doubt just run it
<spiv> (I mean both because PQM doesn't test windows, and because fewer bzr devs run bzr on windows day-to-day)
<poolie> you may not be able to easily/quickly run the whole suite but you can fairly easily run one module of tests
<poolie> i often do that
<spiv> Good idea, thanks for the reminder :)
<lifeless> wine is amazingly good these days
<poolie> mm pinot
<lifeless> did you see the http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/ link ?
<poolie> lifeless, i did, and that makes sense
<poolie> one thing i would add is that tests can become write-once
<poolie> ie they're there, they pass, you don't want to break them but you also may not often actually improve them
<poolie> i don't think shell-like tests are the ultimate but that patch definitely made the tests cleoaner
<poolie> i'd like to work out how to test tribunal
<poolie> what kind of tests would be most useful
<parthm> lifeless: ping
<poolie> hi parthm
<lifeless> parthm: hi
<parthm> hi poolie, lifeless
<lifeless> poolie: tests that catch bugs ;)
<parthm> lifeless: in the context of jams test (https://code.launchpad.net/~parthm/bzr/250451-better-url-for-break-lock/+merge/27187) i was wondering if 10 or 30 s timeout sounds ok to you
<parthm> thats the only thing pending on that patch now before i can put it for review
<poolie> lifeless, mm i might wait until i have an idea of typical bugs and then see what to do
<poolie> at the moment most of them are lack of understanding of how something will interact with gtk
<vila> hi all
<parthm> vila: hi
<lifeless> parthm: I'm easy either way
<lifeless> parthm: we can always change our mind later
<parthm> lifeless: sounds fine. I will put it for review with the current value of 30s. thanks.
<assad> is thr any software which could show differennt revisions side by side. something like meld.
<lifeless> assad: you can use meld
<spiv> assad: well, you could always use meld :)  But there's also 'bzr qdiff' (from the qbzr plugin), for instance.
<poolie> hi vila
<parthm> assad: also, bzr diff --using=meld ... you can set up an alias if you use it frequently.
<assad> ok thank you guys
<poolie> lifeless, did my 'gnuness' branch bounce?
<vila> poolie: hmm, I forgot that one, no probably it get killed when pqm was wipped
<vila> s/no/no,/
<lifeless> poolie: when did you submit it
<poolie> you did, 20 hours ago
<lifeless> ok
<lifeless> no, it got zapped
<vila> lifeless: pretty sure it was just after I submitted the broken one that got cancelled
<lifeless> cleared out the stuff I'd submitted when the  base64 thing was noticed
<lifeless> there was some confusion about who was resubmitting
<lifeless> That is, I was confused, noone else stood a chance ;)
<lifeless> vila: oh hai
<lifeless> vila: my loom support branch
<poolie> ok, re-sent
<lifeless> vila: please check the most recent commit on it; minor stuff
<vila> lifeless: on bzr ? loom ? both ?
<lifeless> oh, as soon as I push it
<lifeless> bzr/loomsupport
<lifeless> has an open, approved mp
<lifeless> I want to land a little bit more.
<lifeless> ok, should be there now
<lifeless> vila: rev 5299
<lifeless> vila: loom trunk has its stuff already
<vila> lifeless: updating diff
<lifeless> vila: just diff -c lp:~lifeless/bzr/loomsupport ;)
<lifeless> vila: I'm asking for incremental
<vila> lifeless: updating, ooooh upstream up to thread.... Thanks abentley !!
<vila> lifeless: byt the way, you mentioned several times something about.... noisy merges in a loom, my leaking-tests loom has lots of those, can you explain a bit more what you have in mind and does it apply there ?
<vila> s/upstream/up-thread/ silly typo
<lifeless> vila: I'm rather tired after last night
<lifeless> vila: my tomorrow first thing I'd be delighted to discuss it more
<vila> lifeless: ok, no problem, I wanted to ask for some time but keep missing the right window
<lifeless> vila: so, the loomsupport change is ok ?
<vila> lifeless: yup, except for the NEWS entry order
<lifeless> vila: whats wrong with the NEWS entry order?
<vila> 'branch' < 'knit'
<vila> no ?
<lifeless> oh
<lifeless> I was asking for the incremental change to be reviewed
<lifeless> not the entire branch
<lifeless> I will fix that
<lifeless> but it would have saved you some time :)
<vila> the incremental change seemed obscure at first glance s//from_/ :)
<lifeless> ok
<lifeless> I wonder if diff -c should show the commit message too
<spiv> webnumbr.com is really cute
<vila> lifeless: maybe, but maybe fixing the tests so that calling make_from_branch_and_tree wasn't necessary (dunno if this makes sense anyway) would have resulted in an easier to read change, as long as it works, I don't care that much
<mlh> spiv: nice! the big G had something similar but the sources were (much) more constrained
<lifeless> vila: i think being able to do default format stuff is good too
<vila> lifeless: sounds perfectly reasonable
<spiv> The interface for creating a graph is quite neat, and the API is pretty cute too.
<mlh> rrd graph would be good as well
<mlh> but it is a good api
<vila> lifeless: I was speaking as a lazy reviewer not as a pedantic tester :-)
<mlh> suggestion submitted
 * mlh goes back to work
<lifeless> spiv: hmmm, open bugs in bzr, boom.
<lifeless> as in , should be trivial
<lifeless> though
<lifeless> hah
<lifeless> the ajax d-feats it
<vila> parthm: you didn't pushed your latest changes, but my last vote was tweak anyway, so please land
<parthm> vila: the diff shows the latest. anything missing?
<spiv> lifeless: yeah, you have to be cunning :/
<lifeless> I've filed a ticket
<parthm> vila: i will land it. thanks for the review.
<spiv> lifeless:
<spiv> http://webnumbr.com/bzr-in-progress-bugs
<spiv> Heh, the "average" function in the API appears broken... it sums N data points ok, but they seem to have forgotten the "divide by N" step.
<vila> parthm: weird, sorry for the noise, I didn't see the push in the mp comments and didn't check the diff itself
<vila> parthm: well, I meant, I *still* don't see the push in mp comments :)
<vila> spiv: growth ! growth ! That's the only important thing !
<parthm> vila: yes. it i don't see it inline either. its 5293 'cleaner handling of lock_url display.' ... maybe a bug due to needs review -> wip -> needs-review transition.
<vila> parthm: no worries
<parthm> vila: or maybe a feature for wip :)
<vila> parthm: features like that are bugs :)
<vila> parthm: can file one against lp-code ?
 * vila insert 'you' above
<parthm> vila: will do.
<vila> hmm, almost aligned ;)
<parthm> vila: bug #595392 .. feel free to add to it in case i have missed out something.
<ubot5> Launchpad bug 595392 in Launchpad Bazaar Integration "commit not seen inline during needs-review->wip->needs-review transition (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/595392
<vila> parthm: perfectly clear :)
<RunePhilosof> poolie, could you please take a look at bug 367545 again.
<ubot5> Launchpad bug 367545 in Bazaar "Huge memory usage for bzr branch/checkout (affected: 5, heat: 21)" [High,Confirmed] https://launchpad.net/bugs/367545
<bialix> heya bzr
<bialix> bonjour vila
<vila> bialix: privet Sacha :)
<bialix> :-)
<bialix> vila: I'm about to tweak right now
<bialix> my I beg you to land that patch then?
<bialix> s/my/may/
<vila> bialix: sure, push your changes and ping me
<bialix> ok
<vila> bialix: I wasn't sure you had a working pqm setup
<bialix> vila: I don't have one
<bialix> and poolie latest patch infers I should use Hydrazine
<bialix> I'm afraid of this beast
<jszakmeister> anyone seeing crazy memory usage during a pack operation?
<jszakmeister> Right now, it's looking like 17.5x-20x the file size when repacking texts. :-(
<vila> jszakmeister: crazy is too subjective :-/
<vila> size of which file ? The biggest pack ?
<jszakmeister> I'm re-creating a problem that we saw with another repo...
<jszakmeister> I'm using a single file, file.bin, and completely changing it's contents every commit...
<jszakmeister> and it has 100m of binary data in it.
<jszakmeister> It *seems* to be relative to the size of that file.
<vila> AFAIK repack shouldn't consume insane amount of memory anyway, commit is still about ~x3 IIRC
<jszakmeister> Yeah, that's what I thought too... but it's definitely real high when repacking texts. :-(
<vila> jszakmeister: so what is the peak memory ? 2GB ?
<jszakmeister> Yeah, depending on when the process gets sampled, I see anywhere from 1.75 to 2.0GB.
<vila> I know jam has some way to track this but I don't remember if there is an env variable for that
<vila> checking with him later in the day seems the best option
<jszakmeister> For a 100MB file.  I'm going to try this with a larger one and see how it changes, but I'm pretty sure it'll grow.
<bialix> vila: ping-ping, ring a bell :-) code tweaked, bzr.dev merged, news conflicts resolved, pushed to lp. ready to land!
<jszakmeister> vila: For max memory consumption you mean?
<jszakmeister> That'd be helpful if he does!
<vila> bialix: sent to pqm
<bialix> :-)-
<vila> jszakmeister: yes
<vila> jszakmeister: and even a plugin (meliae) to investigate
<jszakmeister> Neat.  BTW, that figure was the "real memory" used.  I think the actual VM size is larger.
<bialix> vila: commit message slightly out-of-date, sorry, I forgot about it
<vila> bialix: ? Show unicode filenames in diff headers using terminal encoding sounds fine to me
<bialix> no more "on Windows-only"
<vila> ha, rats, well the NEWS entry is correct, that's the most important
<bialix> okay
 * bialix bbl
<raphink> Hi there
<raphink> when setting up a shared repository with bzr, I put a 02770 right on the top folder
<raphink> now when users add directories, they have the right group, but they don't inherit the "g+w" bit, so other members of the group don't have write access to the contents of this new directory
<raphink> is there a way to do this?
<fullermd> What do you mean by 'add directories'?  As in push in new branches?
<raphink> yes
<raphink> or just add a directory inside a branch
<fullermd> Yeah, I'm pretty sure bzr doesn't have any builtin support for inheriting permissions like that.
<raphink> well I think this has to be done using unix permissions
<fullermd> It does for stuff under .bzr/, but new bzrdirs, not so much.
<raphink> CVS seems to force the permission inheritance when adding a directory with "cvs add"
<fullermd> In the working tree?  I'm pretty sure it doesn't...
<raphink> well I just tried
<raphink> I have a repository in /cvsroot/test
<raphink> when I do a "mkdir /cvsroot/test/toto" , it gets drwxr-sr-x
<raphink> but if I do it with cvs add
<raphink> it gets drwxrwsrwx
<fullermd> That's in the repository, not the WT.
<raphink> well CVS add works directly in the repository, for sure
<fullermd> bzr inherits inside the repo (though there's no mirror of the tree structure in the repo layout in non-antique formats of course)
<raphink> my point is that when I do a CVS add, it seems to not only do a mkdir on the repository, but force the inheritance of the parent dir
<raphink> when you say inside the repo, you mean locally?
<fullermd> Wherever a repo is touched.
<raphink> say, in bzr, I do a branch of my repo
 * fullermd thinks we're talking past each other...
<raphink> I do a bzr add on a directory
<raphink> and I commit it
<raphink> then I push it back to the parent branch
<raphink> I won't get the same result I can get with CVS, which is that this repository will have g+w so the other members of the group can commit to it
<fullermd> It will if the repo has perms right.  bzr WILL inherit those perms on new pack files etc.
<fullermd> At one time I knew exactly which dir it grabbed from.  But I don't bother remembering, I just `find .bzr -type d -print | xargs chmod g+w` or its immoral equivalent.
<raphink> you mean you have a hook on the server to do that?
<fullermd> No, I mean I do that manually when I setup the repo in the first place.  bzr preserves the g+w on new files it makes in the repo.
<raphink> ok
<raphink> let me see
<raphink> thank you for your help already fullermd
<raphink> hmm I just tried again
<raphink> the whole repo is g+w and g+s
<raphink> it's a shared repository
<raphink> I'm pushing back my branch
<raphink> which ends up in $reporoot/branches/mynewbranch
<raphink> and it doesn't inherit g+w
<fullermd> Paste a ll of the file?
<raphink> drwxr-sr-x 3 rpinson    scm_spp 4,0K 2010-06-17 12:14 testraphink
<raphink> and the parent dir is
<raphink> drwxrwsr-x 166 rchalumeau scm_spp 12K 2010-06-17 12:14 /cvsroot/spp/sppcpp/.bzrroot/branches/
<fullermd> OK, so we're talking past each other.
<raphink> what do you mean?
<fullermd> bzr preserves perms on files inside the repo, like [...]/.bzr/repository/packs/*
<fullermd> You're talking about perms on a [new] branch, which don't inherit.
<raphink> yes
<raphink> so new branches cannot be shared?
<fullermd> bzr doesn't touch those at all; it's all determined by the system via umask etc.
<raphink> ok
<raphink> but if I add a dir in an existing branch, then it will work
<fullermd> Yes, those are all internal objects in the revision, which get stored in packs in the repo, which bzr DOES set perms on.
<raphink> alright
<fullermd> For instance, if instead of pushing a new branch, you'd pushed your changes onto the existing branch.
<raphink> so then we have to setup shared branches with g+w and use these for merges
<raphink> for the group
<raphink> other created branches will remain with individual rights, while these can be used for group purposes, right?
<fullermd> Generally, branches fall into one of two categories: (1) long-lived shared branches, and (2) short-lived individual branches.  And those perms aren't a problem for either, since in the first place you'd just blat a g+w over them manually once and forget it.
<fullermd> It's only with relatively transient branches that you still want multiple people writing on that you get into trouble.
<fullermd> You could try fiddling with things so that when bzr is invoked (I'm assuming you're all going over bzr+ssh) it sets the umask to allow group writes.
<fullermd> Though that's a little dangerous on GP, and wouldn't be suitable if that weren't the only config being used on the box of course.
<raphink> thanks for the clarification
<raphink> I'm afraid the categories for the devs are not that clear ;-)
<fullermd> You could setup a cron job to just g+w all the branches under a given dir Every So Often(tm).
<raphink> ;)
<fullermd> bzrtools has a 'branches' command, so you could `cd /where/ever && bzr branches | xargs chmod -R g+W`
<fullermd> Or just forget about subtlety and g+w the entire dir tree under the repo point.
<rom1> hi there
<raphink> fullermd: rom1 is the dev having this issue
<raphink> :)
<raphink> I was just proxyfying the conversation
<raphink> (I'm the sysadmin in charge of the forge)
<rom1> hi fullermd
<rom1> thx for the tips
<fullermd> Well, if working on branches that should be g+w is the only thing bzr is invoked for, wrapping around it and resetting the umask can be a viable solution.
<fullermd> Just stick a 'bzr' shell script in some dir ahead of the real bzr in $PATH with contents like   umask 002 && /real/bzr "$@"   in it
<raphink> that might be an option, thank you fullermd
<rom1> thx a lot fullermd ! now i have to reconsider some stuff in our way of working...
<fullermd> For that matter, if it's a forge, often the ONLY use of the accounts is to access bzr stuff, so you could just setup such a umask as the default.
<fullermd> Reconsideration of working methods is awesome.  It LOOKS like real work, but it's way more fun   ;)
<rom1> sure it is...
<fullermd> Always an interesting back and forth between adjusting your approach to fit the tool, and adjusting the tool to fit your approach.
<rom1> Above all when we have a ten years habit on CVS... It is a really deep change
<fullermd> Definitely.  I had that habit myself.  Sneaking into back alleys...   dressed in rags...  manually editing files in the repo on dark nights when nobody could see...
 * fullermd whimpers.
<rom1> :D
<fullermd> But I'm clean now, I swear.  I haven't used CVS in, like, days.
<rom1> lucky man... [long whisper]
<vila> raphink: which protocol do you use to push ?
<raphink> vila: bzr+ssh
<Lo-lan-do> Hi all
<Lo-lan-do> I'm getting lots of conflicts when merging a branch after a directory was renamedâ¦
<Lo-lan-do> Details: a few files changed in ./gforge/foo in branch 5.0, ./gforge renamed to ./src in branch trunk with a gforge->src symlink, merging from 5.0 into trunk.
<Lo-lan-do> Is that expected?  Can it be avoided?  Is it related to the symlink?
<spiv> Lo-lan-do: sounds odd, renames like that shouldn't produce lots of conflicts
<spiv> Lo-lan-do: perhaps the files were deleted and readded by mistake, rather than renamed?
<spiv> I wouldn't expect the symlink to be related, but then I wouldn't expect lots of conflicts from your description either.
<Lo-lan-do> It may be relevant that both branches are bound to an SVN repository.
<spiv> Ah, I think maybe in that case they do show up as delete/add pairs rather than renames :/
<spiv> The output from the merge command (and "bzr status" afterwards) should make it clear if it's just a rename or if things have been deleted and added.
<Lo-lan-do> Right.  bzr log -v --long tells me that it's a remove/add indeed :-/
<fullermd> You could try a 'status' on the rev that did the move too.
<marsilainen> hi all
<marsilainen> I'm pondering the best way to set up my source server
<Lo-lan-do> fullermd: Same thing.  Okay, I'll blame the rename in SVN.
<Lo-lan-do> Thanks, I'll cope somehow.
<marsilainen> I'm wondering whether it's best to use bzr, sftp, http, or something else for the transport mechanism
<marsilainen> am I right in assuming that mostly people use sftp these days?
<marsilainen> I'm wanting a gatekeeper type of workflow btw
<Lo-lan-do> marsilainen: /me uses bzr+ssh://
<marsilainen> I'd like people to be able to get a branch anonymously though
<marsilainen> so doesn't that rule out bzr+ssh?
<Lo-lan-do> You can have the same repo available through both bzr+ssh and http
<fullermd> Not quite necessarily, though in practice generally.  Doesn't mean you can't use bzr+ssh on the writing side of course.
<marsilainen> so is it generally best to allow people to get the code via http, then send changes to me and I commit them using ssh or whatever?
<marsilainen> I guess that all sounds sensible
<Lo-lan-do> What's generally best is to find a way that sticks so your workflow.  Many scenarios are possible, pick your preferred one :-)
<marsilainen> I guess this sort of workflow/scenario is quite common, but I couldn't find a tutorial which went through it
<marsilainen> anyway, I'll go with that
<marsilainen> thanks for the help
<Lo-lan-do> Based on your description, my choice would probably be to have a local branch bound to a bzr+ssh branch that's also accessible through http.
<marsilainen> ok
<Lo-lan-do> But you may prefer pushing by hand rather than binding, or using sftp instead of bzr+ssh, or lots of other variants.
<marsilainen> I don't know what binding is, so I'll have to look into that
<Lo-lan-do> It's sometimes called heavyweight checkout.
<fullermd> If bzr+ssh works, you almost certainly will want to use it instead of sftp.  Dumb protocols are dumb.
<marsilainen> ok, so yes, that looks like what I want
<marsilainen> so, local branch bound to mainline over bzr+ssh, and http access to the same mainline
<marsilainen> having so many choices is very flexible, but knowing which is the right one to use for a given scenario is quite a challenge :)
<vila> spiv: Still up ? Have a look at babune, your last patch broke :-/
<vila> spiv: more precisely FAIL: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh
<vila> spiv: which makes me wonder if we trigger another bug in paramiko
<mgz> maybe just a tyop, vila?
<mgz> return self._sock.read(count) <- should be recv?
<mgz> ...doesn't explain how it got past pqm though...
<vila> mgz: people reading above my shoulder and pretending *they* found the bug are so irritating :-)
<spiv> mgz: yes, that looks likely
 * mgz takes all the credit
<vila> spiv: indeed, s/read/recv/makes the test pass, tell Vincent you really need to sleep now :)
<spiv> This is a code path that would only be used with sftp, not bzr+ssh
<spiv> I'm not sure why that isn't failing on PQM
<vila> spiv: that's the scary part yes
<spiv> Perhaps PQM doesn't have paramiko?
<vila> spiv: that's the scary part yes :-)
<spiv> vila: so it is indeed my bedtime
<vila> I'll pqm the fix, feel free to investigate when you wake up
<spiv> vila: but I "vote approve" the typo fix, and please file a bug about PQM not catching it
<vila> spiv: I'll do
<mgz> vila: has jam's observation about _probe_bzrdir got you anywhere new with the leaking tests?
<vila> mgz: It clarify my suspicion which helped a lot, I'm tearing the smart server in reusable parts right now while spiv is sleeping :)
<vila> mgz: the hangs themselves are due to my incomplete modifications
<vila> mgz: I need to roll them back and restart with the new test server infra
<sven_sandberg> hi! i have a shared repository (2a) with a few mysql trees in. i am now trying to pull a revision from our central repository (also 2a), and after it has downloaded ,it's taking hours. it's the same with bzr 2.0.2 and bzr 2.2b3 (pulled from lp this morning).
<sven_sandberg> the status message is currently 'Fetching revisions:Inserting stream:repacking texts:texts 242291/637888'
<sven_sandberg> other people tried the same pull without problems
<sven_sandberg> any idea what is going on? is my local repository broken?
<mgz> vila: I'd really be very tempted if you're feeling rewritey to set it up in such a way as you can spawn rather than thread the server it at the drop of a flag
<vila> sven_sandberg: this sounds like a conversion happening on the fly
<fullermd> No, it's repacking.  That can take a while if it's a big repository...
<sven_sandberg> fullermd, so is it somehow trying to optimize my repository? is it possible to turn this off and do it later when i have time?
<mgz> there was talk about TerminateThread being used, but that's really not safe, unlike killing child processes
<Lo-lan-do> You can do it preemptively, but I'm not sure you can disable it.
<vila> sven_sandberg: except if it's the *first* repacking since the conversion which is weird anyway
<fullermd> I don't think you can disable it through the CLI; some code level frobbing can do it.
<sven_sandberg> vila, it's the first time i see this after we upgraded to 2a. but i have been pulling successfully without this happening many times
<vila> mgz: forking will kill perfs on windows, even on Unix it  may be costly, plus some tests except to be able to share some data with the server (that's not super clean, but that's the way it is)
<vila> sven_sandberg: have a look at the .bzr/repository/packs directory sorting the file by size
<mgz> I agree it's probably not a solution we want, but having it as an easy switch in the test at least makes narrowing down certain issues easier
<fullermd> sven_sandberg: It does tiny repacks fairly often, and minor repacks less often, and major repacks not so often, and gigantic repacks rarely.  So the ones you've seen to date are probably over before you notice 'em.
<vila> sven_sandberg: you may be repacking the biggest file which takes time
<mgz> having some problematic subset of server tests forking for the moment would be workable
<sven_sandberg> fullermd, i see, makes sense
<sven_sandberg> vila, there are 35 files, and the biggest one is 299 MB
<sven_sandberg> fullermd, would it be a reasonable feature request to add an option to CLI to turn this off?
<sven_sandberg> i mean, i don't even know if it's doable...
<vila> sven_sandberg: the rule is to pack each set of 10 files into a bigger one, just knowing that there is 35 files doesn't tell me enough
<vila> sven_sandberg: *not* packing would have a pretty bad impact on performance
<vila> sven_sandberg: I don't think you'll run into the same problem soon, otherwise the solution is to repack each night preventively
<vila> sven_sandberg: but if that's the first time you encounter the problem, I don't think it's worth it
<sven_sandberg> vila, i see. the file sizes are, in MB (rounded), 299 38 34 19 17 10 4 3 3 3 3 3 2 2 2 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
<sven_sandberg> vila, how do i repack preventively?
<Lo-lan-do> 35 files can hold about 100000 revisions.
<vila> sven_sandberg: 'bzr pack'
<Lo-lan-do> Er, make that 10000, sorry.
<xapantu> hi all !
<xapantu> Is it possible to execute a script after each comit ?
<sven_sandberg> vila, thank you!
<xapantu> because I would like that a file was updated with thz bzr revision number to each commit.
<xapantu> do you have any idea ?
<xapantu> Thanks ! :)
<mgz> look at the docs for post commit hooks
<vila> xapantu: embedding VCS info in versioned files is rarely a good idea, but have a look at post commit hooks and 'bzr version-info'
<mgz> but... it sounds more like you want the... wassit... right, what vila said
<mgz> what's the term for the $$ thing cvs does?
<xapantu> ok, thanks !
<vila> mgz: see ? I can look above your shoulder too :-P
<vila> keywords
<vila> yeah, there is that too, lp:bzr-keywords ?
<mgz> thanks :)
<xapantu> but I would like to do this on all branch : e.g. : if another developer checkout the branch, he doesn't have the hooks, does he ?
<Lo-lan-do> xapantu: Note that .bzr/branch/last-revision already has the last revision number
<vila> xapantu: then let's step back a bit, what are you trying to achieve ?
<xapantu> i would like to do a dialog window with the revision
<xapantu> Inkscape do this with a makefile but it is very slow....
<mgz> so, when the program is built, you want the revno in the about window, say?
<xapantu> yes
<fullermd> You want to do that as part of the build process rather than as keywords anyway.
<fullermd> Keywords are most applicable when you care about file-level stuff.  You want tree-level stuff for that.
<vila> xapantu: exactly what fullermd said
<xapantu> like on this page : http://wiki.bazaar.canonical.com/KeywordExpansion ?
<xapantu> I am reading it...
<fullermd> Otherwise all you'll find out is "this file that contains the keyword was last updated at time/rev XYZ, even though the rest of the tree has had 600 commits since then"
<xapantu> ok, I am going to try with keywords.
<vila> that's the file-level approach
<vila> ... :)
<mgz> are we talking inkscape here? if so, just working out what's slow with the current makefile and fixing it is probably the right answer
<fullermd> Also, keywords aren't really usable with bzr.
<vila> xapantu: bzr version-info --template 'var = {revno}\n' --custom
<vila> xapantu: start with the above, redirect to whatever file you see fit, running that *can't* be that slow :)
<xapantu> ok, I am going to add this to my makefile, thank a lot :)
<assad> is there a meld like tool for windows? besides bzr qdiff
<sven_sandberg> vila, fullermd, i need an estimate on how long time this will take... will it go through any more slow stages after "Fetching revisions:Inserting stream:repacking texts:texts" ?
<vila> sven_sandberg: the longest ones should be chk and texts, IIRC texts came after chk, if you don't sign your revisions (I think you don't), that should be the last long step
<sven_sandberg> vila, good. yes, it already went through chk. so that's good news. thank you!
<vila> sven_sandberg: right, just repacked by bzr repo, that should be it
<vila> sven_sandberg: can you come back when it's finished to tell us how many packs you end up with and their sizes ?
<vila> sven_sandberg: oh, and all of that occurs without mounted file systems right ?
<sven_sandberg> vila, sure
<sven_sandberg> vila, how do you mean, without mounted file systems?
<vila> sven_sandberg: the repository is on a local file file system or a mounted one ?
<sven_sandberg> vila, local
<vila> ok
<assad> can we collapse all the little revisions into one?
<vila> assad: merge ?
<assad> vila, i made several commits with small changes. i want them to collapse those revisions into one
<assad> in my own branch
<vila> assad: bzr uncommit -r<rev_before_first_commit> ; bzr commit -m 'The whole shebang'
<assad> vila, thanks
<vila> assad: try that in a scratch branch in case you chose the wrong revision
<assad> vila, ok
<LeoNerd> Or, branch -r<firstrev>; merge
<vila> assad: or do several uncommit and use bzr diff to check
<sven_sandberg> fullermd, vila, how hard would it be to hack the source to turn off repacking? can i just comment out something?
<vila> LeoNerd: He wants to get rid of the commits
<LeoNerd> Hrmm.. Well... merge shoudl show them on the history as a single commit
<assad> yeah. the revisions are unnecessarily piling up due to small changes and commit
<vila> LeoNerd: Agreed, that was my first proposal :)
<vila> sven_sandberg: not that hard, but the penalty will strike back quickly: you don't want to query 100s of indices
<vila> svaksha: I understand that it's blocking you right now, but the next occurrence could be in several weeks or months
<svaksha> ?
<vila> svaksha: argh, sorry
<vila> sven_sandberg: : I understand that it's blocking you right now, but the next occurrence could be in several weeks or months
<vila> xchat: stop losing my settings !!!
<guilhembi> vila: sven_sandberg wanted to do an important merge today, he's blocked for hours now waiting for the repack to finish;
<vila> guilhembi: I realize that see above, I'm looking...
<guilhembi> he would be fine with disabling repack, doing his merge, and re-renabling repack after the merge and doing "bzr repack".
<guilhembi> vila: merci beaucoup
<vila> guilhembi: An alternative would be to branch outside of the shared repo
<vila> guilhembi: work there, and pull the branch back once done
<vila> sven_sandberg: that should even be doable *while* the repack is going on
<guilhembi> sven_sandberg: so that means
<guilhembi> cd your_shared_repo
<guilhembi> bzr branch first_tree /other/dir/out/of/shared/repo/first_tree # should take a few minutes
<vila> sven_sandberg: sorry for the Murphy's law striking  :-/
<jam> morning all
<guilhembi> bzr branch second_tree /other/dir/out/of/shared/repo/second_tree # should take a few minutes
<jam> hey vila
<vila> hey jam !
<guilhembi> sven_sandberg: and then
<guilhembi> cd /other/dir/out/of/shared/repo/second_tree
<guilhembi> bzr merge /other/dir/out/of/shared/repo/first_tree
<vila> jam: what's the fastest way to disable auto-repack ?
<guilhembi> bbl
<vila> sven_sandberg: the first tree can stay in the shared repo, the only branch that needs to be outside the repo is the one you want to commit to
<vila> jam: something like : http://paste.ubuntu.com/451111/ ?
<vila> jelmer: some mps are harder to land than others.... :)
<jam> vila: I think you need to do it in the groupcompress repo
<jam> vila: nm, that would do fine
<vila> jam: no autopa... ok
<jam> I'll also note, you should be able to ^C an autopack
<jam> it will want to do it on the next fetch
<jam> but I think the data is already present.
<jelmer> vila: :-))
<jam> (maybe not, I'll check quickly)
<jam> I take that back, it looks like 'pack-names' isn't saved until after the autopack finishes
<vila> jam: what do you take back ? 'data is already present' or 'be able to ^C' (the former I think)
<jam> vila: if you interrupt autopack, it reverts the whole fetch
<jam> pack-names isn't updated until the fetch + autopack is completed
<vila> makes sense from the user point of view
<sven_sandberg> vila ,jam, i can confirm that; i tried to pull, then did ^C when i noticed it's slow, and then it went back to the original state. next time i pull it tries to do the same thing.
<vila> sven_sandberg: ok , did the workaround unblocked you ?
<sven_sandberg> vila, i'm tryingi the out-of-shared-repo approach but it's slow. i have now ^C'ed the repack but it's still running (cleaning up?) at 100% CPU
<sven_sandberg> vila, ok, i the repack stopped now and the 'bzr branch repo out-of-shared-repo' terminated. so i'm ready to do some work now
<sven_sandberg> vila, jam, fyi, it left a lot of bzr-index-HEXNUMBER files in /tmp/ after i did ^C during repack
<vila> sven_sandberg: when you'll came back to your shared repo, you can 'bzr pack' before pulling
<vila> jam: I think the simplest way to address the issue here would be an option to disable autopack on-demand
<vila> jam: a noisy one that will yell: "Watch out ! I need packing ! Gimme my bzr pack soon !"
<vila> jam: so sven_sandberg can ^C the autopack and use the option as long as he needs it and issue the 'bzr pack' at the end of the dat
<vila> day
<sven_sandberg> vila, yes that would be perfect solution for me
<thrope> hi - trying to use bzr+ssh from windows... have the following problem
<thrope> http://pastie.org/1008527
<thrope> SSHException: Error reading SSH protocol banner
<thrope> any ideas? do I need to install anything else for ssh access on windows
<thrope> could it be the nonstanadard port causing problems?
<jam> thrope: that looks like it is able to connect to the remote host, but the remote host isn't offering ssh on that port
<jam> are you sure 2222 is the correct ssh port for that machine?
<thrope> yes
<thrope> ive had it working with tortoise svn and svn+ssh
<thrope> and I can connect with putty from the same winows machine on port 2222 (just checked)
<thrope> oh wait it works now
<thrope> will it use putty keyagent?
<jam> thrope: paramiko will, yes
<jam> vila: any thoughts on the thread timeout issues?
<thrope> cool thanks - i think it was something funny with windows firewall
<vila> jam: didn't you get my reply ?
<jam> vila: well, I replied to your reply :)
<vila> ha, let me check
<jam> do you think that the client has legitimately closed the connection, and the server wasn't informed?
<jam> ooh. another interesting possibility. What if on Windows if you read from a closed socket it tells you, but if you read and *then* the socket closes (without any data) you timeout
<jam> (with the hard 2-min timeout)
<vila> jam: I think the client closed yes
<vila> jam: I suspect that the smart server lacks one check I added in my test server which is that the socket returned by accept shouldn't touched at all and the smart server is trying to read anyway which blocks
<vila> jam: the problem is: during the "serving" phase doing accept() followed by recv() is the normal (and wanted) behavior, but in the "shutdown" phase that should be accept() ; am_I_still_serving() ? then recv() otherwise die
<vila> jam: doing that ensure there is no racing threads, which left the question: Why didn't the server react to the client closing the socket ?
<jam> vila: which is my proposed: "if the socket is closed after recv() starts, then it doesn't get informed until after the hard/soft timeout"
<vila> jam: on windows that is, things works as expected (at least by me :) on lucid/py26, karmic/py2[456]
<jam> which is a complete guess
<vila> jam: yes, and that's why I thanked you in my first reply :) I was expecting some difference between the smart server and my test server but didn't know which
<jjann> Hi. How do I revert all changes made by a given revision? (ie do something like what 'hg backout' does with mercurial)
<jam> jjann: bzr merge -r X..X-1
<jam> sorry
<maco> most recent commit? bzr uncommit
<jam> jjann: bzr merge . -r X..X-1
<maco> also, bzr revert
<jam> the '.' is significant
<vila> jam: I've been side-stepped by a combination of lifeless and spiv patches rendering my loom unsusable until I fix some other failures :-.
<jjann> maco: no, not most recent, and 'revert' doesn't do that
<jjann> jam: thanks
<vila> jelmer: and one more Request for non-PQM managed branch :-P
<jelmer> vila: argh
<jelmer> vila: problem is I'm much more used to submitting lp branches these days
<vila> jelmer: yeah, yeah, they all say that :)
<mhall119> hi, I've got a question
<mhall119> two developers working on a project, can they use bzr+ssh to push/pull from the same location?
<mhall119> if they have to ssh in as different users?
<maco> mhall119: if theyre on the same team...
<maco> and the location is a team location
<mhall119> what do you mean team location?
<mhall119> I'm not using Launchpad
<mhall119> just a server with ssh access
<bialix> mhall119: look at bzr_access script in src/contrib
<mhall119> or would I be better off using bzr serve?
<mhall119> where woudl I find this src/contrib?
<bialix> look into bzr release tarball
<bialix> directory contrib/
<mhall119> oh, ok
<mhall119> I just have bzr installed
<marsilainen> mhall119: I think that usually unix group permissions are used
<marsilainen> so you put both developers in the same unix group
<mhall119> will it create files with g+w?
<mhall119> because default umask makes them g+r only
<marsilainen> and then make sure that the group has appropriate permissions to the files
<marsilainen> you probably need some special umask, not sure
<marsilainen> I think it's in the docs somewhere
<mhall119> hmmm, can you specify a umask for a particular directory?
<marsilainen> maybe it needs a 'sticky' bit on the dir at the top of the repository or something
<marsilainen> I don't know the details, but I believe that's how people do it
<mhall119> I tried that, that just makes new files belong to the same group, but doesn't give them write access
<marsilainen> mhall119: "On many unixes setting the permissions of the base directory to 02770 will allow the group to access the repository, and will let the group ownership be inherited when new directories are created underneath."
<marsilainen> that was from: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<mhall119> thanks marsilainen
<marsilainen> np
<vila> mhall119: it would be simpler to use a single user but two ssh keys
<marsilainen> depends on the situation innit
<mhall119> well, that didn't work...
<mhall119> second user doesn't have permission to push changes
<marsilainen> well, there is probably something more you need to do then...
<Lo-lan-do> You could also play with setfacl
<mhall119> the problem is that when user1 pushes a new branch, it's rwxr-sr-x on the new directory
<mhall119> and rw-r--r-- on the files that it creates
<marsilainen> mhall119: this looks like a howto of sorts: http://profarius.com/content/creating-your-own-bazaar-server
<mhall119> looks like all the same steps I did
<Lo-lan-do> You need either umask 002 or some acls.
<mhall119> but can I umask only that directory?
<Lo-lan-do> Nope, umask is a property of a process.
<Lo-lan-do> It's generally set by the shell.
<mhall119> and, since I"m using ssh, it'll have to be set on my users
<mhall119> right?
<Lo-lan-do> Right.  Or you could write a bzr wrapper that calls umask then bzr.
<mhall119> hmmmm
<ovnicraft> hi folks, i am trying update my repos from lp, so i have this error http://pastebin.ca/1885154
<ovnicraft> says maybe a bug in bzr
<jelmer> ovnicraft: can you please file a bug against bzr with as much info as possible?
<jelmer> ovnicraft: it does indeed look like a bzr bug of some sort
<ovnicraft> i see the bug confirmed in bzr gubs
<ovnicraft> *bugs
<ovnicraft> http://bit.ly/9Uycul
<ovnicraft> set milestone 2.2
<ovnicraft> i think the bug is really important to people who upgrade 2a version the branchs
<ovnicraft> missing references to chk root keys, says the error, itcan be fixed with new set info user in repo or somthing like that?
<ovnicraft> i need the changes from lp
<mhall119> okay, i'm just going to make a single user to share
<mhall119> I don't want to make drastic changes to user's umasks just for this
<jelmer> ovnicraft: sorry, I'm not familiar with the specific bug. You'd probably want to talk to one of the bzr folks
<jelmer> vila: Is your branch hung?
<vila> jelmer: I don't think so
<ovnicraft> jelmer, yes i see the bug info en is pointed to 2.2 release maybe talk with bzr folks can help to fix now or help to fixe
<ovnicraft> *fix
<mmestnik> Hello, I'm working with bzr over samba and there was a problem calling chmod.
<mmestnik> http://paste.pocoo.org/show/226581/
<mmestnik> I've asked in #python about the syntax.
<dickelbeck> newbie could use a little help
<dickelbeck> There exists lp:kicad and I have a local branch of it I have been working on.  1) Edit, 2) commit locally, 3) merge
<dickelbeck> merge said "nothing to do".  Now how do I get my changes back into lp:kicad.  Do not want to submit a patch.
<jelmer> dickelbeck: you could push back into lp:kicad if you have that permission
<jelmer> dickelbeck: alternatively, you can submit a merge proposal so the maintainers of lp:kicad can merge your changes
<jelmer> dickelbeck: you can create a merge proposal by pushing your local branch to Launchpad and then proposing that branch for merging
<dickelbeck> I do. I *am* basically a main maintainer.
<dickelbeck> But I do not yet have bzr experience beyond the initial push I did to establish the launchpad branch.
<jelmer> dickelbeck: in that case you should be able to "bzr push lp:kicad"
<rom1> i think you take the merge command in the wrong direction
<dickelbeck> Now you say I can use push again.
<rom1> merge means merge from and not merge to
<dickelbeck> rom1: I understand that about merge.  There were no recent changes in remote branch.
<jelmer> dickelbeck: so you should indeed just be able to push to the remote branch
<dickelbeck> But the answer to my question is that I need to use push now, correct?
<rom1> yes
<jelmer> dickelbeck: yep
<rom1> if you have modifications on the remote branch, the push command will tell you about it, and you will have to do a merge
<rom1> before repushing
<dickelbeck> thanks, you guys are very helpful.  It is done.  Now I will run for cover.
<jelmer> vila: is pqm slower than it used to be?
<mmestnik> I know this isn't the best way to submit a patch, though it dosen't do anything...
<mmestnik> http://paste.pocoo.org/show/226585/
<vila> jelmer: depends, it now runs all the tests instead of stopping at first failure for example
<mmestnik> This helps with using bzr over a samb mount by protecting the chmods from causing unwanted trouble.
<mmestnik> The next issue is something I can't work out... however if any one would like to feed me with patches I'd test them.
<jelmer> mmestnik: is this with unix extensions enabled on the samba side?
<mmestnik> I'm un-aware of how the server is configured.
<jelmer> mmestnik: with unix extensions enabled the chmod should work
<mmestnik> jelmer: It would be nice if bzr could work around any problematic server/client configuration.
<mmestnik> There are other filesystems that would choke on a chmod so that solution is incomplete.
<jelmer> mmestnik: the chmod is there for a reason though, I presume to prevent files that are private from becoming accessible to other users during merge
<mmestnik> ...and on file-systems that fail the chmod it's irrelevant.
<mmestnik> Hence the failed chmod ;)
<vila> I'm off
<jelmer> vila: have a nice evening
<vila> mmestnik: did you try running the test suite with your patch ?
<mmestnik> It's a nice gesture to try and make it accessible, but it's not essential.
<jelmer> mmestnik: well, in those situations we would have to use whatever semantics are available on those file systems
<mmestnik> It still failed with the patch.
<mmestnik> jelmer: Ahh, it's already done 4 you... nothing to do, no operation.
<mmestnik> Look if chmod says "this bit does not exists" there there is no point in continuing to attempt to access this bit.  vfat won't have more then one read-only flag.
<vila> mmestnik: bzr doesn't expect the local file system to be too exotic but runs on windows, so there may be corner cases where we do things on windows but not on unix with a windows mounted file system
<jelmer> mmestnik: ? Windows has its own security semantics and it can't guess what permissions you want it to have
 * vila really off
<jelmer> vila: the cifsfs used to mount remote windows file servers doesn't support chmod unless the server does
<mmestnik> chmod is chmod.  It's the tool to work with those permissions.
<mmestnik> After the chmod thee is nothing more for you to  do.
<jelmer> mmestnik: on windows those things work with nt acls
<mmestnik> This is not windows and it's up to the ntfs driver to sort converting chmod into nt acls, the application should remain ignorant.
<jelmer> mmestnik: what does ntfs have to do with it?
<mmestnik> What does windows have to do with it?
<jelmer> mmestnik: SMB exposes windows semantics over the wire
<jelmer> mmestnik: if the remote side is running Samba then it can be configured to support chmod's and the cifsfs/smbfs module will know to send it unix modes
<jelmer> mmestnik: if the server doesn't support that it will basically claim to not support any mode changes at all
<mmestnik> I'm just saying that the chmod is there for conveyance, it's failure can for the most part be safely ignored until a user discovers otherwise.
<jelmer> mmestnik: I disagree, data privacy is not opt-in.
<mmestnik> Using samba(or anything else that dosn't have chmod) is an opt-out of data privacy.
<jelmer> mmestnik: we could allow configuring Bazaar to ignore failed changes of file permissions, but it should not be the default.
<mmestnik> That sounds reasonable.  Still the issue is after this patch there are other problems.
<jelmer> mmestnik: what sort of issues?
<mmestnik> http://paste.pocoo.org/show/226596/
<mmestnik> http://paste.pocoo.org/show/226598/
<LabMonkey> I'm trying to follow http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/http_smart_server.html and I keep getting 403 when I browse what should be the root containing all repos.
<LabMonkey> Any help?
<mhall119> does anyone know if the bzr for windows standalone installer comes with an ssh client?
<jelmer> mmestnik: right, it's also not possible to do atomic renames
<mmestnik> :(
<jelmer> mmestnik: bzr currently relies on the platform to find out what semantics to expect, it should probably look at the particular fs more
<mmestnik> What link should I send to my samba admin to enable the chmod stuff at least?
<mmestnik> I think it should be generically written to try a feature(like atomic renames) and then fall back gracefully.
<mmestnik> I understand that that might involve back tracking a few steps, so perhaps there should be a "We are just testing this filesystem" step.
<mmestnik> The application should be able to handle features being removed dynamically.
<luke-jr> SHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0x927cf0c> corrupt: sha-1 of reconstructed text does not match expected sha-1. key ('svn-v4:f396537e-aa06-0410-a58a-90fff5392f0b:vxmlb/branches/Log4perl:3083',) expected sha 061b82af5d2a9435f0ea59b57e87573d4eccc784 actual sha 33977d3efbed4d55aca8bc7208838e850b5fc647
<luke-jr> help? :(
<beuno> luke-jr, knit?
<beuno> that's like a 100 year old branch, right?
<beuno> anyway, try bzr check and brz reconcile
<beuno> otherwise, we'll need jam or some other low-level guru
<luke-jr> beuno: dunno how old...
<luke-jr> I suspect it may actually be corrupt
<tsmith> is there a way to convert a bzr branch to svn?
<jelmer> tsmith: if you have bzr-svn installed you can push into svn
<tsmith> ok i try that
<tsmith> $ bzr push svn://localhost/user_directory --overwrite
<tsmith> bzr: ERROR: Permission denied: "."
<tsmith> user_directory is a brand new svn repo w/ 0 commits
<tsmith> any idea?
<tsmith> jelmer, any idea?
<assad> how to do a "review approve" and "merge approve" through the launchpad ticket interface? it is available through the email service but what about the ticket interface on launchpad for merge approve?
<jelmer> tsmith: you can't push to a svn:// URL usually
<tsmith> o awesome
<tsmith> thanks man
<jelmer> tsmith: Not with svn itself either I mean
<jelmer> tsmith: You'll need svn+ssh://, file:// or http://
<tsmith> file:// worked
<lifeless> assad: what do you mean 'ticket interface'
<lifeless> assad: can you give us an example url ?
<assad> https://help.launchpad.net/Code/Review#Proposing%20a%20merge lifeless
<assad> minus the email interface on that page
<lifeless> thats the docs
<lifeless> I mean a url of a merge proposal you are having trouble with
<assad> lifeless, https://code.launchpad.net/~zubairassad89/sahana-eden/vms/+merge/27697
<lifeless> ok, on that page if you fill in the 'Add comment' box and set the 'Review' field below it to a value, then click save comment
<lifeless> it will do a review - and you can use that to set your review to approve or needs fixing or whatever.
<lifeless> thats the 'review approve' in the web UI
<lifeless> the 'merge approve' in the web UI is via a edit icon to the right of the 'Status: Approved' at the top of the page.
<assad> lifeless, ok
<assad> lifeless, thanks
<lifeless> no problem, hapy to help
<jam> hi lifeless
<jam> Interesting attempt of a DAVE swarm. Another person worked me over overnight with waves of Finks, and did a pretty decent job of taking out a few of my outer resources.
<jam> I did notice that direct assault seemed to only be able to damage 1/2 a tower in a given wave, which seems pretty good. When attacking others I usually shoot for 1-2 towers on the first waves, (obviously more on later waves)
<bitdancer> What are these files that end with things like ~1~ in my checkout?
<bitdancer> Or, rather, I know what they are (old copies of files), but why are they created?
<bitdancer> And how do I get rid of them? :)
#bzr 2010-06-18
<caravel> good evening, people. Is there any ftps plugin as yet ? (is this blueprint still actual ? https://blueprints.launchpad.net/bzr/+spec/tls-and-ssl-support)
<lifeless> caravel: we don't really work off of blueprints
<lifeless> caravel: I don't think ftps has been implemented, https is defintely supported - that blueprint is totally inaccurate.
<caravel> lifeless: fair enough - thanks for your answer - that's about all I found on the subject really, googled a few times already over the past weeks
<lifeless> caravel: we support sftp which is:
<lifeless>  - faster
<lifeless>  - simpler
<lifeless>  - more widespread than ftps
<lifeless> caravel: and we support https
<lifeless> and bzr+ssh, which we recommend
<caravel> but unsupported by FileZilla Server -- which is extremely popular ;-)
<lifeless> I suggest you file a bug
<lifeless> the core dev team work largely off bug backlogs
<lifeless> rather than specs
<lifeless> we use spec when planning complex things with unpredictable interactions.
<caravel> lifeless: I guess it's not a wide requirement anyway -- fedora 13 here, could I bazaar over some ftps mount transparently ?
<caravel> (just a thought)
<lifeless> caravel: you should be able to push/pull over an ftps fuse mount, yes.
<lifeless> caravel: performance will be less than ideal though - pushing and pulling is dealing with a database afterall
<caravel> lifeless: thanks - not looking for performance, rather trying to obtain from our web dev that he commits his code for himself, shares it, permit some backup... fuse should do, if bzr does't time out too fast ?
<caravel> there is no real infrastucture, so the idea would be to usie a (temporary) lenny server... as a bzr client to sync code from his FZ/win over fuse/ftps. Arrhmm, can this make sense ?
<AfC1> I'd never heard of Filezilla before, but one of my clients yesterday had a problem with it's sftp implementation, whereas Nautilus's "connect to server" (via "SSH"/sftp) worked fine.
<lifeless> the bane of my life
<lifeless> [11630.844206] iwlagn 0000:02:00.0: Microcode SW error detected.  Restarting 0x2000000.
<lifeless> caravel: anyway
<lifeless> uhm, you can use any workstation - say yours - to run a bzr server on
<lifeless> if you're doing network mounting, good ol smb will interoperate happily with windows
<lifeless> I'm assuming your web dev is on windows
<mkanat> lifeless: Ugh--what kind of wireless card do you have?
<lifeless> 6000 series
<mkanat> lifeless: Hmm. I guess they're relatively new.
<lifeless> mkanat: arrandale
<mkanat> lifeless: Oh, yeah.
<lifeless> mkanat: whats worse though
<lifeless> mkanat: is that the kernel fails to reset some stuff when the microcode fails
<lifeless> so you have to rmmod + modprobe
<lifeless> fix is partly in maverick
<lifeless> the restart bug affects all iwl cards
<mkanat> lifeless: That's really obnoxious. I've had a laptop that that happens on.
<lifeless> but you have to have a firmware issue too for it to actually annoy you
<lifeless> :)
<mkanat> I've had it happen where, randomly, I start up and the card doesn't work, also.
<caravel> lifeless: yes, he runs on windoz, there is no perpetual server online besides the production, hosted web server -- and some windoz machine at his place
<caravel> bzr fits great with our needs because of its various topologies
<caravel> each is in a different part of the country, rather poor and unreliable bandwidth. soon we'll get a couple of servers, but for now
<caravel> I found easily LftpFS but it's read-only... anyway, getting waaaay off topic. My concern here was how bzr would handle this type of link
<lifeless> caravel: as a push/pull target fine
<lifeless> you can't work on a fuse fs directly though because they don't support OS locks properly
<caravel> "OS locks" what do you mean ?
<lifeless> operating system locks
<caravel> lifeless: ok I'm with you, but in my case, only one app will access the fuse link so it should not matter?
<caravel> (bzr)
<caravel> I'm cautious because while setting up passive and active ftp w(o encryption, I found bzr a bit "delicate" and quite far from the verbose mode.
<caravel> opening a passive ftp to a badly (NAT & FZ ports) configured server, did hang bzr apparently
<caravel> disclaimer: was running bzr's windoz client
<caravel> as soon as the server & router config were rectified, it rocked but I had a few timeouts (while other FTP clients have just no issues)
<spiv> lifeless: did you see https://bugs.launchpad.net/bugs/595473 ?
<ubot5> Launchpad bug 595473 in Bazaar "paramiko not installed on PQM ? (affected: 1, heat: 6)" [Critical,Confirmed]
<caravel> can bazaar explorer / kde take advantage of kio (cf. kio-ftps) ?
<spiv> It would be nice to find out the list of missing features PQM gets when doing 'bzr selftest'.
<spiv> caravel: someone recently added a gio transport for bzr, I don't recall seeing the same for kio though.
<caravel> spiv: thanks
 * caravel finds it real hard to google about such a popular VCS's feature
<spiv> poolie: cute way to make simple graphs: http://webnumbr.com/bzr-in-progress-bugs
<poolie> hi spiv
<poolie> spiv oh wow that's brilliant
<spiv> poolie: yeah, it's very nifty
<spiv> The API is cute too.
<spiv> (Although the AJAX on bugs.launchpad.net/foo makes it awkward to actually get at the interesting numbers, you have to use the +bugtarget-portlet-bugfilters-stats URL)
<poolie> spiv, hi
<poolie> spiv, i wonder if you can use +text?
<poolie> but i guess that would break it's xpath parsing
<poolie> spiv, how could you have used read not recv if you tested it locally?
<poolie> re bug 595473
<ubot5> Launchpad bug 595473 in Bazaar "paramiko not installed on PQM ? (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/595473
<spiv> Yeah, not sure.  With that URL I still got to point and click on a cute table ;)
<spiv> That half of the if/else is only used via SFTP (when faking a paramiko Channel, which is socket-like, for use with paramiko's SFTPClient)
<spiv> So, I tested the bzr+ssh with and without paramiko locally
<spiv> And trusted that the test suite would catch problems in SFTP if I broke that.  Which it did, except on PQM for some reason.
<spiv> I *guess* PQM is lacking paramiko... I wonder if it's lacking anything else.  It would be nice to see the list of selftest "features" it doesn't have.
<poolie> once subunit is working you should be able to get that out
<poolie> of the list of skipped tests
<poolie> hm
<spiv> Well, in some ways the list of unavailable features is more useful.
<spiv> Maybe babune could provide a matrix of feature vs. builder....
<poolie> i mean the skip messages should tell you which features they're missing
<poolie> spiv, so in one place you used recv but in the other it was still read?
<spiv> Oh, right, by implication.  Yes.  It's a bit harder to tell which out of hundreds of skips "should" skip.
<poolie> perhaps we could use subunit tags or something
<lifeless> that reminds me
<lifeless> spm: ping
<lifeless> spm: in balleny, in the pqm bzr chroot, please do 'python2.4 -c import paramiko'
<lifeless> I was wondering
<lifeless> would it be useful to attach the stdout and stderr to all responses
<lifeless> not just failures
<poolie> lifeless, i got stdout and err for a merge conflict failure
<lifeless> poolie: the group by stuff I'd like to do would collate the skips for you
<lifeless> poolie: was it ok ?
<poolie> lifeless, the stderr seems to have lost all its newlines
<lifeless> !
<poolie> aside from that it's ok
<spiv> poolie: not exactly.  I added a new path to handle the fact that SSHSubprocessConnection now might either have a socket or two pipes as its underlying connection
<spiv> poolie: and this object provides a "recv" method so that it can be used with SFTPClient; in that recv implementation in the "if I have a socket" code path I typoed "self._sock.read" rather than .recv.
<spm> lifeless: worked fine
<spiv> spm: huh!
<spm> (pqm-amd64)pqm@balleny:~$ python2.4 -c "import paramiko"
<spm> (pqm-amd64)pqm@balleny:~$
<spm> fwiw
<spm> ii  python-paramiko                              1.6.4-1.1                                    make SSH2 connections with python
<spiv> lifeless: do you have a recent subunit trace from PQM?  Does that show if that test is being skipped?
<lifeless> looking
<lifeless> spiv: what test.
<spiv> Argh, vila didn't put it in the bug.  /me scrolls back...
<spiv> lifeless: bzrlib.tests.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh
<spiv> Hmm.
<spiv> spm: does the chroot have openssh-client?
<spm> spiv: nope
<spiv> Ah-hah.
<spm> :-)
<spm> I'm guessing that's a pls install? :-)
<lifeless> need an rt ?
<spiv> So it would have fallen back to paramiko for SSH in that test, and thus not hit that code.
<spiv> Huh.
<spm> lifeless: for the record, yes, but will get it installed in parallel
<lifeless> we should add that to the build-deps too, for the packaging, so that that test gets run.
<lifeless> spiv: tag, you're it.
<spiv> lifeless: for the rt?
<lifeless> Yes, if thats ok :)
<spiv> lifeless: sure
<lifeless> I've forwarded you the subunit trace btw
<spiv> Thanks!
<poolie> ah so you interactively tested only bzr+ssh, which doesn't call SSHSubprocessConnection.recv?
<spiv> Right, because that's just for SFTP.
<poolie> so it might be worth testing sftp interactively now?
<spiv> I was aware that I was changing code used by the SFTP client, but assumed the test suite would cover me...
<poolie> to check it performs as expected, and to use lsof to check it's actually got a socketpair?
<poolie> mm so the good thing is that it does, but not on pqm
<poolie> good on babune for catching it
<spiv> Right.
<spm> spiv: lifeless: installed
<spiv> spm: thanks!
<spiv> (And by installing openssh-client on PQM, we're possibly shifting the coverage gap to the pure-paramiko codepath, although I think that's an inherently less risky one)
<poolie> i guess we could add a specific test for recv that doesn't count on having sftp but that may not be worthwhile
<poolie> hm
<poolie> ideally the test suite would be such that adding dependencies only turns on new tests and doesn't remove any other coverage
<poolie> ie if we have an external test we'd run both with paramiko and external
<spiv> It would be nice to fix that gap (per_ssh_vendor tests?), but doesn't feel like a very high priority to me.
<poolie> at least for some representative fraction
<poolie> probably not
<poolie> hm
<poolie> things like this have happened before
<poolie> meaning variation based on testing with or without paramiko
<poolie> but it's probably not top of the stack
<spiv> Right.
<spiv> Really, things worked pretty well in this instance: babune caught the bug quickly, and it got fixed very quickly.
<poolie> mm
<poolie> that was good
<spiv> Obviously far from ideal, but defense in depth is good :)
<poolie> i don't think this is a catastrophe
<poolie> but interesting to dig into
<poolie> *in to
<spiv> spm: RT filed, #39941
<spm> spiv: ta
<caravel> thanks & good night
<lifeless> jam: around at all? lazy object question for you
<jam> lifeless: what's up?
<lifeless> I was wondering if we had something that proxied after it loads
<lifeless> even though thats not the common case because of perf concerns
<lifeless> for formats that open disk resources it would be convenient
<lifeless> jam: ^
<jam> lifeless: ScopeReplacer._should_proxy
<lifeless> ah
<jam> lifeless: might not be fine grained enough yet
<lifeless> so I mean
<lifeless> 'a lazy object proxy'
<lifeless> yes, its too broad.
<lifeless> hmm, I'm nearly done with a _LazyObjectGetter approach
<lifeless> I'll see how it looks, gimme 2 minutes
<lifeless> jam: http://pastebin.com/PHMrCSxk
<lifeless> jam: I think this looks ok, simple to use.
<lifeless> jam: what do you think
<lifeless> jam: I'll propose it, you can assess later :)
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27903
<lifeless> jam: to be clear, I don't care if you do/don't look at this in particular
<lifeless> jam: I'm just closing up the conversation I started with you about the lazy import facilies aspect of it.
<mkanat> How do I make bzr forget that I added a file, in my current working tree?
<mkanat> Ahh, figured it out.
<lifeless> mkanat: bzr revert file
<lifeless> mkanat: or bzr rm --keep
<mkanat> lifeless: Yeah, --keep --new was what I figured out.
<mkanat> (It was a bunch of files in a directory, some of which needed to stay.)
<lifeless> yeah
<lifeless> revert tries very hard to be safe
<lifeless> takes  backups of stuff that isn't in a commit
<lifeless> etc
<vila> hi all
<lifeless> hey
<vila> lifeless: hey ! Quick chat about looms ?
<lifeless> oui
<vila> :-)
<vila> lifeless: So, what do you have in mind about the merges in a loom (vague to not pre-suppose anything) ?
<lifeless> oh
<lifeless> so
<lifeless> change up-thread to skip a thread if no conflicts occur
<lifeless> and use the result (PreviewTree or whatever) of merging up to merge into the next thread, and so on.
<lifeless> when a conflict happens, annotate to find the thread that causes the conflict, and:
<lifeless>  - if its trunk [thread 0], ignore all the other threads
<lifeless>  - otherwise  try the thread causing the conflict -> the thread we'd reach and if that works its conflicting due to the merge output
<lifeless>  - etc - working down a list to refine the conflict
<lifeless> do a merge of only the threads involved in the conflict
<lifeless> so the number of merges will go way down, per thread
<lifeless> this will make merging a loom to a loom better
<lifeless>  because common case if you don't touch a thread explicitly, it won't change revid
<lifeless> unlike today where it changes all over the place
<lifeless> oh also
<lifeless> do all merges for 'does it conflict' detection in memory
<vila> Hmm, I think I mostly got it but need to think a bit about it
<lifeless> so we're insulated from pyc file staleness and the like
<vila> on a related subject: how do *you* undo up-thread ?
<lifeless> revert and or revert-loom and or uncommit
<vila> well, up-thread --auto <thread> (yeah --auto is automatic now, but)
<vila> ha, revert-loom, missed that one. No uncommit-loom though
<vila> poolie, poolie, where are you ?
<vila> lifeless: ok, food for thought on that subject, thanks. That looks promising as it addresses my main problem there (commits that "partly" look useless) but I need to draw some picture to better understand it.
<vila> lifeless: about PQM, 2 things:
<vila> 1) Is news_merge configured now ? I suspect poolie couldn't land some patches because of that (and I had to merge locally a couple of mps too).
<vila> 2) I didn't get a failure email for submitting your broken branch (see my comment on the mp)
<lifeless> news_merge can't be configured on branches yet
<lifeless> so 1) no
<lifeless> nag spiv
<vila> oh, and 3) Do we plan to install update_copyright on pqm too ?
<lifeless> 2) see my comment in th e mp
<lifeless> 3) No plans that I know of, and I think it would be wrong anyway; pqm doesn't write code, coders do.
<vila> hmm, good point about 3 but my workflow with loom suffers from that:
<vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging  the threads up make the copyright update bubble up
<vila> for files I didn't touch myself
<spiv> update_copyright sounds a bit too eager.
<vila> lifeless: well, I need another way to address that
<vila> spiv: Did you catch it proposing wrong updates ?
<vila> spiv: nagging: see lifeless remark above about configuring branches for news_merge (I don't get it though)
<spiv> I haven't used it myself.
<vila> spiv: then what do you mean by eager there ?
<spiv> vila: he means that it enabling news_merge ought to be something we can set in the branch, rather than setting in the PQM user's global conf
<spiv> (Which especially makes sense if you consider that merging a branch that adds a NEWS entry generally should add it to the current release when merged by PQM)
<vila> ha, yeah, inserting in the right release would be nice, but a useful first step will be to have it work for bzr.dev
<spiv> vila: triggering updates when you haven't changed the file sounds dubious to me
<spiv> vila: e.g. what if a file in bzr.dev was reverted to a 2009 version for some reason.
<spiv> So, "eager" in the sense it will sometimes trigger when it shouldn't.
<lifeless> its a bug in th eplugin
<lifeless> vila: I suggest you fix the plugin
<lifeless> commit knows that a file showing in 'bzr st' can be unchanged against one parent
<vila> spiv: its history will still mention a change in 2010
<lifeless> so the plugin should never change copyright headers in that caase
<lifeless> its breaking the per-file merge graph too
<vila> meh, I fail to see what is breaked here, the copyright line is a line, its changes are recorded like any other line
<vila> broken
<lifeless> the line should only change when the file has been changed by the user
<lifeless> vila: per file merge graph convergence - you're familiar with it ?
<vila> the copyright changes converge, I can't imagine a conflict occuring there that can't be trivially resolved
<lifeless> you said
<lifeless> 19:05 < vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging  the threads up make the copyright update bubble up
<lifeless> 19:05 < vila> for files I didn't touch myself
<lifeless> that is the problem
<lifeless> if I change a file
<lifeless> and you bzr merge me
<vila> It's arguably close to embed VCS data into a file which is a Bad Idea, but these lines are there for lawyers anyway
<lifeless> and commit
<lifeless> then do per-file log of that file
<lifeless> your merge commit will not show up
<lifeless> if your update copyright plugin makes the file get edited in that commit
<lifeless> even if you haven't changed it
<lifeless> then it will fail on branches merged in different years
<lifeless> e.g. if I have a branch in december 2010
<lifeless> no changes in 2011 to a given file
<lifeless> and you merge it in jan 2011
<lifeless> update copyright should not (and for the laywers, perhaps 'must not') change the file
<lifeless> until you actually do something copyrightable to it
<lifeless> if you had this fixed, I don't think you'd have made the complaint
<lifeless> 19:05 < vila> since I have the plugin installed, merging bzr.dev triggers such updates and merging  the threads up make the copyright update bubble up
<lifeless> 19:05 < vila> for files I didn't touch myself
<lifeless> above
<spiv> It would be interesting to setup a project that kept the copyright line and licence boilerplate on disk via a content filter, and left the canonical texts free of them.
<vila> hmm, and changing the copyright line isn't copyrightable ? Quite possible
<lifeless> vila: its not a created work, its mere data
<lifeless> Oh, I bet you could create a work consisting of opyright lines
<lifeless> but as we use it
<lifeless> ..
<lifeless> no
<lifeless> vila: anyway, I don't really care.
<lifeless> vila: AFAICT fixing the bug I mention will fix the bug you mentioned.
<lifeless> vila: and you asked for a fix.
<vila> lifeless: I see your point, sounds reasonable is what I meant with my last remark
<vila> i.e. the plugin should only trigger if *I* introduce a change in the left-hand parent only
<vila> and for the record, jam wrote the plugin, not me :)
<vila> Doesn't mean I can't fix it either ;)
<lifeless> I think its intended to update if anyone changes the file
<lifeless> but it shouldn't detect an unedited merge as a change.
<vila> yup, it should restrict to the changes introduced by the committer, so yes, too eager
<vila> lifeless: regarding https://code.edge.launchpad.net/~vila/bzr/595587-fix-test-tariff/+merge/27859, you said: 'it would be nice to have just one list of such variables.' but what other list are you talking about ? And 'such variables' being 'variables that subprocess want to respect from the unless explicitly set otherwise (i.e. ignoring the resets in bt.TestCase._cleanEnvironment') ?
<lifeless> vila: well its all tied together right
<lifeless> there are variables we want to reset
<lifeless> there are ones we want to affect the test suite (except for tests that know better)
<lifeless> and so on
<lifeless> we seem to be adhocing it
<lifeless> so that when someone does something new - like the tarif - it needs manual adjustmnet
<vila> so you'd like that list to come from a method close to bt.TestCase._cleanEnvironment and documented ?
<lifeless> or attribute on bzrlib.tests
<lifeless> or something
<vila> yeah, or attribute, ok
<lifeless> I'd just like to remove the duplication
<lifeless> rather than N lists all slightly different
<lifeless> I'd like Y canonical lists that express the intent
<vila> N ==2 so far right or did I missed one ?
<lifeless> I think its much larger than that
<lifeless> IMBW
<vila> lifeless: ok, I'll try to look into that. No objection to make that in a different mp ?
<lifeless> oh, I thought that was clear
<lifeless> I just commented
<lifeless> I wasn't expecting it to be done :)
<vila> I wanted to make sure I understood your intent :)
<vila> I agree that we lack documentation about the impact of env vars, that sounds like a godd plan to address that
<lifeless> while you're here
<lifeless> abentleys branch to do more cleanups of ui factories
<lifeless> spiv: ^ vila; ^
<lifeless> that branch seems stalled; I'm happy to change it in the direction I proposed; noone else seems to really have an opinion
<lifeless> I'd like one of you to express an opinion :)
<spiv> lifeless: Hmm, I don't have an opinion on that :)
<lifeless> I'm happy to polish
<lifeless> But I don't want to make it worse ;)
<spiv> I'm not sure how much of an issue calling clean_up twice or before initialize is likely to be in practice.
<spiv> And other than a vague "yes it's nice to have less globals" feeling your suggestion doesn't feel significantly better or worse to me.
<lifeless> ok
<lifeless> well I'll tweak and land then
<vila> lifeless: I haven't looked deeply, but some holes in the implementation have been mentioned, I don't really care *how* they are addressed as long as they are.
<lifeless> as a second reviewer
<spiv> But I did have "Needs Fixing" vote that should be addressed ;)
<lifeless> sure
<bialix> heya bzr
<bialix> vila: thanks for your help
<vila> bialix: you're welcome
<bialix> :-)
<poolie> hi there bialix, vila
<bialix> good day poolie!
<bialix> poolie: can I start working on --path-encoding option for diff?
<vila> hey poolie !
<bialix> your comment about true output encoding is puzzled me
<poolie> bialix, so there's a couple of things basically
<poolie> first, i don't understand when you would want the paths to be in a different encoding to other non-file-content output
<poolie> second, i think i'd like to get to something about generally detecting whether we shoud use the terminal encoding or something else
<poolie> bialix i didn't propose it for merge yet but https://code.edge.launchpad.net/~mbp/bzr/340394-encoding-option adds a general output_encoding option
<poolie> maybe i should just propose that
<poolie> bialix, https://code.edge.launchpad.net/~mbp/bzr/340394-encoding-option/+merge/27913
<CaMason> Hi guys. I have a trunk with lots of commits. Some of these commits were project releases
<CaMason> I'd like to have a 'release' branch. Would it be possible to merge in from certain revisions to create the release 'tag' in the release branch?
<CaMason> I assume it's a case of creating the branch from an early revision, and then merging with -r x..y ?
<bialix> poolie: sorry, I' afk for a while. bbl
<poolie> np
<poolie> CaMason, typically you'd just merge everything up to that point, ie -r x
<poolie> or -r y
<poolie> but aside from that, yes
<poolie> or if you wanted you could just tag them within that main branch
<poolie> if you've not already done so
<CaMason> poolie, yeah tagging was one option. We'd like to have a seperate release branch though
<poolie> k, so then i'd suggest
<poolie> tag them in the trunk
<poolie> then merge across each tag and commit it
<poolie> into the release branch
<bialix> poolie: re: first, i don't understand when you would want the paths to be in a different encoding to other non-file-content output
<bialix> poolie: on Windows filenames should be in ANSI encoding to be compatible with GNU patch, while terminal encoding is OEM
<bialix> so if I want to save diff in a file, I want it to use ANSI encoding
<poolie> but to me this is really the second point, that saving to a file needs a different encoding to the terminal
<poolie> not that you want different encodings for the filenames vs the other content
<poolie> the case of UCS-2 is illuminating i think
<poolie> you would never want to mix ANSI and UCS-2 within the diff headres
<bialix> for me this is the first point, because windows is 2-encodings system
<poolie> ok
<poolie> i have to go now
<bialix> I don't understand your desire about UCS-2, but as discussion in my merge proposal reveals, this is exceptional case
<bialix> ok
<poolie> i'll try to explain it on email later
<poolie> good night!
<bialix> ok
<bialix> good night and have a good weekend!
<vila> poolie: good night and good week-end !
<vila> bialix:  :)
<bialix> vila: :-)
<marsilainen> hi all
<marsilainen> I don't understand the '--no-trees' option that you can use to 'bzr init-repo'
<marsilainen> I'm not sure when to use --trees and when to use --no-trees... so I guess I don't understand what a 'working tree' is?
<asabil> marsilainen, working tree is the tree of files that you are using bzr on
<marsilainen> ok, so when would I want --no-trees?
<asabil> --no-trees is generally used in servers hosting bzr repos/branches where you don't want to waste disk space
<marsilainen> right, but don't they need the tree of files in order to serve them?
<asabil> in which case bzr will just create the .bzr folders
<asabil> marsilainen, nope, because when you do a bzr branch it just needs the .bzr folder
<marsilainen> so in the .bzr folders, are contained all the checked-in revisions of the files anyway?
<asabil> yes, and they are efficiently compressed/packed there
<marsilainen> ok
<marsilainen> so if I'm serving the files up, it doesn't really matter whether I specify --trees or --no-trees I guess?
<marsilainen> I think I understand now anyway, thanks
<asabil> marsilainen, serving the files or the bzr branch ?
<marsilainen> er
<marsilainen> the bzr branch I guess
<marsilainen> so that people can get it with 'bzr branch http://myserver/bzr/blah'
<asabil> it's better if you use --no-trees I guess
<asabil> and maybe setup loggerhead there
<marsilainen> ok
<marsilainen> thanks
<marsilainen> is there any bzr gui which can work on a branch held remotely?
<maxb> marsilainen: The other thing to bear in mind is that trees/no-trees on a *repository* is a *default* that is applied to *new branches* being created within that repository
<marsilainen> maxb: ok, sure, thanks
<maxb> marsilainen: Define 'work on a branch' ? What kinds of work do you want to do?
<marsilainen> I want to be able to do things like gui diff between revisions as well as commits etc
<marsilainen> when doing web development it makes sense to have the working trees on the web server machine (ie. remote) so that I can test changes before commit etc
<maxb> It is impossible to commit without a working tree existing somewhere
<marsilainen> yes, I understand that
<marsilainen> this is a different question to my one earlier about --trees etc
<maxb> I don't *think* that it's possible to commit remotely - i.e. you need the bzr client doing the commit to be running on the machine where the tree is
<marsilainen> ok
<marsilainen> I suppose I could mount my working tree from the remote machine onto my local machine
<marsilainen> and then use it like that?
<marsilainen> so then I could use olive or whatever locally
<maxb> That should work, though if the network connection is not particularly fast or low-latency, it might be more practical to commit locally and push/pull changes
<marsilainen> it's hard to do that when you're doing active web dev though
<marsilainen> because you make a small change and want to see what effect that has
<marsilainen> commiting each time would be a major pain
<CaMason> I need to revert some changes of a file, but keep others. Is there a way I can do some sort of interactive merge with the HEAD on a single file?
<maxb> CaMason: The only thing I can think of is to do the merge, and then use shelve to interactively remove some of the changes
<CaMason> maxb, I used shelve :)
<sven_sandberg> vila, hi!
<vila> sven_sandberg: hey ! How did it end up ?
<sven_sandberg> vila, i eventually ^C-ed the bzr pull
<vila> in the shared repo ?
<sven_sandberg> vila, then i ran bzr pack manually. surprisingly, this took only 34 minutes
<sven_sandberg> vila, yes
<sven_sandberg> vila, then i ran bzr pull, and it was fast
<sven_sandberg> vila, then i ran bzr pack again, and it took 34 minutes again
<vila> hmm, sounds like the repack succeeded earlier then no ?
<sven_sandberg> vila, this was a lot faster than when i did 'bzr pull' and it implicitly called bzr pack
<vila> how many pack files do you have now ?
<sven_sandberg> vila, now i have 8
<vila> and more importantly *when* did they get created ?
<sven_sandberg> vila, 7 around 3 MB, and on 358 MB
<sven_sandberg> vila, the 7 small ones were created quite soon after i started bzr pack yesterday. the big one was created when i ran 'bzr pack' after having ^C-ed 'bzr pull'
<vila> ho, chances are only the big one is referenced then
<vila> jam: What's the magical formula to look at the pack-names content ?
<sven_sandberg> vila, what does that mean? the others are temp files that can be removed?
<vila> jam: sorry, first of all: heello !
<jam> vila: bzr dump-btree [--raw] .bzr/repository/pack-names
<jam> hi vli
<jam> hi vila
<vila> sven_sandberg: try the above command and !paste the result
<vila> !paste
<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.
<vila> sven_sandberg: I meant, please, what with my manners today....
<jam> sven_sandberg: please include --raw
<jam>  bzr dump-btree --raw .bzr/repository/pack-names
<jam> (*I* prefer the raw form)
<sven_sandberg> vila, :-)
<sven_sandberg> vila, http://paste.ubuntu.com/451622/
<vila> . o 0 (Come on jam, that's bits not meat)
<jam> sven_sandberg: so the other 7 files are not referenced, as Vila suspected
<jam> vila: without raw it converts it to tuples, etc.
<jam> which, personally, puts too many () in the output :)
<vila> jam: hehe, try lisp :)
<jam> sven_sandberg: yeah, I'm aware of that, having tried to hack on gnucash some time ago
<jam> anyway, the extra files...
<jam> I believe it is probably from doing ^C during an autopack
<jam> it leaves the newly fetched content there, not yet referenced.
<sven_sandberg> jam, so should i remove those files?
<jam> sven_sandberg: you are *allowed* to, I don't think they'll hurt anything
<jam> if you do, you can remove the same-named files from .bzr/repository/indices
<jam> now... as to why it took so long to do it as an autopack vs a 'bzr pack'
<jam> the only thing I can think of off-hand is something like peak memory consumption / memory fragmentation
<jam> it is doing the same operation
<jam> but it is possible the fetch still was holding on to some memory
<jam> hmm... I suppose it is also possible that an 'optimize' flag was set incorrectly... but I doubt it would account for hours vs .5hour
<sven_sandberg> jam, ok, so it's not doing something wildly different just because the repository was in a slightly different state?
<jam> sven_sandberg: shouldn't be
<jam> if anything, it should be doing *more* work for 'bzr pack' because it always looks at all files
<jam> it is a bit of a shame we couldn't have poked the old one a bit harder to see why it was taking so long
<vila> A NotApplicable test failing...
<jam> vila: well remember, any given test can have multiple outcomes if the addX gets called.
<jam> (cleanups particularly tend to cause errors after success/skip)
<vila> investigating but TestNotApplicable is raised during setUp and the failure is during the test itself...
<mgz> need to do something about my growing shelf here...
<mgz> time for some 'needs to be in initial branch or not' triage
<chx> is there a way to 'sneak peak' into a shelve, ie extract the diff of a shelve?
<vila> chx: bzr unshelve --preview n
<chx> thankeeee
<lifeless> mgz: hi
<mgz> lifeless: hey
<lifeless> so, your branch ?
<mgz> done watching poor football, back to that
<lifeless> \o/
<mgz> I'll push where I am then enumerate the remaining shelves
<mgz> it's all edge-of-edge cases now, so some of these probably don't need resolving right now
<mgz> okay, 5: use cp* rather than mbcs... might commit this, though it's not reliably testable
<mgz> 4: use Python 3 style namespace-including exception names. can wait.
<mgz> 3: let BaseExceptions propogate when stringifying errors... can wait I think, as doesn't fix it for Python 3
<mgz> 2: a test for another stringifying thing not addressed for Python 3, don't need it.
<mgz> 1: first crack at a per-line regexp matcher. can probably wait as well.
<mgz> only other thing to do is module renaming, which I was saving for last.
<lifeless> sweet
<lifeless> well
<lifeless> I'm keen to land stuff
<lifeless> so if you need feedback on anything, let me know
<mgz> okay, I'll do the moving now and resubmit rather than fiddling more
<lifeless> if you think you'll want to undo anything you've done
<lifeless> then polish it more
<lifeless> but I get the sense you just want to add more, not change your mind on approach
<mgz> yeah, I've been trying to keep all this as private functions for the moment, so it's at least possible to rearrange some of the specifics later
<lifeless> works for me
<mgz> okay, done, tests pass on four implementations
<lifeless> \o/
<lifeless> I'm *really* happy you've done this work
<mgz> hm, resubmit didn't do what I thought it was going to
<james_w> mgz: what are you working on?
<mgz> just yellowed the existing comments
<mgz> james_w: making the tracebacks Python 2 produces correctly encodable to UTF-8 by testtools
<james_w> oh, coo
<james_w> l
<mgz> it's sort of a back port of the Python 3 traceback/string behaviour
<james_w> lifeless: are you looking for testtools to be a repository of matchers as well as the basic functionality?
<lifeless> james_w: I'm happy for matches to go there
<lifeless> james_w: I'm also happy for someone to start and run a dedicated matcher project, which could own the base class
<james_w> ok, I might start submitting them
<lifeless> there is such a thing in java, its a shame that their python port was so unpythonic
<lifeless> (hamcrest)
<james_w> I think AND and NOT would be useful, though I can appreciate that they have their problems.
<james_w> but I've written a couple of generally applicable ones that I could submit
<lifeless> please
<lifeless> until someone gets the activation energy up to run a dedicated project
<lifeless> which I think would be good btw
<lifeless> testtools is happy to be a home
<mgz> I'd sort-of like testtools to grow them rather than splinter it off as a new thing
<lifeless> so
<lifeless> matching can be very useful outside tests
<lifeless> if someone was passionate about using them in - say - a generic object diff facility in IDEA
<lifeless> or whatever
<lifeless> I'd be happy to say 'here, enjoy'
<lifeless> while noone is passionate and driving them as a specific thing, I think testtools devs caring for them is great
<mgz> okay, review is in your inbox lifeless.
<mgz> and, as always, scanning the diff I just spot a sentence with the meaning reversed
<lifeless> :)
<mgz> Python 3 StringIO does *not* expect bytes
<lifeless> yes
<lifeless> seen the recent email thread on p-d ?
<mgz> yeah, I was reading that and thinking of you.
<lifeless> :)
<davidstrauss> lifeless: If you have a minute, I've run into a very funny merge tracking issue: http://pastie.org/private/vtc9hydx3iyn6nhft7ehiq
<lifeless> davidstrauss: wow that is fun
<davidstrauss> lifeless: how is missing able to know what's common but not merge?
<lifeless> I would guess that you have merged in something with an ambiguous base
<lifeless> so that bzr is recursing back
<lifeless> and you've managed to find a failure mode for that
<lifeless> uhm
<davidstrauss> lifeless: In any case, "Branches have no common ancestor" is false.
<lifeless> this is worth a bug; you can manually merge with -r 2397.. to work around
<fullermd> Seems to me I've seen that before...
<lifeless> davidstrauss: right, but that no common ancestor really means 'didn't find an *acceptable* common ancestor'
<fullermd> bug 483388
<ubot5> Launchpad bug 483388 in Bazaar "merge lies about lacking common ancestors when it has multiple choices (affected: 2, heat: 4)" [Medium,Confirmed] https://launchpad.net/bugs/483388
<lifeless> bbiab
#bzr 2010-06-19
<davidstrauss> lifeless: Is there a way to manually manipulate merge data?
<davidstrauss> lifeless: Like, let's say you commit a merge to a public branch. You can't uncommit, but you want to revert the merge *and* have the merge tracking data reflect that.
<fullermd> No, because there isn't "merge tracking data", there's only ancestry.
<davidstrauss> fullermd: Is it possible to "unzip" part of the ancestry?
<fullermd> Yeah, with uncommit   8-}
<davidstrauss> fullermd: but that works poorly for public branches
<davidstrauss> fullermd: other people's checkouts show the removed commits as "local commits"
<fullermd> Well, that's the fallout.  You can't have something in your ancestry and not in your ancestry at the same time.
<fullermd> And making ancestry somehow nontransitive would just be unutterably evil.
<davidstrauss> fullermd: ideally, we'd have a way to record the reversal
<fullermd> Well, ideally a lot of things.  But that would be a very fundamental change.
<taxilian> anyone here used the webdav plugin for bzr that might be able to help me figure out why I can't push or commit over webdav?  it keeps telling me that it can't obtain the lock
<taxilian> and then sits there forever and dies
<lifeless> 4/quit
<jelmer> taxilian: vila is the best person to talk to about the webdav plugin
<jjann> Hi. I have some checkouts of bzr and svn repositories in one of my repositories. I don't want to treat them special (ie use some externals mechanism or something), just add them with their repository meta-data, how can I do this?
<jjann> right now, bzr status shows me the contained repos' top level directories as unknown but bzr add doesn't add them
<jjann> (even a 'bzr add -v some_contained_repos_toplevel' just prints out nothing and some_contained_repos_toplevel/ just keeps showing up as unknown in bzr status)
<jjann> (I'm using bzr 2.1.1 on lucid)
<jelmer> jjann: hi
<jelmer> jjann: if you want bzr to just treat the .svn directories as data, uninstall bzr-svn
<jjann> jelmer: hm, I use bzr-svn on other repositories though. and what about the .bzr directories?
<jjann> essentially you're saying I really should be using externals?
<jelmer> jjann: I don't think there is any way to treat .bzr directories as plain data
<jjann> ok, bzr-eternals it is then, thanks
<jjann> let's hope I'll get by with this better than I did with mercurial subrepos :)
<jjann> I'm confused. I installed bzr-externals, I deleted one of the bzr subrepos, I did 'bzr eadd lp:foo the_dir; bzr ci -m "add lp:foo"'
<jjann> and after that, the_dir/ still shows up as 'unknown' in bzr status
<jjann> ok, seems to be some broken old state from previous attempt, doesn't happen in a fresh clone. sigh. :-)
<jelmer> jjann: I'm not entirely sure if bzr-externals will do what you want
<jelmer> it won't allow you to use 'bzr add' as far as I know
<jelmer> it will will in a way similar to svn:externals
<jjann> yeah, it uses 'eadd', which I did
<jjann> I was just surprised that the newly added external shows up as 'unknown' in the status output
<jjann> but it seems similarly underused and underdocumented as hg subrepos. I keep wondering how most users seem to get by without such a feature. git really is the only one of the 'modern' DVCSes that takes this seriously :(
<jjann> (but git was rejected quite early in our evaluations to find a replacement for svn for various other reasons)
<jelmer> jjann: bzr-externals are a hack for the fact that nested trees aren't supported in bzr yet
<jelmer> jjann: we've been planning that feature for ages but it keeps stalling because we haven't managed to design something that works well in all cases, scales and doesn't require a lot of special casing
<jjann> initially I was hoping to get by with adding the .svn and .bzr directories as plain data since bzr has the nice advantage of tracking directories as well as files (the lack of that feature is the reason that treating svn checkouts as normal data doesn't work in hg for example)
<jelmer> jjann: alternatively  you can use the --no-plugins argument when adding .svn directories
<jjann> that still would only solve half my problem. I'm currently considering hacking my own super low-tech variant, just renaming .bzr and .svn repos pre and post update
<jjann> s/repos/directories/
<jelmer> jjann: is there any reason for wanting to keep the other repositories' control directories around, rather than merging them in?
<jjann> jelmer: they are repositories that don't belong to me and that I want to be able to update easily during project lifetime (ie they are external library dependencies and somesuch)
<jelmer> jjann: you would simply be able to merge in newer versions still
<jelmer> jjann: as bzr remembers the common history with those projects
<jjann> by keeping their meta-data around, I can browse their changelog, I always know what revision of them I have
<jjann> hm
<jjann> can I merge a repo inside a sub-directory of my repo?
<jjann> ie bzr merge lp:foo libs/foo?
<jelmer> jjann: yes, although it works a bit different from that
<jelmer> jjann: you'd want to use "bzr join" to combine the two repositories originally
<jelmer> after that you can use "bzr merge"
<jjann> oh, never even read about join, thanks!
<jjann> I must admit I don't get how exactly join works (or what exactly it does) from its help output. the naive variant of 'bzr join lp:foo' doesn't work at least and I'm not even sure that's what I want
<jelmer> jjann: if you want to have lp:foo live at lib/foo you would run something like:
<jelmer> bzr branch lp:foo lib/foo; bzr join lib/foo
<jelmer> bzr commit -m "Merge in lp:foo"
<jelmer> After that "bzr merge lp:foo" will do the right thing and update just lib/foo
<jjann> brilliant, thanks
<jjann> and it works perfectly with svn repos as well, nice
<jjann> also, I love the "revision folding" bzr does, with the nice folder-like feeling in qlog, fits perfectly here
<jjann> I really must say, when I started evaluating bzr, hg and git, bzr was the one I had heard the most bad things about and still it keeps comming out on top now that I'm actually testing it myself
<jjann> so there really needs to be some publicity work done I think ;)
<jelmer> jjann: Great to hear, thanks :-)
<jelmer> jjann: Our initial performance issues have caused a lot of harm I think.
<jjann> right "it's too slow!" was one of the things I heard most. also "it changes it's repository format like every release, it can't be stable/good"
<abostrom> hum
<abostrom> help needed: i have committed three patches to my branch. if i do "bzr bundle", i get a single patch.
<abostrom> do o need to send three bundles upstream if i want to preserve history? or are the patches hidden somewhere in the blob at the end?
<jelmer> abostrom: they're in the blob at the end
<abostrom> ok, but if i make a fresh branch and merge my bundle, i get only a single commit
<abostrom> trying merge -r gives "bzr: ERROR: Cannot use -r with merge directives or bundles"
<abostrom> aaah
<abostrom> bzr log --include-merges
<abostrom> i see
<abostrom> thanks :)
<jelmer> np :-)
<assad> while doing a bzr diff between two branches: bzr diff --old ARG it says branch ARG , so how do i access the branch name? is it some relative addressing ?
<assad> what is ARG equal to in that command
<wamills> Hi,  I'm new to bzr, but know git.  I am trying to create a branch from a lp tag.  Which of these commands does that?
<lifeless> what do you mean by 'lp tag'
<jelmer> 'morning lifeless
<lifeless> hi jelmer
<lifeless> wamills: what do you mean by 'lp tag'
<wamills> OK I made a branch of gnome-terminal but it is the latest development.  I want to create a branch based on 2.29.6 tag. Like is used in the current Lucid package
<wamills> git checkout -b my-fix 2.29.6
<lifeless> tags in bzr are a property of a branch
<lifeless> so you need to know what branch the tag is in
<lifeless> if you want a branch of the lucid package for gnome-terminal, you can do 'bzr branch lp:ubuntu/lucid/gnome-terminal
<lifeless> and you can query the tags with 'bzr tags -d lp:ubuntu/lucid/gnome-terminal'
<wamills> OK, my first error was starting with the wrong base.  I guess lp:gnome-terminal is just tracking upstream yes?
<lifeless> yes
<wamills> OK let me get to the right project.
<wamills> OK so 2.29.6-0ubuntu5 is the latest tag so I could make changes. commit & push to personal branch right?
<lifeless> yes
<lifeless> if you're making a patch for ubuntu you don't need to worry about tags at all though
<lifeless> just
<lifeless> bzr branch lp:ubuntu/lucid/gnome-terminal (for making a patch for lucid)
<lifeless> hack hack hack
<lifeless> bzr commit
<lifeless> bzr push lp:~USERNAME/ubuntu/lucid/gnome-terminal/BRANCHNAME
<wamills> cool.  Thats good enough for what I am doing today.  I'll RTF(abulos)M for more.
<lifeless> please feel free to hop back in and asj
<lifeless> its the weekend
<lifeless> so a bit quieter than normal :)
<lifeless> also #launchpad for launchpad questions is pretty good
<lifeless> and #ubuntu-motu or #ubuntu-packaging for packaging related things (like how to change a package version number etc)
<wamills> Thanks!  Good suggestions.
#bzr 2010-06-20
<lifeless> mgz: I summon thee
<mario-kemper> hi there, does anyone know a way to keep version info up-to-date when committing changes to a branch?
<mario-kemper> something like subversion properties?
<spiv> Perhaps you are looking for the bzr-keywords plugin?
<mario-kemper> ah, I'll have a look at it
<mgz> missed a lifeless summoning...
<mgz> he got some funny test failures, look fixable when the sun is round the other side of the planet again though
<Jerry_Cottage> I'd been keeping a local branch on my desktop in sync with a parent repo, ".../project_jinx/trunk".  For a bit, I switched to merging from a different parent, ".../project_jinx/bobTest16".  Now it's time to switch back.  So I do a "bzr merge .../project_jinx/trunk" and reconcile & commit.
<Jerry_Cottage> That works ok.  But if I just do a "bzr merge" in my local branch, it still reports "Merging from remembered submit location .../project_jinx/bobTest16"
<Jerry_Cottage> How do I make my local repo forget about the "remembered submit location", and once again only use the .../project_jinx/trunk ?
<mgz> --remember with the old location
<Jerry_Cottage> mgz: Great, worked.  I kept trying to do a switch but that didn't work.
<lifeless> moin oin
<jelmer> hey lifeless
<lifeless> hiya
<mgz> lifeless: I think I've resolved your issues, there might be one remaining but it's not clear what the right answer is
<mgz> I'm happy to be told to do rearrangements by the way
<lifeless> mgz: I know
<lifeless> mgz: I meant
<lifeless> 'I'm not bouncing it for shallow stuff
<lifeless> or cosmetic is perhaps a better work
<lifeless> mgz: so, I should merge again and retry ?
<mgz> yup, pull and test.
<lifeless> mgz: I realised upon waking that the constructor probably has to accept bytestrings
<mgz> if so, can just decode them there maybe?
<lifeless> mgz: but I'd like to try not accepting them at all
<lifeless> and giving a Warning perhaps, on requests for __str__
<mgz> if it's like my nix box, there will still be one failure, due to... something weird
<lifeless> heh
<lifeless> you'd like me to dig?
<mgz> I'll go through tokenizer.c again later and try and work out why it's acting up on nix
<mgz> well, the problem seems to be simple,
<mgz> stick a breakpoint in compat.py on ~line 195 and the line in the SyntaxError has "???" rather than "\xa7\xa7\xa7"
<mgz> I just... am not clear on why
<lifeless> a secret replace clause somewhere?
<mgz> it's not really a big issue, just need to work out what the cause is
<mgz> something like that, I'll check blame on the source in svn
<mgz> meh, yeah:
<mgz> http://svn.python.org/view/python/trunk/Parser/tokenizer.c?view=log#rev57961
<mgz> behaviour change *during* 2.5
<mgz> presumably arrived on the lenny 2.5 but not the mozilla 2.5 I've been using as my 2.5
<mgz> and it's bogus in this case.
<mgz> I'll just expectedFailure it for the moment based on minor version I think
<lifeless> mgz: btw
<lifeless> in #subunit, there is a hudson bot that tests testtools
<lifeless> wow
<lifeless> doesn't that mean it should be a unicode object
<lifeless> rather than str ?
<mgz> no, it's daftness, the tokenizer sets up a stream reader from the coding declaration that decodes iff the coding is not latin-1 or utf-8,
<mgz> then each decoded line is encoded as utf-8
<mgz> and that patch then adds some code that decodes from utf-8, and encodes back to the original encoding, for a line with a SyntaxError
<lifeless> OMFG
<mgz> but overall it means when I get a line from a SyntaxError, it could be any of latin-1, utf-8, or the encoding of the file
<lifeless> wtf wtf omg omg wtf
<mgz> depending on what the encoding of the file is, and what Python version it is
<lifeless> I can't express the sympathy I have for you doing this work
<mgz> and as debian backport things without changing the minor version, I can't even check sys.version_info I think
<lifeless> no
<mgz> I'll... do an end run around all this, and just re-read the file
<lifeless> only security stuff, as a rule
<lifeless> but yeah
<lifeless> EBROKENINTERFACE
<fullermd> All you need to do now is put the errors into a .doc file, and email it to the user...
<lifeless> actually
<lifeless> you should put it in the topic of #python
<lifeless> with 'not ready for use'
<lifeless> its time for some patch reviews
<lifeless> any reviewers around?
<mgz> okay, back to plan b again, using linecache is a pain... man I'm glad I wrote these tests
<mgz> also was mistaken, the mozilla-build bundled python is 2.5.0 not .2 so it's not debian being evil with backporting things, they're different minor versions
<lifeless> doko is pretty good about what he accepts as chrrypicks
<mgz> I'm still slightly screwed on knowing the encoding, but can at least use a version check, now, when did that patch land...
<lifeless> import insanity; insanity.python_encoding()
<cjb> Hi folks.  I've got two distinct bzr repos that I'd like to join; one as a subdir inside the other.  What's the right way to do that?  They don't touch any of the same files, so there's no merging required.
<lifeless> you need to do a merge to join the graphs
<lifeless> the merge-into plugin was the best way to do that for a while; dunno if it still is
<cjb> there's no common ancestor, since they're entirely independent repos
<cjb> ah, thanks.  I'll look into that plugin..
<cjb> lifeless: it worked.  thanks again!
<fullermd> join does the same as merge-into...
#bzr 2011-06-13
<lifeless> well, the normal thing is just to commit at this point
<lifeless> this happens if someone else committed to the remote location and you needed to update to be able to commit
<workthrick> lifeless: yes, I know, but only I use that branch
<lifeless> anyhow, if you grab the revid of the pending merge
<lifeless> and do
<lifeless> bzr revert; bzr pull . -r revid:<,...>
<lifeless> that will reset onto that revid
<workthrick> lifeless: aha, and how do I grab the revid of it?
<lifeless> bzr st --show-ids
<workthrick> hmm, not seeing it
<workthrick> pending merge tips: (use -v to see all merge revisions)
<workthrick>   Maciej Katafiasz 2011-06-13 Add initial lipid DB files from Christer
<workthrick> it shows me the file IDs, but not revids
<lifeless> garh
<lifeless> uhm
<lifeless> bzr heads --dead
<lifeless> should show it; thats in bzrtools I think
<workthrick> yup
<workthrick> lifeless: that worked fine, thanks
<lifeless> cool
 * workthrick packs up and migrates home
<george_e> Quick question... I have installed Bazaar 2.3.1 on a Windows server and I have created a branch with one file in it...
<george_e> How can I push / pull to that branch?
<gour> i see that LP cannot grok (aka import) bitbucket hg branches...what is your experience with hg <--> bzr ?
<spiv> gour: talk to jelmer
<lifeless> gour: we should handle bitbucket branches fine
<vila> jelmer_: Did I mention loom test failing with: TypeError: push() got an unexpected keyword argument 'lossy' ? Or did you already fix that and Alzheimer is striking again ?
<Riddell> good morning
<vila> _o/
<fullermd> Morning?  Pah.  What'd morning ever do for me?
<vila> fullermd: bring coffee ? Good thing that
<fullermd> Morning doesn't bring coffee.  I have to keep it at hand myself, as a weapon for when the morning ambushes me.
<gour> spiv: when is jelmer around?
<gour> lifeless: all the branches i wanted to import from bitbucket were suspended (or not mirror any longer) due to 5 failures
<gour> although i can hg pull without any problem
<Peng> fullermd: Morning brings a beautiful, fresh feeling to the world.
<Peng> fullermd: Also a bunch of noise from your neighbors.
<Riddell> asking again, what's going wrong with me using requeue_package? http://paste.kde.org/81493/
<lifeless> gour: IIRC bitbucket expose broken urls, or is that gitorious
<vila> Riddell: You need to prepend PYTHON_PATH=python_debian/ and of course be in the 'scripts' dire
<vila> ctory
<Riddell> ah, but of course
<vila> Riddell: <cough> did I forget to explain that ?
<vila> Riddell: <cough> it helps to look at the bash hostory
<vila> history
<fullermd> Peng: Obviously, it brings you far better drugs than me   :p
<Riddell> documentation though bash history, the best way
<vila> Objection your honor !
<vila> It's archeology ! Nothing to do with documentation ! I requires removing such remarks from the log !
<vila> This is an obvious trick to influence the jury !
<gour> lifeless: hmmm...but initial import was done...problem was with incremental imports
<lifeless> stub: ok
<lifeless> bah
<lifeless> gour: ok; well have a look at the bzr-hg bug reports
<lifeless> or the wiki page tracking conversion support
<gour> where could i find them?
<gour> here is the branch: https://code.launchpad.net/~gour/myclientbase/trunk
<Riddell> there doesn't see to be any documentation on gpg signing, would it be an idea if I updated http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ and added it to the user guide?
<jelmer_> Riddell: the problem is that we also don't really have a good way to verify GPG signatures yet at this point
<Riddell> jelmer_: yes, is there a reason for that?  nobody bothered to learn gpgme?
<jelmer_> Riddell: I'm not sure of the background - I think part of it is just that nobody got around to it, and we need to watch out for performance issues if we start automatically verifying everything.
<vila> jelmer_: Did I mention loom test failing with: TypeError: push() got an unexpected keyword argument 'lossy' ? Or did you already fix that and Alzheimer is striking again ?
<jelmer_> vila: hi; I think you did, though I can't reproduce it here
<jelmer_> vila: which test ?
<vila> letmecheck
<jelmer_> Riddell: I think jam knows more of the details
<vila> jelmer_: per_branch.test_push.TestLossyPush.test_lossy_push_raises_same_vcs(BzrBranchLoomFormat1)
<Riddell> yes, I see he did a basic verification plugin back in the day which seems to have disappeared
<vila> ./bzr selftest -s bt.per_branch.test_push.TestLossyPush -> ran 13 tests/ 4 errors
<jelmer_> vila, thanks
<jelmer_> vila, I was just running the plugin tests and not finding anything :)
<jelmer_> vila: hmm, we really need an InterLoomBranch..
<vila> ha right, getting all the relevant tests for a given plugin may be tricky
<vila> jelmer_: may be, but you can also push/pull between looms and regular branches
<Riddell> the config options for gpg signatures are strange, create_signatures always is used but I don't think when-required or never is (and can branches require signatures?)
<Riddell> I don't think check_signatures is used at all except that weirdly require turned on create_signatures always
<Riddell> is http://wiki.bazaar.canonical.com/ConfiguringBzr the current documentation for config options?
<Kamping_Kaiser> hi all, i just tried to  commit the deltion of some files (-x 'd two modified files), and bzr told me an empty commit was pointless http://paste.debian.net/119678/ . does this look like a bug or a feature you you? (wondering if i should go looking for a bug report)
<jelmer_> Riddell, that sounds about right
<jelmer_> Riddell, I use "create_signatures = always" myself for that special day in the future when we start being able to actually verify them
<jelmer_> Kamping_Kaiser, what happens if you run "bzr rm" first?
* 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: vila | UDD failures: 485
<maxb> I have a mega bug of udd tag moves for someone to process this week :-) https://bugs.launchpad.net/udd/+bug/795703
<ubot5> Ubuntu bug 795703 in Ubuntu Distributed Development "jubany fixups relating to misplaced tags (AssertionError:<module>:main:find_unimported_versions:check)" [Undecided,New]
<Kamping_Kaiser> jelmer_: if i run bzr rm on the tree as is  it gives the same error. shall i try restoring the files then bzr rming them?
<jelmer_> Kamping_Kaiser: It should at least give a slightly different error (removed vs missing)
<Kamping_Kaiser> jelmer_: http://paste.debian.net/119679/ this is what i get folling on from the last paste. have  i missunderstood your suggestion?
<jelmer_> Kamping_Kaiser, that's odd indeed, please file a bug
<Kamping_Kaiser> jelmer_: should i include the contents of those pastes?
<Kamping_Kaiser> and is there anything else that would be handy? (repo state, etc)
<jelmer_> Kamping_Kaiser: I'm not sure; given I've never seen this and I never use -x I would be inclined to blame -x
<Kamping_Kaiser> ok. i'll tar it up and hang onto it for a few weeks incase its requested
<jelmer> Kamping_Kaiser, thanks :)
<Kamping_Kaiser> np :)
<Kamping_Kaiser> jelmer: submitted as https://bugs.launchpad.net/bzr/+bug/796582, hopefully its lucid enough to be understood
<ubot5> Ubuntu bug 796582 in Bazaar "committing with -x incorrectly declares the commit pointless" [Undecided,New]
<Kamping_Kaiser> and i just realised i didn't specify my version or os, *fail*
<Kamping_Kaiser> 'night all
<jelmer> g'night Kamping_Kaiser
<jelmer> Riddell: Sorry, was distracted there for a bit
<jelmer> Riddell: I guess any more support for verifying signatures, even just some API functionality that might not be hooked up in the UI yet, would be a step forward.
<jelmer> bzr-gtk does verification at the moment, but has implemented it manually. That sort of code really should be in the core.
<Riddell> jelmer: should I update http://wiki.bazaar.canonical.com/ConfiguringBzr to match current reality?
<jelmer> Riddell, please do
<jelmer> Riddell, although I also wonder how well maintained that page still is at the moment compared to the docs in the tree
<Riddell> ah, it's user-reference/configuration-help.txt
<Riddell> maybe I should make that match reality and make the wiki page point to that
<jelmer> Riddell: wfm
<jelmer> Perhaps we should set up a wikkid instance backed onto a copy of lp:bzr so users can still easily contribute fixes
<Riddell> jelmer: is that possible?
<Riddell> much of what was once on the bazaar wiki seems to have been moved to the docs
<jelmer> Riddell: I think it should be, though we might have to wait for wikkid to get openid support. ad it will require some setup of course
<jelmer> like the Ubuntu wiki much of what's on our wiki is outdated, the docs are much nicer and have been better reviewed.. but the wiki is the only thing users can easily contribute to
<gour> jelmer: jello, attempt to mirror some bitbucket branches gives "The import has been suspended because it failed 5 or more times in succession. " where could i find some log or are there some known issues with bitbucket import?
<jelmer> gour, the log should be linked from the import page
<jelmer> you might have to delete the import and create it again if the import existed before the last launchpad deployment a couple of days ago
<gour> jelmer: i do not find it...here is the branch https://code.launchpad.net/~gour/myclientbase/trunk
<abentley> vila: I've restored the original test_merge_from_branch tests and just forced the root-id.
<abentley> vila: The one outstanding issue I know is you and jam disagreeing about how to handle tests that prove an exception isn't raised.
<jelmer> gour, the "see the log" link
<gour> ahh...i thought those were some other logs
<gour> jelmer: is it something bzr-hg related?
<jelmer> gour, how do you mean?
<jelmer> gour, the imports are done using bzr-hg
<gour> jelmer: i mean, some already known issue?
<jelmer> gour: see my comment above, you might want to throw out the existing import and create a new import
<gour> ahh..got it
<abentley> vila: I looked at your branch.  Why did you change test_shelf?
<vila> abentley: just checking I understood how it worked, revert the change if that's an issue
<abentley> vila: it was just surprising because I didn't change that file, and AIACT, you just changed it to use context managers.  The change itself looks fine.
<jelmer> gour, I've been looking at fixing the hg imports recently so if you find issues (after the branch has been recreated, please let me know and/or file bugs)
<vila> yeah, and get rid of the seek, it was indeed to see if I got the context managers right, I shouldn't have committed that
<gour> jelmer: ok
<vila> abentley: I think I said I prefer checking like you did, that's the intent of the test isn't it ? Not checking anything... will be surprising if the test ever fails
<abentley> vila: Okay, I've pushed a revision that merges your changes.  Am I cleared for landing?
<vila> abentley: yup
<abentley> vila: Thanks.  It's been fun hacking on the merge code once again.
<vila> abentley: hehe, glad you enjoyed it ;)
<abentley> vila: aw, darn.  Your testtools is too old for ExpectedException.
 * vila bangs head
<vila> that sucks
<vila> you mean the pqm one right ?
<abentley> vila: Yes.
<abentley> vila: It's okay, I'm rewriting it as assertRaises.
<vila> ok, ExpectedException has been introduced in 0.9.9, 0.9.11 has been released yesterday-ish but pqm still uses 0.9.8
<vila> abentley: cool, can you leave the EE form in comment saying it requires 0.9.9 ?
<vila> abentley: I'm afraid nobody will remember to use it otherwise when testtools is upgraded
<vila> abentley: the lp pqm has a more recent testtools ?
<abentley> vila: Launchpad explicitly manages that dependency, so our buildbot uses it.  (Our PQM doesn't run tests.)
<vila> hmpf
<vila> ok, thanks
<abentley> jelmer: I readdressed that email to exclude the merge proposal because I thought it was meta-conversation that didn't belong  on the proposal itself.
<jelmer> abentley: ah, sorry
<jelmer> abentley: I thought thunderbird was being smart again and had excluded it
<abentley> jelmer: nope.  We use reply-to headers, which require effort to avoid.
<SpamapS> the bzr in daily breaks with a nasty crash for me...
<SpamapS> oh wait, its the bzr git plugin I think
<jelmer> SpamapS, hi
<jelmer> SpamapS, can you elaborate?
<SpamapS> sorry
<SpamapS> yes
 * SpamapS gets a backtrace ready
<SpamapS> jelmer: http://paste.ubuntu.com/625946/
<jelmer> SpamapS: that looks like a mismatched bzr and bzr-git, it should be fixed in newer versions of bzr-git
<jelmer> SpamapS, you're running bzr 2.4-ish I suspect?
<SpamapS> jelmer: daily build
* vila 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: 485
<jelmer> SpamapS: hah, looks like the version number of the daily builds needs to be updated
<ccxCZ> Is there way to make subdirectories separate branches, while the main project would remember the revisions of the subprojects? I asked here some time ago and I was told some implementation of this was underway
<jelmer> ccxCZ: You might be looking for "bzr split"
<jelmer> ccxCZ: bzr split can split off a directory as a new branch, while both the original branch and the new branch keep the original history
<jelmer> SpamapS, that should be fixed now - what version of bzr-git does dpkg report you have?
<ccxCZ> jelmer: I know about that. but that won't keep project state anywhere - which revision of which sub-branch works with the master one
<SpamapS> jelmer: 0.6.0-1~bazaar1~natty1
<jelmer> SpamapS: that's not the daily builds PPA - where does it come from?
<SpamapS> I think from the proposed PPA.. which I also enabled on my way to daily.. ;)
<jelmer> ccxCZ: Ah, ok. In that case you're after nested trees: bug 267770
<ubot5> Launchpad bug 267770 in Bazaar "Bazaar does not support nested branches" [Wishlist,Confirmed] https://launchpad.net/bugs/267770
<jelmer> ccxCZ: until that's implemented in core there are a couple of plugins you can use instead (bzr-externals most notably)
<jelmer> SpamapS: ah, ok
<jelmer> SpamapS: in that case the problem should go away when a new bzr-git is published in the PPA
<jelmer> http://code.launchpad.net/~bzr/+recipe/bzr-git-daily
<SpamapS> jelmer: thanks for checking.
<ccxCZ> kthnx, will check that out
<ssbr> Hi. What's the most recent version of bzr that supports Python 2.5?
<fullermd> 2.3.x
<ssbr> fullermd: excellent, thank you
<SpamapS> jelmer: similar problems with bzr-builddeb
<jelmer> garr, I really should get that new bzr-builder deployed so we no longer have this problem
<SpamapS> http://paste.ubuntu.com/626023/
<jelmer> SpamapS: actually, bzr-builddeb seems ok
<jelmer> SpamapS, which bzr-builddeb are you running?
<SpamapS> 2.7.4+bzr565~natty1
<SpamapS> well.. I was.. have to get some work done for a bit.. but I can move back to it to help diagnose any issues
<jelmer> SpamapS: Can you pastebin the output before the backtrace?
<jelmer> IIRC this happens if bzr-builddeb is unable to find back the upstream tarball *after* it's fetched it
<SpamapS> http://paste.ubuntu.com/626028/
<SpamapS> yes
<SpamapS> hmm
<SpamapS> actually this one may be wrongly building as a native package
<jelmer> SpamapS: it's not building as a native package (otherwise it wouldn't be retrieving the upstream tarball)
<SpamapS> yeah.. never mind
<SpamapS> this branch is a bit whacked
<jelmer> SpamapS: did it fetch a .tar.gz file?
<SpamapS> jelmer: no
<jelmer> the output seems to suggest it did, despite the warning about the invalid host name
<SpamapS> the branch was not setup to bzr bd properly
<maxb> Anyone around who can provide me with a second opinion on whether I've found a bug in TreeTransform.trans_id_tree_path?  namely, does it actually make any sense for it to be resolving symlinks in its path argument?
<SpamapS> its used purely as a source of data for bzr builder recipes..
<jelmer> SpamapS: is the branch available somewhere publicly?
<jelmer> SpamapS: I'm particularly curious because somebody else reported similar behaviour and I never managed to figure out how we could get a success from apt but no file.
<SpamapS> jelmer: lp:ensemble ;)
<jelmer> SpamapS: thanks
<jelmer> SpamapS, the problem appears to be that the version suggests a non-native package but the package is built as a native package
<SpamapS> jelmer: it may have to do with being a 1.0 format debian dir but not native.. so the extraction causes issues
<SpamapS> jelmer: like I said, the debian dir is just not setup right. :-/
<jelmer> so bzr-builddeb thinks that if the ensemble ppa contains a 0.5-0ensemble252~oneiric1 package, that it has the upstream source for ensemble 0.5
<SpamapS> jelmer: it will most likely be removed or fixed soon enough. Maybe a better error message would be in order though. :)
<jelmer> SpamapS, It's not this specific debian directory, more the way in which the recipes are built at the moment (recipes can only be native for now)
<poolie> hi all
<jelmer> 'morning poolie
<jelmer> you're up early :)
<poolie> i'm in california
<poolie> i don't know what time it is :)
<jelmer> ahh :)
<fullermd> Pretty impressive, actually.  Usually it takes people few weeks there before that happens   :p
<poolie> :)
<poolie> a
#bzr 2011-06-14
<mwhudson> bzr tags -d $remote -> 16 vfs calls
<mwhudson> that seems like a lot
<mwhudson> i guess it's hardly been an optimizing target :)
<jelmer> mwhudson: patches welcome? :-P
<lifeless> surprisingly many
<mwhudson> i guess _ensure_real implies a bunch of vfs calls?
<jelmer> I guess we don't have a HPSS call for retrieving tags yet
<lifeless> tonnes
<lifeless> we do
<lifeless> it returns the tags dict bytes
<lifeless> IIRC
<mwhudson> yeah, i mean, pull does the moral equivalent of 'bzr tags' i guess
<jelmer> the /moral/ equivalent?
<mwhudson> in other news, if some magic could happen where bzr tag --delete $tag; bzr push --overwrite removed $tag from the remote branch, that would be nice too :)
<mwhudson> that's obviously a more subtle problem though
<george_e> Quick question... I'm trying to store a password in ~/.bazaar/authentication.conf that has a '#' in it.
<george_e> How can I do that?
<mwhudson> huh, i think the vfs calls result from translating the revid into a revno
<mwhudson> yeah, --show-ids -> 0 vfs
<george_e> Anyone?
<bob2> http auth?
<mwhudson> george_e: well, i think it's parsed with configobj so i think your question is equivalent to "how do i put a value containing # in an .ini style file"
<george_e> mwhudson: I got it.
<george_e> I needed to quote it.
<mwhudson> ah ok, cool
<george_e> Thanks.
<poolie> hi spiv?
<george_e> I'm a little confused when it comes to working trees... I have a branch on a Windows server...
<george_e> ...and on my own local machine, I ran 'bzr pull ftp://...' to checkout the code.
<george_e> ...then I made some modifications to the code and did 'bzr push ...'
<george_e> ...but the code on the server was not updated until I logged in to the server and ran 'bzr update'.
<george_e> Is there some way I can have the code on the server automatically get updated?
<sbarcteam> hi guys.
<jam> morning all
<sbarcteam> with svn one can checkout any subtree of a readable repository. this is convenient for various reasons. What is the way of doing this with bzr ? (don't think I'm starting some kind of flamewar)
<poolie> hi jelmer, riddell
<poolie> oops, jam
<poolie> sbarcteam: check out the whole thing then use views to narrow it down
<sbarcteam> poolie, it is nice when you have a small "whole thing".
<sbarcteam> basically, we have some graphics, and other "content" related materials inside the version control.
<poolie> i agree it would be useful
<sbarcteam> I can see there's a design doc called "NestedTrees".
<sbarcteam> (in launchpad)
<sbarcteam> I wonder where does this thing is standing as of now ?
<sbarcteam> (sorry for english grammar)
<sbarcteam> I wonder where is this thing standing as of now ?
<maxb> It's considered unfinished
<maxb> uhoh, what? Is someone on the case with all those UDD failures?
<maxb> Please tell me people haven't been removing ~ubuntu-branches without replacing the importer's needs
<lifeless> the importers needs were discussed with james_w, poole and the techboard
<lifeless> it should be allowing any uploader to push to any official branch
<maxb> it's the set_official API call that is getting a 401 unauthorized
<lifeless> that's also gated on uploader I think, though perhaps that patch hasn't landed yet
<maxb> (<SourcePackage <Distribution 'Ubuntu' (ubuntu)> <DistroSeries u'lucid'> <SourcePackageName 'linux-meta-mvl-dove'>>, 'setBranch', 'launchpad.Edit')
<lifeless> but if the patch hasn't landed the old rules should be applying
<lifeless> ah, perhaps frozen series are going to be a head-desk moment.
<lifeless> wgrant: ^ thoughts?
<maxb> (<SourcePackage <Distribution 'Debian' (debian)> <DistroSeries u'experimental'> <SourcePackageName 'darcs-monitor'>>, 'setBranch', 'launchpad.Edit')
<maxb> The importer also needs to be able to set official branches for Debian
<makinen> is it possible to push one file?
<makinen> I've made a bunch local commits but I'd like to get only one file pushed to the main branch
<bob2> not really
<bob2> commits are the thing you push
<bob2> you could rewrite I giess
<makinen> ok, is it then possible to commit the merged changes only?
<makinen> I could use --no-strict option with push to omit the uncommitted local files but before pushing I have merge the changes from the main branch
<vila> makinen: commit whatever you want to push is, I think, what bob2 said
<bob2> bound branches lead to confusion :/
<wgrant> lifeless: By frozen you mean released?
<lifeless> thingy :P
<makinen> bzr: ERROR: Selected-file commit of merges is not supported yet
<makinen> :(
<bob2> don't try to break up merges
<bob2> if you insist, bzr revert --forget-merges
<wgrant> lifeless: FROZEN should be OK. CURRENT/SUPPORTED/OBSOLETE won't be.
<lifeless> wgrant: why won't they be?
<wgrant> lifeless: Because uploads to the release pocket of them are rejected.
<wgrant> lifeless: So you can't set the branch for the release pocket.
<lifeless> does soyuz have a test that will francis should use?
<wgrant> Not sure.
<wgrant> I need to go now, sorry.
<lifeless> viao
<gour> jelmer: my hg import failed again - http://launchpadlibrarian.net/73472512/gour-myclientbase-trunk.log
<Riddell> buenos dias
<Riddell> jam: what's the status of your verify signatures plugin?
<jam> Riddell: really-really-old. Like written for bzr-0.xx
<Riddell> jam: is there a reason nobody has implemented signature verification with pgpme?
<jam> Riddell: at one point we looked at the gpg python stuff, but at that time, they were all pretty bad
<jam> I'm hoping things have gotten better
<jam> (like segfaulting, etc)
<Riddell> jamesh: have they? :)
<jam> vila: looking here: http://babune.ladeuil.net:24842/job/selftest-windows/444/
<jam> it says "3 failures" but only shows 1 failure???
<jamesh> Riddell: I half ported jam's signing plugin to my pygpgme binding.
<jamesh> the interesting thing would have been to add things like a commit hook to prevent merging an unsigned revision, or to only allow merges signed with known keys, etc.
<vila> jam: click the 'Show all failed tests >>>'
<jam> vila: so the hidden ones are ones which have been failing for a while?
<vila> jam: no idea
<jamesh> just not sure where I put the branch.
<jelmer> gour: Sorry, missed that earlier. That's a known issue for which a fix is about to land.
<CaMason_> Afternoon all. Is there a plugin or something that I can use to 'label' remote branches to make them easier to merge?
<CaMason_> atm I have to keep asking my devs for the full path to their repo on the server - it would be good to just 'bzr merge nigel-feature-1'
<spiv> CaMason_: there's the 'bzr bookmarks' plugin.
<CaMason_> that sounds promising :D
<spiv> https://launchpad.net/bzr-bookmarks
<CaMason_> thanks, looks good to me
<CaMason_> works great, thanks
<gour> jelmer: any eta? it's not a rush, just curious what to expect
<jelmer> gour, it's already landed in launchpad's development branch, just needs to be deployed.. should be about a week
<gour> jelmer: thank you
<smoser> hi, can i ask for lp:ubuntu/euca2ools to be kicked ?
<smoser> http://package-import.ubuntu.com/status/euca2ools.html
<Riddell> smoser: kicked in which way?
<smoser> sent mail to ubuntu-distributed-devel
<maxb> In the requeue_package.py --full sense
<maxb> but that's all a moot point bug 797088 is fixed
<ubot5> Launchpad bug 797088 in Ubuntu Distributed Development "Launchpad has removed privileges that UDD importer requires to function" [Critical,New] https://launchpad.net/bugs/797088
<jelmer> urgh :-(
<maxb> Yes.
<poolie> hi all
<poolie> ouch
<maxb> So about this ouch... is anyone addressing it?
<maxb> https://code.launchpad.net/~maxb/udd/797088-workaround/+merge/64576
<maxb> spiv: are you actively PPing right now, perchance?
<poolie> spiv was on holiday monday/tuesday
<poolie> and out of town
<poolie> at the moment it's 3am in australia but i think he will be piloting later
<poolie> suggest you mail him
<poolie> or i could
<poolie> review this
<poolie> maxb: can you land it or do i need to?
<maxb> I can land - can you deploy? :-)
<poolie> yes, tell me when
<maxb> done
<maxb> And thanks :-)
<maxb> and ./requeue_package --all-of-type cups will flush the backlog
<maxb> Which should go pretty quickly since the imported branches are sitting on jubany's disk just waiting to be pushed
<sinzui> jelmer: ping
<maxb> we have a pending request for "./requeue_package.py --full euca2ools" as well, if you wouldn't mind whilst you're there
<james_w> maxb, thanks for the workaround
<jelmer> sinzui, hi
<sinzui> jelmer: I want to fix bug 796856 . I have been fixing gtk3 bugs in my own tools and I think I understand all the issues. I do not know if we want a new series for gtk3, or if you want a branch that can be merged into trunk
<ubot5> Launchpad bug 796856 in Bazaar GTK+ Frontends "commands are incompatible with gtk3" [Undecided,New] https://launchpad.net/bugs/796856
<jelmer> sinzui: I think a separate series is probably a good idea, at least while we're still working on gtk3 support
<jelmer> I tried to do a combi gtk2/gtk3 branch a while back and it got too messy
<sinzui> jelmer: I can fork trunk tonight and start working on it.
<jelmer> sinzui, cool :)
<jelmer> sinzui: you're welcome to join ~bzr-gtk if that helps in setting this up
<sinzui> fab. I will apply
<poolie> hi sinzui, jelmer
<poolie> james_w, so are you doing that for maxb or should i?
<james_w> poolie, I'm in a meeting, so if you are free could you do it?
<jelmer> hi poolie
<jelmer> sinzui: welcome :)
<mgz> jelmer, can you use your newly found magic powers on bug 790268
<ubot5> Error: Launchpad bug 790268 could not be found
<jelmer> mgz: Magic fairy dust has been applied to bug 790268
<ubot5> Launchpad bug 790268 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError in smart_add(): 'ascii' codec can't decode byte 0xc4 in position 34: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/790268
<mgz> thanks!
<vila> jelmer: (-:
<mgz> okay, that's another misconfigured locale one, the bug that was duped against it was etckeeper
<mgz> I'll move the one from before to the etckeeper package, and dupe against that instead
<jelmer> we really need a consistent way to deal with these unicode -> fs encoding bugs
<mgz> poolie put up some sensible suggestions on the list
<cordeiro> Hey, I have a (probably silly) question. :) I've separated repositories that I would like to combine in one without loosing the history of the files. Each rep. have the history of a research paper and now I want to combine them into one that will (finally :)) hold my thesis. What is the best approach to create this new rep?
<jelmer> cordeiro, you can merge them into a single repository using "bzr merge" or "bzr join"
<cordeiro> I can do that even if they don't have a single base revision?
<cordeiro> (each one was created independently)
<jelmer> cordeiro, yes, though you'll have to force the merge ("-r0..-1")
<cordeiro> Ahh... this is the astuteness that I was missing. :)
<cordeiro> Thanks, jelmer!
<maxb> poolie: Hi, can you let me know which bits of jubany-wrangling you did, so I know what I still need to ask for?
<poolie> hi maxb, have not done any yet
<poolie> will do them now
<maxb> many thanks. to recap, and ensure we're both on the same page:
<maxb> * update deployment of lp:udd
<maxb> * ./requeue_package --all-of-type cups
<maxb> * ./requeue_package.py --full euca2ools
<maxb> uh, missing .py, but you know what I mean
<poolie> thanks for that
<poolie> udd updated
<poolie> all done
<maxb> Excellent, I shall check status page when the cronjob has fired
<maxb> poolie: Oops! I broke it :-/   Apparently I planned out my change, but then didn't commit it all. I've reopened https://code.launchpad.net/~maxb/udd/797088-workaround/+merge/64576 with another revision.
<poolie> ok
<maxb> I feel silly. I spent so long checking all call-sites and adding a docstring, that I didn't actually make the core of the change.
<poolie> oh well, that doesn't reflect well on my code review either
<poolie> ok, please merge that
<maxb> pushed
<poolie> requeue them again?
<maxb> ./requeue_package --all-of-type cups
<maxb> uh, .py
<maxb> And as for euca2ools, ideally kill its import_package.py process and ./requeue_package.py euca2ools
<Uber_Geek> hello,  I was wonder if there was a guide for SVN users to migrate to BZR
<poolie> done
<maxb> Thanks poolie  - I'm just staring at the failures page and am wondering if somehow some of these are ending up under a different traceback.
<jelmer> Uber_Geek, see http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-svn-users.html
<Uber_Geek> sweet, thanks
<maxb> Something very very wacky has happened, we've got 700 new failures, but I can't see any obvious reason why they would be related to current goings on
<gour> any idea what might be cause of "bzr: ERROR: Invalid http response for https://github.com/chillu/silverstripe-book.git/info/refs: Unable to handle http code 405: Method Not Allowed" ?
<maxb> I think github only supports certain kinds of http access to repositories, which does not include the kind bzr-git wants to use
<maxb> You should be able to use git:// instead
<jelmer> yeah, you need git://
<jelmer> the github http server only supports the smart server http protocol, which dulwich/bzr-git don't support yet
<gour> with that i get: bzr: ERROR: The remote server unexpectedly closed the connection.
<gour> (bzr branch -v git://github.com/chillu/silverstripe-book.git)
<jelmer> gour, that command seems to work for me
<gour> interesting...
<gour> jelmer: shall i try with trunk?
<jelmer> gour, worth a shot; what version are you running?
<gour> jelmer: 0.6.0
<gour> 2.3.3
<gour> let me try with trunk
<jelmer> poolie: what was the magic incantation you did last time to get the SRU moving after it was uploaded to -proposed?
<gour> jelmer: same problem with the trunk
<jelmer> gour, newer dulwich perhaps?
<jelmer> gwenhwyvar:/tmp% bzr branch -v git://github.com/chillu/silverstripe-book.git
<jelmer> Branched 114 revision(s).
<gour> jelmer: i've dulwich-0.7.1
<gour> that's the latest in ports
<jelmer> gour, server side glitch perhaps? Have you tried again?
<poolie> jelmer: (let's describe this on the sru wiki page)
<poolie> basically it was, download it and test it
<poolie> perhaps then add a comment on the bu saying it's all ok
<poolie> perhaps checking that someone else useed it is goods
<poolie> *good
<gour> jelmer: "Branched 114 revision(s)." - on the 5th attempt after 4 failures...so much about github glory :-)
<poolie> then i think you need to ask a sru-team member on irc to progress it
<poolie> i haven't worked out any non-interactive way to make it happen
<gour> jelmer: btw, how is it that you host dulwich at samba.org? is samba project satisfied with waf build tool?
<jelmer> poolie: ah, thanks. I'll ask
<jelmer> gour, most of the projects I started in my personal time are hosted on samba.org
<jelmer> gour, we're fairly happy with waf..
<gour> nice to hear...i hope that maybe bento will be enough for my purposes...otherwise there is waf back-end support
<jelmer> gour, not all aspects of it, but we're happy with the choice we made (there don't appear to be any good alternatives)
<gour> fbuild?
<jelmer> gour: never heard of fbuild, do you have a link?
<gour> jelmer: https://github.com/felix-lang/fbuild
<gour> downside is that it's python-3 only, although not problem for me
<jelmer> gour, it looks interesting
<jelmer> gour, yeah, python 3 is a no go for us for at least the next year or so (probably more)
 * gour hopes bento will emerge into nice (python) packaging tool
<maxb> I'm rather perplexed how we ended up with "727 packages failed with key AssertionError:<module>:main:find_unimported_versions" all of a sudden
<maxb> Could I have a ./requeue_package.py libclass-throwable-perl, to check whether it's a persistent problem?
<poolie> sure
<KombuchaKip> Does the nautilus-bzr plugin hook Nautilus file renaming to bzr rename?
<poolie> not sure
<poolie> it seems like it should
<KombuchaKip> poolie: Let's fine out. One sec...
<KombuchaKip> poolie: Just tested and no it doesn't appear to. I'll add a ticket on Launchpad.
<poolie> k
<visik7> hi
<visik7> how is handled the file:// protocol ?
<visik7> can I put relative paths ?
<visik7> like bzr brach file://../ ?
<poolie> no, they're always absolute
<visik7> :(
<poolie> just use the path
<poolie> bzr branch ../../blah
<visik7> I cannot
<poolie> why?
<visik7> bzr is called from inside maven release plugin
<visik7> and I cannot commit the absolute path in the parent pom
<KombuchaKip> poolie: Done: https://bugs.launchpad.net/bzr-gtk/+bug/797438
<ubot5> Ubuntu bug 797438 in Bazaar GTK+ Frontends "nautilus-bzr plugin does not hook rename" [Undecided,New]
<amanica> jelmer Hi, if you have a moment can you quickly look at the question I just posted: https://answers.launchpad.net/bzr-git/+question/161452  (How do I push multiple branches into one repo on github?)
<amanica> whoops, thought he was here now. nevermind.
<maxb> Well, grr. We do have a new persistent problem, and I don't know why
#bzr 2011-06-15
<maxb> Could I have a copy of jubany:/srv/package-import.canonical.com/new/logs/packages/libfile-touch-perl please?
<james_w> maxb, http://paste.ubuntu.com/626940/
<maxb> thanks
 * maxb stares at the log and wonders what changed that it now errors
<poolie> hi amanica
<maxb> Hmm. I'm totally failing to be able to reproduce the "727 packages failed with key AssertionError:<module>:main:find_unimported_versions" issue
<maxb> Is UDD's meta.db small enough that I could download a copy?
<poolie> i'll look
<spiv> Hi maxb
<poolie> hi spiv!
<maxb> Hi
<spiv> Thanks for digging into those failures, it's a shame to have slipped so far backwards :(
<poolie> maxb: 153MB; so probably yes
<maxb> poolie: Great - maybe you could copy it into the www directory?
<poolie> yup
<maxb> or symlink could work too, I guess
<poolie> done
<maxb> downloading
<maxb> got it
<maxb> Grr. It works fine here
<maxb> Given the importer queue is empty, I propose a ./requeue_package.py --all-of-type libfile-touch-perl    - even though a previous single requeue failed again, the importer might as well be exhaustively checking each failure still fails again, given I'm totally unable to reproduce the failure, even having supposedly used identical data
<spiv> maxb: ok, I'll kick that off
<spiv> maxb: if that fails, I guess we start narrowing down version differences and the like :/
 * maxb crosses fingers and hopes the problem disappears as mysteriously as it arrived
<spiv> (in the software on jubany, that is)
<spiv> Requeued, let's see what happens.
<maxb> Hmm... this is odd. I see a different testament sha in the DB to what bzr testament reports
<maxb> but that still should not be able to cause this failure modoe
<poolie> thanks for the reviews gz
<poolie> hi spiv; can you comment on my mp about del methods?
<spiv> maxb: huh
<spiv> maxb: so some of those failures are indeed clearing :/
<spiv> e.g. âSuccess libfile-touch-perl: Nothing newâ
<spiv> poolie: sure
<james_w> maxb, workaround-fix merged and rolled out, thanks for the fix
<maxb> thanks
<maxb> spiv: Hmm. Mysterious indeed. I can only conjecture that my first broken version of the workaround managed to trigger some insanely counter-intuitive behaviour
<poolie> spiv, thanks for that
<spiv> np
<poolie> i'm surprised bug 659590 could be reliably fixed by relying on del
<ubot5> Launchpad bug 659590 in bzr (Ubuntu Lucid) "[SRU] dput sftp upload hangs after all files successfully uploaded" [Undecided,Triaged] https://launchpad.net/bugs/659590
<poolie> perhaps it's an object that's only ever refcounted at present
<poolie> perhaps i should revert that one change, and then file a separate bug to deterministically close them?
<spiv> I think that would be safest.
<spiv> If this were the start of the 2.5 release cycle rather than near the end of the 2.4 cycle I'd be more tempted to land it and see what the fallout is
<spiv> I'm not sure that removing that __del__ would necessarily cause a regression along those lines, but given that we have had surprises in this area before my instinct is to be a little conservative.
<poolie> really that bad?
<poolie> hm
<poolie> i'm glad i asked then
<spiv> Hmm, it may be interesting to note that bzrlib.transport.ssh has something similar, but with weakref callbacks
<spiv> i.e. makes sure to try kill the SSH subprocess when the corresponding object is GCed (if it hasn't already)
<poolie> hm
<Kamping_Kaiser> hi all. trying to update a pakage with bzr merge-upstream and it tells me i haven't got a tag on the branch upstream-0.2011. how can i tag that branch? help on branches/branch/tag/tags didn't clear it up for me
<KombuchaKip> Is there any way to get the branch revision number, e.g. just 43, as opposed to something like 43 kip@thevertigo.com-20110612001024-3tncb5tbxh30d7zx when one runs bzr revision-info?
<Kamping_Kaiser> bzr revno?
<KombuchaKip> Kamping_Kaiser: Thank you. I didn't see that switch.
<Kamping_Kaiser> KombuchaKip: np
<spiv> Kamping_Kaiser: 'bzr tag -r REV TAG_NAME' sets a tag on a branch
<spiv> Kamping_Kaiser: specifically it sounds like bzr merge-upstream is looking for a tag called "upstream-0.2011"
<Kamping_Kaiser> spiv: the error implies i have multiple branches. could that be the case, or is it just fooling with me?
<spiv> I think you may be misreading the error
<Kamping_Kaiser> quite possible. full message is 'bzr: ERROR: Unable to find the tag for the previous upstream version, 0.20110614, in the branch: upstream-0.20110614'. i don't know how to tell if i'm in that branch; bzr info doesn't tell me
<spiv> Kamping_Kaiser: Right.  I see the confusion.
<spiv> Kamping_Kaiser: "upstream-0.20110614" is the tag name it is looking for
<spiv> (Which would be the tag corresponding to upstream version 0.20110614)
<Kamping_Kaiser> spiv: thanks for clarifying. have to say, thats a rather confusing message :/
<spiv> Apparently so!
<spiv> I'll file a bug about that.
<Kamping_Kaiser> spiv: thanks. if you could let me know the number that would be great :)
<spiv> bug 797518
<ubot5> Launchpad bug 797518 in bzr-builddeb "Confusing error from merge-upstream when upstream tag is not found" [Undecided,New] https://launchpad.net/bugs/797518
<Kamping_Kaiser> thnks
<Kamping_Kaiser> *thanks
<Kamping_Kaiser> hi all, another merge-upstream question. while using merge-upstream it deleted my debian/ directory. is this, uh, normal? http://paste.debian.net/119879/ am i missing more tags? (bzr help merge-upstream doesn't mention tags at all)
<spiv> Kamping_Kaiser: I don't think that's normal, but I don't know enough about bzr-builddeb to suggest how to debug :(
<Kamping_Kaiser> spiv: np. i'll hang around, hopefully someone else will wander by
<spiv> Kamping_Kaiser: hmm, although a quick guess might be that the debian/ directory is incorrectly part of the previous upstream-* version?
<Kamping_Kaiser> spiv: let me try retagging to check
<spiv> Kamping_Kaiser: or just inspect the contents (e.g. with 'bzr qlog')?
<Kamping_Kaiser> spiv: qlog doesn't appear to be a bzr command
<spiv> Kamping_Kaiser: it's part of the qbzr plugin
<spiv> ('bzr viz' from the bzr-gtk plugin is nearly as good)
<Kamping_Kaiser> ah, don't have that plugin
<Kamping_Kaiser> spiv: looks like you are correct - it wants the upstream release tagged, not the package release.
<spiv> Kamping_Kaiser: yes, the upstream-* tags are for tagging upstream versions
<spiv> (Although I think normally you'd rely on merge-upstream or import-upstream to create those revisions and tags for you)
<Kamping_Kaiser> spiv: its probably because i crated the repo with dh-make manually, instead of bzr dh-make (which i just discovered)
<vila> morning all !
<fullermd> What, again?  We just survived the last one...
<jam> morning all
<mgz> will try to find some time for coding today, about to go offline though
<Riddell> spiv: can't hear you
 * jelmer waves
<spiv> Software.  It's marvellous.
<jelmer> should we try skype?
<Riddell> jelmer: mumble still not happy for you?
<Riddell> is vila around?
<vila> errk, here I come
<jelmer> Riddell, not really, trying the audio wizard setup again..
<jelmer> \o/
<maxb> james_w: Do you remember what the "sleeping to stack" thing the UDD importer does is for? (Sleep for 5 minutes after pushing a dev-focus branch if the push created a new remote branch) Is it, as speculated in the code, obsolete now launchpad doesn't have separate read / write branch areas?
<spiv> maxb: sounds highly plausible
<spiv> jelmer, Riddell, vila, jam: g'night!
<vila> spiv: cu !
<jelmer> Riddell, one of the bugs associated with it is bug 465517
<ubot5> Launchpad bug 465517 in bzr (Ubuntu Natty) "'bzr push' copies the entire repository if there is a BzrDir but not a Branch" [High,In progress] https://launchpad.net/bugs/465517
<Riddell> jelmer: unapproved queue is fairly long, hasn't been processed in a week, I guess you can try politely pinging members of ~ubuntu-sru
<jelmer> Riddell: thanks - just pinged pitti in #ubuntu-devel
<vila> jelmer: I forgot to ask, which bzr versions did you deploy on lp ?
<jelmer> vila: 2.3.3
<vila> jelmer: thks
<jelmer> vila: I'm looking forward to the day we can deploy 2.4
<vila> yeah, happens every 6 months ;)
<james_w> maxb, experimentation showed that if it slept for about the latency of copying branches between the two areas they still failed to stack
<james_w> maxb, no-one had any explanation for why it was happening, so I left it at 5 minutes which seemed to avoid the issues
<spiv> james_w: so now that there's no copying to wait for that sleep is probably unnecessary then?
<james_w> spiv, the conjecture at the time was that it wasn't the split that was causing it, but no alternative explanations were forthcoming
<spiv> james_w: hmm.  Still tempting to try removing it and see if the bug and/or trigger is no longer present...
<james_w> yeah
<spiv> Or maybe it if it still fails it might be more obvious why
<spiv> And with that optimistic thought I'm off to bed!
<achiang> hello, looking for some help on how to recover from a pretty bad mistake. :-/ i had 2 branches, A and B. for a long time, i've been making changes in A, and then merging/pulling into B. i just made a mistake of pulling B back into A, and want to undo that.
<achiang> even worse is that both A and B are committed and pushed into LP.
<maxb> This doesn't sound too bad
<maxb> The potentially slightly tricky part is that you will have to identify the old tip of A by browsing the revision history and figuring it out
<maxb> Are A and B public? Sometimes it's easier to explain by just saying "look at these branches"
<achiang> no, A and B are not public, unfortunately.
<maxb> Alright.
<maxb> First thing is - we need to be clear on whether you pulled/pushed B into A, or merged it
<maxb> Second, are you familiar with qbzr and "bzr qlog" ?
<jam> have a good night everyone
<achiang> i definitely did a 'bzr pull B', so i do not have a clean merge point. :(
<maxb> OK, so, start "bzr qlog", and look back in the history for the last merge of A into B - this should allow you to identify the revision that should be the correct tip of A
<achiang> maxb: ah, what i do have is good versioning
<maxb> james_w: Thanks - do you know if it has been revisited at all since the "two areas" design was changed to a single area? It seems likely that this behaviour could be removed now, for significant simplification of the code.
<achiang> so, my A version string looks like: 0.4~bzr457
<achiang> and my B version string looks like 0.4~bzr457versionB
<james_w> maxb, it has not been revisited
<achiang> so, i think that r457 in A is the last time i branched off B
<achiang> or rather, r457 in A is the last time i merged it into B
<maxb> achiang: Ok, that will help in confirming that you have found the right revision, but you'll still need to hunt through the history. If you start "bzr qlog", and look back through the merge commits, it should hopefully be reasonably easy to locate revisions which are intended to be part of A
<achiang> maxb: hm, actually life is a little easier -- on another machine, i have a good copy of A before my mistake
<maxb> achiang: OK, so once you have convinced yourself that it is not missing any revisions that should be there, you can just "bzr push --overwrite" it to other places where it needs to be
<achiang> maxb: ok, i'll try that
<achiang> maxb: is there a way to diff branches at the revision level?
<vila> achiang: bzr qlog branchA branchB
<vila> achiang: or bzr qlog branchB branchA
<vila> generally you put the most inclusive one first (trunk)
<achiang> hm, thanks
<maxb> Some of the older UDD branches are... not very pretty
<maxb> scala has somehow managed to end up with separate (though related) upstream revisions in ubuntu and debian, and three separate revisions for each version, one in unstable, one in testing, and one in ubuntu
<maxb> Despite never having had an ubuntu delta
 * jelmer waves
<apw> can anyone explain why bzr moves things to .moved when merging?
<vila> apw: bzr help conflict-types
<vila> apw: but in a nutshell, I suspect you're running into a parallel import ?
<vila> apw: i.e. do you have a few .moved files or a huge number of them ?
<apw> i have a world of them, and the importer is somehow making the kind of mess which reintroduces the collission for every upstream merge, and it is getting on my nerves
<vila> :-/
<apw> vila, is there some way i can say ... these files are the same file really, treat them as a textual collission
<vila> apw: so, the root issue is that bzr use file ids to track renames and that works well except... when the "same" files received different IDs
<vila> apw: not yet no, sorry, but it's a know issue for udd and we should fix it (and will)
<apw> vila, so i should be using git to do my merge then, git-bzr or something, as that will not make the same mistake
<vila> known
<apw> vila, anyhow thanks for the info that is helpful
<vila> I don't know how bzr-git handle that
<apw> well git doesn't track files, so its merge would be what i want, just texttual
<vila> apw: but yes, git doesn't have this problem
<vila> yup
<vila> apw: what is the package you're having an issue with ?
<jelmer> bzr-git won't help with that
<apw> vila, module-init-tools
<apw> jelmer, i atually meant git-bzr in that context
<apw> jelmer, as in check it out in git, merge it there with its dumber merge, and push it back into bzr
<vila> maxb: does module-init-tools ring a bell ?
<jelmer> apw: Ideally bzr's merge would support per-path merging
<apw> jelmer, well indeed, but as right now what it does is hose my working directory and break my poor mind ...
<maxb> I have not looked at module-init-tools
<jelmer> apw: it shouldn't actually be that hard to implement, there just never has been a lot of reasons to implement it
<apw> vila, so in my problem case the merge seems to have merged some files, ie noticed they are ok, then moved them aside, such that if i take the 'other' side i won't actually get the other side i'll get only like 2 files
<maxb> Unfortunately I think quite a few of the UDD imports have ended up with differing Ubuntu vs. Debian file-ids
<apw> maxb, and thats insoluable? as the merge side of things just doesn't work at all when they are like that
<vila> apw: I don't follow, how do you take the 'other' side ?
<maxb> It's a tractable problem, but it's most easily solved by throwing away the mangled import and reimporting if there are no non-importer revisions
<gour> is 2.4 going according to the schedule?
<apw> maxb, that seems fine, what i don't get is once i have merged them why it doesn't know they are then the same
<vila> gour: so far, yes
<vila> 'once I have merged them' How ?
<apw> vila, i have a tests directory with some files, i merge in a near identicle directoy with the same conents different file id's
<apw> vila, and i end up with tests/ with one directory in with the one new file from the merge, and everything else in tests.moved.  i then say "bzr resolved --action=take-other which to my reading should give me whats in what i am merging and nothing from my local
<fullermd> But you haven't _merged_ the files, you've just picked one or the other.
<maxb> OK, so in the module-init-tools case, the problem is that we have the existing oneiric branch which is derived from an import of upstream's git - whereas the existing debian branches are derived from tarball imports
<apw> vila, but what i get is exactly one file from the other side and nothing else.  that seems like a completely erronius resolution
<vila> apw: argh
<apw> fullermd, well indeed, but picking the ones from the right place aught to sort out the wrong file ids in my world
<vila> apw: 1) 'bzr resolve --take-other' *with no path specified* has bugs
<maxb> So in this case it is uncovering the problem that UDD cannot work for merging changes from Debian if the ubuntu side is tracking one representation of upstream but the debian side is tracking a different one
<apw> vila, quality software
<vila> apw: well, I just fixed one today, 'cause I had a bug report ;)
<vila> apw: what version are you using ?
<apw> maxb, and i can't fix it can i, not even by careful use of merging
<apw> vila, whatever version is in natty
<apw> vila, its hard to know whats a bug and whats meant to work that way when i am in such a pickle
<vila> 'bzr version' but that's probably 2.3.1 (2.3.3 is currently SRUed)
<vila> apw: I know
<maxb> apw: Well, you could, but if you "fixed" the use case of merging from Debian, you would have introduced the equivalent problem for merging from upstream's bzr-git import.
<vila> apw: I know :-(
<apw> 2.3.1 indeed
<vila> apw: there are no known bugs if you use 'bzr resolve --take-other FILE' (at least in trunk)
<apw> maxb, i assume the problem persists because of how the importer pushed down new versions ... now if i push my branch to the import branch before i upload, it shouldn't stand on my branch at all should it ?
<maxb> The root cause of failure here is that we have allowed official package branches to be used with non-UDD-importer upstream sources, without realizing and documenting how this breaks the merge workflow
<apw> maxb, might that let me fix the ids ?
<gour> vila: good luck with release...it looks it might be an important one
<apw> maxb, i think module-init-tools was a very early adopter of bzr and so very very likley all the horrors you suspect have happened to it
<maxb> apw: The importer will honour tagged revisions pushed before uploading if it assesses their content to be essentially the same as the upload
<apw> so then its down to what 'essentially the same' means ... as i have watched it wack my tagged revisions before
<maxb> apw: Basically the problem is that someone decided to make lp:ubuntu/oneiric/module-init-tools be a branch derived from upstream's vcs (which is a good idea in general) but without knowing the consequence that it is incompatible with merging from a Debian UDD-imported branch
<apw> maxb, i suspect it actually was joined there before the importer existed even
<apw> maxb, so no magic bullet ... just slog t
<apw> through the conflicts every time, papering over the bugs in resolved ...
<maxb> Well. If I was doing this merge, I would disregard lp:debian/module-init-tools completely
<apw> maxb, ok, is there somewhere else i can get the 'contents' and apply it?
<maxb> I would import the debian .dsc into a local branch and merge that
<apw> maxb, ok will give that a go, it cannot possibly be any harder
<apw> maxb, any idea where i'd find that
<maxb> If we want to continue this style of package maintenance, I'd probably take the opportunity to disentangle from the unwanted debian import whilst we still can, first.
<maxb> Ah, so is this package maintained in bzr in debian? Looks like it
<maxb> Right OK
<apw> maxb, could be, i have managed to merge the package in the sense that i know the real differences from debian and its back to a small set thereof
<apw> maxb, the plan was to try and push it back to being related in the 'normal way' when i started out
<maxb> So the nice and tidy way to manage this would definitely be to remove the painful messy 3.13-1ubuntu1 revision before we build any more history on top of it
<apw> maxb, whatever you think is appropriate
<maxb> So, here is what I'd do:
<maxb> * Have a local copy of lp:ubuntu/module-init-tools
<maxb> * Have a local copy of the Debian packaging branch which Debian is actually using - *not* lp:debian/module-init-tools
<maxb> * In the ubuntu branch, uncommit the painful merge of 3.13-1ubuntu1 ("bzr uncommit")
<maxb> * Reconstruct that revision with different ancestry, by first merging the appropriate revision from Debian's bzr ("bzr merge -r 3.13-1 ../local-debian-branch"), then removing all the files, unpacking Ubuntu's .dsc into the tree, and committed
<maxb> committing
<maxb> At that point, I'd be well placed to merge 3.16-1 from Debian with bzr helping, rather than fighting me
<apw> that sounds at least sane
<apw> so i need to find their upstream branch,
<apw> hopefully that is in their package
<apw> maxb, i'll have a go at that and publish something for review
<maxb> I can try to do what I just described and post exact commands
<maxb> Hmm, their debian/control lacks Vcs-* fields - naughty
<apw> maxb, yeah i think i grok your intent and indeed why it makes sense, its finding the debian one which will challenge one
<maxb> Ask Scott James Remnant?
<apw> maxb, well i don't think he is maintining the debian side, we have been deviant from them for the longest time
<maxb> Oh yikes, I have misinterpreted somewhat
<maxb> "3.12-1" was deceptively a direct upload to maverick apparently, not via debian
<apw> ahh yes, there was much badness done in the packages history
<maxb> oh, yuck
<maxb> erm, right
<maxb> oh
<maxb> there's no Debian history in this branch at all
<apw> whats annoying is i know how to un-fook self here with git, i'd just take the debian import, drop our files on it, merge the history from the current mess branch without taking any files at all and push the result
<maxb> just Ubuntu history mislabelled with debianlike revisions
<apw> maxb, yeah this branch is an utter mess, i wonder if i rm'd all the files in the ubuntu one and merged it into a new checkout of the debian one
<apw> would i get a clean debian one with the ubuntu history still attached but not affecting me ?
<apw> ie all my files would be the right id's from the import side
<maxb> Vaguely - I am currently trying to remember how I solved one of these before
<apw> well perhaps i will go try that
<apw> and see what bzr vis does after
<maxb> apw: I think I know what to do now
<maxb> bzr branch -r 3.13-1 existing-ubuntu-branch reconcile-fileids
<maxb> cd reconcile-fileids
<maxb> bzr merge ../existing-ubuntu-branch # which is at 3.13-1ubuntu1
<maxb> bzr revert . # Note the final . character in the command
<maxb> Delete everything but the .bzr dir
<maxb> Copy in the content from 3.13-1ubuntu1
<maxb> bzr diff, briefly check the output looks like the existing ubuntu delta
<maxb> bzr ci -m "Committing existing Ubuntu 3.13-1ubuntu1 with fileids from Debian UDD branch>"
<maxb> done
<apw> maxb, why do i get ids from debian there?  as i never mentioned it anywhere?
<apw> or is that 3.13-1 the real debian one in that case
<maxb> Yes, that's correct
<apw> ok will give it a go and see if we can unfook this mess
<apw> maxb, thanks
<maxb> I will try these commands too and make sure they actually do what I claim :-)
<apw> maxb, well it looks sane enough in bzr vis, will try merging it up as well
<apw> as there is anohter upstream version to merge to as a test
<maxb> It does appear to have done something approximately sensible
<apw> maxb, thats doing much more what one might expect, exactly one conflict, where i'd expect one
<apw> maxb, awsome thank you, that revert . thing is essentially what i would have done in git too
<maxb> There really ought to be a way to do this without deleting and manually replacing the tree, but I'm having trouble thinking of one right now
<apw> maxb, but as the history is still attached i can still find everything so i think its ok
<apw> maxb, and the merge to 3.16-1 has gone exactly as i would expect not just the odd conflict nice ... thanks
<dash> i'm getting a lovely 'checksum mismatch' error when trying to pull from an svn repository. anything i can do to diagnose/work around this, or is cloning a fresh branch outside the shared repo my best bet?
<poolie> dash, hi, i suggest you file a bug with details and then branch into a different repo to see if that helps
<maxb> dash: A fuller view of the error message would help a useful answer
<dash> thanks
<dash> it's just "bzr: ERROR: checksum mismatch: '0fa285e09d5f0258f68f2bd3c95474af' != '3f62e97923e50d938a211951ff56e753' in mysvndir/trunk:22246"
<dash> no traceback
<maxb> Please check your ~/.bzr.log - I think the traceback will be saved there
<poolie> hi maxb
<maxb> hello
 * Riddell politely reminds spiv to review his bzr-explorer merges sometime today
#bzr 2011-06-16
<poolie> hi spiv
<poolie> and riddell
<dash> okay so i'm still getting 'checksum mismatch' when doing a new branch from svn  into a standalone branch
<poolie> i think its clashing with your bzr-svn cache
<poolie> which might be in ~/.bazaar/
<poolie> you could try savinga copy and moving it away
<ptressel> I'm trying to extract a working tree from a branch for which I have only the .bzr directory. (Background is that I did a bzr branch, but that failed just at the end when it could not create a symlink on windows. Looks like the repo is intact though.) I cd'd to the branch directory where .bzr was, and did "bzr checkout". That got Error 183, file exists, on the .bzr directory itself.
<poolie> hm
<ptressel> I'd like to redo the checkout under cygwin, which can create symlinks, but the above error is stopping that.
<poolie> try 'bzr checkout broken other'  - ie into a different directory
<ptressel> Is there something wrong with my syntax for "bzr checkout"?
<ptressel> Ah, ok.
<ptressel> And then move the files back in?
<ptressel> Almost worked...  That didn't get the "file exists" error, but...it still couldn't make the symlink.
<ptressel> I thought that was the usual workaround for symlinks on Windows.
<poolie> oh, it failed under cygwin?
<ptressel> Right
<poolie> :/
<ptressel> Odd.
<ptressel> I've asked the person who put the symlink in to take it back out, but it might be a while...
<ptressel> :(
<ptressel> cygwin can create symlinks -- just checked.
<ptressel> Hmmm, I wonder if the fix that added the "unable to create symlink" error message is checking for attempted symlink creation *before* trying it...
<ptressel> The workaround of using cygwin was mentioned before that fix.  https://bugs.launchpad.net/bzr/+bug/81689
<ubot5> Ubuntu bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,Confirmed]
<CarlFK> after bzr branch foo, how do I back up a rev? (need to figure out which of the last 5 - 10 commits broke it)
<ptressel> CarlFK, if this is a throwaway branch and you've got the real code saved elsewhere, you can back out each change in turn by doing "bzr uncommit" then "bzr revert".
<CarlFK> ptressel: it is, thanksl
<ptressel> Welcome!
<spiv> CarlFK: you can use "bzr revert -r REV" to revert just the files to the state at a particular rev
<spiv> CarlFK: and then plain "bzr revert" to restore the files back to the current revision
<ptressel> So that doesn't affect anything but the working tree?
<ptressel> Safer... ;-)
<spiv> Right.
<ptressel> So one could go backwards down the revisions with "bzr revert -r -1", "bzr revert -r -2", etc.
<lifeless> .
<elmo> does anyone have an example of a plugin that extends or overrides a builtin command?
<elmo> the docs for 'extending an existing command' are 'TO BE DOCUMENTED.'
<lifeless> loom overrides status
<elmo> lifeless: ta
<lifeless> loom is also one of the older plugins; its stule may be a little... idiosyncratic
<elmo> is there a concept of repository specific plugins?
<elmo> i.e. any user of the (shared) repository runs the plugins
<elmo> I can see why there wouldn't be ... ;-)
<lifeless> no, security considerations
<lifeless> there is the ability for a plugin to do nothing on repositories it doesn't know about
<elmo> bah humbug
<lifeless> e.g. in the repo config you provide the config for the plugin
<lifeless> and you install the plugin globally for all users.
<elmo> oh, that'd work
<lifeless> the plugin then checks for a config and if none found on a repo does nothing.
<elmo> lifeless: can I get bzr to tell me the default plugin paths or shall I UTSL?
<lifeless> gmm, I thought it was in bzr --version
<lifeless> but no
<lifeless> ah
<lifeless> check in ~/.bzr.log
<elmo> lifeless: aha, ta
<lifeless> basically your plugin becomes a submodule of bzr
<lifeless> see the setup.py for loom etc
<marvin2> Hi, could someone please explain how "bzr split" works?
<marvin2> I need to create a branch out of a directory in an existing tree.
<marvin2> Whatever changes I commit to files inside that directory should be stored only in that directory's own repo - is this how it works?
<jam> morning all
<Merwin> Hum, is a way to do a "lightweight" checkout from a lp repo? Downloadin lp:openerp-addons is around 500Mo wheras I ust want to "get the latest version", not especially all the commits...
<spiv> Merwin: "bzr branch --stacked", except there's bugs that make that much slower (and transfer more bytes) than it needs toi
 * spiv goes to pick up his kid
<Riddell> hola
<gour> jelmer: hello, any hint about this one: http://pastebin.com/4Wp3nr3H
<vila> English experts, what means 'not wild' in 'Not wild this is added for all tests regardless of the flags.' ?
<jelmer> vila: I think it's short for "I'm not wild about X" (I'm not enthusiastic about it)
<vila> jelmer: makes sense, thanks
<jelmer> gour: It means bzr-git found an error trying to create an object from scratch again - the resulting object didn't match the sha it expected
<jelmer> gour: bzr-git is now a fair bit more pedantic about it, older versions got it wrong in some situations
<spiv> vila: FWIW, I agree with jelmer about "not wild"
<vila> spiv: great, yeah, made sense, never encountered that usage before and I was wondering if it was a typo...
<vila> I thank mgz (and you guys ;) for teaching me more sophisticated English ;)
<fullermd> Nah, if it were a typo, you'd have intuitively understood it   ;p
<Riddell> how many hours does it take to do a branch of emacs?
<jelmer> Riddell, jam probably has some experience with that..
<jelmer> it used to take quite a while, I'm not sure if that's changed with 2.4
<gour> jelmer: so, there is no workaround to update the repo?
<jelmer> gour: no, you'll have to create a fresh clone
<vila> fullermd: hehe
<gour> jelmer: ok. i did it
<jam> Riddell: from gnu or from lp?
<jam> AIUI it is quite a bit faster from lp
<nooga> hi
<jelmer> hi nooga
<lifeless> vila: subunit-sum could go in subunit ;)
<nooga> i've created new project on my laptop and i'd like my friend to co-work with me via local network
<nooga> how do i allow him to access my branch and make changes?
<jelmer> nooga: if you give him ssh access, he can use bzr to make a checkout if you both have write access to the bzr branch
<vila> lifeless: thanks, that's the middle-term plan, I don't want to wait for it to be released to be able to use it (and there may be some tweaks required to land in subunit which may break the way I intend to use it)
<nooga> so i need to make a user account for him in my system and let him log in via ssh
<jelmer> nooga: just sftp access or the ability to run the bzr command should be sufficient
<vila> lifeless: one concern raised by jam (for example) is to use a single 'counter' dict detail (including all counters) in the subunit stream instead of one detail per counter, what's your feedback on that ?
<jelmer> nooga: After that, he should be able to run something like "bzr co sftp://yourlaptop/path/to/bzr/dir" or "bzr co bzr+ssh://yourlaptop/path/to/bzr/dir"
<vila> jam: cicp-add approved, can you land it ? I'd like to include it in 2.4b4
<vila> jam: oh, forgot to mention in th review: line too long :-}
<jam> vila: copied from a line that was too long, but I can try to fix
<vila> hehe
<jam> vila: re-wrapped, and sent to pqm, you just have to wait for the backlog (and hope there aren't NEWS conflicts)
<jam> in the test suite now, I guess
<vila> jam: yeah, so no news conflicts
<psynaptic> hey
<psynaptic> I have done it again
<psynaptic> merged trunk into my working copy with changes
<psynaptic> is there an easy way to fix it or do I have to manually edit each file?
<psynaptic> I know I could shelve each hunk, but that assumes they are not mixed changes
<jam> vila: landed
<vila> jam: yup, saw it, I'm having an issue with an added test for selftest-config-stats I can't reproduce locally though :-/
<jam> sorry to hear that, bbiab
<vila> jelmer: do you have other landings planned ?
<vila> ha crap, I'm pretty sure this is an outdated subunit/testtools combo on pqm :-/
<jelmer> vila: nope, nothing important in the queue for bzr.dev
<vila> jelmer: ok, I'll cut 2.4.b4 as  soon as I sort this mess out, better if pqm is free for that :0
<psynaptic> git rules
<Riddell> basic python question, I'm running a for loop over a method which returns names, what's a good way to count the number of times each name is returned?
<vila> Riddell: without more context, I'd go with a dict of names -> number of occurrences
<Riddell> vila: but if I do mydict[name] += 1 then it fails on the first time because mydict[name] doesn't exist yet
<vila> yeah, that sucks :) except KeyError: mydict[name] = 1
<james_w> .setdefault()
<james_w> mydict.setdefault(name, 0)
<james_w> mydict[name] += 1
<james_w> or use defaultdict if it's in the oldest Python you support
<vila> ha right, I knew it somewhere in the back of my head but it refused to pop up ;)
<james_w> that's what I'd do at least
<Riddell> groovy, thanks james_w, vila
<Noldorin> can someone please clarify the differnce between a repository, branch, and working tree? are these meanings universal between VCSs?
<maxb> They are roughly universal in core concepts, but they often have rather different UI
<maxb> A repository is a place in which history is stored on disk.
<maxb> A branch is a representation of an ongoing line of development
<maxb> A working tree is an area on disk where new revisions are prepared before committing
<maxb> Bazaar repositories are *really* only about storage
<maxb> Mercurial and Git repositories also behave as a container for a set of branches - whereas Bazaar's container for a set of branches is "Your filesystem"
<amdahlj> Hi, does anyone know if it is possible to call the visual diff viewer in bazaar explorer from command line?
<amdahlj> rather than the standard command line output you'd get just by calling bzr diff
<amdahlj> does anyone know if it is possible to call the visual diff viewer in bazaar explorer from command line?
<Buttons840> if i init-repository with --no-trees   then the branches will not have working trees, but i'm not sure what this means?
<amdahlj> pretty quiet in here so far buttons, I'm taking a look at your question though
<Buttons840> well, basically my question is just "what is a working tree"   i've read the docs and help but i'm not understanding
<Buttons840> just a conceptual question
<jelmer> amdahlj, I think you're looking for "bzr qdiff"
<amdahlj> thanks jelmer
<amdahlj> will try it out
<amdahlj> Yes, you are right jelmer, thank you very much
<jelmer> Buttons840, a working tree is an area with the actual files in it so you can prepare a commit - I think somebody else explained it well earlier:
<jelmer>  A repository is a place in which history is stored on disk.
<jelmer>  A branch is a representation of an ongoing line of development
<jelmer>  A working tree is an area on disk where new revisions are prepared before committing
<jelmer> (from maxb)
<jelmer> if you want to be able to edit files, you need a working tree
<Buttons840> jelmer: so how is --no-trees even possible; that's like saying "don't allow changes to repository" or "don't allow changes to the files on the disk"   at least, that's my view
<jelmer> Buttons840: You can still push revisions into or pull revisions out of a branch without a working tree
<jelmer> Buttons840: --no-trees is useful if you have a server where your history is stored, but where you don't do direct editing
<Buttons840> so what information is stored in a working tree? i though no information was stored until i commit?
<Buttons840> thought*
<jelmer> Buttons840: no history exists until you commit
<jelmer> Buttons840, the files in the working tree that have been added with "bzr add" are in the working tree
<jelmer> Buttons840, say you want to store a file named "README" in a bzr branch
<jelmer> Buttons840, only in a working tree would that file actually exist in the file system so that you can open it with your editor
<Buttons840> ok, that makes more sense
<Buttons840> thanks
<Buttons840> are there branch naming conventions i should conern myself with?
<jelmer> Buttons840: not really
<MarkAtwood> how come running "bzr log -r-3..-1 lp:myproject" downloads half a meg, slowly, from launchpad?
<jelmer> MarkAtwood: it's not a very well optimized code path,
<MarkAtwood> does it pull down the entire changelog over the network, and then just display the 3 most recent entries?
<jelmer> it's also a fair bit better in newer versions of bzr, though still not as quick and efficient as we'd like
<jelmer> MarkAtwood: no, it's more efficient than that but it falls back to reading some of the actual files in the repository rather than streaming just those three entries
<MarkAtwood> Bazaar (bzr) 2.2.1
<MarkAtwood>   Python interpreter: /usr/bin/python 2.7.0
<MarkAtwood>   Python standard library: /usr/lib64/python2.7
<MarkAtwood>   Platform: Linux-2.6.35.9-64.fc14.x86_64-x86_64-with-fedora-14-Laughlin
<MarkAtwood> ok
<jelmer> The initial wait of a few seconds for every connection to Launchpad is a bug in Launchpad that jam has been working on
<jelmer> the speed will improve further as we implement more calls in the smart server directly
<MarkAtwood> ok
<MarkAtwood> this is a pattern i use a lot, because i coordinate the merges from suggested merges into lp:drizzle/build then lp:drizzle/staging and then finally lp:drizzle
<MarkAtwood> and so im always "peeking" at the top of the log for each of those, to keep track of where I'm at
<MarkAtwood> lp:drizzle/build and lp:drizzle/staging are picked up and ground up by our Jenkins array
<briandealwis> Hi everybody.  I'm using bzr 2.4b2 & bzr-svn 1.1.0dev.  I'm trying to set up a custom layout for bzr-svn.  The setup is almost like "trunk", where branches are found under branches/ but the actual trunk is in trunk/product.  Adding "branches = branches/*;trunk/product" to my subversion.conf leads to an error when I try 'bzr svn-layout URL': bzr: ERROR: <bzrlib.plugins.svn.remote.SvnRemoteAccess object at 0x12f3bd0> does not support co-located 
<briandealwis> I tried wiping out my ~/.bazaar/svn-cache to no avail
<jelmer> briandealwis, hi
<briandealwis> hi jelmer
<jelmer> briandealwis, can you post the full backtrace?
<briandealwis> sure, hold on
<briandealwis> jelmer: http://pastebin.com/wu9RGZNw
<jelmer> briandealwis, is it just "bzr svn-layout" or do other commands give this as well?
<briandealwis> Hmm, good question: I hadn't tried.  But trying to branch the trunk seems to work.
<briandealwis> jelmer: huh, and 'svn-layout URL/trunk/product' works
<briandealwis> as does 'svn-layout URL/branches/<<branch-name>>'
<briandealwis> but 'svn-layout URL/branch' or 'URL/trunk' fails
<jelmer> briandealwis: Looks like it's just invalid handling of a particular exception at the moment
<jelmer> briandealwis: can you file a bug about this?
<briandealwis> will do
<briandealwis> thanks jelmer
<jelmer> thank you :)
<santagada> there is really no bzr record/staging?
<santagada> I have to shelve everything and then unshelve and commit?
<jelmer> santagada: hi
<jelmer> santagada: yes
<santagada> jelmer: is there any plans to implement something like the hg record extension?
<santagada> I just want to filter my commits
<jelmer> santagada: What does hg record do?
<santagada> jelmer: I think it is mostly the reverse of what shelve do, the same as git interactive commit
<santagada> jelmer: it asks if you want to commit each piece of a file/the whole file
<santagada> jelmer: very simple and makes me wonder why bzr has only the inverse (shelve)
<santagada> well it is useful, if you want to test each patch before commiting
<amdahlj> is there an easy way to exclude a particular file from qdiff?
<amdahlj> something like -x for commit
<jelmer> santagada: I don't think there is anything like that (yet)
<poolie> hi all
<vila> poolie: hey !
<jelmer> 'evening poolie, vila
<vila> jelmer: _o/
<poolie> vila, thanks for updating all the bugs
<poolie> closing the closed ones, i mean
<poolie> not just today
<vila> poolie: hehe, -w option on check-newsbugs is a treat :)
<poolie> is it?
<poolie> is that for --write?
<poolie> tnhat's cool
<vila> --webbrowser
<vila> when they are all opened in tabs, it's really easy to update them
<poolie> i think we talked at the sprint about systematic release naming
<poolie> i think we should
<poolie> i noticed openstack are doing this too
<vila> really ? I may have missed that one
<vila> you mean, giving names to bzr releases ?
<poolie> yes
<poolie> at the moment the naming's a bit arbitrary
<vila> hmm
<poolie> i think we talked about matching the letter of the ubuntu release they synchronize with
<vila> you're ~2h late for 2.4b4, or are you thinking about the series instead ?
<vila> ha, right series then
<vila> well, I'd like that too, if only to make references simpler
<poolie> the series
<poolie> and/or the final release
<poolie> i don't think betas need names
<vila> yup, nor point releases
<poolie> so we need a scheme
<poolie> perhaps famous markets in the world
<vila> haaa, worth searching a bit
<poolie> or islands
<poolie> needs something with reasonable coverage of every letter
<vila> yup, well, at least the remaining ones ;)
<Riddell> what island begins the O?
<poolie> Oahu?
<poolie> or Old Spitalfields, as a market (according to wp), though the 'Old' is cheating a bit
<Riddell> Oronsay
<Riddell> I'm not convinced the world has that many famous markets
<poolie> there's a lot of Oronsays apparenttly
<poolie> yeah, that is a bit of a problem
<poolie> using a scottish one would be nice
<Riddell> I agree :)
<Riddell> Orkney, Outer Hebridies
<Riddell> Oigh-Sgeir, could start a trend of hard to pronounce ones :)
<jelmer> Riddell, :)
<vila> ok, 2.4b4 frozen, uploaded, already fixed ... and babune on its way to turning blue again (including OSX !) leaving only windows as the ugly duckling ;)
<vila> that was quite a day (including my elder daughter starting her final exam and generating a lot of stress across the whole family ;)
<vila> so, have fun guys and see you tomorrow, well, in a few hours
#bzr 2011-06-17
<CarlFK> bzr revert -r 0; bzr pull - will that get me current rev?
<CarlFK> I was doing some revert's looking for a bug, now i need to get back to 'trunk
<fullermd> Highly doubtful.  What's wrong with just 'revert'?
 * fullermd isn't really here, just dropping by...
<CarlFK> revert did stuff.  pull says "No revisions to pull." - did revert get the new commits ?
<poolie> good luck to her, vila
<poolie> CarlFK: 'revert -r 0' will take you back to an empty tree, which is strange
<poolie> if you just want the currenty tree, use plain 'revert'
<CarlFK> that's what I need.  thanks
<poolie> thanks for the release, too, vila
<simosx> Is there a page with git + bzr equivalent commands? I want to perform a 'git reset --hard' in bzr and am looking for the command.
<vila> simosx: I don't know any such page. What does reset --hard ?
<vila> maxb: regarding bug #795703, this is what I meant http://paste.ubuntu.com/628306/
<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
<vila> Riddell: _o/
<Riddell> good morning
<Riddell> today is a good day to code
<vila> :)
<simosx> vila: 'git reset --hard' will reset any modified files to the repository initial state.
<simosx> vila: what I want to do is to reject my repository modifications (which were not committed) so that I can start over.
<vila> simosx: both the working tree (file content on disk) and the branch pointer (where should the history start) ?
<vila> ha, right, so just 'bzr revert' then
<vila> check 'bzr help revert'
<maxb> Hi vila
<simosx> vila: thanks, it worked!
<vila> hey maxb ! Trying to clear the pi queue a bit
<maxb> For me, the main reasons I did not want to add any helpers to the udd branch for bug 795703 are: I don't want to write a general tool when I'm uncertain of the need, and, the intent of my changetag and removetag definitions is clear even without looking at the implementation
<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> I have decided to not care about the pi queue until bug 797008 is fixed (Monday)
<ubot5> Launchpad bug 797008 in cgal (Ubuntu) "Sync cgal 3.8-1 (multiverse) from Debian unstable (non-free)" [Wishlist,Fix released] https://launchpad.net/bugs/797008
<vila> maxb: I got that, read my last comment ?
<maxb> uh
<maxb> bug 797088
<ubot5> Launchpad bug 797088 in Ubuntu Distributed Development "Launchpad has removed privileges that UDD importer requires to function" [Critical,New] https://launchpad.net/bugs/797088
<vila> maxb: ha, right, it's needed to change the tags too ?
<maxb> Well, in most cases, changing the tags will allow a formerly broken import to proceed, which will most likely result in it wanting to create new branches
<vila> bah, yeah, of course
<maxb> That's only a "likely". Some of them could probably complete successfully
<vila> ok, anyway, my point is not to write a generic tool but to focus on avoiding user errors, you know, the kind that happen when people make tyops
<vila> and also collect data about how we fix issues in a more central place than the bugs
<vila> maxb: so, the script I pasted above is intended to be sourced so 1) we/I don't have to remember to set PYTHONPATH, BZR_PLUGINS and so forth each time I need to issue such a command, 2) collect the patterns
<vila> maxb: any feedback before I propose it or should I just fdi ?
<maxb> Re typos - what extra checking were you envisaging in this case?    Re data collection - I agree recording repeated failure cases is good - but I don't think changetag and removetag scripts would accomplish that.
<maxb> Uh, what paste? I don't see it
<vila> grr, damn xchat
<maxb> oh, now I do
<maxb> just way up ^^^^^ there
<vila> ha, good, I thought I forgot to type enter somewhere
<maxb> hmm
<maxb> OK, I have several different observations about that
<maxb> One, I really dislike that the various python scripts require certain environment variables to be set to work properly
<maxb> My preferred way to address that would be making them not require that, rather than adding wrappers which set those envvars
<maxb> A number of the scripts already contain sys.path manipulation towards this goal
<vila> yeah sure, I agree with that but practicality beats purity, I want a working solution *now*, I sear I want to make it right later
<vila> s/sear/swear/
<vila> And I really mean it
<maxb> Two, do ubuntu: and debianlp: work from jubany? Plain lp: does not, which is why I've been writing all commands in bug reports as bzr+ssh://bazaar.launchpad.net/+branch/ since the London sprint
<vila> hence my efforts around pkgimport.conf. Your refactoring of icommon goes in the same direction and I appreciate that
<vila> maxb: yes they do (at least they appear to for 'bzr tags')
<vila> maxb: I suspect it depends on the commands. Did you already tried for 'tag' ?
<maxb> hmm.... but, are they giving you a readonly http transport?
<vila> dunno, certainly the same behavior than for lp:, that can be fixed easily in fixit.sh and we should fix it in bzr too (but we'll always lag on jubany which is still using 2.3)
<maxb> Additionally, I do not like ubuntu: and debianlp: - it feels very unnecessary to introduce yet another syntax. Especially for debianlp: which saves only one character over lp:debian/
<vila> maxb: implementation detail ;)
<vila> ha no, it leaks in the echo's
<maxb> OK, I have more to say about implementation details, but only that
<vila> no no, keep going, I'll fix that
<maxb> For example:
<maxb> * If it is intended to be sourced, it should not have a #! line
<vila> !
<maxb> * Using == inside a shell [ a == b ] is a bashism, so I try to always write [ a = b ]
<maxb> * I'm quite picky about my shell quoting, and in this case $@ is not sufficiently quoted - should be "$@"
<vila> maxb: but isn't that forbidding adding more flags ?
<maxb> No, "$@" is magic, and expands to multiple arguments
<vila> wow, in all shells ?
<maxb> In all shells likely to be encountered in a modern Linux distribution :-)
<vila> ok
<vila> about being picky, why don't you use ${xxx} instead of $xxx ?
<maxb> Why would I use a longer syntax if the shorter one is completely equivalent :-)
<maxb> I am picky about quoting just in case my variables ever end up containing spaces or shell metacharacters in their values
<maxb> However, the use of braces around a variable or not is verifiably right or wrong just by looking at the code, without having to consider variable values
<vila> right, but it means it's not completely equivalent indeed :)
<vila> fair enough, we have the same concern about different cases ;)
<vila> maxb: we probably want to restart mass_import next time we pull on jubany. Not strictly needed but I dislike running code that is not on disk anymore
<maxb> Yes... I have not pushed that point because I'm still moving stuff around even more
<vila> maxb: ok, keep going ! ;) That was just a reminder for all parties involved ;) We need a losa to restart it
<maxb> !?
<maxb> really?
<maxb> That seems.... silly
<maxb> Especially given we don't need a LOSA to stop it
<vila> well, that's the way it is...
<maxb> Blah
<vila> Don't get me started on that :)
<maxb> I'm glad my workplace is much better about not blocking people on an overworked subset of people with root@
<maxb> Hmm. technically we could stop mass_import.py and restart it. Just not via sysvinit :-)
<maxb> Aaaanyway....
<maxb> Why do we need to run the imports with LANG="en_GB.UTF-8"?
<maxb> Is it just in an attempt to make bzr happy about unicode filenames?
<maxb> Because it doesn't seem to actually accomplish that
<vila> probably, the locale is not set otherwise
<vila> huh ?
<maxb> When I retried the import of the UnicodeDecodeError failures, approximately one third completed successfully for me locally
<vila> ha, well, running with an appropriate local doesn't mean there is no more unicode bugs in bzr ;-}
<maxb> I'm fairly sure I was using bzr 2.3.3 at the time
<maxb> Isn't jubany on that too?
<vila> 2.3.1
<maxb> hmm
 * maxb afk ----> office
<vila> maxb: have a nice day and thanks for the feedback
<maxb> you're welcome - looking forward to a nice decrease in the failure count come Monday
<jelmer> vila: hah, you noticed the extra self.debug() too
<vila> jelmer: well, while validating the release for once and when babune turned red, yes, I noticed ;0)
<vila> jelmer: I'm cursed. This happens *only * when I don't run the tests just one last time to be sure ;)
<jelmer> vila: :)
<jelmer> vila: I patched it out in the Debian packages (just uploaded)
<fullermd> Well, if you ran the tests one fewer time, it wouldn't turn red   :p
<vila> jelmer: because you *had* to or just because you noticed ? (And yes, I thought about builds and was wondering which testtools versions were in the wiled)
<vila> fullermd: hehe, babune has its own life, I'm only serving it ;(
<vila> rhaa :-)
<fullermd> Vger seeks the Creator?   :p
<jelmer> vila: I had to, Debian has a newer version of testtools
<vila> fullermd: hehe
<jelmer> vila: thanks for doing the release btw
<jelmer> vila: There are a few more failures on the debian buildds because of missing homedirectories
<jelmer> vila: this seems to happen every other release; would it perhaps be possible to have a nonexistant home directory on one of the babune slaves?
<vila> jelmer: yeah, that's a deeper issue but one we may consider to be an isolation one
<vila> jelmer: hmm, no ${HOME} at all will be tricky to setup, but running with HOME unset may be doable
<jelmer> vila: With $HOME set to a nonexistant directory perhaps?
<jelmer> that's what happens on the buildds at least
<vila> trying locally this fails early with: failed to open trace file: [Errno 2] No such file or directory: '/foobar/.bzr.log' :)
<vila> ok, with BZR_LOG set it's running
<vila> jelmer: hmm, but no failures...
<jelmer> vila: whoa, it's already done running the testsuite?
<vila> Ran 26750 tests in 212.707s
<vila> re-trying without BZR_PLUGIN_PATH (since HOME is invalid there are no plugins there) shouldn't be different but let's see
<jelmer>   File "/build/buildd-bzr_2.4.0~beta4-1-i386-H_tSaY/bzr-2.4.0~beta4/build/lib.linux-i686-2.6/bzrlib/tests/__init__.py", line 2164, in _subprocess_log_cleanup
<jelmer>     with open(log_file_path, 'rb') as log_file:
<jelmer> IOError: [Errno 2] No such file or directory: '/home/buildd/.bzr.log'
 * vila checks /foobar really doesn't exist
<vila> ARGH, it catches plugins installed system-wide, qbzr windows all over the screen  8-)
<vila> right, but still no failures related to HOME (if I remember correctly the failures expected from qbzr)
<vila> jelmer: summary: I can't reproduce. Wth is going on then ?
<vila> jelmer: did you fix some of those (then how) or are you just ignoring them ?
<jelmer> vila: I'm trying to reproduce it here as well but failing
<jelmer> https://buildd.debian.org/fetch.cgi?pkg=bzr&arch=i386&ver=2.4.0~beta4-1&stamp=1308309988&file=log is the log from the buildd
<jelmer> HOME is set to something that doesn't exist, and we override BZR_HOME to point at something that does exist
<vila> lol, I didn't see "graphical" boxes like that for... 20 years ? :D
<vila> ...and clearly there are nicer that all the fancy stuff kids use today...
<jelmer> vila: :)
 * jelmer still remembers the "Alt" numbers for generating most of those
<vila> jelmer: hey ! But this is running with BZR_HOME=debian/bzrhome (I won't mention -user in BZR_PLUGIN_PATH ;-p)  how come we end up with /home/buildd ...
<jelmer> vila: /home/buildd is the home directory of the user that runs the process (a path that doesn't actually exist)
<vila> I got that, but... isn't BZR_HOME supposed to override HOME... or is it only for .bazaar ?
<vila> jelmer: this sounds like a genuine bug to me, you should file one (ot three) ;)
<vila> trace._get_bzr_log_filename() respect BZR_LOG and BZR_HOME (unless none is set in which case it fallbacks to os.path.expanduser('~') which may do the wrong thing here
<jelmer> vila: I think BZR_HOME is only for ~/.bazaar
<vila> jelmer: no, just checked ;) see ^^
<vila> jelmer: this one is really puzzling... I can imagine that the log file is recorded in the cleanups even if it's not written too but I can't find an explanation for the wrong path...
<vila> jelmer: i.e. it may that the fix is simply to catch NoSuchFile but that will be masking a deeper issue...
<vila> like a test isolation bug *except* that TestExceptionReporting directly inherit from TestCase where we unset HOME...
<vila> BAH !
<vila> Stoopid vila !
<vila> repeat after me: you should never use TestCase if you need disk resources !
<fullermd> Hm.  So, if I removed all the TestCase's in my local bzr, I'd have more disk resources?
<vila> right, especially under /tmp ;)
<vila> jelmer: didn't we allow trace.mutter() and friends to fail silently recently ?
<vila> jelmer: did you file a bug or should I ? I still don't understand how we end up with a bad path, but I see why we end up with a path
<jelmer> vila: I think the problem really is in the cleanup code
<vila> jelmer: there is an isolation issue escaping me but there are already bugs to fix that will address your problem
<vila> partly
<jelmer> vila: which requires the path to always exist - previously it used a testtools method which didn't as far as I can tell
<vila> well, the issue is that it capture a path that is not used and fail to catch NoSuchFile, that's one bug
<vila> a second one is that some test use TestCase when they really want TestCaseInTempDir at least
<vila> a third one is this bogus path
<vila> for the first one, I'm not sure we should check the file exist (at that doesn't mean it won't be written to later by the test)
<vila> so we may want to catch NoSuchFile, *but* that will mask the other two which is bad
<jelmer> hmm
<jam> hi all, I just uploaded the bzr-2.4b4-1-setup.exe
<jam> anyone care to give it a quick spin so I can see if it is good enough to shut down the build machine?
<fullermd> You need to make some change and upload a new one.  It's _sooo_ close to a palindrome...
<vila> oooooh, let's prey for a bug ;)
<jam> 2.4b4-2 is still not a palindrome
<vila> jam: did you remove the infamous self.debug() ?
<fullermd> Blech.  I only prey on things with fewer than 6 legs.
<jam> vila: I used whatever you tagged as 2.4b4
<jam> so probably not
<jam> we'd first have to change the numbering scheme
<jam> since 2.4b4-2 isn't 2.4b4.2
<vila> when I say it out loud I don't pronounce the dots ;)
<jam> vila: funny, I do. "two point four bee four dash one"
<fullermd> Dit, Dat, and Dot.
<vila> jam: that may have to do with a cultural thing :)
<jam> I might say "bzr two four"
<jam> but the b and final dash mess things up
<vila> s/[.-\/#/ ftw
<Riddell> jam: so you need a test of getting the file from launchpad and installing on windows?
<vila> crap
<vila> s/[.-]/#/ ftw
 * vila notes Riddell stepped up to build windows installers
<vila> :-P
<Riddell> test!  I said test!
<vila> I heard 'I can' and 'windows' :D
<maxb> aww
<maxb> You scared him away
<vila> LOL
<maxb> beta-ppa/natty uploaded
 * maxb goes in search of lunch before doing the other series
<vila> nahhh, he tried the installer while being connected on IRC, we'll soon get our emordnilap
<fullermd> It's a doubly fun palindrome, really, because even as you say it, you know that it's not really true that 2 4 is before 2   ;)
<vila> yeah, it will become true only for 2.4b4-25
<fullermd> Well, you never know...   it IS windows, so maybe we'll end up there  :p
<vila> yeah, you're allowed a few false starts when learning how to build them, definitely a sign for Riddell
<Riddell> jam: installs and working fine
<Riddell> windows is painful, takes 10 minutes to start up as it does updates setup, 10 minutes to log in as it does updates config then 10 minutes to shut down as it does updates install
<Riddell> given a revision id how do I get the revision number?  branch.revision_id_to_revno() doesn't work for commits from merged branches
<vila> . o O ( 15:08 - 14:47 = 21 minutes, 30 minutes lost in windows, ~10 minutes download + tests => Riddell *owns* a time machine, damn it !)
<fullermd> It's not really a time machine, just relativity.  Windows is so dense that when you get close to it, time slows down.
<Riddell> :)
<Riddell> I'm not convinced by the widget theme used by bzr explorer, it doesn't seem to fit in with much of windows, but maybe that's just normal for windows
<mdeslaur> I get bug #798688 with the bzr in natty-proposed
<ubot5> Launchpad bug 798688 in bzr (Ubuntu) "possible regression in natty-proposed" [Undecided,New] https://launchpad.net/bugs/798688
<jelmer> mdeslaur: hi
<mdeslaur> hi jelmer
<jelmer> mdeslaur: "bzr up" there works fine with 2.3.1?
<mdeslaur> jelmer: let me try, one sec
<mdeslaur> jelmer: oh, hrm, this is what I get with 2.3.1:
<mdeslaur> mdeslaur@mdlinux:~/uct/ubuntu-cve-tracker$ bzr update
<mdeslaur> Unable to obtain lock  held by sbeattie@bazaar.launchpad.net
<mdeslaur> at crowberry [process #31170], acquired 4 hours, 22 minutes ago.
<mdeslaur> See "bzr help break-lock" for more.
<mdeslaur> bzr: ERROR: Could not acquire lock "(remote lock)": bzr+ssh://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/
<mdeslaur> jelmer: much clearer
<jelmer> mdeslaur: ah, hmm
<jelmer> mdeslaur: thanks for the bug report
<jelmer> time to abort that sru I guess :-/
<mdeslaur> jelmer: I'll add that to the bug
<mdeslaur> jelmer: ok, thanks, I'll downgrade for now
<jam> Riddell: thanks for the sanity check
<jam> did you check that bzr+ssh worked?
<jam> (py2exe and setuputils don't get along very well, so every so often I forget to easy_install -Z and an updated package is removed from the installer)
<vila> jelmer: ok, got the bogus path explanation
<jelmer> vila: cool - what was it?
<vila> jelmer: BZR_HOME is set to None by the test (as does HOME) *but* os.path.expanduser('~') *still* returns it (probably from /etc/passwd or something)
<Riddell> jam: no, should I just try a checkout?
<vila> jelmer: so, using TestCase instead of TestCaseInTempDir is really the root cause
<jam> Riddell: just 'bzr info lp:bzr' is enough
<vila> jelmer: even if the symptom is confusing
<jam> just making sure that Paramiko is available
<vila> cough
<jelmer> vila: ah!
<vila> Riddell: make sure you did bzr launchpad-login or you will default to http
<vila> jelmer: I'm working on a patch
<jelmer> vila: great :)
<vila> jelmer: I just need a bug # ;)
<jelmer> vila: happy to file one
<vila> jelmer: confirmed, in posixpath the comments are lying like hell, even with HOME unset they access pwd.getpwuid(os.getuid()).pw_dir
<vila> jelmer: hmm, so the root root cause is a side-effect of spiv's clever trick to collect subprocess log files
<jelmer> vila: bug 798698
<ubot5> Launchpad bug 798698 in Bazaar " bzrlib.tests.test_selftest.TestStartBzrSubProcess test break if $HOME does not exist" [Medium,Triaged] https://launchpad.net/bugs/798698
<jelmer> vila: yeah, the use of "with" there suggests it was recently changed :)
<vila> switching to TestCaseInTempDir still sounds like the easiest path despite the cost (not that many tests impacted)
<vila> the funny thing is that (may be while reviewing it but recently anyway) I realized that *defining* run_bzr on TestCase was a bit weird as it's quite hard to run bzr without any disk access (config files, log files, etc)
<vila> but trying to move it to TestCaseInTmpDir revealed some valid use cases, so I punted. I should have tried harder ;)
<vila> jelmer: great thanks
<Riddell> jam: unable to authenticate to ssh host as use jr@...
<Riddell> I've no idea how to import my ssh keys into windows
<jam> Riddell: well, you may not have your key, but at least it didn't tell you it couldn't try
<vila> jelmer: hehe, now that I'm fixing the bug, I *can* reproduce it :D
<vila> bah
<Riddell> groovy
<jam> Riddell: I could walk you through it if you care, but that is enough of a test for what I needed
<Riddell> then I don't care :)
<vila> with a first fix (wrong obvously :), I reproduce the bug
<vila> haaaaa, finally, I understand...
<vila> jelmer: except for your build, the tests were succeeding because they wrongly grabbed ~/.bzr.log
<vila> so we need to catch NoSuchFile after all _/
<vila> :-/
<jelmer> vila: ahh :-/
<vila> owwww, to add insult to injury, I now find: XXX: Testtools 0.9.5 doesn't have the content_from_file helper which is why I ended up leaving a self.debug() yesterday >-/
<vila> jelmer: do you have a way to reproduce or do you need a true release to do that /
<vila> ?
<jelmer> vila: I don't really have a way to test other than to do a new upload to Debian
<jelmer> vila: (doesn't have to be an upstream bzr release)
<vila> right, so the fix is at lp:~vila/bzr/798698-bogus-log-files but needs polish
<vila> jelmer: there was really two bugs: test_exceptions needs a log file (I still don't know how it can succeed without one, I suspect we tolerate having no .bzr.log file)
<vila> so it should use TestCaseInTempDir
<vila> TestStartBzrSubProcess ~stubs run_bzr, so it should inhibits _subprocess_log_cleanup (totally avoiding the issue)
<jelmer> vila: Thanks
<vila> waitase
<jelmer> hmm?
<vila> use revno 5987
<vila> TestStartBzrSubProcess can still use TestCase
<vila> jelmer: now to write test for that....
<vila> jelmer: I think you were right from the beginning, having a build slave may be the easiest (surprisingly ;)
<vila> I need a setup where the user exist but has no home but it still able to run selftest 8-)
<workthrick> hiya, what's the place I'm supposed to dump extra libs in for the win32 standalone bzr?
<workthrick> ahh, it was plugins/$plugin/_lib as I thought, it's just that bzr branch lp:dulwhich does not result in a pure lib directory structure
<jelmer> hi workthrick
<workthrick> hey jelmer
<workthrick> I was a tad busy and didn't really have the time to work on git-fileids
<Riddell> jamesh: could you take a look at the bzrlib/gpg.py verify method I added sometime, to make sure I'm using gpgme in a sane way?
<maxb> jelmer: Hi. At some point between pushing 2.4.0~beta4-1 and -2 today, you somehow moved the 2.4.0~beta4-1 tag to a revision that is not in the alioth branch
<maxb> jubany request - please requeue_package.py euca2ools
<maxb> flacoste has changed stuff that should allow the importer to create *Debian* official links now (but not Ubuntu until the next deploy)
<james_w> maxb, done
<maxb> looks like it has successfully pushed back :-)
<maxb> requeue_package.py bootchart clementine cqrlog extundelete fonts-oldstandard gerris glade gnome-desktop3 gtksourceview3 haskell-cookie haskell-cryptohash haskell-lambdabot-utils haskell-largeword haskell-monadrandom haskell-ranged-sets helium hunspell-ml jalv jcaptcha key-mon letodms libirc-utils-perl libjemmy2-java libnet-dropbox-api-perl libpam4j libsocket-linux-perl localizer openvrml php-letodms-core python-coverage-test-runner python-llfuse r-b
<maxb> ioc-edger rt-extension-assettracker ruby-activeresource-2.3 ruby-activesupport-2.3 ruby-git ruby-highline ruby-hoe ruby-rails-2.3 ruby-shoulda skytools3 virtualbox xyscan
<maxb> ^ the rest of the ones which have a good chance of succeeding now
<james_w> is it r-bioc-edger in the middle there?
<maxb> yes
<maxb> curse silly protocols with arbitrary length limits :-)
<james_w> done
<james_w> we should really make this a push button that you can press :-)
<maxb> Hmm... maybe - usually a requeue alone is not enough though
<maxb> I'd have to become a core-dev first :-)
<james_w> yeah, I don't think we could easily get rid of shell access completely, but if you could trigger requeue_package calls it would be a start
<maxb> Hmm, so euca2ools failed again, but it seems to have updated the oneiric branch before it died, so I'm calling that a partial success :-)
<james_w> heh
<maxb> Hmm, I should make the status page display the result of SELECT COUNT(*) FROM commits
<maxb> To quantify the number of packages with branches sitting on jubany waiting to be pushed back, if only the pushback run would not die
#bzr 2011-06-18
<djzielin> hello
<djzielin> I am having a problem with bzr
<djzielin> I was doing a commit, and my internet went out.
<djzielin> now I can't get commit to work properly
<djzielin> I am trying to commit several code modifications.
<djzielin> so the upload should not be that long...
<djzielin> but when I do the commit, it just keeps going and going
<djzielin> uploading more and more
<djzielin> and then after about 40 mb it dies.
<djzielin> I just looked at the /srv/bzr/.../repository/upload directory
<djzielin> and it is filled up with my attempts to commit.
<jelmer> how does it die?
<djzielin> hmm
<djzielin> I think it a broken pipe
<djzielin> after running for a very long time (and uploading like 40mb)
<djzielin> but it has only like 45k in changes
<djzielin> so I'm not sure whats happening.
<djzielin> maybe its trying re-upload everything?
<jelmer> it might be trying to do something like that if it's repacking and you're using a dumb transport
<djzielin> should I just delete the most recent pack file?
<djzielin> I am using ssh for the transport
<djzielin> to do the commit
<jelmer> no, removing a pack file would presumably remove the history in it too
<jelmer> bzr+ssh, or sftp?
<djzielin> oh
<djzielin> its actually sftp
<jelmer> that might explain why it's slower - bzr+ssh should be quicker and use less resources
<djzielin>  I'm trying the commit again
<djzielin> its up to 30mb
<djzielin> (it uploads rather slow because I'm on a cable modem)
#bzr 2011-06-19
<brainwave_> anyone help me to use bzr to get ubuntu packages
<nicoulaj> Hi all
<nicoulaj> In "bzr status", paths are shown relative to the repository root and not the current directory, anyway to get rid of this ?
<jelmer> nicoulaj: hi
<jelmer> nicoulaj: I don't think there is something like that at the moment, but IIRC there is a bug report about it.
<nicoulaj> jelmer: this behaviour is really annoying :(
<rsingh> hello all: a quick question. I have successfully merged my code from my server, but my logs have not been updated on my desktop. The code was done on my laptop, and I pushed it to the server. Now i am on my desktop, and i successfully merged, but after bzr log, it only goes up to the last log i committed on this desktop. Is that normal? should i have expected all the logs i committed from the laptop as well?
<rsingh> My worry being that if I edit on this desktop and push, then I will lose all the logs documenting my work from the laptop...
#bzr 2012-06-11
<lahwo> hello. if ive got a main branch and ive branched off the main branched and made some commits in the branch i branched off the main branch, can i merge those commits back into the main branch but be selective about it?
<lahwo> make any sense?
<bob2> not really
<bob2> you can merge a prefix of the branch, but not random selections
<bob2> workarounds include: rebase/rewrite, cherry picking or just merging the whole thing
<lahwo> what's the command to cherry pick?
<bob2> you can probably guess
<bob2> I don't have bzr installed to check
<lahwo> all right, thanks
<gour> lahwo: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/adv_merging.html
<lahwo> gour, that's great
<lahwo> thanks to both
<lahwo> :)
<mgz> morning!
<gour>  /me is considering to switch to bzr (from hg), but it looks that 'survival guide' is not up-to-date mentioning looms (instead of pipeline) as MQ equiv.
<jelmer> gour: I think it might predate pipeline
<mgz> so, I use mq with hg, but I've never felt the need for an equivalent in bzr
<mgz> tend to use a combination of named feature branches and shelves instead
<mgz> which are just more painful with hg
<gour> i'd like to work on some patches and tweak them until they're ready for merge...possibly with the ability to combine several of them into one commit...what do you suggest?
<gour> mgz: how are you, in general, satisfied with bzr in comparison with hg?
<mgz> yup, but can't do a completely fair comparision I think
<mgz> bzr I use for a whole range of stuff, whereas hg I've just used on a couple of really projects, and not from the admin side
<mgz> so, python for instance, still involves me uploading a diff to their tracker
<mgz> which isn't very dvcs
<mgz> ^+big
<gour> i believe that bzr might be easier/safer to use for potential contributors of our projects (mostaly windows & mac users)...that's why we do not want to consider git at all
<gour> mgz: i believe that bzr should be good-enough for big projects as well
<mgz> gour: right, but with bzr I know to do shared repo+lightweight checkout for those, which isn't immediately obvious for beginners
<mgz> that said, mozilla had a pretty involved getting started doc with "do it this way", so there's no reason a project can't define workflows clearly for would be contributors
<gour> i wonder if we'd have real need for lightweight checkouts, although it seems they are needed for pipeline, but we need to read more about it
<mgz> it's mostly useful when you've got build artefacts that are expensive to regenerate and lots of pretty similar feature branches
<gour> what about colocated branches? (i still have to read about them...)
<jelmer> gour: they're not ready for production use yet
<gour> jelmer: they will be in 2.6?
 * gour is reading 2.6 docs
<jelmer> gour: the basics of colocated branches are present since 2.5 (the backend side of them, APIs, etc)
<jelmer> gour: not sure if 2.6 will have the finished UI integration
<gour> good, good...
<gour> mgz: is there anything you miss in bzr from hg?
<mgz> gour: nothing relevent, I'm rather envious of their installer though
<gour> mgz: heh, ok...being on linux no problem with installers :-)
<jml> what's the difference between supports_diff and supports_delta on LogFormatter?
<jelmer> jml: I think one is the file-level delta and the other the diff
<jelmer> jml: ("bzr log -p" vs "bzr log -v")
<jml> jelmer: ah, thanks.
<jml> jelmer: I'm trying to add a custom log formatter, but I can't seem to get it to be passed the diff.
<jml> even thought supports_diff = True as a class variable
<jelmer> jml: you might have to manually request it
<jml> Hmm.
<jml> jelmer: thanks.
<jml> although, hah, bzrlib.patches.parse_patches won't parse the diff that log creates
<jml> oh wait never mind
<jelmer> jml: what are you trying to do ?
<jelmer> hi Noldorin
<Noldorin> hi jelmer
<jml> jelmer: this: http://paste.ubuntu.com/1035548/
<jelmer> jml: ah, neat
<jelmer> jml: related, have you seen Colin's LOC counter script?
<jml> jelmer: yes, I believe I have.
<jelmer> cool
<jml> Hmm.
<jml> I don't think there's any good way to construct the command so that -p is not required.
<jelmer> jml: can't you manually request the diff if -p wasn't specified?
<jml> jelmer: oh, yeah, good point.
<jml> jelmer: heaps slower though.
<jml> I want a way in 'bzr log' to see all of the authors of a merged commit, ideally sorted by who authored the most revisions
<jml> this is to get around PQM marking itself as author & committer
<jml> I see there's an author_list_registry in log
<jml> but it only gets the revision, and I don't know how to go from that to the tree of merged revisions without a repository, and I don't know how to get a repository without implementing my own cmd_log
<jml> ah, got an example
<gour> i installed bzr-fast-import plugin, but attempt to import repo (from git) gives: "bzr: ERROR: Unable to import library "fastimport": bzr-fastimport requires the fastimport python module"
<jelmer> gour: you need to install python-fastimport too
<gour> plugin is listed as "fastimport 0.14.0dev"
<gour> ahh, ok
<jelmer> gour: (not the bzr plugin, but the python module)
<jml> actually, no, not an example :\
<jml> can I get a log report for a list of revisions?
<jml> hmm.
<gour> http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/gpg_signatures.html page says: "There is still a number of digital signature related features which are hoped to be added to Bazaar soon. These include bzr explorer integration and setting branches to require signatures." (bottom) is there any concrete plan in regard?
<lifeless> I don't believe so.
<lifeless> jml: what do you mean
<jml> lifeless: bzr log -r X, Y, Z to log revisions X, Y and Z
<lifeless> jml: ah, no. Our algebra is a range definer only.
<gour> lifeless: is there some roadmap for > 2.6?
<lifeless> I'm not sure TBH
<lifeless> Generally fix things, merge patches etc for sure; I don't know of specific big-ticket tasks though.
<gour> ok
<thomi> Hi, is there a way to get a 'bzr log' that shows all revisions that changed a particular line (or lines) in a certain file? something like 'bzr log path/to/file:10'
<thomi> I guess the problem is that line 10 will be different across revisions.
<mwhudson> thomi: do you want something programmatic?
<mwhudson> i think qannotate might let you do something like that interactively
<thomi> ideally, yes
<thomi> oh, let me see
<mwhudson> ah maybe it was gannotate...
<thomi> hmm, qannotate shows me the who made the last revision to a particular line
<thomi> but AFAICT doesn't let me search older revision for that line
<mwhudson> thomi: gannotate has forward and back buttons
<mwhudson> it follows logical lines though, not numbered lines
<mwhudson> i guess you could look at what it's doing in the source
<thomi> mwhudson: ahhh, thanks - that works perfectly
<thomi> \o/
#bzr 2012-06-12
<mgz> morning
<jelmer> moooin
<gour> morning all
<gour> any fish shell user here beign aware there is bzr completion for fish?
<gour> i used fish in the past, but there was none...then we switched to zsh (as well as to hg, fossil), but now we would like to have it for bzr
<mgz> could you adapt the bash-completion builtin plugin? and just alter the output script it generates.
<gour> i'll try...
<matsubara> vila, hi :-)
<vila> :)
<matsubara> vila, so, should I add something to bazaar.conf to make it agree with authentication.conf?
<vila> So, the lp plugin checks that the launchpad_username is the same than the one selected in authentication.conf
<vila> and the launchpad_username can (so far) only be defined in bazaar.conf
<vila> matsubara: are you issuing the bzr commands or do you rely on the jenkins plugin for that /
<vila> ?
<matsubara> the idea is that jenkins will run the command for me, but AFAICT it's just running bzr branch lp:<foo-branch>
<matsubara> and I'm issuing the commands with jenkins user to test things
<vila> matsubara: yes. I was thinking about adding -Olaunchpad_username to override bazaar.conf when needed, but if you can't provide that, that's a no go
<matsubara> vila, I can provide that to jenkins, yes
<matsubara> vila, but I'm getting an bzr: ERROR: no such option: -O
<jelmer> matsubara: older versions of bzr don't support -O unfortunately
<vila> ghaa, upgrade bzr ?
<matsubara> is it bzr branch -Omazabot lp:maza-server?
<vila> bzr branch -Olaunchpad_username=mazabot lp:maza-server
<matsubara> I have Bazaar (bzr) 2.4.1 installed there
<vila> yup, too old
<mgz> any reason not to straight up run bzr as a seperate user?
<vila> jenkins is the user I think and it needs the related access rights to write on disk
<matsubara> mgz, it's going to be run by the jenkins user
<matsubara> you're right vila :-)
<mgz> well, set BZR_HOME to a different dir with a whole different conf then?
<vila> 2.4.1 is weird though, 2.4.2 being out, what are you using to get only 2.4.1 (just curious, won't help here)
<vila> yeah, heavy workaround but would work and seems to be the only way to address the issue in the short term
<matsubara> vila, don't know. it was there when I got access to the machine
<matsubara> and I don't manage the machine, so I'd rather not upgrade the bzr client until I can talk to retoaded who manages the box
<matsubara> I'll try the BZR_HOME trick then
<vila> matsubara: alternatively, since the issue is in the lp plugin, you may be able to avoid the issue by using 'bzr+ssh://' urls instead of 'lp:' ones
<matsubara> vila, thanks for the tip. mgz's suggestion kinda worked. Now I'm having a public key denied problem and I think bzr is send the wrong key for authentcation
<vila> you used BZR_HOMR not HOME right ?
<matsubara> vila, yep
<matsubara> https://pastebin.canonical.com/67878/
<matsubara> vila, the output ^
<matsubara> is there a way to also define which ssh key to use?
<vila> matsubara: ssh -vv bazaar.launchpad.net
<mgz> also `BZR_HOME=maza-bazaar-conf/ bzr launchpad-login`
<vila> .ssh/config is still obeyed, not sure how to make ssh try several keys
<matsubara> vila, output of ssh -vv: https://pastebin.canonical.com/67879/, it's trying to use the default id_rsa, while I want it to use the maza_lp key
<vila> yeah
<matsubara> mgz, I ran that command already
<matsubara> and it returns mazabot as the user, which is the correct one
<matsubara> vila, .ssh/config: https://pastebin.canonical.com/67880/
<vila> ssh-add maybe
<matsubara> I just changed s/.launchpad/bazaar.launchpad.net/ in .ssh/config and it seems to be doing something. waiting on the output
<matsubara> aha! branched!
<vila> yeah, the leading '.' is an authentication.conf trick
<vila> *.launchpad.net should work in .shh/config though
<matsubara> but then bzr client will default to that key for everything else as well, won't it?
<vila> matsubara: and from ssh_config(1), you can have multiple IdentifiyFile directives so all keys are tried
<matsubara> hmm
<vila> yeah, you need an .ssh/config thta works for all your users
<vila> well, 'need' is a bit strong, but you get the idea
<vila> and you probably should remove the 'User' directive from .ssh/config and let bzr provide it
<vila> (that is, provide the user when attempting to connect and rely on .ssh/config to try the various keys until the right one succeed)
<matsubara> darn, apparently jenkins bzr plugin won't allow me to define a custom BZR_HOME
<mgz> jenkins doesn't let you just set an var for the environment of running an external command?
<matsubara> I'm trying to find out
<ccxCZ> can I make bzr shell not connect to the parent when using it in bound branch?
<ccxCZ> ah well I guess I can workaround it with cd /
<matsubara> mgz, vila: I'm going for lunch and will figure out how to teach jenkins to use custom env variables. thanks a bunch for your help!
<ricardo_> Hola, intento iniciar bazaar para version control system y no me permite configurar etckeeper.conf Â¿Que puedo hacer?
<jml> does bzr have a helper for printing tales?
<hazmat> does bzr support any form of revno expansion in a file?
<mgz> hazmat: see the bzr-keywords plugin
<hazmat> mgz, thanks
<mgz> generally you want to do something else in your build process though
<mgz> jml: I don't know what a printed tale would look like I'm afraid
<jml> sorry, I meant 'tables'
<fullermd> What, you've never read Chaucer?
<mgz> hm, no, 'fraid not in that case. python-novaclient uses something called prettytable but I don't think it's all that pretty.
<jml> mgz: thanks.
<mgz> I don't think I've ever read Chaucer pretty printed...
<mgz> just from photocopies
<mgz> was involved in a performance in the original language in a pub once though
<jml> hmm.
<jml> istr bzr had an easy way to get a dump for kcachegrind
<mgz> `bzr --lsprof-file something.callgrind command`
<jml> thanks.
<jml> yay
<jml> for those interested, I have been using your help to generate a high score table for lp:launchpad, where the score is lines of code added: http://paste.ubuntu.com/1037100/ is my latest cut.
<mgz> what are the prizes you're giving away? :)
<jml> mgz: dignity & honor.
<mgz> wallyworld certainly deserves something
<mgz> wooden spoon?
<jml> mgz: perhaps a leather-bound print out of all the lines he's added?
<jml> code is at lp:bzr-damage btw. Would appreciate any tips on how to do things better.
<leo2007> how to sync branches from upstream?
<leo2007> My current repo (emacs upstream) has the following branches http://bpaste.net/show/31321
<leo2007> which has not been updated for a while. upstream has created new branches. I want to bring my local branches up-to-date.
<jml> jelmer: are you responsible for bzr-stats?
<nilg`> hi, I have a question regarding private branch and collaborative work
<nilg`> suppose you have the trunk A, I branch A, do some commits to get B
<nilg`> during this time A got some commits too, and becomes A'
<nilg`> B is on a private branch, and the guys how owns that branch wants me to push his changes to the trunk (now A')
<nilg`> so I branch B, locally, rebase it from A' (bzr rebase TRUNK)
<nilg`> i push the stuff to the trunk, now A''
<nilg`> the guy who owns B, in between has committed some changes, so now it become B'
<nilg`> and he also wants to update in branch, so he rebase B's according to A''
<nilg`> but now the commits of B' that I've pushed on the trunk are duplicated on B''
<nilg`> how to avoid that problem?
<nilg`> thx
<vila> don't rebase
<vila> merge instead
<vila> by rebasing you're roughly saying: I don't care about what happened in branch B. When you later try to "merge" again, you do care. So if you want to track B, merge it.
<LeoNerd> Rebasing is a form of rewriting history. As with any rewrite, you need to be careful with it
<jelmer> jml: whoops, missed that earlier
<jelmer> jml: fsvo responsible
<jelmer> jml: the code was written by jam and myself
<eridu> is there a way to have a bazaar branch that maps to a git "branch" within a git "repo"? I'd like to use bazaar in a typical multi-directory shared-repo layout, but push to github.
<eridu> (it wasn't my choice to use github)
<ccxCZ> eridu: bzr-git plugin has git-import command for this
<eridu> ccxCZ: can I use the branches to push back to github?
<ccxCZ> (you need fairly recent bzr-git for git branches to work)
<ccxCZ> yup, or any git repo
<eridu> woot! thank you!
<eridu> (I was really worried I'd have to use git)
<Zoohouse> When I try to run bzr lp-propose-merge lp:gwibber --message=Submitting my edits of the docsctrings to the plugin files. If there's no problems with the edits and it's approved, I'll continue editing the docstrings within the GTK files. Nature of edits: converted current docstrings to Python's PEP 257 styles.  I get the following error: bzr: ERROR: extra argument to command lp-propose-merge: my
<Zoohouse> scratch the question. I needed quotes around the comment.
<evillyEvil> Is it possible to propose a branch for a merge without having to go to Launchpad?
<jelmer> evillyEvil: "bzr lp-propose"
<evillyEvil> jelmer: So do I still need to push the branch to launcpad first?
<evillyEvil> jelmer: Actually, I also got this error bzr: ERROR: No module named lazr.restfulclient.resource
<evillyEvil> You may need to install this Python library separately.
<jelmer> evillyEvil: yes, you'll have to install lazr-restfulclient
<jelmer> evillyEvil: you do indeed need to push the branch first (I think)
#bzr 2012-06-13
<mgz> morning
<BasicOSX> Is the bzr dev branch still at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev? I've been at revision 6524 for what seems like months
<mgz> BasicOSX: yup, a few things want mergin up from earlier series though
<jml> jelmer: oh right, so, bzr-stats
<jml> jelmer: I find myself working on similar stuff from time to time and am thinking of merging my similar stuff into it
<jml> jelmer: but I don't think I understand the code in bzr-stats very well.
<abentley> jelmer: I'd like to introduce my team-mates to native colocated branches.  Are there any docs?
<jml> there are no docs, there is only pain.
<abentley> jml: Is that specifically about colocated branches?
<jelmer> jml: okay
<jml> abentley: yes. I don't know of any docs.
<jelmer> jml: Contributions are welcome, I can also give you pointers if that would help.
<jelmer> abentley: I don't think they're ready for production use either yet; the API side is there, and some bits of the UI
<jml> abentley: and while I really like using them, they are buggy enough that I personally wouldn't recommend them strongly to another team mate.
<jml> jelmer: what's all this 'classify' stuff about?
<mgz> misspelling of the day: Ununtu
<jelmer> jml: In what way are they buggy? I would rather say they're unpolished
<jelmer> jml: It classifies files as documentation, code, translations, etc
<jml> jelmer: yeah, unpolished is better.
<jelmer> jml: It's used for the About dialog in bzr-gtk to give people proper credit
<jelmer> jml: See "bzr credits"
<abentley> jelmer: the main pain point for me is the lack of config support.  I want a way to map file://foo,branch=$BAR to lp:~abentley/project/$bar.
<jml> jelmer: ah ok.
<jml> jelmer: how does the collapsing work? I sort of understand collapse_by_person, but I don't think I get collapse_email_and_users. Should they be used in conjunction?
<jelmer> jml: I'm not sure, I think that was originally jam's code
<jml> jelmer: my motivating use cases are getting things like number of mainline commits by person since a date, or finding out how many lines of code have been added / removed per person. duplicate records are a pain there.
 * jelmer looks
<jelmer> jml: IIRC it groups by both fullname and email
<jml> jelmer: e.g. http://paste.ubuntu.com/1039164/ and the awful code in utilities/community-contributions.py in Launchpad.
<jelmer> jml: ah, I see
<jam> jml: the issue is that people often don't use the same user information over time. Especially in early bzr, and for people working on many different machines. So we try to figure out that john@arbash-meinel.com is the same as john@canonical.com or whatever. But also user's don't spell their name 100% the same, etc.
<jelmer> jml: I think the collapse code could definitely be useful there
<jam> like the jelmer in your example
<jml> jam: right, I think I understand the issue
<jelmer> maybe it would be worth putting into bzr core?
<jelmer> I think it already has a fair amount of tests
<jml> jam: but not how to go from "I have a list of usernames please make me something that maps them to a best guess of a list of people"
<jam> jml: well bzr-stats was my attempt at it, but I wrote that code ~5 years ago. So I haven't been thinking about it as much recently.
<jml> jam: heh, understood.
<jam> I know empty strings were a problem, as it ended up linking everything to me
<jam> since somewhere I committed with only an email address, or something like that.
<jam> Probably doing it as a 'these are some known mappings, try to find more' might be an interesting way to do it.
<jelmer> jam: I vaguely recall that was fixed since
<jam> jelmer: it was, hence *were* a problem.
<jam> I'm not sure if there were other edge cases that linked too much.
<jelmer> jam: sorry, English reading fail
<jam> but the "map username to all known email addresses" and "map email addresses to all known usernames", and then you can iterate that cycle until it converges.
<jam> jml: ^^
<jml> jam: thanks.
<jml> the other thing I want to do a lot is work around PQM claiming to own the merge commit
<jml> which is accurately done by assembling all of the authors of all the merged revisions
<jam> jml: you can argue that the merge commit isn't significant, vs the actual commits, so just ignore the PQM done.
<jam> jml: how do you get negative numbers in your list?
<jam> or is that LoC ?
<jml> jam: not if one of your metrics is 'how many changes landed on trunk' or if you want to answer 'what trunk changes have I landed since January'
<jml> jam: net LoC. Lines added - lines removed.
<jam> jml: sure, but then you should be ignoring all the individual commits, I think.
<jml> jam: it's motivated by the LP LoC-neutral change policy.
<jml> jam: I don't understand. How do you get "what trunk changes have I landed since January" without looking at individual commits in a PQM-managed branch?
<jam> jml: so if the revision is in the history, it has landed on trunk, right?
<jml> jam: I guess.
<jam> so if you want to split out "how many commits" from "how many features/branches have landed".
<jam> Then you probably want to go to each rev, and look at just the merged revisions. And attribute that to the individual authors (each gets +1 per pqm commit)
<jam> merge_sort is your friend there
<jam> while not mainline: authors.add(rev.authors)
<jml> ok. that makes sense.
<jam> jml: you're more than welcome to expand bzr-stats if it is doing what you want, and you are also welcome to propose merging it into bzr core (I think). It seems a bit waffley about accuracy of stats, which is why I would tend to put it in a plugin, but there has certainly been a move to put more in core.
<jam> anyway, EOD here, you can always email if you want more info
<jml> jam: thanks
<tedg> It was suggested that I look at Bazaar Keywords plugin: http://wiki.bazaar.canonical.com/KeywordExpansion
<tedg> But that seems kinda dead
<tedg> Is that part of the main Bazaar now or was it considered not a good idea?
<mgz> tedg: generally, there are nicer ways of doing what that kind of thing was used for in cvs/svn
<mgz> invoking bzr in your build script to get version and so on.
<tedg> The problem is I don't have a build script :-/  This is for getting a juju charm to have the same revno as the Bazaar repo it's in.
<tedg> http://askubuntu.com/questions/149553/how-do-i-make-a-juju-charms-revision-match-the-bazaar-revision-of-its-repo
<mgz> I did point hazmat at keywords for that kind of thing the other day
<mgz> have you tried it and can't get it to work, or are just worried about it?
<mgz> there may be juju-specific annoyances to work around, to do with how it deploys charms and what it installs on units
<tedg> I haven't tried keywords, it doesn't seem to be in Ubuntu and has no releases... so that, in general, makes me uncomfortable :-)
<tedg> Plus, I don't understand how things would work if someone didn't have the plugin.
<tedg> It seems like I'd be making my repo "ted only"
<tedg> So I was hoping the answer was "merged into mainline under a different name" :-)
<mgz> well, I suspect it straight up won't work as juju wants to run from branch effectively, and doesn't install any bzr plugins
<mgz> but having that and no way of pulling the revision from the charm is a little daft.
<tedg> I honestly don't know why they have "revision" at all -- seems like it'd be better to always pull it from the VCS, what ever that may be.
<jelmer> tedg: that doesn't necessarily work, since not all VCSes have sortable revision ids
<tedg> jelmer, All the ones that I care about do ;-)
<tedg> And, you *could* calculate it for others with some sort of plugin.  It'd be expensive, but eh.
<Han> I just got an out of memory error while running "bzr branch bzr://bzr.savannah.gnu.org/emacs/emacs-24"
<Han> This system has got 4Gb memory. What can I do to prevent that?
<jelmer> Han: what version of bzr are you using?
<Han> Bazaar (bzr) 2.4.2
<Han> Hoi Jelmer. :-)
<Han> It's a kind of a shame to download 120mb and to end up with nothing.
<jelmer> I was wondering if it was /the/ Han :-) hi!
<jelmer> 4Gb should be plenty; and AFAIK most of the memory improvements are already in 2.4
<lifeless> Han: are you running 32-bit or 64-bit? If 32-bit, then individual processes cannot use all 4GB (not that we should need to in this case...)
<Han> 64
<Han> I'm going to try the same command with 2.5.1, see what happens.
<jave> how can I revert all the changes to a file in a branch, so the file is same as upstream?
<pikkachu> hi, I'm getting this error when I try to branch from launchpad: http://pastie.org/pastes/4082141/text
<pikkachu> Bazaar 2.5.0, Python 2.7.3, Windows 7. Any help?
<mgz> pikkachu: looks like you have ssh problems, try `ssh -vv yourlpusername@bazaar.launchpad.net`
<pikkachu> mgz: I use PuTTY's plink (BZR_SSH=plink)
<mgz> ah, in which case, manually run `plink you@bazaar.launchpad.net` and accept the fingerprint
<jelmer> 'evening mgz, pikkachu
<mgz> then try again (you have BZR_SSH set to the location of plink, right?)
<pikkachu> good evening jelmer
<pikkachu> mgz, I have the impression it was working before, and that in my old windows I didn't need to do that :(
<mgz> ..just try it? I bet plink will complain about the fingerprint
<pikkachu> thank you mgz, it worked!
<pikkachu> not sure why it used to work before, but it's gone now
<mgz> presumably putty learnt it before but then forgot it again recently
<mgz> or you're being MITMed
<pikkachu> maybe in older versions of bzr/putty, it used to ask to add the server right there in $bzr branch
<mgz> nope, that never worked unfortunately
<pikkachu> hmm, then it seems my feeling I could branch before is just wrong, and I just had added the host manually before in my old windows with plink/whatever but can't recall
 * pikkachu searches for excuses to not think he's being mitmed
<mgz> well, I can see what the fingerprint I have, then you can compare with what you got for bazaar.launchpad.net
<mgz> $ ssh-keyscan bazaar.launchpad.net>/tmp/key && ssh-keygen -lf /tmp/key
<mgz> # bazaar.launchpad.net SSH-2.0-Twisted
<mgz> 1024 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89 bazaar.launchpad.net (RSA)
<mgz> you had:
<mgz> ssh-rsa 1024 9d:38:3a:63:b1:d5:6f:c4:44:67:53:49:2e:ee:fc:89
<mgz> so you're fine :D
<pikkachu> :)
<pikkachu> thanks all
<deepa> Hi, how does partial trees work?
<deepa> does it differ to partial checkouts in some interesting ways that miht make me not want to use it?
#bzr 2012-06-14
<Noldorin> hey folks
<Noldorin> d
<Noldorin> oe
<Noldorin> s
<Noldorin> oh dear. keyboard acting up again
<Noldorin> brb
<Noldorin> so, question was:
<Noldorin> what's the best way to install bar on mac presently?
<Noldorin> os x lion specifically
<Noldorin> i see the wiki page on it, but it suggests only python 2.6 supportâ¦ is this the best we can do still presently?
<Noldorin> ho hum
 * Noldorin watches the tumbleweed.
<wgz> pre-morning all
<mgz> morning all!
<vila> MorninGZ
<mgz> how is the nation of france?
<vila> sunny (for  a change)
<mgz> ha, and we have rain, where it's been a mostly fine earlier in the week
<vila> yup, it was the opposite here...
<Han> Is there a workaround for my memory predicament?
<Han> ~/nfs/Emacs% bzr branch bzr://bzr.savannah.gnu.org/emacs/emacs-24 -Dmem_dump
<Han> bzr: out of memory
<Han> Dumping memory requires meliae module.
<Han> Lets see what this does. http://stackoverflow.com/questions/2073643/bzr-svn-out-of-memory-error
<jelmer> Han: note that that approach is specific to bzr-svn, which fetches revisions from svn in an incremental fashion (as that's the only way for svn)
<jelmer> Han: how are you branching, using the http or bzr:// URL?
<jelmer> you might want to try the other
<Han> hmm idea... I just went browsing around a bit on bzr.savannah.gnu.org and then I found: http://bzr.savannah.gnu.org/lh/emacs/emacs-24/files =)
<Han> Let's see what happens.
<Han> bzr branch http://bzr.savannah.gnu.org/r/emacs/emacs-24
<Han> bzr: out of memory | Fetching revisions:Inserting stream:Estimate 759738/1232693
<Han> grrrr
<jelmer> Han: have you tried over bzr:// ?
<mgz> that's what he tried first. someone else also had the same problem with emacs last week, so it's clearly an ongoing issue.
<fullermd> Error: recursion detected  ;)
<mgz> it does feel a bit like our answer to OOM is try A, try B, try A
<mgz> if it's specifically that repo that's been bloated accidentally, getting it from a different place (we still have  a launchpad mirror?) would be fine,
<mgz> otherwise I'm not sure. a dumb copy of the data would work until the next big repack.
<Han> mgz, thanks for listening.
<mgz> Han: really you need help from one of the emacs guys
<Han> Makes sense.
<mgz> I'm not sure any of them hang out in here, but several pay attention to the bazaar mailing list
<Han> They should be found on #emacs I suppose.
<Han> In the meanwhile I commit herresy. ;-)
<WasserDragoon> hello everyone if i'm running bzr branch lp:egtk do i get the 3.1 release? https://launchpad.net/egtk
<WasserDragoon> development focus is 3.x series and last release is 3.1 so it seems i'm getting the 3.1 release when running bzr branch lp:egtk right?
<WasserDragoon> hm no when running bzr branch lp:egtk i'm getting the trunk code (507 revisions), last revision of 3.1 release is 491
<WasserDragoon> ok i was looking for bzr tag:... lp:egtk but where to look for the tag name? 3.1 isn't the tag name
<WasserDragoon> hm no there are no tags... i'm giving up now. pls help
<KombuchaKip> 'bzr checkout something Foldername' is how I checkout into Foldername. What's the equivalent for pulling into a new Foldername?
<KombuchaKip> Wait, no, that should be 'bzr branch something Somefolder'
<Noldorin> what's the easiest way to install bar on OS X Lion?
<Noldorin> do i need python 2.6 ?
<youlysses> *bzr?
<youlysses> I'm pretty sure there are a few "homebrew" repos/ package managers outthere for MacOSX. Probally be the best course of action.
<youlysses> *Or rather "easiest". :-P
<Noldorin> youlysses: typo yes :P
<Noldorin> hmm
<Noldorin> i see
<youlysses> I'm not familar with MacOSX at all, but I'd assume getting and installing it from source would be as hard as on GNU. (Not at all. :-P)
<Noldorin> heh
<Noldorin> not necessarily
<Noldorin> but perhaps
<Noldorin> youlysses: the annoying thing is that it seems to only work with py2.6 :S
<youlysses> Noldorin: They haven't ported to 3.0+ yet ...?
<Noldorin> youlysses: not even 2.7 :P
<Noldorin> youlysses: and no, no bar runs on 3.x i don't believe
<Noldorin> not on linux or windows
<Noldorin> bah
#bzr 2012-06-15
<youlysses> t
<scientes> whats with all the orphaned bzr plugins in debian http://www.debian.org/devel/wnpp/orphaned ?
<mgrandi> if youc click on them you'll see that jelmer is requesting an adopter
<mgrandi> so they are probably still developed but they need a maintainer that creates debs (thats almost a job in itself) of the latest versions and whatnot
<scientes> well why can't whoever is doing the ubuntu work, just pick up debian?
<mgrandi> they have different policies =P
<mgrandi> and its probably a lot of work
<mgrandi> if creating deb files wasn't black magic i might see if i could do it haha
<scientes> meh its not that hard
<spiv> mgrandi: maybe now's a good time to learn ;)
<mgrandi> i can't even find a good guide
<mgrandi> ive only seen guides on how to use easyinstall and other helpers
<spiv> I'm sure jelmer would be glad to help a willing volunteer
<scientes> you just need to write a makefile, and if your package works with automake, its mostly "magic" and done for you
<mgrandi> these are python plugins so i dont think they have makefiles
<scientes> (same for some other build systems)
<mgrandi> makefiles themselves are black magic
<scientes> ^^^
<mgrandi> id also probably need a debian install haha
<scientes> yes you would, but you can use "debootstrap" to do it all in a chroot
<scientes> which will run from any distribution
<scientes> http://wiki.debian.org/Debootstrap
<mgrandi> looks like it would just be easier to shrink a partition then try to run debian ontop of something else
<mgz> morning!
<jelmer> mgz!
<mgz> !
<vila> jelmer, mgz: hey
<gour> morning all
<gour> fast-export/import from fossil --> git fails...otoh, fossil --> git works as 'fossil export --git ../repo.fossil | git fast-import' withing git repo...is it possible to use bzr's fast-import via fossil's pipe so that we can convert our fossil repos straight into bzr?
<jelmer> gour: s/git/bzr/ for the first occurance of git?
<jelmer> I think there were some known issues with the fossil fastexporter, it removed all files for each revision or something along those lines
<gour> for now, fossil does export --git only
<jelmer> gour: It's worth a shot to try --git and feed that output into bzr fastimport
<jelmer> I vaguely recall there were issues with fossil fastexport output format though
<jelmer> or maybe that was Monotone?
<gour> jelmer: i'm trying that, but no idea how to feed that output into bzr fastimport...fossil export --git task.fossil | bzr fast-import neither fossil export --git task.fossil | bzr fast-import task.bzr works
<gour> i sent a post to fossil list but the attachement exceeds 40k quota there :-(
<jelmer> gour: you might want to try generating an intermediate file with the fastimport data
<jelmer> gour: 'bzr fast-import' takes two arguments: the filename of the fastimport stream to read and the branch to import to
<gour> jelmer: it crashes with the same mark as git import
<gour> jelmer: http://pastebin.com/9wsUWgeF
<gour> jelmer: i can email you *.fi file
<gour> git import fails with "fast-import fatal: mark :711 not declared"
<jelmer> if git fails too, I would put the blame on fossil
<jelmer> gour: there's not much I can do with that, I'm not a fossil contributor :)
<gour> right...the problem is that i could not post *.fi file there...
<gour> ok
 * gour just wants to import repos from fossil to bzr...
<gour> there is no addremove in bzr to add all unversioned files and rm all missing ones?
<jelmer> gour: "bzr add" without arguments will add all unversioned files
<jelmer> and bzr commit will automatically remove files that were rmeoved
<gour> thank you
<WasserDragoon> hi how to get the release code from version 3.1 from https://launchpad.net/egtk
<WasserDragoon> there are no tags and i don't want to look into the .tar.gz download always whats the last revision (in .bzr folder)
<mgz> WasserDragoon: surely that's a question for the maintainers of that project rather than bzr
<WasserDragoon> mgz: i don't have a good connection to these guys ;-)
<mgz> neither do I, but the launchpad page makes it clear enough who to ask
<mgz> try email or irc given on https://launchpad.net/~danrabbit
<mgz> just guessing from log/release timestamps, you probably want r491
<WasserDragoon> mgz: right but i don't want to look in all next releases what the last revision was
<WasserDragoon> but i will send a mail to danrabbit
<mgz> you can suggest `bzr tag -r491 egtk-3.1.0` to him
<WasserDragoon> mgz: to late i already sent the mail but thanks i'll do that in the next mail ;-)
<Mook_as> hmm, I guess starting with bzr 2.4, `bzr revert dir/file` also tried to revert the containing directory if there are no other changes in that directory? (steps to reproduce in http://pastebin.com/5Awyr8Bg )
<gour>  /q
#bzr 2012-06-16
<gour> morning
<gour> i need one advice...pulled one git(hub) repo using bzr-git, did some small contribution (bzr completion for fish shell), pushed to my github account, created pull request and the 'patch' was applied by git-rebase to upstream. however, attempt to bring the updated branch back to bzr using bzr-git creates many conflicts and/or creates man new files...probably due to rebase but i'm not familiar with it nor i have
<gour> intention to use it not really seeing use for it. now i'd like to work further on the project and contribute more, but i wonder what would be the most painless way to do it without using rebase in bzr(-git)?
<gour> i also believe that using hg-git won't make the problem easier to me:..
<jelmer> hi gour
<jelmer> gour: how did you push to your github account?
<jelmer> go	dpush indeed creadoes an implicit rebase
<jelmer> arghm lag
<jelmer> gour: dpush indeed does an implicit rebase
<gour> jelmer: dpush
<gour> but the maintainer seemingly used rebase to apply all the different contributions
<jelmer> gour: that would lead to issues in git as well
<jelmer> gour: although perhaps not content conflicts
<gour> jelmer: maybe i should just do contribution in my bzr-git branch and then prepare patch for applying to avoid those conflicts
<jelmer> gour: I would just "bzr pull --overwrite" after the changes have been merged upstream
<gour> jelmer: thanks...let me try that
<gour> jelmer: that worked ok and, imho, better than my attempts with hg
<jelmer> cool
<awilkins> lifeless, ping?
<gour> is 2.6. development going according to the schedule?
<jelmer> gour: sure, I guess?
<jelmer> schedule?
<gour> jelmer: well, release in august?
<gour> i just saw a thesis from jun 2010 entitled 'Analysis and Comparison of Distributed
<gour> Version Control Systems?
<gour> bzr looks quite good in some aspects, but wonder what has changed in between?
<gour> here is the link http://thehappy.de/~neo/dvcs.pdf
<vila> Branches in Bazaar are created by cloning a repository (a repository is
<vila> called branch in Bazaar); each Bazaar repository may only have one branch
<vila> head.
<vila> As a workaround Bazaar provides shared repositories
<vila> eeeerk, wtf ? *Every* bazaar repository can have as many branch heads as you desire
<gour> heh...it's not only phd thesis :-)
<gour> s/it's not/it's
<gour> ahh
<gour> s/not only/not
<vila> quite good from what I read so far, will print for bed :)
<gour> :-)
<Wiz_KeeD> hey guys
<lifeless> awilkins: pong
<awilkins> Since you wrote the page mentioned here ... : http://askubuntu.com/questions/151387/confirming-pgp-key-on-launchpad/151458#151458
<lifeless> I did ?
<awilkins> It says "lifeless"
 * awilkins waits for it to load
<lifeless> hah
<lifeless> no, it says 'last edited by'
<awilkins> Aha .. close enough?
<lifeless> it was created by matthew revell
<lifeless> https://help.launchpad.net/YourAccount/ImportingYourPGPKey?action=info
<lifeless> and edited by many others
<lifeless> anyhow, you have my attention :) - whats up ?
<awilkins> Ah well.... I guess since I knew you from here it lit a bulb
<awilkins> Just a possible improvement in explaining that gpg expects an EOF
<awilkins> I would have done it but I don't seem to have any ability to edit those pages
<lifeless> thats locked down to an explicit group, if you want to help maintain the docs I can add you in/
<lifeless> Step 6 in importing your key is the relevant
<lifeless> one - the confused person seems to have taken the encrypted email *out* of their email client.
<awilkins> I'm not sure whether he got relief from the EOF or from installing Enigmail
<Noldorin> hey folks
<awilkins> Enigmail doesn't come by default though
<awilkins> I don't mind being added to that group, I guess .. I think I can be trusted not to deface things :P
<lifeless> I've posted a question for him on that.
<lifeless> awilkins: whats your LP id ?
<lifeless> Noldorin: hi
<Noldorin> how's it going, lifeless ?
<awilkins> lpid == adrian-wilkins
<Noldorin> any exciting bzr/launchpad news?
<lifeless> Noldorin: we're hoping to make ppa's massively better in the next 2 months, I'm pretty excited by that
<Noldorin> lifeless: cool. i'm not using Ubuntu presently, but that would encourage a growth in packages i suppose :)
<lifeless> other way around; growth in packages and popularity means we're getting overwhelmed, have to make it better to cope ;)
<Noldorin> lifeless: hah i see.
<Noldorin> so what are these changes basically?
<Noldorin> improvements...
<lifeless> https://dev.launchpad.net/DisklessArchives
<lifeless> is the design side of it
<Noldorin> bar is very stable and feature-complete these days, so i can't see much more work being done on it really...
<lifeless> sorry, thats the technical side of it
<lifeless> https://dev.launchpad.net/LEP/DisklessArchives is the design/high level side
<lifeless> It would be nice to have better history editing support in bzr, I think that makes more different to folk that we realised back-when
<Noldorin> lifeless: oh okay. so the number of packages as well as users on Ubuntu is swamping you eh? :P
<lifeless> for stuff not in the main archive itself, yeah.
<lifeless> the main archive gets carried by lots of mirror networks
<Noldorin> lifeless: okay so essentially it's a problem of inefficient distribution over the PPA servers at the moment
<Noldorin> so you're going to improve the architecture and protocol model...
<Noldorin> to make things work smoother and cope with capacity increases better?
<Noldorin> also, by history editing do you mean rebasingâ¦ or rather, editing old commit messages and such?
<awilkins> Or more like git rebase =i
<awilkins> -i
<Noldorin> awilkins: what's that do?
<awilkins> git rebase -i lets you pick and choose, reorder, squash, etc, your commits
 * awilkins is answering a question from 2 hours ago #RainMan
<lifeless> awilkins: Noldorin: editing - I mean rebase -i and similar tools; editing old commit messages either in a rebase fashion, or via something more complex, but actually supporting it would be the first thing ;)
<lifeless> Noldorin: yes, make things smoother, more responsive, and scalable.
<Noldorin> oh hi again lifeless
<Noldorin> heh, delay
<Noldorin> lifeless: so what is "rebase -i"?
<Noldorin> i just know what rebasing does in general, pretty much
<awilkins> It presents the commits you ask in a text file, you edit the file, it reorders then, squashes them together, ignores them, etc
#bzr 2012-06-17
<gour> morning
<mgrandi> hi
<gour> is extmerge plugin obsolete?
<gour> another thing i'm curious is that it seems that pipelines are recommended over looms to have mq-like functionality in bazaar, but i wonder if it's really required or one can do it using feature branches & shelve only?
<gour> probably there is something more in looms/pipeline which i do not understand (yet)
<mgrandi> im not experienced with either of those sorry =(
<gour> ok
<Noldorin> lifeless: given any thought to my namespace suggestion yet? :)
<jelmer> Noldorin: namespace?
<jelmer> gour: you can do the same thing with feature branches and shelves
<Noldorin> jelmer: this was a conversation about launchpad i had with lifeless from earlierâ¦ don't worry ;)
<lifeless> Noldorin: not beyond that discussion
<gour>  jelmer: thanks...that's what i hope to hear ;)
<Noldorin> lifeless: heh fair enoughâ¦ any plans to? :)
<lifeless> Noldorin: as I said at the time, its not on any roadmap; examining that part of the interaction design is unlikely to bump stuff in the roadmap today; as for getting in in the future, most of the 'urgent' backlog is more functional in nature.
<Noldorin> i.e. "no. we're never going to get around to this"
<Noldorin> haha, fair enough
<lifeless> perhaps :) I don't want to hold false hope out. OTOH we don't have any reason *not* to re-examine things there and improve, but doing that has to compete with all the other pressures and tasks.
<lifeless> 'I don't know' would probably be a better summary.
<Noldorin> yeah
<Noldorin> it seems to me that if an issue is low priority, then it stays low priority forever
<Noldorin> there will *always* be more "important" tasks than it no?
<lifeless> two things can happen; we can drain the lake above it, or something can push it up to a higher level.,
<lifeless> so, say we decide to do a usability review, we might find that namespace management is a primary driver for all sorts of poor interactions and UI
<lifeless> at which point, everything namespace is going to become more important
<bob2> also, 'everything namespace' is a good name for a new-wave post-industrial rock band
<lifeless> bob2: make it imperative
<lifeless> namespace everything
<Noldorin> lifeless: i see. fair enough :)
<Noldorin> at least i've planed the seed now!
<Noldorin> heh
#bzr 2013-06-11
<Saviq> hi all, is it possible to have a commit hook installed _in_tree_?
<Saviq> i.e. if I'd like to ship a hook that will run a test suite / style check on each commit, is it possible to have per-checkout, or does it have to be in a global plugin?
<lifeless> security wise, plugins have to be global.
<lifeless> but you can have a plugin be *active* per-tree.
<lifeless> by having it consult a setting in the branch.conf
<Demosthenex> does anyone have a document describing a best practice for maintaining multiple forks from a common source?
<Demosthenex> imagine starting with a documentation template as a common parent, and cloning that to create each fork. you make tons of commits to the forks that will never to back to the parent. when you do though, how can you separate just that piece to send back?
<Demosthenex> you can tell i'm lacking the terms to describe this accurately
#bzr 2013-06-12
<bob2> Demosthenex, sure, cherrypicking is a thing
<bob2> Demosthenex, but in practice it'd often be better to not do that and instead make use of the templates and derive from them or whatever
<Demosthenex> my example was where while making a document, a change should return to the parent to be included in new/updated docs from now on.
<Demosthenex> obviously not everything should be ported back
<Demosthenex> and the alternative is manually updating...
<Demosthenex> the second example i have is another common one, where you have a standardized config file as the parent, each host has a branch with it's changes. why not push a single commit from a child back to parent, so it can push to the other children (ie: updating the standard)
<Demosthenex> that is cherry picking?
<lifeless> no
<lifeless> cherry picking is merging a non-connected part of the history graph
<Demosthenex> well, branching/merging tends to imply that changes will eventually return to the trunk...
<Demosthenex> that's why i thought fork was right...
<Demosthenex> parallel forks
<Demosthenex> how can you exchange single commits when they share a parent?
<bob2> cherry-pick
<lifeless> or ensure they are teh first commit on the branch :)
<Demosthenex> both examples start from a very slow to change parent... all the work is in the children.
<Demosthenex> i'm thinking it sounds likely i just may do it manually :P
<Demosthenex> i didn't see much in the bazaar site on cherry picking.
<bob2> well, you'd need to read the manual
<Demosthenex> http://wiki.bazaar.canonical.com/CherryPick
<bob2> sure
<lifeless> Demosthenex: I generally just make sure there is a branch which can be fully merged.
<lifeless> Demosthenex: don't tangle up 'things you want to merge' and 'things you don't want to merge.'
<Demosthenex> lifeless: i think that's the question... do i want to merge?
<Demosthenex> it's just a common occurance, i'm using a documentatio template, it's small and contains code...
<Demosthenex> i write a document, and change the code snippets (lots of docs, little code), and i want to push just the code portions that came from the template back
<Demosthenex> right now i hand repeat those changes.
<bob2> which is silly
<bob2> either make the changes upstream or use cherry-pick
<lifeless> right
<Demosthenex> that's why i was asking if cherry picking might do it
<lifeless> or use a third branch for those changes until you're satisfied and merge that branch both upstream and to your doc branch
<lifeless> yes cherrypicking will copy patches, its basically the same as diff+patch
<Demosthenex> i'm pretty sure i can isolate the changes that i want to a whole commit, thus my interest
<_arch> Hey, I want to add a revno as a variable to each committed file. Any suggestions? I've tried to write a post_commit-hook but it does not seem to recognize changed files.
<lifeless> post-commit would be too late
<lifeless> there is a plugin for doing variable injections like that
<_arch> The keyword-plugin?
<bob2> suggest not doing that
<_arch> at all? I don't like the idea much either but I need some way to get revno for each file a customer is using for support and debug :(
<lifeless> _arch: do they have bzr?
<lifeless> _arch: if so, just have them run 'bzr revision-info'
<_arch> No. I'll try to explain
<bob2> add it somewhere during your build process
<_arch> The files run on an embedded system. Our customer gets modified files from us every now and then. They might not have to update all of the files on the system
<_arch> they also might roll back on some of the files every now and then
<bob2> use 'bzr revision-info' in your build script
<lifeless> do they edit the files ?
<_arch> no they don't
<lifeless> If not, just ask them for the shasum of the file
<lifeless> you can look that up
<lifeless> or, as bob2 says, embed version info as you ship the file to the customer, rather than in VCS
<_arch> can't look that up, because they don't remember which version of the file they are using and it's not trivial to get the shasum from the embedded system.
<_arch> I guess that's a better way
<_arch> it's a damn stupid problem anyway :)
<hikiko> hello
<hikiko> is there any bazaar command/option to see the differences between 2 different branches? (like bzr diff but for all files)
<rly> Is there a gitk like tool for bzr?
<rly> ALso, what's the command to delete all local changes like git reset --hard?
<vila> rly:  try qbzr or bzr-gtk plugin
<vila> rly:  probably 'bzr revert'
<rly> vila: note that I didn't commit anything.
<vila> right, so 'bzr revert' will  do (more explanations with 'bzr help revert')
<rly> vila: how do I do the equivalent of git pull?
<rly> vila: bzr merge does something different.
<rly> It seems to be bzr update
<vila> bzr pull ?
<rly> vila: thanks
<rly> I don't get why there are so many version control systems, but I suppose everyone must be thinking that everybody else before did it wrong.
<LeoNerd> Often because projects have to get to a certain level before they become "public" enough that everyone else sees them, so you tend to get multiple differnet ones being started all at the same time
<rly> So far I have used: cvs, svn, bzr, monotone, darcs,git,fossil,veracity,mercurial, and I am sure I am forgetting a few.
<LeoNerd> p4?
<rly> No
<LeoNerd> Ah.. lucky :)
<rly> I installed bzr-gtk, and then what?
<rly> I had expected a bzr-gtk command in /usr/bin
<rly> bzrk also does nothing.
<rly> At no point does this page explain how to use it: http://wiki.bazaar.canonical.com/bzr-gtk?action=show&redirect=BzrGtk
<rly> It lists a changelog which is at best a detail.
<rly> I get it finally.
<ianbrandt> Greetings.  I had a symlink in Bazaar that prevented Windows users from checking out the project per https://bugs.launchpad.net/bzr/+bug/81689.  I've removed the symlink, added a copy of the file in its place, and committed a new HEAD revision.  On Windows I still get the same error trying to branch the project.  Does this bug apply if there is a symlink anywhere in the history of the project?  I would have thought a checkout would
<ianbrandt> if the latest revision contains no symlinks.
<ubot5> Launchpad bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,In progress]
<ianbrandt> abentley: Hello.  I noticed you started the wiki page on Windows symlink support (http://wiki.bazaar.canonical.com/WindowsSymlinkSupport).  Do you know if there is any workaround for getting "bzr: ERROR: Unable to create symlink 'foo' on this platform" on checkout even after the 'foo' symlink has been removed and replaced with a file in the latest commit?
<abentley> ianbrandt: No, if the symlink was removed in the latest commit, I'm surprised that you can't do a checkout.
<ianbrandt> abentley: Okay.  Me too.  This is with 2.5.1.  On my mac when I do revno I get 4102.  Same on Windows where the repository was checkout out, but the tree failed to populate.
<ianbrandt> bzr ls -R --kind=symlink at the root of the project returns nothing on my mac.
<ianbrandt> bzr revert -r 4102 on Windows results in "bzr: ERROR: No final name for trans_id 'new-1120' file-id: None root trans-id: 'new-0'"
#bzr 2013-06-13
<jave_> hello
<jave_> is ploblematic to use non-ascii in commiter name?
<jave_> I'm experiencing the issue here:
<jave_> https://github.com/felipec/git/issues/38
<LarstiQ> jave_: nafaik
<LarstiQ> jave_: I'd suspect it is git-remote-bzr where the problem is
<jave_> LarstiQ: ok, I delved some more and there seems to be some unicode/ascii conversion issue with git-remote-bzr
 * LarstiQ nods
<LarstiQ> jave_: that sounds plausible
<tuv> is this the official irc channel for bzr?
<tuv> i pulled from a different branch, and now everytime i 'bzr update', i get 'bzr: ERROR: [Errno 1] Operation not permitted:...' for some (arbitrary, afaict) file. I rm the file, update again, and I get the same error for another file!
<tuv> what could be causing this?
<tuv> if I don't rm the file, and update again, I get the same error for the same last file
<tuv> it's a huge repository, so if this goes on, it could take a while
<tuv> reiserfs
<fullermd> errno 1 is (on my system anyway, but that low is probably common) EPERM, which would fit.  But I can't think of any way on its own bzr could have put things in an EPERMish way.
<fullermd> The files are writable by $YOU?
<tuv> yes. i'm rm'ing them. i can revert them too
<fullermd> rm'ing wouldn't prove it, since you don't need write on a file (or any perms, for that matter) to delete it.
<fullermd> And revert would be the same, since it doesn't strictly speaking edit the file; it rm's it too.
<tuv> i don't own them, but i belong to the files' group, and they have write access for group
<fullermd> But doing an update would, so that's the salient difference...
<tuv> ok.. trying to edit a file
<fullermd> (rm'ing a file requires you have write perms to the directory the file is in; the files perms are irrelevant.  Hence why /tmp requires the sticky bit)
<tuv> i can edit them
<tuv> it seems all the problematic files have their permissions changed (-x)
<fullermd> Mmm.  Well, bzr should be able to edit them on your behalf, then...
<tuv> it's having difficulty chmod'ing them, it seems
<fullermd> That could be.  Can't chmod a file you don't own.
<tuv> ah
<tuv> right. that seems to be it
<tuv> i'm trying to manage the repository as a different user than the one using it
<tuv> apparently it's not working
<fullermd> Yeah.  Always tricky.
<tuv> chown.. update completes without errors :)
<fullermd> With BSD fs semantics (or SysV and use of g+s), you can usually manage to pull it off, but dark corners like that require manual work...
<tuv> how do i make sure i have a certain revision id checked out in my working tree?
<tuv> revno was giving the revision no. although the update to that rev was not complete
<fullermd> revno tells you the revno of the head of the branch; revno --tree tells you what the working tree considers itself at.
<tuv> and do i have to use another command to resolve the revno to revision id?
<fullermd> There's a revision-info command that shows both (and it has a --tree as well)
<tuv> nice. does it detect a dirty tree?
<fullermd> Don't think it says anything about that.  version-info can.
#bzr 2013-06-14
<scientes> how do i view a revicsion patch ?
<scientes> like "git show"
<fullermd> Not entirely sure what that does, but 'diff' would be a good start.
<scientes> i have a revision number
<bob2> bzr diff -cXXX
#bzr 2013-06-15
<Jip> hi
<Jip> we have a problem with our bzr repository. https://bugs.launchpad.net/armagetronad/+bug/1190375
<ubot5> Launchpad bug 1190375 in Armagetron Advanced "bzr repositories are corrupted" [Undecided,Confirmed]
<Jip> anyone an idea how to fix it?
<LarstiQ> Jip: I recall there are some things you can do
<LarstiQ> Jip: a general thing you can try is `bzr reconcile`
<Jip> LarstiQ: i tried bzr reconcile already without luck
#bzr 2013-06-16
<Jip> hi
<Jip> I have asked already, but does someone have an idea how to fix this? https://bugs.launchpad.net/armagetronad/+bug/1190375
<ubot5> Launchpad bug 1190375 in Armagetron Advanced "bzr repositories are corrupted" [Undecided,Confirmed]
<Jip> I tried to bzr reconcile already
<Jip> it seems that something went wrong with removing a file when another branch was merged ~800 revisions ago
<lifeless> have you tried the bugfix jam proposed for it?
<Jip> lifeless: how can I do that?
<mwhudson> why can i not control-c a bzr serve process?
 * bob2 vaugely blames threads
<mwhudson> seems likely, doesn't it
<lifeless> you should be able to
<lifeless> if you can't, thats a bug
#bzr 2014-06-09
<mark06> help please, http://vpaste.net/aMDor
<mark06> bzr 2.7.0dev1
<jelmer> mark06: that's a known issue; see the udd bug tracker
<mark06> ok so currently I'm stuck and can't use UDD for this package, right?
<jelmer> mark06: there is some option you can set to prevent this
<jelmer> mark06: the bug report has details
<mark06> I asked in packaging channel but no answer... any suggestion on the following issue?
<mark06> it's been a while since I used PPAs and I moved from bare patches to bzr branch, which doesn't fit well with non-UDD packaging... I started my custom pidgin as a bzr branch based on upstream's tarball, well...
<mark06> I guess I need to merge all ubuntu-specific changes introduced by the package, I can't simply build my own package from scratch... that'd be easy if I based my branch on the above (if it was ever working)... so I could simply merge....
<mark06> so what approach should I do? I'm thinking of doing a bare diff and try applying in the source package... that isn't much elegant as from source code point of view all my commits will be compressed into a single big diff.... but I see no other way... suggestions?
<mark06> is there any command to convert a series of commits into a series of separate patch files?
<mark06> is it possible to undo an specific commit in a branch? reverse cherry picking?
<jelmer> mark06: there is uncommit, or reverse cherry pick
<mark06> done, thanks
<mark06> what should I use as replacement for bzr builddeb, since I can't do UDD?
<mark06> bzr -Olaunchpad.packaging_verbosity=off?
<LeoNerd> jelmer: Offhand, do you know the latest progress on bzr-git, and the dulwich version problem? I'm still getting:  bzr: ERROR: exceptions.AttributeError: 'BazaarObjectStore' object has no attribute 'get_graph_walker'
<jelmer> mark06: yeah, that will disable the freshness check that is buggy
<jelmer> (the exception you ran into before)
<jelmer> LeoNerd: nobody is working on bzr-git as far as I know
<mark06> took a bit long but worked, thanks!
<LeoNerd> jelmer: :(
<mark06> is it possible to somehow merge diverging branches?
<LeoNerd> Hah.. I have an interesting solution to bzr-git here. It seems the bzr-git plugin can checkout, and can do the pushing parts of commit/push, but can't actually fetch and update.
<LeoNerd> So you can make a new checkout, in which you're allowed exactly one commit before it breaks.
<LeoNerd> But that commit does at least make it back to github or wherever; so you can just blow away that checkout and make another one for next time. \o/
<mark06> bzr status
<jelmer> LeoNerd: I might have a look at fixing it for the purpose of git-remote-bzr at some point
<mark06> is there any way to tweak bzr builddeb so it doesn't rely on the package version for fetching the upstream version?
<jelmer> mark06: that's how debian packaging works, unless I'm misunderstanding?
<mark06> I want to use version like 1:2.9.0-rs137-0ubuntu3.1 but it thinks upstream is 1:2.9.0-rs137
<mark06> but this is very inconvenient for a *feature* ppa, it's really annoying that every debian/ubuntu update supersedes your features... then the user always get bizarre regression alternations...
<mark06> I mean, it's inconvenient to attach rs137 after ubuntu3.1
<mark06> unless there's a way to avoid this odd superseding
<jelmer> mark06: what does rs137 indicate?
<mark06> I didn't get well what exactly makes it guess what the upstream version is like
<jelmer> mark06: it just uses the standard format for Debian packages
<jelmer> even if you would get bzr-builddeb to use a different upstream version string, all other debian tools would break
<mark06> rs137 is my naming scheme for my feature/bug patches to pidgin... http://pidgin.renatosilva.me/
<jelmer> mark06: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<jelmer> mark06: if they're changes to the upstream branch and not the packaging, then you indeed want rs137 in the upstream version (as that reflects reality)
<mark06> what I mean is given 1:2.9.0-rs137-0ubuntu3.1, why it splits into 1:2.9.0-rs137 ("the upstream") and 0ubuntu3.1, and given 1:2.9.0-0ubuntu3.1-rs137, why it splits into 1:2.9.0 (correct upstream) and 0ubuntu3.1-rs137? the rule is unclear to me
<mark06> but in that case the diff from "2.10.9-rs137" upstream  would be essentially void from actual changes and include only debian/ubuntu packaging changes... even so, I don't know how to make it find "2.10.9-rs137" since I am trying to create the very source package and that one still doesn't exist
<mark06> is that really the workflow, let this bizarre regression alternation just happen? what ppa developers are expected to do? foresee an upcoming debian/ubuntu update and build before that?
<mark06> it would be nice if it automatically merged the debian/ubuntu changes into the ppa
<mark06> hmmm I kind of cheated it with 1:2.10.9-rs137+0ubuntu3.1
<mark06> it likes the '-0', it seems
<mark06> so bzr builddeb could be smarter and create the patch from commit diff
<mark06> it rather ignores all the dvcs thing and asks you to dpkg --commit or something, in a bare patch...
<jelmer> mark06: that's not bzr-builddeb asking it, but dpkg
<mark06> right, but bzr let it happen... it could have handled it automatically since the idea of UDD is not dealing with raw patches anymore right...
<jelmer> mark06: it could suggest you run "bzr dep3-patch" instead, I guess
#bzr 2014-06-10
<mgrandi> is there a global option for bazaar to not output anything to stdout?
<bsd> -q / --quiet ?
<mgrandi> Yeah, but that wasn't working bsd, i think there is just a bug in how bazaar calls the ssh program , leading to me getting "stty: standard input: inappropriate ioctl for device' from the remote ssh server and then that causes output which makes pythonw.exe break
<fullermd_> That's probably something from the shell rc file that isn't checking that it has a terminal before doing terminal stuff.
<mgrandi> where is that configured? my server is just like, a stock ubuntu server
<mgrandi> cause it only happens if i use an external ssh, (bzr uses 'ssh' on mac, windows i was using plink), using paramiko its fine
<fullermd_> Dunno.  You might find it by inspection, or trigger it manually and start dumping debug printfs around 'till you narrow it down.
<fullermd_> (well, debug echos)
<fullermd_> Probably the former of course, since you pretty well know it's a stty call.
<mgrandi> ugnnnnn
<mgrandi> well at least windows works fine with paramiko now, so i guess i can just use that
#bzr 2014-06-11
<fullermd_> I wonder if anybody's ever used bzr on VMS...
<jelmer> fullermd_: the way you say this makes it seem like you're about to try?
<fullermd_> I never drink that much before noon.
<fullermd_> I was just about to write "you can grab the current code with bzr from..." to somebody on VMS, then I realized they probably _can't_.  Or, wait, can then?  Hmm...
<fullermd_> I'm pretty sure there's no VMS support code in bzr, but I wonder if the python env on VMS emulates enough POSIXisms that it doesn't need it.
<fullermd_> The python package on http://www.vmspython.org/ seems to ship mercurial...
<SamB> wow, somebody on VMS?
<SamB> it seems like it's hard to get VMS nowadays
<fullermd_> I think it's pretty easy, actually.  You just buy the wrong company for some other reason, and Tag!  You're it!
<SamB> even if it *is* legal to use the "borrow media from a friend" approach to install it now
<fullermd_> According to http://h71000.www7.hp.com/openvms/pdf/openvms_roadmaps.pdf it's actually still in some level of support on VAX through next year.
<SamB> what other ISAs does it support again?
<fullermd_> VAX, Alpha, and Itanic.
<SamB> okay, so, um, remind me which of those is the least dead?
<fullermd_> Yes   ;)
<SamB> I guess Debian most recently dropped Itanic so maybe that's the one?
<fullermd_> Well, according to Wikipedia, VAX was still being manufactured up through 2005.  The 21364 was the las Alpha, and that predated the Compaq buyout in '98, but was apparently still made until 2007.
<fifer> I'm setting up a very simple bzr setup on centos 6 which has 2.1.1 available with out getting too radical repository wise. How big a diference is there between 2.1.1 and 2.6? Not even using it for source, primarily text documents, manufacturing CNC files and drawings.
<fifer> Especially interested in the ability to propigate changes in ways you cant with svn.
#bzr 2014-06-13
<chrisirc> Hello. I'm a bzr newbie (well not really, used it a little bit about 10 years ago), trying to get to see all branches in a repo ,i.e. explore a repo.
<chrisirc> I'm on Debian and I've installed bzr-explorer with its dependency qbzr.
<chrisirc> Those tools sound like they would do what t
<chrisirc> I want, but, I can't figure out how to start the,
<chrisirc> m, those packages don't have a single entry in any */bin/
<chrisirc> directory. (sorry, my return key is funky, triggers all the time.)
<chrisirc> Basically I'm looking for the equivalent of "gitk --all".
<chrisirc> Can a bzr repository contain multiple branches like Git? How can I list them? "bzr branches" shows 1 line, "* (default)".
<chrisirc> Do I need to pass options to "bzr clone" to get more than the default branch?
<fullermd_> Running qlog on a dir will find all the branches under it, 'branches' needs -R to work right, clone is just an alias for branch which pulls the given branch (not 'default', as that lacks meaningful meaning)
<fullermd_> Or more explicitly, bzr practically never does repository-level operations, it's essentially all branch-level.
<bob2> (repos are mostly just a storage space optimisation in bzr)
<mgrandi> try just 'bzr explorer' ?
<mgrandi> to start bazaar explorer
<mgrandi> or any of the 'q<whatever>' commands like fullermd_  said
<Rich_Morin> I just installed Bazaar on OSX 10.7.5, using the 2.6.0 installer from http://wiki.bazaar.canonical.com/MacOSXDownloads  How can I find out where this might have put bzrlib?
<fullermd_> bzr version says.
<Rich_Morin> bzr version says "ERROR: Couldn't import bzrlib and dependencies.  Please check the directory containing bzrlib is on your PYTHONPATH."  Beeep.
<Rich_Morin> recursion: see recursion
<fullermd_> OK, so we know the answer is "not where it should be"   :)
<Rich_Morin> progress!
<Rich_Morin> Well, find(1) found /Library/Python/2.6/site-packages/bzrlib
<Rich_Morin> How much of that needs to go in the PYTHONPATH
<fullermd_> Up through the 2.6 I think.  Though the real answer should be "none of it", since it sounds more like the bzr install isn't really in sync with your python install, so forcing it may not put you in a good place anyway.
<Rich_Morin> The really annoying thing is that I only need Bazaar in order to get a Go library.  So I'm three levels down a stack of incidental complexity.
<fullermd_> Maybe you can shortcut that away.
<Rich_Morin> ???
<fullermd_> What lib where?
<Rich_Morin> "launchpad.net/goyaml"
<fullermd_> LP has tarball downloads.
<fullermd_> For that matter, up top of that page it points at github.
<fullermd_> So really, what we need to do is get bzr working and bzr-git installed, so you can use that to get git, and use that to get it   :)
<Rich_Morin> erm, which page?  I _have_ git
<fullermd_> https://launchpad.net/goyaml says "PROJECT MOVED: https://github.com/go-yaml/go-yaml-v1" right up top.
<Rich_Morin> Thanks!  That looks promising.
<Rich_Morin> I hope I don't have to understand   yaml.Unmarshal([]byte(data), &t)  just to parse some YAML :-)
<fullermd_> Of course not; you just do it in perl instead    ;)
<Rich_Morin> Actually, I have this script running in Ruby and Julia, but neither is very fast, so I'm trying Go.
<Rich_Morin> I haven't written any Perl in several years, but...
<Rich_Morin> Does Go have a simple way to print a data structure, ala Ruby's inspect method?
<Rich_Morin> I'm getting '{ {%!s(int=0) []}}' for a hash, which doesn't show me the data...
<fullermd_> Dunno.  Getting from "passingly aware" to "working knowledge" of go hasn't get gotten within a loud shout of the top of my todo list.
<fullermd_> s/get/yet/
<fullermd_> Maybe https://github.com/davecgh/go-spew ?
<fullermd_> (from http://stackoverflow.com/questions/12540057/is-there-a-go-language-equivalent-to-perls-dumper-method-in-datadumper )
<mgrandi> Rich_Morin: sorry for your troubles! thats a mac issue, since they changed what version of python that is called when you just call 'python'
<mgrandi> https://bugs.launchpad.net/bzr-mac-installers/+bug/731391/comments/25
<ubot5> Ubuntu bug 731391 in Bazaar Mac Installers "bzr: ERROR: Couldn't import bzrlib and dependencies. Please check the directory containing bzrlib is on your PYTHONPATH. Traceback (most recent call last): File "/usr/local/bin/bzr", line 102, in <module> import bzrlib ImportError: No module named bzrlib" [Medium,Fix released]
<mgrandi> you just have to edit the top line of the script and make it call python2.6 rather then python
<mgrandi> and i have to go, but good luck! =)
<Rich_Morin> tnx
<Rich_Morin> Fortunately, the library I wanted to install in Go has been moved to another site that doesn't use Bazaar, so I can move on.
<JustinZ> OK, I've created my launchpad site, added ssh keys but every time I try "bzr push ...etc" I get "No new revisions or tags to push."
<JustinZ> But there are plenty of files in my directory to push
<fullermd_> You sure they're not already pushed?
<JustinZ> https://code.launchpad.net/~justin-zobel/budgie-desktop/trunk
<JustinZ> Says This branch is empty
<JustinZ> after bzr push
<fullermd_> How many revs are in your local branch?
<JustinZ> I'm a complete noob at this so you'll have to explain a little more if you can please.
<JustinZ> revs meaning revisions of files?
<fullermd_> Yeah.
<JustinZ> Well theres about 20 files in the root directory
<fullermd_> e.g., how many show up when you run log?
<JustinZ> bzr log shows nothing :/
<fullermd_> Well, then push did just what it's supposed to   :)
<JustinZ> Ooooh
<JustinZ> Ok so I did bzr add
<fullermd_> push doesn't push files from your dir.  It pushes commits from your branch.
<JustinZ> hmm ok
<JustinZ> ok so how do I get my files uploaded initially fullermd_ ?
<JustinZ> phwoar, may have figured it out
<JustinZ> had to set whoami, commit, push
<fullermd_> Well, you'd have to commit 'em...
<JustinZ> seems to be uploading something somewhere :D
<JustinZ> yep got it.
<JustinZ> Thank you!
#bzr 2015-06-08
<CcxCZ> LeoNerd: I guess that's more a question for #launchpad
<LeoNerd> m?
<LeoNerd> Oh... my question from Friday. Mmmmm lag.
<CcxCZ> weekends :-)
#bzr 2016-06-16
<cgregan> Hello #bzr. I just re-installed my system clean and have ssh up and working, but when I attempt to do anything with bzr and launchpad I get "No RSA host key is known for bazaar.launchpad.net and you have requested strict checking." Any ideas?
<LeoNerd> Try ssh'ing with regular ssh
<LeoNerd> It probably complains. Add to known_hosts in some flavour
<cgregan> same complaint
<LeoNerd> Wellyes, it will do
<cgregan> adding to known_hosts
<LeoNerd> Hmm
<cgregan> got it LeoNerd..thanks!
#bzr 2017-06-16
<mgz> jelmer: https://code.launchpad.net/~gz/brz/py3_lockdir/+merge/325879
<mgz> hm, wrong channel, wtv
#bzr 2018-06-17
<Prodi> is there a 2.8 windows build?
