#bzr 2007-08-28
* Starting logfile irclogs/bzr.log
<fabbione> test
<fabbione> good :)
<lifeless> kthxbye
<brmassa> guys, i forgot to redit my personal info when reinstalled my system and now some commits are considered as another person. how can i fix it?
<Peng_> brmassa: Uncommit them.
<Peng_> Unfortunately.
<brmassa> !!! really?
<ubotu> Sorry, I don't know anything about really? - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<Peng> Haha. Nice, ubotu.
<Lo-lan-do> Hi all
<Lo-lan-do> I'll paste this http://paste.debian.net/35561 now, in order not to lose the URL for when jelmer comes around.
<lifeless> brmassa: yes, we don't support editing commits; doing that essentiall changes data that is meant to be irrevocable.
<brmassa> hmmm
<brmassa> i was thinking about "merging commiters" or alias...
<brmassa> something like this...
<Lo-lan-do> lifeless: Irrevocable, but still uncommittable :-)
<brmassa> lifeless, i saved my gpg on my pendrive. once i reinstalled my ubuntu, how can i import them back? launchpad keeps complaining..
<fullermd> Well, uncommit doesn't revoke it.  It just deports it   ;)
<lifeless> brmassa: uhh, dunno what you mean
<lifeless> mvo: grats
<mvo> hey lifeless, thanks
<kanhaiya_kk> NamNguyen: Hi
<kanhaiya_kk> good morning
<NamNguyen> kanhaiya_kk: hello
<kanhaiya_kk> Actually , yesterday due to network prob. i cant clear my points
<kanhaiya_kk> NamNguyen: i tried this "bzr check http://192.168.10.16/~ignu/water" from .17 m/c
<kanhaiya_kk> NamNguyen: but how to open that file here ?
<NamNguyen> kanhaiya_kk: what file?
<kanhaiya_kk> means any file from water dir. ?
<NamNguyen> kanhaiya_kk: bzr check is different from bzr checkout
<NamNguyen> please try again with bzr checkout
<kanhaiya_kk> okay wait
<kanhaiya_kk> NamNguyen: yes, now i can edit file..
<NamNguyen> good
<kanhaiya_kk> after this i have to do bzr commit and then bzr rspush na ?
<kanhaiya_kk> NamNguyen: but then also i have confusion. before i tried bzr branch on .17 machine and now im trying bzr checkout. what is the difference in both commands ?
<lifeless> branch makes a new line of developemnt, checkout works on the existing branch like svn or cvs do
<NamNguyen> kanhaiya_kk: one follows centralised model, the other (branch) follows decentralised model
<kanhaiya_kk> okay..means bzr checkout is right for me.
<kanhaiya_kk> good
<kanhaiya_kk> but still....one sec
<AfC> Unless, of course, you don't have write access to the branch you're checking out, in which case you end up doing decentralized development anyway.
<lifeless> NamNguyen: uhm, thats a confusing way to describe it. Because in a cental model using 'branch' is the way to make a new (centralised) branch.
<kanhaiya_kk> sorry.....confusion is increasing
<NamNguyen> lol
<kanhaiya_kk> :(
<lifeless> NamNguyen: 'branch' is useful in both centralised and decentralised scenarios. 'checkout' is also useful in both workflows though it is strongly biased towards centralisation.
<kanhaiya_kk> after checkout.and after doing editing.when i do commit...it is giving me some errors.
<kanhaiya_kk> some write_lock errors.
<NamNguyen> lifeless: branch is not necessary after you have a bzr init on the working dir, am i correct?
<lifeless> NamNguyen: EPARSE
<spiv> kanhaiya_kk: right, HTTP is read-only.
<AfC> Yet another one burned by read only checkouts. {sigh}
<kanhaiya_kk> so how should i commit changes to my main servere ?
<AfC> kanhaiya_kk: if you don't mind being adventurous and learning a few new concepts,
<kanhaiya_kk> hmmm
<lifeless> kanhaiya_kk: SFTP probably is easiest.
<NamNguyen> kanhaiya_kk: use sftp
<kanhaiya_kk> im ready for anything...actually, here im learning very new things
<lifeless> kanhaiya_kk: use a SFTP URL to your branch.
<kanhaiya_kk> means no commit...directly sftp
<kanhaiya_kk>  ?
<NamNguyen> kanhaiya_kk: you tried to use http://192.168.xxx.16/~ignu/water
<AfC> kanhaiya_kk: wait a sec - a) is this an existing public project or are you starting fresh, b) do you have ssh access to the server in question
<AfC> ?
<NamNguyen> now try it with sftp://192.xxx.xxx.16//home/~ignu/water
<NamNguyen> erm, i missed a public.html in that URL
<lifeless> a better usel might be sftp://192.168.xxx.16/~/public_html/water
<AfC> lifeless: sftp assumes ssh privs, right? So why would you not recommend bzr+ssh:// ?
<lifeless> AfC: less dependencies.
<kanhaiya_kk> NamNguyen: i tried this bzr rspush sftp://192.168.10.16/~/public_html/water
<kanhaiya_kk> but getting error bzr: ERROR: Invalid rsync path u'sftp://192.168.10.16/~/public_html/water/'.
<lifeless> AfC: don't need bzr installed on the remote end. This is therefore easier to get started, and bzr+ssh can be added in easily.
<fullermd> Well, he's got bzr on the server since he's (or was the other day) update'ing the WT there.
<kanhaiya_kk> AfC: yes this is existing project and ssh is also working
<lifeless> fullermd: I don't know these thigns :)
<AfC> ~ doesn't work over the wire, does it? As I recall, you need to use absolute path names
<fullermd> lifeless: Well, you have a life, and don't watch IRC all night   ;)
<lifeless> AfC: sftp://host/~/foo works.
<lifeless> I believe its documented in bzr help
<AfC> lifeless: how about that
<lifeless> we treat /~/ as 'dont cd at the remote end'
<fullermd> Yah.  bzr+ssh doesn't interpolate ~'s, but sftp does.
* fullermd stabbies bzr+ssh a few times.
* AfC finds having sftp actually working a bigger "dependency" than installing bzr on the target server, so has never used it
<lifeless> AfC: sftp is on by default if ssh is IME
<AfC> Probably just gun shy from the bad old days. Certainly ssh.com's ssh2 didn't have it on by default, and it was a pain in the ass to get working
<NamNguyen> kanhaiya_kk: sorry i've never used rspush, my guess is your URL could probably be changed to rsync://... instead of stfp:// if you're going to use rsync?
<AfC> Whatever - never would need to use sftp anyway, given the fact that I can invoke the server via ssh
<spiv> kanhaiya_kk: why are you using "rspush" instead of "push"?
<lifeless> AfC: oh yes well. openssh for th win :)
<AfC> lifeless: indeed.
<AfC> kanhaiya_kk: any luck writing to an sftp:// URL yet?
<NamNguyen> kanhaiya_kk: bzr checkout sftp://192.168.xxx.16/~/public_html/water
<AfC> spiv: because he has a certain plugin package installed, which vastly inflates the command namespace, which causes new users to agonize over which command they're supposed to use, which inevitably leads to people not realizing a) what the core commands were and b) that they had all the power needed all along
<spiv> AfC: thanks for answering the meta-question ;)
<fullermd> Or perhaps because he was pointed at it because of his desire to have an up-to-date WT on the server.
<AfC> fullermd: that certainly would be a useful capability. I was quite saddened when I was told by the developer that it would never be included in bzr, even though it seems a natural thing to do automatically and transparently if you already have bzr+ssh as a transport.
<Peng> Holy crap. You know that file bzr takes like 35 seconds to diff? Hg takes 8.
<poolie> Peng, it would be interesting if you could merge that C patience diff patch recently posted and measure that
<Peng_> poolie: Yeah, it would probably help.
<Peng_> I have to admit I just Tailored that branch over to hg, and the .bzr repo is on another partition, but I could check it.
* Peng_ wanders off.
* igc dinner
<ubotu> New bug: #135234 in bzr "Checkout should record relative paths (dir move problem)" [Undecided,New]  https://launchpad.net/bugs/135234
<glogiotatidis> hello
<glogiotatidis> is everyone available to help me with a prob?
<glogiotatidis> everyone = anyone ;)
<glogiotatidis> I am using bzr push sftp://host/path to push a repo
<glogiotatidis> and bzr claims to have commited a branch
<glogiotatidis> but only .bzr exists on host/path
<glogiotatidis> am i doing something wrong?
<fullermd> No, that's what's supposed to happen.
<fullermd> (you _are_ pushing a branch, not a repo)
<glogiotatidis> but if I bzr push /tmp/site pushes everything
<glogiotatidis> when I use sftp acts like this
<Kinnison> The sftp transport does not support working trees
<Kinnison> where the local file transport does
<fullermd> Local pushes will create working trees, because it's reasonable to manage them that way.  Remotely, it's not.
<Kinnison> so pushing over sftp will not update/create a working tree
<glogiotatidis> ok and how can I push a dir remotely?
<Kinnison> a dir?
<Kinnison> Do you mean with working tree?
<glogiotatidis> yes
* Kinnison can think of ways to bodge it, but nothing official
<Kinnison> You could ssh to the machine afterwards and do a bzr update
<fullermd> The nearest official way would just be to use bzr on the server to co/update it, either manually or via a hookish method like push-and-update.
<glogiotatidis> hmm I got it
<glogiotatidis> what I want to do is to update my website on my hosting provider
<glogiotatidis> is there a way you use to do that? (maybe better than this?)
<fullermd> Well, my websites get updated via make(1) and install(1)...
<fullermd> If you've got shell access and bzr installed there, the above will work.  Failing that, rsync is probably your easiest bet.
<glogiotatidis> ok I will try this, thanks for your help!
<yoavb> hi, I installed bzr v0.15 and am trying to migrate my svn repository to it using svn2bzr.py (v0.6)
<AfC> yoavb: step 1: upgrade to bzr >= 0.18.
<yoavb> I got deprecation errors and then crashed, should it resolve this?
<yoavb> This was the error: ./svn2bzr.py:426: DeprecationWarning: bzrlib.branch.initialize was deprecated in version 0.8.
<yoavb>   os.makedirs(branch_path)
<yoavb> ./svn2bzr.py:91: DeprecationWarning: bzrlib.branch.BzrBranch5.working_tree was deprecated in version 0.8.
<yoavb>   branch.__wt = branch.working_tree()
<yoavb> Traceback (most recent call last):
<yoavb>   File "./svn2bzr.py", line 575, in ?
<yoavb>     if __name__ == "__main__":
<yoavb>   File "./svn2bzr.py", line 568, in main
<yoavb>     svn2bzr(dump_file, opts.args[1] , creator_class,
<yoavb>   File "./svn2bzr.py", line 501, in svn2bzr
<yoavb>   File "./svn2bzr.py", line 362, in run
<yoavb>     elif node_kind == "dir":
<yoavb>   File "./svn2bzr.py", line 428, in add_dir
<yoavb>     self._branches[unpref_path]  = branch
<yoavb>   File "./svn2bzr.py", line 91, in _new_branch
<yoavb>     branch.__wt = branch.working_tree()
<yoavb>   File "/usr/lib/python2.4/site-packages/bzrlib/symbol_versioning.py", line 121, in decorated_method
<yoavb>     return callable(self, *args, **kwargs)
<yoavb>   File "/usr/lib/python2.4/site-packages/bzrlib/branch.py", line 1486, in working_tree
<yoavb>     raise NoWorkingTree(self.base)
<yoavb> bzrlib.errors.NoWorkingTree: No WorkingTree exists for file:///tmp/repository/butils/.
<lifeless> yoavb: please use a paste bin rather than pasting such things in the discussion channel. Also read what AfC said to you.
<lifeless> night all
<mwhudson> night lifeless
<Hattory> hi, I wanted to know as I can contribute to the translation of the Italian homepage: http://bazaar-vcs.org/PaginaIniziale
<Hattory> There are some errors
<Odd_Bloke> What's the accepted way of sanitising Unicode strings so they can be displayed on an ascii-encoded output?
<Hattory> i want to edit the italian homepage.... i can take as reference the English hompage? I can translate all?
<AfC> Hattory: (unless the page itself is locked,) the Bazaar website is a wiki so you can just go ahead and edit it
<Hattory> it's open ;D....... i look other hompage (fr, ja ecc...) and they have not translate all.... therefore I wanted to know what I could make
<Hattory> Therefore I can write every thing?
<Lo-lan-do> jelmer: Following your advice, I tried to upgrade my bzr-svn branch, but I ran into problems.
<Lo-lan-do> jelmer: http://paste.debian.net/35561
<jelmer> Lo-lan-do: how public is that repository, could I download a copy of it from somewhere?
<Lo-lan-do> The SVN repo cannot be accessed anonymously unfortunately, but I can upload my branch somewhere if that helps.
<Lo-lan-do> I'll upload a tarball of the branch, with the code and the .bzr dir (but not the .bzr.backup)
<Lo-lan-do> Uploading to http://mirobole.placard.fr.eu.org/~roland/tmp/gforge-trunk+bzr.tar.gz -- ETA 15:30 UTC (half an hour, give or take a few minutes)
<ssh_rdp> Hi, Is the bazaar encrypted branch (SoC2007 Project) usable now?
<bigon> hi
<bigon> I have a question, is it possible to add a post-commit hook on a remote branche?
<jelmer> Lo-lan-do: thanks
<Lo-lan-do> jelmer: Upload complete.  Beware, it's 119 MB.
<ollie> stupid question maybe, but should applying a v0.9 bundle on win32 using 0.18 work?
<ollie> doing "bzr merge foo.bundle" results in: "Nothing to do"
<ollie> searching for "bundle" in the bug tracker didn't result in any hits that looked promising
<jelmer> ollie: Means all revisions have already been merged
<ollie> jelmer: I don't see them in the log
<jelmer> hmm, not sure then
<jelmer> what does 'bzr missing path-to-bundle' output ?
<ollie> bzr: ERROR: Not a branch C:/.../file.bundle/ (from "bzr missing file.bundle")
<dato> ollie: do you mean a 0.9 or 0.90 bundle?
<hsn_> ah, bzr still at rc1
<ollie> dato: # Bazaar revision bundle v0.9
<dato> okay
<ubotu> New bug: #135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New]  https://launchpad.net/bugs/135320
<Lo-lan-do> Hey, whacky idea: is there a bzr-baz plugin in the works? :-)
<jelmer> Lo-lan-do: there was a spec for it at some point
<jelmer> but I don't think there is anybody working on it
<james_w> abentley: thanks.
<ollie> can anyone suggest a way to test if a bundle is ok?  I've got a bundle generated on windows that I've tried to merge on both windows and os x; using 0.18 on windows and bzr.dev on os x; both tell me there's nothing to do
<james_w> ollie: how did you generate the bundle, i.e. what command and arguments did you use?
<ollie> james_w: I didn't -- a submitter sent it to me
<ollie> as it turns out, after a couple hours of head-banging, I noticed my editor say its encoding is x-UTF-16LE-BOM
<ollie> which seems to be the issue
<ollie> since saving as utf-8 at least tells me line endings aren't \n
<ollie> "nothing to do" isn't the greatest error message, though
<james_w> there is a hidden command called 'bundle-info', try running that and seeing if it reports that there are actually revisions in it.
<ollie> on os x, using bzr.dev I get told it's an unsupported bundle version
<ollie> though, when I try to merge it, I get told it won't because of a missing revision (locally)
<ollie> on windows, using 0.18 (from the installer), it says there's no such command
<james_w> so you now have a different response on osx?
<ollie> sorry, I thought I'd said I was using bzr.dev on os x and 0.18 on win32
<ollie> trying to indicate it's not working anywhere (for me)
<james_w> if you read the bundle and find the revision id of the final revision then you can see if it has been installed in your repository by running bzr log -r revid:<revid> in the branch that you are trying to merge in to.
<james_w> you said "both tell me there's nothing to do", but a missing revision is not "nothing to do"
<ollie> yes, I did say that -- I've fed 3 bundles into 2 different versions of bzr
<ollie> 1: x-UTF-16LE-BOM encoding; 2: saved as utf-8; 3: line-endings converted from \r\n -> \n
<ollie> w/1: "nothing to do"; w/2: wrong line ending; w/3: can't apply because revision is missing
<ollie> sorry if I sound short -- I'm frustrated and I don't think there's anything that can be done to actually apply this bundle
<ollie> anyway, thanks for trying to help, james_w
<james_w> no problem.
<james_w> if you just want to apply then patch will do so.
<james_w> 3 sounds like you have been sent on a bundle that is based on a revision that only you user has.
<james_w> if you look at the parent id of the last revision in the bundle it should be one of your revisions if you want to apply it using bzr.
<ollie> james_w, yeah, it just took a lot of doing to get that far -- and I was surprised that rather than be told the input was bad, bzr said "nothing to do"; also, it's a bit surprising that "bzr merge bundle" says it can't because of the missing parent, but bundle-info says the bundle version isn't supported
<ollie> I mean, if merge can figure out it can't apply the bundle -- surely there's some level of support there ;-)
<james_w> bundle-info was broken for a while because it is hidden command, and only Aaron used it.
<ollie> ah, ok
<james_w> I think that you are getting "nothing to do" because the bundle parser skips stuff that it doesn't understand, and you ended up with nothing, and so got "nothing to do"
<james_w> would you like to file a bug explaining the issues you are having, and telling us how the output could have been more helpful?
<ollie> skips stuff it doesn't understand is pretty crummy
<james_w> I guess bundle with no revisions should get and extra message, "nothing to do, empty or corrupt bundle?"
<bwinton> So, XML is pretty crummy too?  :)
<ollie> sure, i'll file a bug; I mean from a expectation point of view, if it doesn't like it, it should say so -- not just pretend it doesn't exist ;-)
<james_w> it's just working how patch does, so that you can for instance merge from an email without having to extract the right bits.
<siretart> hi EtienneG.
<EtienneG> siretart !
<EtienneG> how ya doin' ?
<siretart> how are you?
<siretart> :)
<siretart> thanks fine!
<EtienneG> I am not so bad
<siretart> are you working on getting bzr 0.90 to gutsy?
<siretart> I've notice that it is in debian for some time
<lifeless> mroning
<lifeless> james_w: have you had someone do the release stuff you need done ?
<james_w> morning lifeless.
<james_w> Aaron merged everything, I'm building the release now, so I will need someone to upload, will you be available?
<lifeless> james_w: sure thing
<james_w> lifeless: http://jameswestby.net/bzr/bzr-0.90.tar.gz
<james_w> and http://jameswestby.net/bzr/bzr-0.90.tar.gz.sig please
<lifeless> on it
<lifeless> james_w: done
<james_w> lifeless: thanks.
* ..[topic/#bzr:james_w] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz
* ..[topic/#bzr:james_w] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz | Complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
* ..[topic/#bzr:james_w] : The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
<james_w> lifeless: there is an item on the checklist to update doc.bazaar-vcs.org. I guess that may be important here with Ian's docs in directories change going in. Are you able to do it or should I ask someone else?
<lifeless> Uhm, I'm not sure where it is; poolie is most knowledgable
<james_w> thanks, I'll speak to him.
<abentley> ollie: When you give merge a URL, it tries to open it as a bundle.  If that fails, it tries to open it as a branch.  Evidently your bundle was in a branch that you were up-to-date with.
#bzr 2007-08-29
<abentley> It doesn't say "nothing to do" if it can't find anything mergeable.
<lifeless> abentley: perhaps it could say '%URL is already fully merged.'
<abentley> Sure.
<lifeless> good morning btw
<ollie> abently, no, it was a bundle it couldn't read; when I opened the bundle in my editor and resaved it as utf-8, I progressed to being told it didn't have \n line-endings; when I changed it to line endings, I was told a parent revision was missing
<ollie> or maybe I'm misunderstand, but based on the progression, that wasn't the scenario
<cprov> lifeless: ping
<lifeless> pong
<cprov> lifeless: I'm running bzr-pqm from gutsy and getting this error:
<cprov> BzrBadParameterUnicode: Parameter content is unicode but only byte-strings are permitted.
<cprov> bzr 0.18.0 on python 2.5.1.final.0 (linux2)
<cprov> arguments: ['/usr/bin/bzr', 'pqm-submit', '-m', '[r=kiko]  Fix #134345 (ppa-tos page), #135186 (ppa page typo), #135385 (configuration files fixes for ppa) and fix poppy to store upload with g+w permission.'] 
<lifeless> cprov: 'bzr plugins' -> pastebin
<cprov> lifeless: have you seen it before ? how can I workaround it ?
<lifeless> run the one from lpdebs probably
<cprov> lifeless: https://pastebin.canonical.com/53/
<cprov> lifeless: right, I have missing upgrades from lpdebs. I hope they will fix the problem. (sorry, I should have checked before). Thanks
<RainCT> hi
<RainCT> I just started pushing something to a new branch in Launchpad but then I realized that I forgot to commit and aborted it (Ctrl + C). Now I get bzr: ERROR: File exists: u'/~rainct/freevial/testing/.bzr': mkdir failed: unable to mkdir each time I try to push it again, and on Launchpad on the branch's page it says      Launchpad could not mirror this branch     41 seconds ago.            The error was:       Not a branch:. I've tried with --use-exist
<lifeless> RainCT: you disturbed it during the initial setup
<lifeless> RainCT: better to let it finish, then commit, then push again to add the additional data :)
<lifeless> anyhow, this should fix it
<lifeless> python
<lifeless> >>> import bzrlib.bzrdir
<lifeless> >>> d = bzrlib.bzrdir.BzrDir.open('sftp://bazaar.launchpad.net/~rainct/freevial/testing')
<lifeless> >>> d.create_branch()
<abentley> ollie: So you are saying the directory your bundle was in was not a branch?
<abentley> And not inside a branch?
<RainCT> lifeless: the "d = ..." says  bzrlib.errors.NotBranchError: Not a branch:
<cprov> lifeless: just for the record,  bzr-pqm (0.13~20070226-0ubuntu2) from lpdebs is working correctly.
<ollie> abentley, sorry, I guess I misunderstood.  the current working directory from which I tried to merge a bundle created by someone else one a separate machine was itself a branch.
<abentley> When you got "Nothing to do", it's because it was merging that branch.
<ollie> ok, because it failed to read the bundle
<abentley> Right.
<abentley> lifeless makes a good point that it should be clearer about what it's merging.
<ollie> it would have been uber-helpful if it had stated that it was unable to make any sense of what I gave it
<abentley> On http, that would mean no branches would ever work.
<abentley> Not to say we can't do better, of course.
<ollie> not being burdened by any implemenation details, it seems completely counterintuitive to pass something to merge and be told there's nothing to do (when you're looking at the bundle in your editor and can see that there is stuff)
<abentley> Well, that can also happen with bundles you've already merged, so the "editor" test isn't very conclusive.
<igc> morning
<lifeless> RainCT: ok
<lifeless> RainCT: you need to login via lftp or sftp and delete everything in that dir
<lifeless> RainCT: then you can replace the d = line with
<lifeless> d = bzrlib.bzrdir.BzrDir.create('sftp....')
<lifeless> and do d.create_repository
<lifeless> d.create_branch()
<lifeless>  - first one should have been do d.create_repository()
<abentley> igc: morning
<igc> morning abentley
<igc> morning lifeless
<ollie> abentley, no, I understand that, but I'm not speaking the abstract -- I'm talking about a scenario where the code didn't exist in the target repo and the conversation (between bzr and I) consisted of my saying "merge it" and it saying "you're good to go!"
<RainCT> lifeless: and how can I connect to it? (does LP even allow it?)
<ollie> anyhow, I don't mean to beat a dead horse ;-)
<lifeless> RainCT: 'sftp bazaar.launchpad.net'
<lifeless> RainCT: or lftp sftp://bazaar.launchpad.net
<abentley> lifeless: You wrote the hooks stuff, right?
<lifeless> yah
<abentley> I'm not finding a lot of documentation on how it's supposed to be used.
<abentley> Add an entry to the Branch dict?
<abentley> via a plugin?
<lifeless> abentley: you want a plugin to add a new hook type, or to hook into one of the hooks ?
<abentley> Hook into one of the hooks.  (post-push).
<lifeless> Branch.hooks.install_hook()
<lifeless> plus
<lifeless> e.g.
<lifeless> Branch.hooks.install_hook('post-push', hook_function)
<lifeless> and to name it, which is a UI convenience
<RainCT> lifeless: ok. deleted it, and python continued saying it isn't a branch, but it seems now I can push to it. Thanks :D
<lifeless> Branch.hooks.name_hook(hook_function, 'my-do-x')
<lifeless> RainCT: cool
<lifeless> abentley: these are on the base clsas of BranchHooks
<abentley> So you install it and then name it?
<lifeless> yeah
<lifeless> naming is optional
<abentley> Does it predate registries?
<lifeless> its just so that when pb's are showing hooks running, that slow hooks are shown as english rather than as the object's __str__
<abentley> Sure.
<lifeless> abentley: No, it didn't seem like a good fit
<lifeless> I guess each hook e.g. 'post-push' could be considered a registry
<abentley> Yeah.  I guess I see why you did it that way.
<abentley> if you were doing it in one fell swoop, it would be something like Branch.hooks.register_hook('post_push', my_push_hook, "My push hook")
<lifeless> yeah. install_hook could sanely take a text_name=None parameter to allow that
<lifeless> the name_hook method came a release after hooks were added
<abentley> Ah.
<lifeless> so I added a separate method so that plugins can do
<lifeless> if get_attr(Branch.hooks, 'name_hook', None): Branch.hooks.name_hook(...)
<abentley> yeah, that's a bit of a lack in python's introspection.
<lifeless> you can get at the signature I believe, but its just not as easy or quick
<lifeless> you need the introspect module which has heinous dependencies IIRC
<abentley> Hmm.
<abentley> When you say Graph.heads should not be on a single-key graph layered on a multi-key graph, why do you say that for heads specifically?
<lifeless> Well heads was under discussion
<lifeless> but more generally part of the work to tune packs is going to be ensure we don't spend a chunk of time just tupling and detupling things
<abentley> Do you think the same thing for find_unique_lca?
<lifeless> so the low level key for the revisions GraphIndex is (revision_id, )
<lifeless> and the Graph object is key agnostic from what I recall - or nearly so.
<lifeless> that is, it really works on key_type:[key_type ...]  -
<lifeless> so just passing in the right key type should allow everything to fit together nicely
<abentley> Okay.
<lifeless> on text indices the low level key is (file_id, revision_id)
<lifeless> so theres more work involved in converting every get_parent request from get_parents(revision_id) - it goes to iter_entries([(file_id, revision_id)] ) and then that gets stripped on return to give a node with parents as (revision_id,), and finally that is restored to just revision_id at the top level adapter
<abentley> Graph isn't the One True implementation of its interface.  There's no need to assume such translation.
<lifeless> I realise that; what John was proposing had that translation.
<lifeless> my reply to him was pointing out that we should avoid it, in however he structured his api.
<abentley> I would really like to have Graph.heads for use in reconcile, which is why I ask.
<lifeless> definately use it
<abentley> And it seems like the only code you actually have a problem with is "g = graph.Graph(entry_vf)"
<lifeless> reconcile is repository format specific
<lifeless> so theres no impact on packs by using it like that
<lifeless> bbiab, grabbing breakfast
<abentley> lifeless: Would a VersionedFile.get_graph() method satisfy you?  Then different VersionedFile implementations can specify their Graph implementation.
<sandrot> is there a changelog available for .90 :
<sandrot> ?
<abentley> sandrot: There is the NEWS file.
<sandrot> k so I have to branch
<sandrot> or get tar
<sandrot> 'pulling' from another person means that the person I'm pulling from needs to have his branch accessible to me via ssh on his own box or via a server he can 'push' or upload to right?
<abentley> pulling works on any of the protocols we support: http, sftp, ftp, bzr, bzr+ssh or local files.
<lifeless> abentley: the problem is the keys that should be returned
<lifeless> abentley: in many respects I want to stop using VersionedFile where dataset partitioning isn't helpful
<sandrot> Mmm, thanks. I was just thinking that because I keep myself  behind a firewall (blocking ssh) in order to have someone pull to me I have to make my branch available to my server which accepts ssh (or other protocols), meaning that in order for me to share my branch I need to push first
<abentley> lifeless: Surely untupling in VersionedFileGraph.heads isn't expensive.
<lifeless> abentley: if it occurs only at the interface surface it isn't a problem
<lifeless> occuring all the way down is a problem
<abentley> Right.
<abentley> So doing vf.get_graph() would allow us to avoid doing it all the way down.
<lifeless> ok
<lifeless> I guess my hesitation is trying to avoid the vf interface except where it clearly makes sense. Which is probably over-exaggerated at the moment. So vf.get_graph sounds fine.
<lifeless> Hmm, I think what I want to achieve is decoupling 'file history' vs 'text construction'.
<lifeless> file history queries tend to be one off operations, not part of large things like 'branch' 'checkout' etc
<abentley> That's fair.
<lifeless> text construction tends to be part of things like merge, and thats where the artificial VF interface causes roundtrips.
<lifeless> text insertion likewise, though we can queue that to avoid round trips more effectively
<bartt> Are nested repositories working?
<bartt> I don't seem to be able to add a nested repository.
<bartt> E.g. bzr add path/to/nested/repository only reports # of ignored files
<abentley> lifeless: You are the person who wants to select graph ancestors on a per-file basis, though.
<abentley> bartt: You cannot add a tree into another tree.
<lifeless> abentley: I don't think I'm the *only* person :).
<abentley> Yes, but surely doing VersionedFileGraph.find_unique_lca is the obvious approach.
<lifeless> abentley: per file lookups can be grouped though
<lifeless> thats the obvious approach, and as long as the repo its being queried on is local it will perform fine
<abentley> And at present, the repo being queried is always local.
<bartt> abentley: I thought that nested tree support was added in 0.15?
<igc> So more reviews today from me starting with abentley's TreeTransform rollback one
<abentley> bartt: No, only support code.  It is not complete.
<igc> abentley: were you planning to tweak anything following Kuno's feedback or should I review it as is?
<bartt> Thanks abentley
<abentley> igc: The only thing is that I should handle errors creating the pending-deletion directory the same way as errors creating limbo are handled.
<igc> abentley: I was hoping you'd say that
<igc> I'll go ahead and review and ask for that tweak
<abentley> Okay.
<sandrot> What exactly does a repo with or without "trees" mean? what exactly is a tree?
<abentley> Thanks.
<lifeless> igc: I'm going to profile commit performance with packs today.
<sandrot> erm, what is a tree in the context of a shared repo
<igc> lifeless: great. I'll push my latest code this morning in case it's of interest
<lifeless> igc: I'm focused on repository interactions immediately.
<igc> np
<lifeless> I want to see how slow the repo layer is
<lifeless> or has to be
<lifeless> igc: also, how should we collaborate; I'm working in packs; I can spin off patches for bzr.dev easily.
<lifeless> but not for your branch as easily
<lifeless> my patches should be small but frequeny. Does this work for you ?
<igc> lifeless: I'm still a few days away from using the commit-candidates branch effectively ...
<lifeless> righto
<poolie> abentley, what igc said about the merge queue goes for me to
<igc> I need to get commit changed to incremental vs 'build from scratch' first
<poolie> too
<abentley> poolie: Glad to hear it.  I think we have the right intentions, it's just a juggling act.
<igc> so lifeless, if you can keep pushing hard on packs and getting bzr.dev closer to using them, I'm good with that
<sandrot> what does a 'tree' mean in the context of a shared repo...what happends to branches in a repo when I run init-repo --trees versus init-repo --no-trees ?
<abentley> sandrot: A tree is the directory (and subdirectories) that contain your source code in editable form.  See bzr help working-trees.
<sandrot> abentley: thanks, I'm just finding it now actually
<sandrot> I read a lot of shared repo docs but didn't read http://people.ubuntu.com/~ianc/doc/en/user-reference/bzr_man.html#repositories yet
<sandrot> seems that a working tree is similar to svn's working copy
<abentley> The big difference is that SVN's working copy is never in the same location as a branch or a repository.  In Bazaar, the SVN layout is called a 'checkout'.
<abentley> A lightweight checkout, to be precise.
<sandrot> Mmm, I always assumed the working copy was the copy of code you're currently working on. So when I checkout a branch my checkout is now a 'working copy'
<abentley> In SVN, that's the only way of getting a working copy.  But with Bazaar, "branch", "init" and "push" can also create objects with working trees.
<sandrot> push doesn't create a working tree thought right? you can checkout or branch from a pushed location
<abentley> When you push to a local location, it creates a working tree, and yes, you can checkout or branch from a pushed location.
<abentley> Push always creates a branch, and on local locations, it also creates a working tree.
<abentley> creates *or updates* I should say.
<ubotu> New bug: #135421 in bzr "different exit code for internal errors" [Wishlist,Triaged]  https://launchpad.net/bugs/135421
<abentley> igc: Shouldn't NEWS.html be up somewhere on doc.bazaar-vcs.org?
<igc> yes
<igc> abentley: it looks like doc.bazaar-vcs.org is yet to be upgraded following the 0.90 release ...
<igc> poolie has done this in the past for the RM
<igc> I'm pretty sure I have permissions now so I can do it I think
<abentley> Do we even have a link to NEWS in the documents?  I tried a few guesses at the URL...
<abentley> but it was 404 city, baby.
<igc> see http://people.ubuntu.com/~ianc/doc/ for what 0.90 will look like ...
<igc> clicking on "Release Notes" takes you to NEWS.html
<abentley> Beauty.
<abentley> We gotta turn that TOC into a sidebar or something.
<abentley> Any progress with getting the pretty version of the docs online?
<igc> abentley: see http://people.ubuntu.com/~ianc/pretty_docs/ for the current pretty-docs output as well
<igc> by 'current', I mean a snapshot from a week or so back of course
<abentley> Sure.
* netjoined: irc.freenode.net -> kubrick.freenode.net
<lifeless> spiv: ping - calls?
<lifeless> poolie_: I see 3 failures
<lifeless> and one of those is due to the failure to isolate CFLAGS
* igc lunch
<poolie_> lifeless, only 3?
<poolie_> hm
<poolie_> have you pushed to your knits branch recently?
<poolie_>  because that's where i pulled from
<lifeless> poolie_: its one commit behind
<poolie_> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ right?
<lifeless> http://people.ubuntu.com/~robertc/baz2.0/repository is the canonical location
<poolie_> lifeless, i'll check that one then
<lifeless> one thing that concerns me ian, for commit performance
<lifeless> is that we're three times slower than hg, but I'm seeing our gzip time as dominating
<lifeless> at 80% of profiled time
<abentley> lifeless: Potentially, you want to store uncompressed knit records, and then gzip the whole container.
<abentley> Maybe faster, probably better compression.
<lifeless> abentley: I'd love to know precisely what git's packing algorithm is
<lifeless> I think I'm saying 'there is something wrong' when hg's commit is faster and our time is in gzip
<lifeless> not that I disagree with your point
<poolie_> lifeless, ok, in that branch i have only 2 failures
<tonyyarusso> Hi, I'm not familiar with version control systems at all (yet), and I was wondering if someone could either explain or give a link to a good explanation of how bazaar compares to things like SVN, CVS, and git.
<jeremyb> istr that bzr's wiki has a really good explanation
<jeremyb> i think wikipedia has something too
<jeremyb> +comparison for both
<jeremyb> http://bazaar-vcs.org/SCMComparisons
<jeremyb> http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
<jeremyb> http://better-scm.berlios.de/
<tonyyarusso> jeremyb: Cool, thanks
<abentley> tonyyarusso, jeremyb: The better-scm site is pretty useless.  I would avoid it.
<jeremyb> hah
* jeremyb is reading http://better-scm.berlios.de/to-avoid/
<jeremyb> not that i would ever consider using MS Visual SourceSafe anyway
<abentley> I was unable to convince the author that baz and bazaar are difference VCSes.
<jeremyb> heh
<abentley> So Bazaar is listed under "Arch", completely inappropriately.
<jeremyb> yeah, i see it doesn't have it's own listing in the sidebar
<jeremyb> never heard of vesta before
<jeremyb> "Note: related to Bazaar, is Bazaar-NG, which is written from scratch by the same parent company. It aims to offer some advantages over Bazaar, but is not an Arch implementation, nor is it compatible with Bazaar. A tool is available to convert Bazaar repositories into Bazaar-NG, but not the other way around.
<tonyyarusso> Looks like git is sort of specialized and limited-use, CVS is becoming obsolete, and if I was going to learn something it should be Bazaar, Subversion, or both.  Does that sound accurate?
<jeremyb> "CVS is becoming obsolete" yes from some perspectives :)
<tonyyarusso> Well, it lacks a number of features listed for other ones, and others (like Subversion) are listed as improvements on it.
<jeremyb> git, bazaar, *and* mercurial not or :)
<tonyyarusso> I know O'Reilly has a Subversion book - is there a comprehensive guide for Bazaar yet?
<jeremyb> tonyyarusso: oh, sorry i misread.  i thought that abentley provided the quote in jest.  i will provide a better answer :)
<jeremyb> CVS is becoming obsolete by most standards although is occasianally used for new projects and has some diehard fans
<fullermd> CVS is long since obsolete.  What it is, is _known_.  People have decades of history in it, and know it inside and out.  That's worth something.
<jeremyb> right
<jeremyb> i wouldn't say git is specialized or limited use but it does have quirks and it's got some small hurdles for windows users.  git and mercurial both have support for syncing with svn.  git has more mature biderectional support.  bzr has not quite stable support for writes to svn last i heard and i think the read support is better.  afaik mercurial doesn't have any
<abentley> I was not joking.  He cannot get his facts straight.  If you read that site, you will know less about version control than you did beforehand.
<jeremyb> abentley: i thought that tonyyarusso's line quoting the site was you talking
<jeremyb> superficially bzr, hg, and git all implement the same principles but there are variations
* jeremyb tries to remember the good (or at least i remember people saying it was good) bzr/hg blog post
<jeremyb> abentley: well both his bazaar and bazaar-ng links redirect to bazaar-vcs.org so it shouldn't be too hard to convince him that they are the same.  but convincing him that he used the wrong link might be a challenge
<jeremyb> abentley: how recently did you try to convince him?  the arch page has an almost 2 year old timestamp
<abentley> I've got no interest in trying to convince him any further.  He's demonstrated that he will just ignore inconvenient facts.  He's not worth thinking about.
<jeremyb> hah, that site has an empty irc channel
<jeremyb> abentley: i was just wondering
* jeremyb ponders
<jeremyb> i was sure CVS allowed copies retaining history for the original and the new file.  (people file bugs to get those copies done for the mozilla repo all the time)  his comparison says CVS doesn't support them...
<mdmkolbe> I enjoy learning new systems and I've just come off of learning and using darcs at an intermship.  I've learned to like the distributed model (I'm a former svn user), and am looking for a system to use on my own projects.  (I'll have compile and install at as a non-root accout.)  I'm consiering mercurial, bzr and git.  Can anyone point to or give a good comparisen of these?
<jeremyb> they all can be installed in your home dir
* jeremyb wonders what's happening with forest (or was that hg?)
<jeremyb> mdmkolbe: what OS?
<mdmkolbe> jeremyb: both linux (as non-root) and windows/cygwin (but I administer that system so root isn't such an issue)
<jeremyb> hrmm
<jeremyb> git isn't supported as well on windows but i've never tried it (i think there's some performance issues too but neither of those are based on recent data)
<jeremyb> mdmkolbe: depends how much time you have.  personally i'd just try them all
<jeremyb> on a small scale not for a real project
<jeremyb> (i have used git and mercurial a bit not so much bzr)
<mdmkolbe> jeremyb: I'm a motivated learner except that school has started and my brain is filling up to the point where I'm discovering the need to choose what I will and won't learn (which is sad, but I guess it's part of getting older.)
<AfC> mdmkolbe: my personal response to your question about which version control system to use is in http://research.operationaldynamics.com/blogs/andrew/software/version-control/git-is-like-cvs.html
<jeremyb> whoa, git is like cvs?
<fullermd> jeremyb: CVS doesn't.  Manual mucking around in the repository does.  Sorta.
* jeremyb reads
<jeremyb> fullermd?
<jeremyb> doesn't what?  ohh, moves?
<fullermd> Yah.
<lifeless> fullermd: well it can record moves as well as git can
<fullermd> Harsh.
* lifeless is both trolling and completely serious, simultaneously
* jeremyb understands
<lifeless> food time
<jeremyb> fullermd: well, for mozilla, it's automated to the point where you hand a script a text file with source and destination on a single line seperated by a space and it takes care of everything
* mdmkolbe puts one more stroke in the tally for bzr after reading
<fullermd> Yeah, but what it takes care of is still a mess.  And CVS doesn't know anything about it.  You just sorta have the history of the file available.
<mdmkolbe> What repository format does bzr use?  (I ask b/c of the claims in http://keithp.com/blog/Repository_Formats_Matter.html)
<AfC> mdmkolbe: a constantly improving one
<AfC> mdmkolbe: And I disagree with Keith (who is, incidentally, a good friend of mine); tool usability is what matters.
<AfC> mdmkolbe: and despite the rather appealing-at-first-glance notions inside Git, I have LOST DATA with Git and NEVER LOST DATA with Bazaar.
<mdmkolbe> to summarize the linked article "git is good b/c each file is writting once then never touched again; hg is bad b/c it appends to the files on each commit"
<mdmkolbe> AfC: heh, that kind of puts Keith's claims in perspective
<AfC> mdmkolbe: we've all read it. Most of the people here are _also_ good friends with Keith.
<fullermd> I'm not.  I'm a poor pathetic outsider, clutching at windowsills and begging for scraps of bread.
* AfC goes out for coffee
* fullermd hits up AfC for spare change on the way.
<mdmkolbe> How well does bzr support "software archiology"?  One of the troubles with darcs I found was that of trying to track down the historical context of a change (that introduced a bug I'm attempting to fix) that isn't always captured by the patch dependancy graph.
<jeremyb> hg has a built in function to do a binary search for the bug
<jeremyb> i don't remember who else has what
<mdmkolbe> jeremyb: ?!
<jeremyb> all have pretty good history viewing tools
<jeremyb> mdmkolbe: ?
<jeremyb> mdmkolbe: you know what a binary search is, right?
<mdmkolbe> jeremyb: yes, but that's not something I expected from a VC system.  You just point it at 'make' and your program and ask it to recompile until the search find the change causing the bug?
<jeremyb> i've never used it
* jeremyb looks
<jeremyb> http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension
<mdmkolbe> jeremyb: thx for the link
<jeremyb> sure
<fullermd> darcs is a special case there, since it doesn't do historical context...
<jeremyb> darcs drives me nuts!!!
<fullermd> I always say, why drive when it's close enough to walk   ;)
* jeremyb thinks...
* jeremyb knows he's missing something...
<jeremyb> who's brian o'sullivan?
<jeremyb> something wrong with his repo
<jeremyb> or at least the web frontend
<jeremyb> http://hg.serpentine.com/mercurial/hg/book/book/convert/book/book/book/book/book/book/book/
<fullermd> /bork/bork/bork?
<igc> mdmkolbe: if you haven't seen them already, http://bazaar-vcs.org/BzrWhy lists several blog posts explaining why Bazaar is better than most alternatives (in our opinion)
<jeremyb> oh, ooops
<jeremyb> brian o'sullivan and that repo are both hg
<abentley> Nice guy, though.  Wish he were on our team.
<poolie_> mdmkolbe, there is a bazaar bisect extension which might be more to the point
<poolie_> there is also iirc 'darcs trackdown' which i think was the first system to have it
<lifeless> poolie_: there was an IBM paper on this at LCA 2004
<lifeless> describing the technique for tracking down gcc regressions automatically
<poolie_> based on cvs
<lifeless> yes
<poolie_> ok, so darcs may have been the first to generalize and automate it
<poolie_> or maybe not
<poolie_> lifeless, btw where you wishing for a different behaviour in vim ^O?
<poolie_> maybe that was someone else?
<lifeless> dunno
<poolie_> anyhow, g; takes you to the place you last changed the text
<lifeless> yup
* fullermd didn't know that.
<fullermd> I usually fake it with undo.
<jeremyb> heh
* jeremyb has done the faking as well
<jeremyb> any of ya'll actually work for canonical?
<jeremyb> who's mccormickit.com?
<mdmkolbe> where is the repo for bzr?  is there a web front-end?  (I mean the repo for the source to bzr)
<jeremyb> yes
<mdmkolbe> I couldn't find it from the bzr website (maybe I'm just looking in the wrong place)
* jeremyb is finding it
<jeremyb> http://bazaar-vcs.org/bzr/
* jeremyb looks some more
<jeremyb> having trouble finding a frontend hosted by the main project but i see 2 front ends for the main repo
<jeremyb> http://codebrowse.launchpad.net/~bzr/bzr/trunk
<jeremyb> http://goffredo-baroncelli.homelinux.net/bazaar/bazaar-NG-dev
* jeremyb remembers a better frontend for git, bzr or hg but is having trouble finding it
<lifeless> jeremyb: yes, some of us work for canonical
* jeremyb runs across https://blueprints.launchpad.net/bzr/+spec/ignore-versioned-files
<lifeless> https://code.launchpad.net/~bzr/bzr/trunk is the launchpad mirror of bzr.dev
<lifeless> http://codebrowse.launchpad.net/~bzr/bzr/trunk
<lifeless> is a web ui to browse it
<thumper> does bzr diff require a checkout?
<jeremyb> haha
<jeremyb> thumper: you already have a copy locally.
<thumper> jeremyb: no, I don't
<thumper> I have a branch
<thumper> perhaps I should have said WorkingTree
<thumper> lifeless: how come I can't do "bzr diff -r-3..-1" on a branch without a working tree?
<spiv> thumper: https://bugs.launchpad.net/bzr/+bug/6700
<ubotu> Launchpad bug 6700 in bzr "bzr diff -r 10..20 http://foo" unsupported" [High,Confirmed] 
<thumper> spiv: so a working tree is needed?
<thumper> arse
<lifeless_> 15:20 < lifeless> thumper: patches gratefully arsed
<lifeless_> 15:21 < lifeless> igc: ^ remember this bug ? :)
<lifeless_> 15:22 < lifeless> ok, thats 9ish hours, I'm calling it a day.
<lifeless_> 15:22 < lifeless> igc: poolie and I think a gzipless repo might be an interesting test, so I'm going to overhaul the knitversionedfile code some more tomorrow
<igc> lifeless: yes, haven't forgotten it :-)
<thumper> lifeless: :) unfortunately I have other priorities right now
<igc> lifeless: yes, an interesting test indeed
<igc> thumper: FWIW, lifeless gave me that bug on my first day at Canonical. :-( It's still on my list but behind performance work
<thumper> igc: as long as it isn't forgotten :)
<igc> thumper: no risk of that :-)
<mdmkolbe> thx all for your help
<AfC> Eeek. What does "Not running as bzrlib.plugins.gtk, things may break." mean?
<AfC> [bzr 0.90.0, bzr-gtk 0.90.0] 
<AfC> ... and indeed, `bzr viz` crashes.
<dato> AfC: that the bzr-gtk plugin is not installed in a directory named just "gtk"
<AfC> Yes it is... er, no its not. Typo on my part. Shit.
<AfC> Called it "bzr" not "gtk". That was stupid...
<AfC> (in ~/.bazaar/plugins)
<AfC> dato: thanks
<dato> np
<tolonuga> can anyone edit http://doc.bazaar-vcs.org/bzr.dev/server.htm and replace ":1234" with ":4155"? thanks.
<jeremyb> tolonuga: looks like it's generated from this file: http://codebrowse.launchpad.net/~bzr/bzr/trunk/annotate/pqm%40pqm.ubuntu.com-20070825182243-a3w20rpadbfz8euc?file_id=server.txt-20060913044801-h939fvbwzz39gf7g-1
<jeremyb> tolonuga: so, anyone that can checkin there...
<tolonuga> ok, thanks. unfortunatly I can't checkin, I'm only a stupid user looking at docs and finding tiny issues. will open a bug if noone responds here, so the issue is not forgotten.
<mwhudson> tolonuga: you could send a bundle to the mailing list, that's the usual way for things like this
* igc dinner
<tolonuga> how can I create a mail in bundle format from a local commit? preferable something I can cut&paste into my mail app - I don't want bzr to send email itself.
<fullermd> bundle will spit out a bundle on stdout; you can redirect that into a file, then attach it.
<tolonuga> ah, thanks!
<markvandenborre> I'm looking into using bzr to manage a few django (web framework) projects I am working on together with a friend
<markvandenborre> I would regularly be working offline (on the train)
<igc> night all
<markvandenborre> up-to-date code would be needed on each of our machines, plus an external webserver
<Odd_Bloke> igc: Night!  Thanks for the merges. :)
<markvandenborre> what kind of workflow would you recommend?
<Odd_Bloke> markvandenborre: You could just use a centralised workflow, because you can commit locally when working offline...
<markvandenborre> ok, will be investigating that path
<markvandenborre> Odd_Bloke, thx a lot!
<Odd_Bloke> markvandenborre: That's not necessarily the only/best one to use though.
<Odd_Bloke> But it would work.
<markvandenborre> Odd_Bloke, I figured I would really need a feature like local commits because of my long train commutes
<markvandenborre> Odd_Bloke, you think that would be the easiest way to get started with bzr?
<Odd_Bloke> markvandenborre: If it makes sense in your situation, then do it. :p
<markvandenborre> :)
<markvandenborre> is it bad policy to setup a central repository for web projects on a production webserver?
<markvandenborre> it's not a leaky php server, and only running sshd and apache, but still...
<markvandenborre> I can imagine it's not a good thing to have both on the same server, even if it's very well managed
<markvandenborre> any thoughts?
<markvandenborre> would it be better to put the bzr repository on a physically separate machine?
<dato> lifeless: I'm uploading 0.90-1 to debian. I guess some ubuntu person will have to make sure it makes through UVF.
<fullermd> markvandenborre: That sounds like a site policy question.  bzr certainly wouldn't care.  It's not hard to move stuff around later if you change your mind...
<markvandenborre> fullermd, yes, it is a site policy question... trying to be careful about setting things up with minimal overhead, but still safe
<markvandenborre> fullermd, your remark about easy of moving is definitely interesting!
<markvandenborre> thx!
<fullermd> As a handwavy position statement, I tend to think that if a server gets cracked, the VCS history is probably one of the least interesting things on it...
<markvandenborre> you're probably right about that
<fullermd> (situations change cases, of course, but as a general rule)
<fullermd> I'm all about putting all your eggs in one basket, and watching that basket like a hawk   ;)
<markvandenborre> now on a machine without php, with only 80 and 22 open, that might be a sound policy
<markvandenborre> you're probably right that I'm too paranoid
<fullermd> On the flip side, if there's no particular reason _not_ to have the central repo on the server server, there's also probably no particular reason _to_ have it there.
<markvandenborre> fullermd, it's a bit stupid to put up a separate (virtual) machine just for bzr
<fullermd> Probably, yeah.
<cnus8n> hi, is there any link to a tutorial on setting up a bazaar with webdav?
<laga> hey guys. i've just done a "bzr revert" - how can i revert the revert itself?
<laga> eg undo it?
<markvandenborre> Odd_Bloke, in the situation that I just described (2 developers, web development, frequent offline commits), is there also a comfortable way to do without a central repository?
<gabe_> laga: just revert to the most recent commit
<gabe_> markvandenborre: you can use push/pull
<gabe_> markvandenborre:  i.e. a decentralised system
<laga> gabe_: i made a change, reverted said change and now i want to go to the state before the revert
<gabe_> if you don't have a commit of that change then you can't
<gabe_> unless you manually redo it
<siretart> lifeless: are you working on getting bzr 0.90 into gutsy?
<markvandenborre> gabe_, thx
<laga> gabe_: thanks.
<markvandenborre> gabe_, how would I then be able to sync stuff with the other guy when I am at a remote site?
<laga> gabe_: lucky me - it was not a crucial change :)
<gabe_> markvandenborre: np you can read all about pull push and merge on the documentation part of the bazaar site
<gabe_> yer
<gabe_> markvandenborre:  to sync stuff with a remote computer you would need access to it via the internet. I personally have ssh setup. In this case you can push or pull bzr repositories using sftp
<gabe_> does the other guy have ssh running?
<markvandenborre> gabe_, yes, but his provider blocks every port below 1024
<gabe_> well either get him to run ssh daemon on a high port
<fullermd> Well.  There are two distinct questions here...
<gabe_> or try http or the built in bzr server on  a high port
<fullermd> One is "do you work centralized [i.e., on a shared branch]  or decentralized [on individual branches you merge back and forth] ".
<gabe_> but you would also need port forwarding if he is beind a NAT or firewall
<fullermd> The other is "If (b), how do you access each other's branches"
<gabe_> markvandenborre: in this case I think it is easiest to have a central server that you can both push or pull from
<fullermd> You can go (b) decentralized, with no shared trunk, but still use a central server to reach each other's branches.
<gabe_> so he can put his changes on the server and you can pull them to yur comptuer
<gabe_> then you don't need to worry about firewall, NAT, and blocked ports
<AfC> fullermd: that's more or less what we do
<mdmkolbe> In bzr what is the correct way to construct a self contained set of patches to be sent upstream? (e.g. darcs send --output foo.patch-bundle)
<dato> mdmkolbe: `bzr send -o foo.patch-bundle` should work
<dato> mdmkolbe: if your bzr is a bit old and does not have send, use `bzr bundle >foo.patch`
<fullermd> For values of "a bit old" that mean "some ancient version released more than 18 hours ago"...
<dato> fullermd: oh, 0.18 didn't have it?
<mdmkolbe> data: there is no "bzr send" in my version ... ok bundle-revisions works
<mdmkolbe> thx
<fullermd> Nah, the send stuff is new in 0.90.
<dato> mdmkolbe: it should be smart at guessing what to diff against, but you can specify the location of the branch you branched from as an argument
<mdmkolbe> dato: if it guesses wrong will that be detected at patch application time?  (e.g. take A and make branch B from it;  commit a change to B; branch C from B; commit a change to C that depends on changes made in B;  make a patch that should have been between C and A but I did it wrong and it's actually from C to B and try to apply that to A).
<dato> mdmkolbe: it will be detected because it will fail to apply. and note that, while "a change to C that depends on changes made in B" makes sense in the darcs world, in bzr if you branch from B, revisions in C will *always* depend on revisions in B even if the changes are in different files
<dato> (so it is normally recommended that you branch from A instead of B if you know the changes are independent)
<mdmkolbe> dato: thx, the "note that..." part actually helps my understanding of the bzr model quite a lot.
<dato> :)
<mr_daemon> Hello!
<mr_daemon> I just got into bazaar, and I quite like it so far. I might event switch from svn, actually. However I can't get sftp:// or bzr+ssh:// to work with the Windows client... I used the standalone installer...
<mr_daemon> This is basically what happens: bzr: ERROR: paramiko.SFTPError: Garbage packet received
<bwinton> Can you stfp or ssh in to the same server from your Windows box?
<mr_daemon> Yes, it works fine.
<mr_daemon> I can checkout, get, pull and push to that server with a Linux or OS X client
<bwinton> Did you google "paramiko.SFTPError: Garbage packet received"?
<mr_daemon> I must admit I didn't because I just noticed the error above the stack trace as I came on here. So, to google it is.
<bwinton> (It looks like it's a bug in the version of Paramiko that ships with the Windows installer...  Which version of bzr are you using again?)
<bwinton> https://lists.ubuntu.com/archives/bazaar/2007q2/024210.html
<mr_daemon> I'm using stable, which is 0.18
<bwinton> Hmm...  (I think that's what I'm using as well, but I might have upgraded to 0.90...)
<bwinton> (Oops., coffee time.  Back in a few.)
<mr_daemon> Yeah, I'm overdue for a break as well. Thanks for you assistance, too :)
<bwinton> My pleasure!  Hopefully someone can help you out a little more...
<Lo-lan-do> What's the difference between sftp:// and bzr+ssh://?
<Lo-lan-do> (I mean, the user-visible difference, I don't much care about the internals :-)
<bwinton> One uses SFTP, the other uses ssh to spawn a bzr process on the remote machine...
<fullermd> One uses sftp, the other uses bzr over ssh  ;)
<bwinton> Dang.  I dunno, then.
<mr_daemon> Well, when I try bzr+ssh the error is a tad more explicit, it prints out the output from the ssh server.
<mr_daemon> bzr: ERROR: Generic bzr smart protocol error: bad response ("user@host's password: \r")
<Lo-lan-do> Maybe it only works with ssh keys?
<Lo-lan-do> (Feel free to ignore me, I haven't touched Windows in years)
<mr_daemon> Could be. Let me try, I'll just pop a public key in with putty then try again.
<mr_daemon> haha, that's fine. I'm more of a unix guy stuck on windows right now, so I'm just trying to cope.
<asabil> hi all
<asabil> is there any way to be able to checkout on repositories ? (not branches)
<fullermd> No.
<asabil> so that it would be possible to checkout the root of the repository and get all the projects (that's what svn users are used to apprently)
<asabil> fullermd: what would you suggest then ?
<asabil> creating one huge branch ?
<Lo-lan-do> Multiple branches linked with the subtree thingy?
<asabil> oO, how do you link branches ?
<asabil> any doc ?
<fullermd> Eek, no...   I suggest managing user expectations.  With a blunt object   ;)
<Lo-lan-do> Haha, doc.
<fullermd> Well, first I think you finish implementing subtrees...
<asabil> ???
<dato> asabil: it's easy to write a small script that downloads all existing branches in a repository, and there is already code (in bzrtools) to update all of them with one command.
<asabil> ok dato, the thing is just that I have to deal with windows developers, and I need to make it as stupid-proof as possible
<asabil> thanks
<mr_daemon> Okay I just tried with public/private keypair, and it seems paramiko is ignoring the ssh agent and still asks for a password...
<dato> well, then you'd probably want for that small script to be a command in bzrtools, but it does not exist yet.
<NamNguyen> does anyone know how bundlebuggy work?
<bwinton> abentley does.
<NamNguyen> he sure does, but he's not around
<NamNguyen> does pqm allow me to review patches before merging them?
<NamNguyen> there is so little docs on either of them
<bwinton> I believe it does, since people on the bzr list talk about merging patches manually...
<NamNguyen> bwinton, i might have made myself unclear but by reviewing i was refering to a similar approach as bundlebuggy
<bwinton> For instance...
<NamNguyen> i.e. it's gotta be approved before being merged
<fullermd> pqm merges when you send it.  You review before that.
<mr_daemon> OKAY nevermind me. Actually bzr 0.18 on windows, the self-contained bundle, works with sftp -- but you have to use ssh keypairs.
<NamNguyen> that's what i understand from the description
<mr_daemon> Somehow the password prompt makes paramiko choke.
<NamNguyen> fullermd, do you know if bundlebuggy talks to pqm to initiate the merge after a merge request is approved?
<fullermd> AFAIK, bb and pqm don't have anything at all to do with each other.
<fullermd> bb just grabs patches off the ML and keeps track of who's voted what on them.
<NamNguyen> then how is patch merged?
<fullermd> One of the developers mails it to pqm.
<NamNguyen> by forwarding?
<fullermd> I think most of 'em use a bzr plugin.
<fullermd> I don't think you can forward a patch to pqm, you send it a command and a branch location to merge from.
<NamNguyen> does that mean 1. the developer merges the patch himself, 2. he publishes that branch, 3. pqm then merges from it?
<fullermd> Yah.
<NamNguyen> woot, quite some work there
<NamNguyen> pqm could have just read a merge directive
<fullermd> Well, in much the sense that bzr could have just run server-side hooks via the smart server...
<NamNguyen> what kind of hook? i only know about post_commit hook
<fullermd> Any hook.  It was an abstract comparison.
<NamNguyen> oh, alright
<fullermd> Either one is just a SMOP.  Nobody's done the P.
<fullermd> (at least, I don't think anyone has)
<mr_daemon> Wait -- bazaar has post_commit hooks too? Okay, I'm definitely sold.
<NamNguyen> mr_daemon, er, what VCS doesn't have post_commit hook?
<NamNguyen> i'm curious
<mr_daemon> Well, I was just spoiled by how easy it was to write a post commit hook for subversion.
<mr_daemon> But actually -- Darcs doesn't.
<mr_daemon> Which was the only other VCS I actually sort-of liked.
<mr_daemon> Well, before bzr that is.
<Lo-lan-do> Does RCS have hooks? :-)
<fullermd> I think RCS _is_ a hook   :p
<Lo-lan-do> Good point.
<kanhaiya_kk> NamNguyen: hi
<kanhaiya_kk> you there ?
<kanhaiya_kk> can anybody help me ?
<kanhaiya_kk> i ll tell me present status first
<bwinton> Maybe.  What's your problem?
<kanhaiya_kk> i have checkedout the source on .16 and .17 machine
<kanhaiya_kk> same source
<kanhaiya_kk> first i edited the test.html file on .16 machine and then on .17
<kanhaiya_kk> and then i done commit and update
<kanhaiya_kk> first on .16 and then on .17
<kanhaiya_kk> while doing on .17 it was giving some errors...due to conflicts.
<kanhaiya_kk> so how to resolve such conflicts ? or is there any other method to handle such situation ?
<kanhaiya_kk> bwinton: now your turn.
<bwinton> Googling for "bzr how to resolve conflicts" gives me the following urls:
<bwinton> http://muffinresearch.co.uk/archives/2007/06/05/dealing-with-conflicts-in-bazaar-version-control/
<bwinton> http://bazaar-vcs.org/Tutorials/CentralizedWorkflow#id16
<kanhaiya_kk> bwinton: okay thank you
<bwinton> Are either of those helpful?
<kanhaiya_kk> i ll check and get back to you
<bwinton> (OOps, that second one should have been http://bazaar-vcs.org/Tutorials/CentralizedWorkflow#merging-changes-back instead...)
<kanhaiya_kk> okay wait
<kanhaiya_kk> bwinton: that somewhat manual process...
<kanhaiya_kk> how can we avoid for conflicts ?
<kanhaiya_kk> bwinton: because, if group like us working on same project means, conflicts ll take place every hour.
<kanhaiya_kk> so i want to avoid such situations.
<dato> kanhaiya_kk: conflicts only arise when two people modify the same line in incompatible ways. that should be less frequent that you paint.
<kanhaiya_kk> dato: okay
<kanhaiya_kk> if 2 developers edit the same file, but not the same lines, then conflict ll not arise na ?
<dato> kanhaiya_kk: no, it won't
<kanhaiya_kk> okay good
<kanhaiya_kk> i ll test it...wait
<bwinton> Cursed IRC client...  Did I miss anything?
<dato> 17:23 <kanhaiya_kk> i ll test it...wait
<dato> that was the last line
<bwinton> 'k.  Cool, thanks!
<bwinton> (Say, does anyone know if there's a way to get ubotu to msg me the last n lines?  So that I don't have to ask next time?)
<kanhaiya_kk> dato: thanks...it is working fine
<ness> Hi, I want to factor out some functions of one source file into a new one. Can I somehow make bzr sorta retain the version history of these functions (for merging)?
<bwinton> This is getting kind of tiresome...
<mwhudson> so i'm talking about bzr at pyconuk in a couple of weeks
<mwhudson> my slides are at http://python.net/crew/mwh/pyconuk07_bzr.pdf
<mwhudson> comments welcome :)
<james_w> ness: no, sorry that is not possible.
<bwinton> mwh: "Bazaar aims to be safe, friendly, free and fast" In that order?
<ness> james_w: ok
<mwh> bwinton: it's what bazaar-vcs.org _used_ to say on it's front page
<NamNguyen> i dont quite get the idea of "aims to be free"
<NamNguyen> it's either free, or non-free
<bwinton> mwh: On "Working With Others", you might want to mention that push doesn't update the remote server.  i.e. the files won't be there.
<mwh> bwinton: hmm
<bwinton> mwh: Colour in your pictures would be nice, if its easy to do.  If not, they're fine...
<bwinton> (I mention the push-not-update because it bit me when I started, and has bitten at least three other people that I've seen...)
<mwh> i was engaged in extreme rushing for a deadline with the pictures, but it got pushed back
<NamNguyen> darn, bundle buggy requires procmail
<mwh> it would be good to make them a bit prettier, indeed
<mwh> i'll mention what push does out loud, i think, i don't want to clutter the file
<mwh> file -> slide
<bwinton> mwh: Cool.  In the some pictures, should rev B be "B+i" or "B+1", and if it's "B+i", should the "i" be an "n", and should it look more like the server (with the multiple revs stacked)?
<mwh> bwinton: heh, the B+i think is a hack because i didn't want to get into talking about how revisions are numbered in bzr
<bwinton> Okay, but I think you can sweep it all under the rug, and just call it "B"...  No, wait...
<mwh> and perhaps trying to indicate machines on the diagrams is a bit unfair
<bwinton> How about A (living on the server), B (on your machine), and C (on his machine)?
<mwh> they should probably be branches
<bwinton> Then you can have B+1, C+1, B+2...
<mwh> bwinton: yeah, that works
<bwinton> I think the separate machines are a good idea...
<bwinton> It drives home the "You don't need the server" feature.
<bwinton> If you could put the other two machines inside a picture of an airplane, that would be cool, but completely excessive.  ;)
<mwh> hehe
<bwinton> Also, back near the first slide, "Distributed means there is no privileged central location" perhaps should be "Distributed means there doesn't have to be a privileged central location", since in the workflows, you say "Centralized  all data lives on a single server, like Subversion", where there is obviously a (socially-)privileged central location.
<bwinton> In "Better Centralization", s/emacs/notepad/ ;)
<NfNit|oop> bwinton: but implementation-wise, that central copy is equal to all others.
<NfNit|oop> And I think that's the important part.
<bwinton> Nf: Kind of, but G*d help you if you release off of the non-central copy...
<bwinton> Like I said, it's socially (not technically) privileged.
<NfNit|oop> why?   In fact, releasing off of a non-central branch might be a good idea.
<NfNit|oop> so your central version can be a "dev".
<radix> I agree with bwinton; it's worth pointing out that it's not *necessarily* centralized
<NfNit|oop> and your non-central one a "stable".
<bwinton> Nf: then I would argue that you've actually gotten the notions of  "central" and "non-central" backwards.  ;)
<radix> I have talked with many people who didn't want to go with bzr because they thought they couldn't have a central branch.
<bwinton> Nf: It's a terminology issue at that point, I believe.
<NfNitLoop> radix: Oh?   Hmm, I guess in that case it does merit pointing that out.
<NfNitLoop> But it wasn't log into my reading about bzr that I found the page on workflows and that all got cleared up.
<bwinton> mwh: In "Better Centralization", I might change the background colour of "co", and then later on in "Working Distributedly", use a new background colour for "branch", to highlight the major user-level difference between the two...
<bwinton> mwh: Basically answer the question "Why do changes stay local in one case, but not the other?".
* mwh catches up on comments
<mwh> bwinton: maybe i should have the centralized workflow use vim and the distributed use emacs :)
<mwh> (and then mention that emacs is obviously superior)
<james_w> dato: thanks for the quick upload.
<bwinton> Heh.  :)  Anyone who can't code in "cat > filename"/"copy con filename" doesn't deserve the label "Programmer".
<mwh> bwinton: at a higher level, do you think it's a reasonable selection and ordering of topics?
<bwinton> Let me check in a second...
<bwinton> I'm almost at the end.
<mwh> it's probably too much, it's only a 30 minute talk
<bwinton> Maybe not...  People tend to talk fairly quickly...
<bwinton> At least, I tend to talk fairly quickly...  :)
<bwinton> The pictures are 14 of the slides, and those should go by really fast.
<mwh> certainly
<mwh> it's 40 slides in keynote
<bwinton> If you're running short, you could drop the Launchpad portion.
<bwinton> That's odd, it says 49 in the pdf.
<bwinton> Actually, why is the Launchpad stuff in there?
<mwh> well, partly because my job is working on launchpad/bazaar integration :)
<mwh> the reason that the pdf has more pages is that keynote makes a slide per 'build step' of each slide
<bwinton> Ahhh...  Makes sense.
<bwinton> It seems good to me, if you can fit it all in.  It's hard to say more without knowing the what the audience is going to be like...
<dato> james_w: np
<mwh> it's the first time this conference has happened, so noone really does :)
<bwinton> If it's all people who have seen bzr (i.e. me), you could skip some of the earlier stuff, and concentrate on the launchpad bits.  If it's people who haven't heard of a DVCS, then the earlier stuff would be more useful.
<bwinton> Maybe ask at the start, and flip past the appropriate slides, then.
<mwh> i think i want the talk to be about 40% advertisement for dvcs, 40% advert for bzr and 20% on launchpad/bzr
<mwh> bwinton: yeah
<bwinton> So you don't plan on giving it 110%, then?  ;)
<mwh> bwinton: i'm not expecting most people to have used a dvcs
<bwinton> I wouldn't have either, but there was Linus' talk at Google on Git...  I hear that's been pretty popular...
<bwinton> So even if they haven't used a dvcs, they might have heard about them.
<gabe_> there some mercurial screencast on google video also
<bwinton> Yeah, I saw that one as well...  Bryan O'Sullivan (I think) is a pretty good speaker.
<matkor> Hi !. Can I update many working trees at once ? like bzr update this that and/that/dir/too ?
<mr_daemon> matkor: Uninteresting trivia, but if you're on unix with bash, you can probably get away with doing this:
<mr_daemon> for i in this that and/that/dir/too ; pushd $i && bzr update && popd ; done
<matkor> If mr_daemon: I would have to give password each time when using sftp transports
<mr_daemon> matkor, That is true, but you could also use private/public keypairs, feed them into ssh-agent beforehand, and enjoy the blissful automated action of this.
<mr_daemon> This is clumsy, but the only quick way i could think of =/
<matkor> mr_daemon: OK. thank you very much
<Lo-lan-do> If all remote repos are on the same host, there's a trick that allows SSH to reuse an existing connection.
<Lo-lan-do> ControlMaster or something.
<Lo-lan-do> I don't know if it re-asks for passwords, though.
<mwh> new version of my slides: http://python.net/crew/mwh/pyconuk07_bzr.pdf
<Odd_Bloke> mwh: Ooh, pretty. :)
<bwinton> mwh:  I finally figured out what was bugging me with A+i/A+2i...  It seems like he's progressing twice as fast as you are!  What do you think about changing it to A+i and A+i2?
<mwh> it's _supposed_ to be an allusion to complex numbers :)
<bwinton> Yeah, i kind of got that, but he's still going from i to twice i in the time that it takes me to go from 2 to 3...  :)
<bwinton> (It's certainly complex.  ;) )
<hstuart> mw, few quick comments: on page 2 it seems odd to add (technically speaking) from slide 2 to slide 3 when there are releaved points below that; p. 33: you can work on a train? perhaps revise to: you can work while travelling?; p. 41: consider different bullets for different levels, e.g. boxes for the second level (also other slides); the quality of your logo is much too low, it'll look severely pixelated when projected
<hstuart> mwh, even
<hstuart> mwh, also it annoys me that the sans-serif font in your drawings writes 1 as I
<mwh> bwinton: i'm ditching the A+i vs A+1 stuff
<mwh> it's just confusing
<bwinton> That's probably for the best...  What are you going to replace it with?
<bwinton> hstuart: I was going to suggest he change "on a train", to "on a plane, train, or automobile", because who doesn't like a good Steve Martin/John Candy movie?
<hstuart> heh
<bwinton> (With the caveat that if you're the one driving any of the previous, perhaps you shouldn't be coding...)
<mw> wrong mw :)
<dato> mwh: I think both should read A+1
<dato> or s/should/could/ :)
<mwh> dato: err
<mwh> dato: no thanks :)
<dato> well, sooner or later people will have to deal with that
<hstuart> mw, I blame tab completion :D
<dato> gives you a nice opportunity to say "the revno does not uniqly represent a revision" or something like that
<bwinton> That's why I like to go with unique prefixes for my name.  ;)
<mwh> new version uploaded
<mwh> with the font of just "1" carefully changed on lots of slides :)
<mwh> dato: i'd rather write in a mini revid
<dato> mwh: your call :)
<hstuart> mwh, well, the rest of my concerns are still present in the new version ;)
<mwh> hstuart: indeed
<mwh> hstuart: i think i respectfully disagree with you on most of them
<hstuart> mwh, heh ok, no worries
<bwinton> Is the logo actually too low-res?  I figured it'ld just be the SVG version, and so wouldn't matter what resolution it's projected at...
<hstuart> bwinton, you can try to zoom in. Looks like an embedded png
<bwinton> I guess at 300% I can see the pixels...
<mwh> it's a png
<mwh> but most projectors are 1024x768 at best
<hstuart> *shrug* I might just be overly picky with such things
<Lo-lan-do> Hm.  Is this a Bazaar presentation, or just a pretext to plug Launchpad?
<bwinton> Lld: A bit of both, I believe...
<mwh> i would like to embed the svg, somehow i doubt keynote supports that
<bwinton> To quote """[13:00]  mwh: i think i want the talk to be about 40% advertisement for dvcs, 40% advert for bzr and 20% on launchpad/bzr"""
<mwh> Lo-lan-do: would "is that a chip i see on your shoulder?" be an overly unfair response to that?
<Lo-lan-do> I don't know.  I've heard the idiom, but I have no clue as to what it means, I'm afraid :-)
<Lo-lan-do> (Yay for being French)
<mwh> Lo-lan-do: of course it's not "just a pretext to plug launchpad"
<bwinton> mwh: Would http://www.xml.com/pub/a/2004/01/07/keynote.html be of any use to you?
<bwinton> (Hmm, apparently not.)
<mwh> bwinton: probably not, and certainly not given that i have another talk to write for the same conference :-)
<bwinton> Okay, I'm off.  Have a fun evening, everyone!
<Janzert> mwh: very minor (i.e. just ignore me) nit/bug in the talk, pg. 37 first link reads +login but tries to link to +register
<mwh> Janzert: thanks
<mwh> hooray keynote
<lifeless> morning
<thumper> morning
<abadger1999> abentley: ping
<abentley> pong
<abadger1999> abentley: We're doing a license audit of Fedora packages and I noticed that trac+bzr doesn't have a GPL version in any of the source files.
<abadger1999> Because of the wierd wording of the GPLv2 we're being told to mark that as "any version of the GPL"
<abadger1999> Is that what you intend?  Or GPLv2? Or GPLv2+?
<abentley> I'm not the sole author of trac+bzr.
<abentley> I'd certainly place my code as GPL2+
<abadger1999> Yeah... I gather that anyone of you (the authors) can choose the GPL version as it's currently under any version that the receiver of the code chooses.
<abadger1999> Would you be upset if I list it as GPL+ (Meaning GPL any version)?  I can certainly do that until someone decides they are authorized to add a version to a source file.
<abadger1999> I just like to ping someone about this when I see a COPYING file that's GPLv2 but the lack of version-in-code means we consider it GPL+.
<abentley> abadger1999: This means also GPL1, I supposed?
<abadger1999> Yeah.
<abentley> That would bother me a bit.  Clearly the authors intended 2, and possibly 2+.
<abadger1999> Exactly my problem :-(
<lifeless> so the issue is this clause
<abentley> To me, it is clear that it was intended to be distributed under 2, and any other version is not clear.
<lifeless> If the Program does not specify a version number of
<lifeless> this License, you may choose any version ever published by the Free Software
<lifeless> Foundation.
<lifeless> if the readme or *something* does not says 'Version 2 GPL or later, see COPYING for the licence'
<lifeless> then that clause makes it the recipients choice.
<lifeless> abadger1999: I'd strongly argue that a README or something else is sufficient, not a per-file heading (to satisfy the clause - because the clause talks PROGRAM)
<abadger1999> lifeless: Sure.  I'll take that.  Although, license in the source is definitely preferable (as it's unambiguous at that point)
<lifeless> abentley: and easy fix is for you set version 2, because you are *an* author, you can just say 'I chose version 2+ for my modifications, which is compatible with the licence'
<abentley> We don't have a version specified anywhere that I can tell.
<abadger1999> bzr+trac just doesn't have a GPL version anywhere except the COPYING file.
<abadger1999> lifeless: +1  That would make the work as a whole GPLv2+ which makes the license clear.
<abentley> Okay, I will specify 2+ for my version of trac+bzr.
<abentley> Do you want a source code change before you apply that?
<abadger1999> abentley: It would be great for the notice to show up in the files I pull from your repo.
<poolie> good morning
<lifeless> mornink
<poolie> lifeless, i'm going to separate out a branch for you that adds to the pack repository the ability to store and get texts by hash
<lifeless> poolie: ok
<lifeless> I saw some commits in that direction;
<poolie> i thought it'd be better to review them separately first
<abentley> abadger1999: Okay, revno 181 has GPL 2+ in the README and the main source file.
<lifeless> is it the sha of the representation in the repo or the sha of the reconstituted text
<poolie> i think it's a good way to try out the splitting even if we don't finally want them addressed that way
<lifeless> will they be delta compressed
<poolie> lifeless, at the moment they are not compressed
<poolie> so they're the same
<abadger1999> abentley: Thank you much.  Helps me keep the lawyers happy while doing what I think the developers intend  :-)
<poolie> neither dictionary compressed or delta compressed
<lifeless> (not because I care about the answers, but I want the interface to be clear about what it is delivering)
<poolie> hello abadger
<abadger1999> poolie: greetings
<lifeless> poolie: I'm doing a knit format bump to make it more flexible and the index optional.
<poolie> oh, you're not the badger i thought you were :)
<poolie> but hello anyhow
<lifeless> hes a badger not b badger :)
<poolie> anyhow the interface would be defined as the hash of the reconstituted text
<poolie> you may have also seen i was making a base class with some of the repeated code between the two knit formats
<lifeless> two knit formats ?
<poolie> i mean, two knit-in-pack repository classes
<abadger1999> :-)  I was notified that my lawsuit was going well the other day and had to call Texas collect to clarify that I'm a different badger.
<lifeless> oh; uhm; I'd rather not do that, because of the unclarity about the subtrees stuff
<lifeless> Moving things into PackCollection is how I planned to reduce the duplication
<poolie> what unclarity?
<lifeless> I believe some of the subtrees policy is expressed by what class; some by attributes, some by code
<lifeless> so a base class will bring in multiple inheritance
<abentley> abadger1999: So what's the status of trac+bzr?  Is it in fedora already, or in the next release?
<abadger1999> abentley: It's in Fedora already.   Let me lookup which versions its built for
<abadger1999> abentley: Fedora 6,7, devel (will be 8) and RHEL-5  It's the trac-bazaar-plugin package.
<poolie> yes, it did bring in mixin style MI
<poolie> i'm not a fan of MI in general but it's better than copy and paste
<abentley> abadger1999: So I could say "since Fedora Core 6"?
<lifeless> I guess; I worry it will just stick around, what I had hope to achieve was just a few delegated methods
<abadger1999> Yep.  That would be accurate.
<lifeless> which while technically copy n paste is hardly so
<lifeless> what I'd really like to achieve is a single class that can be parameterised by the format to enable/disable subtrees
#bzr 2007-08-30
<poolie> btw there's some docstring corrections in my pack-repo branch
<lifeless> I'm thinking about this knit change
<lifeless> heres what I plan:
<lifeless>  - add a new subclass of knit that writes a different knit record but can read either
<lifeless>  - add a new interknit to convert data from regular knits to this
<lifeless> change packs to use the new knit
<abentley> abadger1999: Thanks.  I've emailed the other contributors, to confirm it's okay with them (though I understand I'm not required to by law).
<abadger1999> That's excellent.  Thanks for helping me clear that up.
<kiko-afk> <yml> I am still getting the same error on windows : bzr: ERROR : ERROR 2 The system cannot find the file specified
<kiko-afk> has anyone seen this error?
<lifeless> no
<lifeless> if you run with BZR_PDB=1 you can drop into pdb and poke around
<lifeless> or check .bzr.log for a backtrace
<kiko-afk> it's windows though
<lifeless> ye
<lifeless> s
<lifeless> bzr version will show where the log file is
<lifeless> (bzr --version)
<abadger1999> abentley: BTW, I have a little patch that makes python setup.py sdist include the COPYING file
<abadger1999>  http://toshio.fedorapeople.org/packages/trac+bzr-install.patch
<kiko-afk> intriguing! thanks.
<abentley> I don't understand your setup.py change.
<abadger1999> I'm not sure why, but setuptools is deciding not to include COPYING in the tarball even though it is listed in data_files
<abadger1999> moving it from data_files to MANIFEST.in makes setuptools more cooperative.
<abentley> weird.
<abadger1999> There's also some setuptools documentation that makes me think that data_files is for real data_files that the python module depends on at runtime
<abadger1999> While MANIFEST.in can feed files into the tarball that aren't put into the installed module tree.
<abentley> Okay, I'll take it on trust.
<abadger1999> heh. Thanks :-)
<abentley> lifeless: I don't know if the bzr.dev deb Recommends xdg-utils, but it should.  (The recent bzr send updates use xdg-email if possible)
<lifeless> probably doesn't.
<lifeless> I haven't started building dailies yet though
<abentley> Okay.
<abentley> Just thought of that, reading today's IRC log.
<lifeless> thanks
<lifeless> uhm, where to record this :)
<beuno> does anyone know why someone would be getting these errors: http://paste.ubuntu-nl.org/35614/
<poolie> it looks like it's trying to run putty and failing
<igc> morning
<beuno> poolie: I believe it's related to: https://bugs.launchpad.net/bzr/+bug/107155
<ubotu> Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed] 
<poolie> hi igc
<beuno> it is  :D
<poolie> beuno, yes, that looks like it
<igc> morning poolie. Feeling better today?
<poolie> suggest you try the workoround
<beuno> it fixed it for him, thanks poolie
<poolie> igc: no :)
<poolie> beuno, could you try to write a patch for it that  changes the code that determines the ssh version ?
<beuno> poolie: I can give it a try, yes   :D
<beuno> I'll have to find a pc with windows around the office to test it, but I guess it shouldn't be too hard
<Janzert> would anyone have a guesstimate for when win32 0.90 installers will be up?
<poolie> Janzert, typically they come within a day or two of the release
<lifeless> I'm not sure who is building them this time
<poolie> alexander haro?
<Janzert> ok, thanks
<lifeless> yah
<lifeless> might need a oing
<lifeless> ok, should have our 0.90 debs up shortly, last build glitches for feisty gutsy sid seem fixed
* lifeless foods
<tonyyarusso> btw, in case anyone cares I asked Apress and O'Reilly if they had any plans for a Bazaar book.  Both said no, not at this time, but were open to proposals.
<kiko-afk> if they pay me a million dollars I will write two books on bzr
<lifeless> spiv: hows that digit ?
<spiv> lifeless: in motion ;)
<poolie> digit?
* lifeless defers to spiv
<spiv> I used a phrase like "I need to extract my digit" in a call yesterday when talking about getting the latest hpss fetch optimisation work up for review.
<poolie> lifeless, there's an extension of look before you leap
<poolie> which is about giving nice error messages if someone uses an api wrongly
<poolie> for example if you give just a string rather than a tuple to an index as a key,
<poolie> it just fails to match, or gives you a 'weird' error when trying to insert
<poolie> i would have thought this was a bug, but it's probably not - checking everything takes time
<poolie> and once i realize it's my bug it won't happen again
<lifeless> right
<poolie> you do pay the cost of developers being more mystified when they have bugs though
<poolie> so possibly we should arrange to run with -O in normal use, but with assertions on in development
<lifeless> so I'd be much happier if "asd"[0] [0]  errored
<poolie> that sorta thing
<lifeless> well in this case its a string blackhole
<lifeless> (1,2)[0] [0]  errors
<poolie> another thing like that was the patch from aaron i reviewed a while ago
<poolie> things that are meant to yield a sequence of strings can silently return just a string instead, potentially making you do much more work
<lifeless> yup
<lifeless> my pet wish for python - have a byte data type. not *bytes*, *byte*.
<poolie> mm
<poolie> woot
<lifeless> so gzipping is a net win
<lifeless> we spend 4m20 seconds in IO if we don't gzip
<lifeless> 1m40 if we do
<lifeless> this is for a copy of mozilla, naturally
<beuno> poolie, I'm finishing up the patch for bug #107155, should I just send it to the ML with [MERGE]  in the topic, or would you like to review it?
<ubotu> Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed]  https://launchpad.net/bugs/107155
<lifeless> beuno: just send to the lsit; things get reviewed there :)
<beuno> lifeless, should of guessed, thanks.  I'm a bit nervous as this is actually changing code in bzr, I'm not that confident yet  :p
<poolie> lifeless, do you want to talk about gzip some more?
* igc lunch
<lifeless> sorry, no browser:
<lifeless> gzip each hunk
<lifeless> real    5m53.774s
<lifeless> user    4m7.047s
<lifeless> sys     0m12.901s
<lifeless> no gzip
<lifeless> real    7m8.611s
<lifeless> user    2m41.846s
<lifeless> sys     0m16.821s
<lifeless> gzip entire contents
<lifeless> real    4m46.153s
<lifeless> user    4m29.457s
<lifeless> sys     0m11.961s
<lifeless> so we spend nearly 50% of our user time doing gzip
<lifeless> but overall time is IO bound for mozilla's tree if we don't gzip
<beuno> lifeless, should of guessed, thanks.  I'm a bit nervous as this is actually changing code in bzr, I'm not that confident yet  :p
<beuno> (sorry, wrong windows)
<lifeless> :)
<beuno> irssi still confuses me with the actual terminal sometimes, so up + enter is dangerous  :p
<abentley> igc: ping
<igc> hi abentley
<abentley> Hi there.
<abentley> I wanted to try and get a clearer idea of the distinction between "user guide" material and "user reference" material.
<igc> the 'reference' should cover every detail ...
<bheekling> Does bzr work from behind an http proxy?
<bheekling> ie, if I set the http_proxy etc variables
<abentley> 'cause the hook document was definitely meant as a how-to.
<igc> but not bother explaining how to use those details
<lifeless> bheekling: yes
<igc> how-to is definitely 'User Guide' material
<bheekling> it doesn't seem to be working for me, it says "bzr: ERROR: Transport error: Server refuses to fullfil the request"
<igc> abentley: I'm pleased to see hooks added to the User Guide ...
<lifeless> bheekling: interesting. You might try http+httplib
<lifeless> rather htan just http
<igc> The list of actual hooks though also lives in the Reference I feel
<lifeless> and please file a bug with as much information as you have - what proxy server
<abentley> igc: I think a certain amount of reference material is necessary to any how-to.
<igc> yes. At least enough to explain things and give samples
<bheekling> lifeless, what do you mean by http+httplib?
<abentley> I guess I could ignore all the other hook types and just talk about the push hook.
<igc> abentley: if and when we get lots of hooks, I don't think I want all of them in the Guide
<abentley> And then link to a hook reference.
<igc> That sounds good
<lifeless> bheekling: 'bzr OPERATION http+urllib://server/path'
<abentley> What is strange but true is I often 'bzr pull' my own patches off Bundle Buggy.  The hook docs were written at work, but I'll finish them at home.
<igc> I download patches off BB all the time, even though their in my email somewhere
<igc> s/their/they're/
<abentley> igc: I download my own patches, though.
<igc> ok, you win :-)
<igc> can't beat that :-)
<bheekling> lifeless, it works with that, thanks :)
<lifeless> bheekling: can you please file a bug?
<lifeless> bheekling: specify what proxy you have if you know
<bheekling> lifeless, okay, I'll do that
<lifeless> thanks
<bheekling> lifeless, correction, it seems bzr works with my proxy just fine, that problem was a random fluctuation I think :)
<bheekling> Its importing happily now
<igc> poolie: any further thoughts re whether -D needs to stay a global option or not? I'm planning to make it a "standard option" instead of a global one unless I hear a reason not to
<lifeless> it affects everythin
<lifeless> so it should be global IMNSHO
<igc> ok - so it *must* remain global?
<poolie> igc, hi
<lifeless> I think so, because we might do e.g. -Dcommand at some point, to track ui loading
<lifeless> if we're happy not to do that, then having it standard is ok
<igc> It seems to me that the limitations re global options are aceptable to -D
<lifeless> profiling is the most boringest thing
<poolie> igc, i agree it's ok to change it
<poolie> is there a particular motivation for changing it?
<igc> I can certainly see a case where parsing it before anything else would be required
<igc> poolie: just following up your email
<igc> ... where you thought out loud about 'maybe -D doesn't need to remain global'
<igc> IIRC that is
<lifeless> ok
<lifeless> annotations cost us heaps
<lifeless> $ rm -rf .bzr && bzr --no-plugins  init --experimental && bzr --no-plugins add > /dev/null && time ~/source/baz/repository/bzr --no-plugins  commit -m "Initial commit"  2>/dev/null
<igc> so poolie, given the feedback from lifeless, I'll leave it global
<lifeless> real    3m50.336s
<lifeless> user    3m34.897s
<lifeless> sys     0m10.941s
<lifeless> thats a 30 second improvement
<lifeless> on initial commit
<lifeless> just by not caching annotations
<lifeless> (4m23 to 3m50)
<igc> lifeless: interesting
<abentley> lifeless: that's strange, because annotations do require sequence matching, but so does knit delta generation, and AIUI, they share the same sequence matching.
<lifeless> we do less string manipulation without annotations
<lifeless> because annotations are stored as line prefixes in the knit record
<abentley> So even changing our annotation representation might help a lot?
<lifeless> potentially
<poolie> lifeless, one thing you could try is using lzo compression
<poolie> which uses less cpu than gzip
<lifeless> I found nearly no difference using one gzip file versus one-per-record
<lifeless> user    4m29.457s
<lifeless> user    4m3.963s
<lifeless> in fact, it went backwards
<lifeless> which was weird
<abentley> Smaller working set, maybe.
<poolie> lifeless, is there already a container record that says "give me the contents of the bytes record at (off,len)"?
<lifeless> poolie: EPARSE
<lifeless> do you mean API ?
<poolie> my index tells me i want the record at a certain location in the container
<poolie> yes, api
<poolie> mistyped
<lifeless> pack.make_readv_reader
<poolie> excellent
<lifeless> abentley: I don't think so; compressing the entire pack to a single zip should have nearly identical memory use
<lifeless> I htink there is still room for considerable noise
<lifeless> btw feisty gutsy sid repos on bazaar-vcs.org have bzr/bzrtools/bzr-gtk 0.90 now
<abentley> lifeless: nice.
<abentley> Edgy?
<lifeless> on my list
<abentley> Ah.  Not as easy to update, then?
<lifeless> not quite, got to back out some packaging changes that removed explicit versioning on depends
<ajmitch> etch is the same?
<lifeless> yah
<NamNguyen> can we cast a vote with BB's web interface?
<lifeless> if you have an account; accounts are granted when abentley things you are sane
<NamNguyen> lifeless: i'm running bb on my machine
<NamNguyen> but i cant find any button to approve or decline a merge request
<abentley> NamNguyen: Congratulations.  AFAIK, that's the first independent install.
<abentley> NamNguyen: You have to be logged in.
<NamNguyen> abentley: and i have logged in
<igc> ManNguyen: have a read of http://bazaar-vcs.org/IanClatworthy/CoreDeveloperHandbook. It should answer some of the questions you had yesterday
<igc> NamNguyen: ^^^
<abentley> So it should show you voting options from "reject" to "approve" on the request page.
<NamNguyen> i see a list of tabs, but i dont see any buttons
<poolie> lifeless, it looks like i want something like that, but creating a BytesRecordReader, not a ContainerReader...
<abentley> You need to go to the page for a particular request.
<lifeless> poolie: you want one record out?
<poolie> well, possibly more than one
<lifeless> poolie: thats going to perform badly on high latency links
<abentley> By clicking on the summary link
<lifeless> poolie: I don't see why it doesn't do what you need - you iterate the container to get the byte records you want
<NamNguyen> abentley: thank you, it's weird, now i can see it, i was so sure i didn't see that before
<poolie> oh i see
<abentley> No problem.
<poolie> there's just one more layer...
<abentley> I saw earlier you were upset it used procmail.  Does your server not have procmail?
<NamNguyen> it's running on windows
<abentley> Amazing.
<NamNguyen> so i wrote a pop3 client to manually poll at 5-min interval
<NamNguyen> and submit it to the web
<abentley> Hmm.  Maybe that makes sense for Windows.
<NamNguyen> yea, it doesn't have local maildir
<NamNguyen> but of course, then it wouldn't be "real-time" enough
<lifeless> cygwin has procmail if you want it
<abentley> Well, you certainly can set up a local mail server on Windows, I just imagine it's a pain.
<NamNguyen> i'm using gmail apps
<lifeless> setup.exe from cygwin, select fetchmail and procmail; or at least thats what I'd do:)
<NamNguyen> it's better just to write a few lines of pop3
<abentley> lifeless: You shameless former-cygwin-developer, you :-)
<lifeless> :)
<abentley> NamNguyen: Well, if you've got any feedback on Bundle Buggy, I'd be interested to hear.  But I'm off to bed in a minute.
<NamNguyen> linking bb and pqm
<NamNguyen> but, good night aaron
<NamNguyen> it'd be a complete solution for patch management
<abentley> Ah.  The reason BB doesn't submit to PQM is because usually by the time a patch has been approved, it no longer merges cleanly.
<NamNguyen> so a human is required after all
<abentley> Well, for the Bazaar codebase at least.
<poolie> it would be nice to have them integrated
<poolie> someday
<abentley> We are constantly updating the top of the NEWS file, so we get conflicts there.
<lifeless> the big difference is in userspace
<lifeless> hg spend 1 minute in userspace
<lifeless> we spend 3.5-4.5
<poolie> and is it mostly in gzip, or was that a wild goose chase?
<lifeless> we spend 1m20 in gzip
<lifeless> gzip each hunk
<lifeless> (with hot source files)
<lifeless> real    4m23.884s
<lifeless> user    4m3.963s
<lifeless> sys     0m11.649s
<lifeless> no gzip
<lifeless> real    7m8.611s
<lifeless> user    2m41.846s
<lifeless> sys     0m16.821s
<lifeless> gzip entire pack
<lifeless> real    4m46.153s
<lifeless> user    4m29.457s
<lifeless> sys     0m11.961s
<AfC> "hot source files"
* AfC has an image if Bazaar being used by a XXX movie company.
<abentley> G'night, folkds.
<abentley> folks, even.
<lifeless> night abentley
<lifeless> this is interesting
<lifeless>  du -sh .bzr/
<lifeless> 142M    .bzr/
<lifeless> thats the pack repo
<lifeless> hg had a 280M repo
<lifeless> with no annotations, naturally
<lifeless> poolie: up to a chat ?
<AfC> (what are annotations?)
<poolie> lifeless, in a sec
<AfC> (heard them mentioned here a few times as having a space impact)
<poolie> AfC, our memory of what revision changed a line
<lifeless> AfC: precalculated line -> revision id mappings
<poolie> it makes gannotate and weave merge fast
<lifeless> AfC: what makes 'bzr blame' so fast
<AfC> Huh
<AfC> Neat. Thanks.
<lifeless> poolie: ok, ring my mobile please, I'm going for a walk
<fullermd> Pack repo of what?
<poolie> mozilla
* fullermd blinks.
<fullermd> That's freakin' small.
<poolie> just the initial import i think
<AfC> Not sure if you gents saw this on planet.gnome.org or elsewhere, but this post by Alex Gravely is excellent, http://www.beatniksoftware.com/blog/?p=74
<fullermd> Oooh, ok.  So it's merely "rather nice", not "mind-zonkingly tiny".
<lifeless>  du -sh .
<lifeless> 669M    .
<lifeless>  du -sh .bzr/
<lifeless> 142M    .bzr/
<lifeless> so 550M for the source
<lifeless> holy fuck this test is taking forever
<lifeless> a$ python -m timeit -s 'from bzrlib.tuned_gzip import GzipFile; from bzrlib.osutils import pumpfile' "of=GzipFile('/dev/null', 'wb'); pumpfile(file('../mozilla.tar', 'rb'), of); of.close()"
<abadger1999> Hmm... bzr branch bzr+ssh:// seems to have a regression compared to bzr branch sftp://
<abadger1999>  bzr branch bzr+ssh://fedorapeople.org/home/fedora/toshio/public_html/bzr-repo/packagedb/fedora-packagedb-stable
<abadger1999> Copying repository content as tarball...
<abadger1999> bzr: ERROR: Tags not supported by BzrBranch5('file:///var/tmp/fedora-packagedb-stable/'); you may be able to use bzr upgrade --dirstate-tags.
<lifeless> there is a bug on this
<abadger1999> Cool.  I'll go look in launchpad.
<lifeless> (but no fix yet)
<lifeless> when spivs patches arrive they will fix it
<abadger1999> excellent.  Thanks for the info.
<lifeless> (by deprecating that other api)
<poolie> spiv, hi?
<spiv> poolie: hello
<spiv> Hmm, will have to finish this email on the train.
* spiv -> gone
<Lo-lan-do> Hello all.
<poolie> spiv, quick call?
<Lo-lan-do> Is there a way to have a branch living under another directory than where the repository is stored?
<poolie> no, it has to be contained within the repository
<dato> but, you can just put it elsewhere
<poolie> this is more for avoiding confusion than technical reasons
<Lo-lan-do> Is that a theoretical impossibility?
<Lo-lan-do> Ah, no, good.
<poolie> um
<dato> the revisions will not be transferred to the repository, but you can push them by hand
<Lo-lan-do> Actually, let me come up with the context.
<poolie> let me make sure i understand? do you mean you want a branch whose history is stored in a directory that's not above the branch?
<dato> or you can create a lightwheit checkout of a branch elsewhere in the filesystem
<lifeless> Lo-lan-do: yes, local push will create trees; there should be a bug on that
<Lo-lan-do> 'kay.  I can live with that for now, since there's remove-tree :-)
<Lo-lan-do> Ah, but bzr branch doesn't know about --create-prefix.
* Lo-lan-do goes mkdir
<mwhudson> is there a bzr-gtk 0.90 deb yet?
<jelmer> there is one in debian, not sure whether it's been uploaded to bazaar-vcs.org or ubuntu yet
<mwhudson> ah
<fullermd> thumper: Whoops, I lied.  It's post-0.90, so no release yet.
<hstuart> mwhudson, jelmer, it's up in feisty at least
<hstuart> at least an apt-get upgrade fetched it for me this morning
<mwhudson> it is?
<jelmer> ah, ok - so it's up on bazaar-vcs.org
<mwhudson> oh
<mwhudson> i don't have bazaar-vcs.org in my repo list
<hstuart> I live life dangerously ;)
<mwhudson> well, i run bzr.dev most of the time...
<elmo> bzr's managed to take a 30Mb tree and turn it into 51Mb just to import - is that ratio expected?
<hstuart> hmm, the bzr upgrade on my second box is failing, though
<hstuart> getting a: error in control file: `Files' value not specified at /usr/sbin/install-docs line 804, </usr/share/doc-base/bzr> line 10
<mwhudson> elmo: i'm not quite sure what you mean by 'import'
<mwhudson> that ratio does seem a little big, how compressible is the stuff you're importing?
<elmo> mwhudson: bzr init; bzr add; bzr commit
<elmo> mwhudson: it's /etc/gconf from a feisty fesktop; I suspect very compressible in a tar sense, less so in an indiviual file sense
<mwhudson> i would expect that to increase the size of the tree by ~the size of the tree when gzipped
<mwhudson> each file gzipped independently
<mwhudson> hstuart: hm, me too
<hstuart> so... who do we lynch? ;)
<rocky> hmm... the new feisty deb for bzr 0.90 seems busted?
<hstuart> slightly
<rocky> lol
<rocky> kk... just making sure someone knew ;)
<hstuart> you can solve it by adding this line to /usr/share/doc-base/bzr : Files: /usr/share/doc/bzr/html/index.html   as the last line
<hstuart> not sure whether that's a decent fix, but it got the rest through installation here
<rocky> ah thanks
<rocky> here's a quick question ... when i install bzr deb it says "INFO: using old version '/usr/bin/python2.3'" because i manually installed python2.3 into /usr/bin ... /usr/bin/python points at python2.5 so why would it be saying that?
<hstuart> no idea, sorry
<rocky> hm... time to ask #ubuntu i suppose ;)
<dato> hstuart: yeah, known problem (re install-docs). I think lifeless is on top of it.
<hstuart> ok, great
<lifeless> yes
<lifeless> had a missing output dir, but otherwise its looking good
<lunatic> is it possible to cancel a pending merge ?
<dato> lunatic, `bzr revert`, if I understood you correctly
<lunatic> yes but revert does not stop the status message to display "pending merge"
<dato> lunatic: it does, it does. at least here it does.
<lunatic> ok, so I perhaps have a strangeness here
<lunatic> thanks for all
<abentley> lunatic: "revert ." will not clear the pending merge, only "revert" with no arguments.
<abentley> lifeless: The major costs in annotation, diffing and merging are sequence matching operations.  It would be nice to serialize the get_matching_blocks output.  Could you investigate how much that costs?
<lifeless> whats the difference between that and our deltas today?
<lifeless> hmm, actually 10pm here
<kiko-afk> lifeless, one trivial question
<lifeless> I'm going to finish my talk slides and sleep
<lifeless> remind me tomorrow :)
<kiko-afk> lifeless, does the new (packs?) format produce a smaller file than the knit?
<kiko-afk> our knits are now 250MB!
<lifeless> kiko-afk: launchpads ?
<kiko-afk> yes
<lifeless> 250M seems a little small to me
<mwhudson> i think kiko just means the inventory.knit ?
<lifeless> $ ls -lh launchpad.packs/.bzr/repository/packs
<lifeless> total 347M
<lifeless> -rw-r--r-- 1 robertc warthogs 346M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.pack
<lifeless> ~$ ls -lh launchpad.packs/.bzr/repository/indices/
<lifeless> total 25M
<lifeless> -rw-r--r-- 1 robertc warthogs 2.1M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.iix
<lifeless> -rw-r--r-- 1 robertc warthogs 2.1M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.rix
<lifeless> -rw-r--r-- 1 robertc warthogs 1.2M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.six
<lifeless> -rw-r--r-- 1 robertc warthogs  19M 2007-08-16 07:55 9e0bcc57d834ca3ae0b5f5844d82dedb.tix
<lifeless> du -sh on a knit repo:
<lifeless> 434M
<lifeless> with --apparent, 395M
<lifeless> so yes smaller
<lifeless> mainly due to a more effective dictionay compression on the indices
<lifeless> kiko-afk: the big win is the ability to partially read indices though
<lifeless> and for you, the streaming network push will reduce push and pull times dramatically
<lifeless> even without the smart server
<kiko-afk> lifeless, yes, just the inventory.knit file.
<kiko-afk> will that file be smaller?
<lifeless> that file does not exist anymore
<kiko-afk> are there any other large files like that?
<lifeless> yes, the .pack files :)
<lifeless> see the ls -lh I gave above
<kiko-afk> 346mb, wow.
<lifeless> its the entire database
<lifeless> including your sample debs :)
<lifeless> kiko-afk: I have sent instructions on how to dogfood packs to the bazaar mailing list
<lifeless> kiko-afk: .pack files are write-once
<lifeless> kiko-afk: they can be rsynced much more safely
<kiko-afk> lifeless, so we rewrite the 346mb to other files later?
<lifeless> though still not entirely as safe as using bzr itself; but I can push at 80% of rsync speed.
<lifeless> kiko-afk: yes, with logarithmic backoff. So for that 346MB file we're probably at 20K commits in it
<lifeless> or something like that.
<lifeless> so I'd expect a rewrite of it at 100K commits
<lifeless> until then its static
<kiko-afk> lifeless, I wonder why using a single file that large is a good idea -- why shouldn't we have a smaller ceiling in order to avoid disk frag and just general problems with dealing with it.
<lifeless> the design rationale covers this I believe
<lifeless> in short, we have a smaller VFS requirement set, better control over physical disk layout, the ability to avoid many roundtrips to access data
<kiko-afk> by using a single file?
<kiko-afk> I'd be interested in reading that
<lifeless> we write a single file & its indices during commit
<lifeless> every 10 commits we collapse these to 1 files with 10 commits
<lifeless> every 100 commits we collapse 10x10 commits packs to 1x100 commit pack
<lifeless> etc
<kiko-afk> how interesting
<kiko-afk> does that not grow exponentially more expensive?
<lifeless> logarithmic backoff
<kiko-afk> i.e. when it's time to move the 1000 commits it will hurt? :)
<lifeless> it will, but:
<lifeless> bzr+ssh does it on the server
<lifeless> the move is cheap as its little more than a readv + write
<lifeless> when we do a push we create a single pack anyway, regardless of the number of commits being pushed
<lifeless> so its actuall less often than every 10 operations that this kicks in remotely, in the common case
<lifeless> we can only issue a single readv for one file at a time
<lifeless> our biggest network performance problem is latency
<lifeless> so consider moz - 55K files
<lifeless> 55K indices
<lifeless> thats 110K * RTT at a minimum
<lifeless> 112000 commits - thats 4 .pack files, wit 4 indices each - we can in principal pull the whole data in 16 * RTT
<lifeless> kiko: anyhow, my performance figures so far back up this strategy; I can push from here to london only 25% slower than rsync, and thats without much tuning at all
<kiko> lifeless, that's pretty sweet. good job!
<kiko> lifeless, I was wondering if the larger pack size doesn't hurt on local operations too though -- it should of course
<lifeless> total data is the same
<lifeless> so the page cache pressure cannot be worse
<lifeless> however the number of files is smaller
<lifeless> so there's less dentries to care about
<lifeless> night all
<ignas> how do i revert a bzr checkout to some older date?
<bwinton> bzr help revert
<gabe_> bzr revert -r 45
<bwinton> followed by: bzr help revisionspec
<gabe_> for example?
<bwinton> I think he meant more "bzr revert -r date:yesterday", Gabe...
<bwinton> Or "bzr revert -r date:2007-08-14,17:10:14"...
<ignas> bwinton: thank you
<bwinton> My pleasure!  (It's amazing what bzr help will tell you...  I swear it's one of my favourite features...)
<ignas> bwinton: indeed, just that it was "Waaah, it's broken, how do i make it work again" situation ;)
* Starting logfile irclogs/bzr.log
<ubotu> New bug: #135891 in bzr "bzr 0.9.0 package blows up" [Undecided,New]  https://launchpad.net/bugs/135891
<jkakar> So, it looks like the problem I reported above (#135891) has resulted in a completely b0rked bzr install.
<jkakar> I'm getting this complaint when I try to run bzr: bzr: ERROR: Couldn't import bzrlib and dependencies.
<jkakar> I guess the quickest/easiest thing I can do is download a tarball from the website and munge my PYTHONPATH.
<bwinton> I thought the quicker fix would be to add the Files line, and re-install...
<bwinton> (I'm looking up the message on gmane for you, but there was a thread about it earlier today...)
<jkakar> bwinton: Oh, maybe you're right.
<jkakar> bwinton: Thanks for looking up the message.
<dato> jkakar: try this:
<bwinton> (Sadly, it looks like the web interface is down...)
<jkakar> bwinton: I found it (in my mail), thanks.
<dato> # echo "Files: /usr/share/doc/bzr/html/*.html" >>/usr/share/doc-base/bzr
<dato> # dpkg --configure -a
<bwinton> No worries.  I'm glad you could find it.
<jkakar> dato: Thanks!
<dato> I'm fairly confident it will work, but please report back :)
<jkakar> dato: Not quite.
<jkakar> $ sudo echo "Files: /usr/share/doc/bzr/html/*.html" >>/usr/share/doc-base/bzr
<jkakar> bash: /usr/share/doc-base/bzr: Permission denied
<jkakar> Editing the file by hand with 'sudo emacs ...' works. :)
<dato> right, you cant use >> with sudo
<dato> since the >> runs as your user
<bwinton> Can't you do something along the lines of "sudo ( cat ... >> foo )", to spawn a root process?
<dato> bwinton: yes. eg. sudo bash -c "echo "Files: /usr/share/doc/bzr/html/*.html" >>/usr/share/doc-base/bzr"
<jkakar> bwinton, dato: Thanks for the help; I'm happy and unblocked. :)
<bwinton> My pleasure.
<bwinton> Hey, is it possible for a mere mortal to run a Launchpad instance of their own?
<bwinton> i.e. if I wanted something Launchpad-y for my company's private internal source code...
<Odd_Bloke> bwinton: Nope, Launchpad isn't Free software yet for precisely that reason.
<bwinton> Wait, for precisely which reason?
<Odd_Bloke> It's intended to be a central point of development which doesn't work so well if there are several hundred of them. :p
<tetron|mac> I get a syntax error trying to set up bzr on OS X.  something about 'from bzrlib.symbol_versioning import (deprecated_function,'  ?
<bwinton> So it's aiming more to be a Sourceforge, and less to be a Trac?
<jkakar> bwinton: I recommend you talk to emurphy@canonical.com about private commercial access to LP.
<jkakar> bwinton: He's statik on freenode, and often present in this channel.
<bwinton> jkakar: Thanks.  I probably won't since my company is still using VSS, but it's good to know that there's a contact for that sort of thing...
<tetron|mac> this is with bzr 0.90, the latest release...  and stock Python 2.4.4 on OS X.  is this a known bug?
<jkakar> bwinton: Oh, VSS is so sad.  I feel for you. :)
<bwinton> Yeah.  The server went down one day, and the whole office stopped working for a couple of hours...  Actually, it was kind of nice...  :)
<jkakar> Heh
<tetron|mac> anyone?  anyone have any idea why "setup.py" on bzr 0.90 just totally fails?
<bwinton> Which platform, what's the error message?
<bwinton> Sorry, OSX, failed import...
<bwinton> No idea.  I can say that it works for me on OSX.  But that's not exactly helpful, is it?
<tetron|mac> never mind, I think I know what's wrong
<bwinton> I'm on Python 2.4.3, installed as a framework.
<bwinton> Yeah?  What was it?
<tetron|mac> it's suddenly decided to revert to using the system Python 2.3.5...  I swear I have 2.4 installed though
<bwinton> Yeah...  I get that a lot too.  I've gone so far as to put /Library/Frameworks/Python.Framework/Versions/Current/... in the #! line of a bunch of my cgi scripts...
<g0ph3r> erm... i'm not sure but it seems that bzr got recently updated (to 0.90) on my ubuntu box, which seems to have broken my bzr installation. i'm unable to run it and i see dpkg errors in synaptic... is this related to the earlier thread here? (in other words: can i fix this issue by the echo command above?)
<dato> g0ph3r: yes
<bwinton> gopher: Give it a try, and let us know.  ;)
<g0ph3r> ok, will do so
<g0ph3r> ok, this fixed it. synaptic now completed the package setup and i'm able to run bzr now...
<g0ph3r> is there somewhere where this should/needs to be tracked as a bug
<g0ph3r> +?
<dato> g0ph3r: it's reported already, https://launchpad.net/bugs/135891
<ubotu> Launchpad bug 135891 in bzr "bzr 0.9.0 package blows up" [Undecided,New] 
<g0ph3r> thx
<g0ph3r> ok, just left a comment with the error message that bzr threw (at least for me) for others to easier find this bug... seems i missed it since my search didn't find the error message :)
<g0ph3r> thanks a lot for your help folks!
<ddaa> Is it valid to have a branch reference point to a path, or are only file: URIs accepted for local references?
<lifeless> ddaa: URL's only
<beuno> yay! my patch seems to have fixed bug #107155. I should use bzr bundle to generate the patch and send it?
<ubotu> Launchpad bug 107155 in bzr "_get_vendor_by_inspection incorrectly determines "plink" to be the executable" [Medium,Confirmed]  https://launchpad.net/bugs/107155
<lifeless> beuno: bzr send
<ddaa> lifeless: thx
<beuno> lifeless, great, thanks
<beuno> lifeless, bzr won't send it directly, right?  I have to generate the patch file first and attach it to an email?
<lifeless> it will fire up your mail client
<lifeless> if you have bzr.dev
<beuno> wierd, it doesn't...  I'll just add -o and send it manually like last time
<abentley> beuno: What happened when you tried send without -o?
<lifeless> morning abentley
<abentley> morning.
<beuno> abentley, it opened up nano
<lifeless> abentley: interesting performance note
<beuno> aaah, wait, I needed to write my message there  :p
<beuno> I'm not very bright today
<lifeless> time to write 1MB of data in python - as a single block of bytes - 19usec. Time to write 1MB of 1000 lines using writelines - 500usec, Time to ''.join(lines) then write - 620usec.
<lifeless> beuno: :)
<beuno> I wrote the patch yesterday though  :p
<abentley> beuno: If you install xdg-utils, it will use your default mail client.  It also can be configured directly for Thunderbird, Evolution and Kmail.
<beuno> abentley, great, installing now, thanks
<beuno> works perfectly  :D  (is that a suggested in the deb package?)
<dato> no, this conv. reminded me of that, thanks
<dato> but gnite now
#bzr 2007-08-31
<abentley> lifeless: So you're saying lines are evil?
<lifeless> abentley: I'm saying there is a significant cost in changing representations (outside of C ?) and that we probably want to really aim for one representation end to end at some point
* abentley was kidding
<lifeless> oh right ;)
<abentley> I agree that end-to-end is a useful goal, but it's hard to imagine how to reconcile that with delta compression.
<lifeless> hg seem to delta on bytes
<abentley> I suppose binary delta compression could work.
<lifeless> the C library they wrote does a line split without copying
<lifeless> or something
<lifeless> certainly they don't seem to do splitlines() during commit
<lifeless> I have pack commit at 3.5x hg commit, I'm trying to pull it down to < 2x
<ddaa> is the "atexit.register(_rmtree_temp_dir, root)" in TestCaseWithMemoryTransport still present in current bzr?
<ddaa> it's causing pain with the launchpad test suite
<ddaa> generally, please do not use atexit for test suite cleanup... it's gross
<lifeless> I don't recall a patch removing that anytime recently
<lifeless> mind you I don't recall putting that in ;)
<ddaa> lifeless: I know you have better taste that that, I was broadcasting
<abentley> To answer your question "whats the difference between [get_matching_blocks output]  and our deltas today", get_matching_blocks doesn't produce a delta, just match regions.  Knit deltas can't directly produce get_matching_blocks output (but if you have the fulltexts, then they can accelerate that).  Multiparent deltas with a single parent can produce get_matching_blocks output, but with multiple parents, they can't.
<lifeless> get_matching_blocks is whitespace-ignoring specific right ?
<abentley> No, it's generic.  It's what we use for everything.
<abentley> knit deltas, annotation, diff.
<lifeless> if we implement diff -w
<lifeless> or annotate -w
<lifeless> -w ignores whitespace so "    foo = 'bar' "   and "    foo = 'bar'" are considered to match
<abentley> I'm not quite sure what you're asking, but having pre-calculated get_matching_blocks output would allow us to dramatically reduce the regions we compare for arbitrary diffs.
<abentley> Or annotate, for that matter.
<lifeless> presumably via composition of these regions
<abentley> Yes.
<lifeless> I'll think about this some
<abentley> It seems like we may have over-optimized "annotate".
<lifeless> I think we should be able to get diff performance up to where hg have it on arbitrary texts before we implement caching.
<lifeless> annotate - possibly yes
<abentley> While it's nice to be fast, it doesn't have to be as fast as fulltext access.
<abentley> And for annotate merge, you don't need annotations for most lines, and you don't need precise annotations for lines that were introduced by common ancestors.
<lifeless> yup
<abentley> So possibly storing get_matching_blocks regions is better than caching annotations.
<lifeless> it would be less data for sure
<lifeless> do we have an uncached annotate facility still ?
<lifeless> or do I have to recreate it to disable the annotation cache in packs?
<abentley> I thought only bzrtools did that, until we got weaves.
<abentley> Anyhow, I do have the bzrtools code, but I bet it's pretty dated.
<abentley> There is the reannotate code, though.
<abentley> That should do the trick.
<abentley> It annotates from parents to children, not from children to parents.
<lifeless> so full history ?
<lifeless> anyhow, we're going to need a cacheless annotate routine somewhere
<abentley> Well, if you had an annotated fulltext of an ancestor, it could work from that.
<abentley> And for merge purposes, you could start at a common ancestor.
<abentley> But if you want the full annotation with no cache, you have to go through history anyway.
<lifeless> yes full history all sides
<lifeless> with the potential to stop early if we go from child -> parent
<BryceLeo> anyone had a problem installing the new bzr via synaptic in ubuntu?
<BryceLeo> feisty fawn if it matters
<abentley> Well, there was a problem reported this morning, but I'm unclear whether it applies to Feisty.
<abentley> Does it say "error in control file: `Files' value not specified"?
<BryceLeo> yup
<BryceLeo> i think i've got a fix
<BryceLeo> yup it's super simple
<BryceLeo> let me pasebin it right quick
<lifeless> BryceLeo: fixed packages are already building
<BryceLeo> awesome
<BryceLeo> well i've got a patch if anyone wants it now
<BryceLeo> haha now if only you guys could fix why the python binding for gtkmozembed crashes with https
<lifeless> hahah
<lifeless> just figured out why GzipFile is _so_ slow
<lifeless> it overrides the default compression level for zlib
<lifeless> GzipFile('foo', 'wb') == gzip -9
<BryceLeo> whoops
<lifeless> q: why is bzr slow
<lifeless> a: stdlib fuckage
<Peng> Don't the docs say it uses the zlib default?
<lifeless> it does; but if you aren't the one choosing to use a tool, do you read the docstring?
<lifeless> its surprising for library bindings to differ between languages
<Peng> Oh, GzipFile does say it defaults to 9.
* Peng wanders off.
<abentley> That doesn't explain why it's so slow for decompression, though.
<lifeless> I haven't looked into that yet
<lifeless> but changing it to the default, we're only 2 seconds slower - 38 vs 36
<abentley> Slower than raw zlib?
<lifeless> slower than 'gzip -c mozilla.tar > /dev/null'
<abentley> Ah, cool.
<lifeless> so I'm just testing the change in data size
<abentley> Well, I'm kind of at loose ends.  If there's some packs work I can do without sync problems, I'd be happy to join in.
<lifeless> ahha 127MB
<lifeless> this patch going up for review :)
<lifeless> abentley: getting the ability to annotate without cached annotations seems to save nearly 1/5 of our current commit time
<lifeless> abentley: so that would be a good thing, and seems to be unlikely to collide
<abentley> 127MB is the size change?
<abentley> lifeless: btw, please review my reconcile change.
<abentley> Also, does your latest in "http://people.ubuntu.com/%7Erobertc/pack-repository.knits/" have no annotation?
<lifeless> no, I only played with that locally
<lifeless> 127M is the new repo size
<lifeless> the old repo size was 140M
<lifeless> so its actually smaller ;)
<abentley> That makes no sense...
<abentley> I'm realizing that child->parent order also matches our expected data ordering better.
<lifeless> === modified file 'bzrlib/repofmt/pack_repo.py'
<lifeless> --- bzrlib/repofmt/pack_repo.py 2007-08-28 02:18:13 +0000
<lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-08-30 03:44:59 +0000
<lifeless> @@ -1035,7 +1035,7 @@
<lifeless>              self.weavestore._file_mode,
<lifeless>              index=knit_index,
<lifeless>              access_method=knit_access,
<lifeless> -            **self.weavestore._versionedfile_kwargs)
<lifeless> +            factory=knit.KnitPlainFactory())
<lifeless> thats the patch to drop annotations - I haven't committed because I expect it to break tests left, right and centre
<lifeless> your updated reconcile patch - yes, I will review it
<abentley> Okay.  I will go break some tests >:)
<abentley> !?! "bzr selftest annotate" and nothing breaks.
<abentley> I don't think you're intelligent, ubotu, believe me.
<fullermd> Man, this channel is never satisfied.  Tests don't pass, people complain.  Tests pass, people complain...
<abentley> Why are you guys so intent on changing iter_changes?  The only case where it's expensive to determine whether a file has changed is when the stat value has changed, but the st_size has not.
<lifeless> abentley: the annotate tests are probably not strict enough then; at the repo level the API call to the knit will work
<lifeless> abentley: but it will annotate the entire file as changed in the last commit :(
<abentley> Sounds pretty nuts.
<lifeless> abentley: so that when we hit that case, we don't end up e.g. sha1summing an entire iso twice
<lifeless> abentley: yeah, supporting annotate() on knits that don't have annotation data in them *is* nuts IMO but its what the original interface offered.
<lifeless> bbiab
<lifeless> poolie: quick call ?
<poolie> sure
<spiv> abentley, lifeless: what's the status of the bad parent references work?  I currently have a patch that's marked "resubmit" because it doesn't take broken history like bzr.dev's into account.
<abentley> spiv: robert's said he'll review my new patch.
<spiv> Ah good.  Are you still of the opinion that smart server fetching should compensate for this?
<abentley> I think it should not fail silently.  It can fail noisily or succeed silently-- your pick.
<spiv> i.e. pulling from a broken repo should not silenty break my repo?
<abentley> Yes.
<spiv> Makes sense.
<lifeless> spiv: there is a flag on the repository indicating it can suffer from this form of corruption
<lifeless> spiv: so if it is set you'll need to check that the knit parents match the last modified in the parent's ancestries.
<lifeless> this is expensive, so we may want to do a format bump just to ensure that we have a format without the flag set
<lifeless> abentley: ^ does this make sense to you ?
<lifeless> spiv: wanna quick chat ?
<spiv> lifeless: yeah, that'd be good
<lifeless> k, I'll ring
<spiv> ta
<abentley> lifeless: Yes, that makes sense to me.
<abentley> Hmm.  Maybe it could be a supplemental flag?
<abentley> Because it would still be readable by older clients.
<lifeless> abentley: I meant a flag on the object, not on disk
<lifeless> abentley: thinking about it some more with spiv; we think the client can check if the delta basis is present and error if its not
<abentley> I meant the format bump you were talking about.
<lifeless> abentley: no, I don't think it can be a supplemental flag or older clients will write to the repo too
<lifeless> abentley: and could then introduce this defect
<abentley> Oh, drat.
<lifeless> igc: compression fix has landed
<igc> lifeless: excellent - just checked pqm 5 mins ago checking its progress :-)
<abentley> Anyhow, I was surprised you said it was expensive to detect this, and I agree it makes sense to error on missing delta basis.
<abentley> spiv: Would it make sense to provide a way to do dumb fetch?
<lifeless> abentley: by dumb you mean the current knit join approach ?
<abentley> Yeah.
<abentley> For people who can't reconcile the source repo.
<abentley> But I also mean, just using the dumb transport.
<abentley> But this is only likely to affect initial branches anyhow.
<lifeless> I think that might be reasonable but given that few people run bzr+ssh-only repo's anyhow
<lifeless> igc: pushed a pack repo that has the compression fix too, to my 'repository' branch.
<igc> lifeless: thanks. I'm interested in a pack repo with annotations separated next :-)
<abentley> igc: I'm working on stripping annotations completely.
<igc> abentley: from knits?
<abentley> From packs.
<igc> I guess I was assuming that would be a format bump and it may as well come with the pack stuff?
<igc> cool
<abentley> Yeah.  We'll see.  It may not be performant without at least caching get_matching_blocks.
<abentley> But since we can extract that from our delta formats, who knows?
<Peng> Stripping annotations from packs? As in 'bzr annotate'?
<lifeless> igc: I pasted the patch for that here
<igc> code,code,code ... measure,measure,measure ... code,code,code ...
<igc> lifeless: ok, I'll grab it later - just trying to get an options patch out right now
<abentley> Peng: yes.  It's a significant cost when committing large trees.  We promise not to break anything.
<fullermd> It doesn't break anything; all the tests still pass   ;)
<Peng> abentley: But will it make bzr annotate slow?
<lifeless> Peng: s/?/er?/
<lifeless> yes
<Peng> Even slower?
<Peng> Yuck.
<Peng> One thing I liked about bzr was speedy annotations, and now it'll be worse than hg.
<Peng> I know I know, I'd be whining about slow commits if you didn't do this. :P
<abentley> Why do you think it will be slower than hg?
<lifeless> why do you say it'll be worse than hg ?
<Peng> I don't know.
<Peng> I compared it some time.
<Peng> Hold on.
<Peng> ....
<Peng> Hey, where can I get a copy of the repository branch new enough to access the repository branch?
<abentley> http://people.ubuntu.com/%7Erobertc/pack-repository.knits/ ?
<lifeless> yup
<lifeless> Peng: see my dogfooding mails to the list
<Peng> I didn't think that branch was up-to-date enough.
<NamNguyen> abentley: what does auto_merge.py do?
<lifeless> Peng: I've explicitly stated that I keep it up to date enough to read the other branch
<lifeless> Peng: its the bootstrap
<Peng> Oh.
<abentley> NamNguyen: It marks merge requests merged if they have been merged into the mainline.
<NamNguyen> abentley: how is that done? i looked at the code but didn't understand it much
<Peng> Okay, I get it.
<NamNguyen> something to do with merge_id, is it supposed to be unique?
<Peng> I need to throw out my old branch of repository, and get it again?
<abentley> No, not merge_id.
<abentley> First it downloads the latest version of the mainline.
<abentley> Then it finds which revisions are newly part of the mainline's ancestry.
<poolie> lifeless, are you going to upload a new 0.90 deb?
<abentley> Actually, it just finds which revisions are part of the mainline's ancestry.
<lifeless> poolie: yes when I don't get md5 errors from the deb archive during build
<abentley> Then it looks at the merge requests, and sees whether their head revision is in the mainline's ancestry.
<lifeless> Peng: Please read the mails with [PACKS]  in the them on the list.
<lifeless> Peng: they contain all the relevant info
<Peng> Blaaah.
<NamNguyen> abentley: suppose that two merge requests branched from a same revision
<abentley> I don't know what you mean by "branched".
<NamNguyen> they come from a same revision
<abentley> The only thing that matters is the head revision-- the newest revision in the merge request.
<abentley> So you have two merge requests trying to submit exactly the same change?
<NamNguyen> different change
<abentley> Where they branched from doesn't matter.
<NamNguyen> isn't the head revision the parent revision?
<abentley> No.
<abentley> The head revision is the youngest revision.
<abentley> If the merge request has a bundle, all the other revisions in it will be ancestors of the head revision.
<NamNguyen> and when this bundle is merged, is the revision id kept unchanged?
<NamNguyen> its revision ids
<abentley> Yes, revision ids are never altered.
<NamNguyen> i see, so the idea of automerge is to check all outstanding merge requests' latest revision ids to see if they are in the branch
<abentley> Right.
<lifeless> Peng: if you've read the mail and are lost I'll happily help you
<lifeless> Peng: but I don't have time to simply be repeating myself sorry
<Peng> lifeless: Yeah, I get it. I need to get a mail client up and running and start reading the list. :P
<lifeless> Peng: gmane has it
<Peng> I can't get Gmane to load at the moment.
<Peng> I'm reading the list on lists.ubuntu.com.
<lifeless> ok
<Peng> Okay!
<poolie> are the generated html files going to be called .htm or .html?
<poolie> i thought we agreed to change it to .html?
<sri> sup
<poolie> hi
<Peng> Annotating a 1000-line file with 1600 revisions, user time:
<Peng> bzr knits: 1.1 seconds
<Peng> bzr packs: 3.6
<Peng> hg: 4.0
<Peng> Bzr 0.90 was a few msec faster than the pack version in a knit branch. :P
<abentley> poolie: They're html, but no one has updated the online documentation.
<abentley> igc was looking into it last I heard.
<poolie> the cron job is running, but maybe it's not copying them across
<igc> poolie: the doc usually gets updated as part of the release rollout
<lifeless> Peng: ms differences are sampling noise
<igc> I've been meaning to ask you about where James got up to
<lifeless> Peng: the 3.6 seconds is due to the single text index not doing partial loads
<Peng> lifeless: Will that be improved in the future?
<lifeless> yes
<Peng> Yeah, you're right, it was just noise.
<Peng> lifeless: Okies.
<Peng> lifeless: But removing annotation data will make it slower ..
<lifeless> thats right.
<lifeless> but every file version has to get committed by definition
* igc lunch - bbiab
<lifeless> only some get annotated
<lifeless> so we could for instance have a background task to generate an annotation cache
<lifeless> fire off a thread as a commit hook
<Peng> Huh.
<lifeless> or cache different data that helps annotations as abentley mentions
<lifeless> lots of options
<lifeless> but removing 20% overhead during commit that is only sometimes used seems like a pretty good idea
<Peng> Yeah, it does.
<Peng> I just liked having fast annotations. :P
<lifeless> e.g.
<lifeless> if you ask for an annotation of file X, we cacn cache the results
<ubotu> New bug: #135770 in bzr (main) "bzr faild ti install (dup-of: 135891)" [Undecided,New]  https://launchpad.net/bugs/135770
<Peng> Removing 20% overhead from commits won't change if they're "fast" or "slow", but the change will make annotating "slow" instead of "fast".
<Peng> Anyway, I don't want to stop you or anything.
<Peng> Just sayin'.
<lifeless> the way you get from slow to fast commits is by stripping overhead thats not needed
<Peng> Well sure. It's a significant improvement and that's a good thing. But commits going from 1s to 0.8 is still "fast", and 10 to 8 is still "slow".
<Peng> But annotating going from 1 second to 4 is "fast" to "slow".
<Peng> Anyway, I'll shut up.
<Peng> The change is a good idea.
<Peng> I just hope that you'll be able to keep annotating as fast as possible! :)
<abentley> lifeless: Got annotation of plain knits tested and working.  Where do you want it?  Technically, it could even go in bzr.dev, I guess.
<lifeless> abentley: bzr.dev :)
<lifeless> abentley: I want to keep the branch as small as possible at all times
<abentley> Aw, drat.  I'll hafta cherrypick.
<abentley> igc: It seems as though the path must start with 'callgrind.out', not just the basename.
<igc> in my code you mean? If so, I'll fix that
<poolie> i'm looking into why the docs aren't visible
<igc> thanks poolie
<poolie> they are being built; they might not be copied to the right directory, or something like that
<poolie> ok i think that's ok now
<abentley> Awesome.  Now we have a copy of NEWS to point people at.
<abentley> lifeless: I've got the new annotation code using precalculated get_matching blocks everywhere possible.
<lifeless> abentley: you're on fire
<abentley> That too.
<igc> abentley: +1 to that
<abentley> But without matching blocks for the righthand parent of merges, there are still 279 calls.  And that's 40% of runtime.
<lifeless> whats your test file, NEWS?
<abentley> Yep.
<abentley> revision 2000
<abentley> That still takes 13 seconds.
<abentley> So I don't want to go higher.
<abentley> I'm not storing any new data, just using the knit deltas to extract get_matching_blocks output.  Which is why the 40%.
<abentley> Because knit deltas only tell us about the left parent.
<lifeless> man python you suck
<lifeless> a$ python -m timeit 's = [] ; s.append((200, 300)); s.pop()'
<lifeless> 1000000 loops, best of 3: 0.874 usec per loop
<lifeless> $ python -m timeit 's = [] ; s.append((200, 300)); del s[-1] '
<lifeless> 1000000 loops, best of 3: 0.528 usec per loop
<abentley> Sheesh
<lifeless> $ python -m timeit 's = [] ; s.append((200, 300))'
<lifeless> 1000000 loops, best of 3: 0.398 usec per loop
<lifeless> .130 to do del s[-1] , .480 to do s.pop()
<fullermd> If it helps, it takes my system longer to do the pops than it takes yours to do the whole bunch   :p
<lifeless> fullermd: do you see the same relative costs?
<fullermd> ~1 -> ~2.3.
<fullermd> Well, ~1 - ~1.25 - ~2.3.
<fullermd> Eyeballs similarish, yah.
<lifeless> copy n paste is easier :)
<fullermd> Little over double cost for pop, 'bout 25% more for del.  Close enough.
<poolie> lifeless, thanks for making a sid/gutsy repo
<abentley> lifeless, poolie: I've started work on a NEWS-specific text merge, but no ETA on completion yet.
<abentley> Annotating the latest version of NEWS takes 1m25.767.  Eeps.
<abentley> g'night.
<poolie> lifeless, i think splitting the news might make it easier for people developing across releases
<poolie> because their changes would not accidentally end up in a different release
<igc> poolie: thanks for the doc stuff. It looks good except that the 'latest' link is still pointing to some older doc?
<poolie> thanks, fixed ?
<igc> poolie: yes, assuming latest means 'current release', not 'development'
<lifeless> latest is not clear
<igc> we do have bzr.dev for that
<igc> I'd prefer 'current' to 'latest' my self
<poolie> maybe we should just get rid of that link and let people who want the latest look at bzr.dev?
<igc> that would do
<igc> 2nd thoughts ...
<igc> I'd like a 'current' link
<lifeless> latest was meant to mean current release
<lifeless> I didn't think about clarity enoug at the tome I think
<igc> it's need IMO, I just don't like the name
<poolie> can someone glance at http://bundlebuggy.aaronbentley.com/request/%3C2422be180708301335x3103b2c9mbaf318e287b4cf3b@mail.gmail.com%3E
<poolie> please
<beuno> please :D
<beuno> btw, is bundlebuggy a custom thing?  it's marvelous  :D
<Peng> beuno: Yes, but it's open source.
<beuno> Peng, aaah, well, it's a great idea/implementation
<Peng> Totally. :)
<igc> poolie: that looks fine to me. I'll approve it in BB
<poolie> igc, thanks
<beuno> yay!  does the bug close my itself in LP?
* beuno guesses "no"
<poolie> which bug?
<beuno> the one that the patch is for, #107155
<lifeless>  python -m timeit '{1:2, 2:3, 3:4}'
<lifeless> 1000000 loops, best of 3: 0.584 usec per loop
<lifeless>  python -m timeit 'dict(((1,2), (2,3), (3,4)))'
<lifeless> 100000 loops, best of 3: 2.15 usec per loop
<fullermd> 'bout the same ratio here.
<lifeless> just the inner tuple there is tuple is 0.177
<lifeless> ok, bye. I need to pack
<beuno> aaaaanyway, time I get some sleep, ping me if you need anything else with the patch, night all  :D
<poolie> beuno, i've just sent it off
<beuno> poolie, great, thanks a bunch, I'll close the bug then
<poolie> spiv, quick call?
<spiv> poolie: sounds good.  Two minutes?
<poolie> sure, call me when you're ready
<poolie> igc, i like custom_help()
<igc> thanks
<igc> spiv: is http://bundlebuggy.aaronbentley.com/request/%3C20070826091222.GC11127@steerpike.home.puzzling.org%3E merged into the bzr.dev yet?
<poolie> igc, would you like a catchup call? when were you going to finish today?
<spiv> igc: not yet, thanks for the reminder.
<igc> poolie: don't mind either way. Need to wrap up around 6 tonight
<poolie> ok, can we talk about 5:30?
<igc> sure
<poolie> cool
<poolie> i'm stepping out for a bit
<igc> poolie: before you go ...
<igc> I'm about to do some reviews
<igc> any preferences for which ones?
<poolie> not in particular, though i do think doing some is a good idea
<poolie> i'm just doing yours
<igc> ok - I'll do the --change one from Lucas and the pre-commit hook one
<NamNguyen> igc, thanks for reviewing the patch for pre_commit hook
<NamNguyen> does a commit to CommitBuilder actually commits anything?
<NamNguyen> or does it only flag that a commit is done, ready to be flushed out to disk
<igc> few minutes - on phone
<siretart> is there a spec or bug or something for the 'bzr cp' feature?
<siretart> I'm trying to maintain file templates in a bzr branch. after I change the template, I want all changes I was doing there to be merged into copies of that file. is that possible with bzr?
<poolie> siretart, i believe there is a spec discussing how it could work, but it is not implemented atm
<poolie> one of the issues is how to determine what changes should propagate or not
<siretart> I'd like to subscribe to the spec. do you remember how it was called?
<poolie> no
<siretart> I imagine that it is tough, though ;)
<igc> NamNguyen: CommitBuilder.commit does the actual commit to disk
<igc> See bzrlib/repository.py
<fullermd> Well, it's probably not especially easy to do, but working out (and agreeing onn) what it should do is even harder   :)
<NamNguyen> igc: but if there's an exception in a precommit hook, the whole commit seems to be discarded
<NamNguyen> i can be wrong here, but isn't there some kind of rolling back mechanism?
<igc> NamNguyen: looking closer, it looks like self.branch.set_last_revision_info is the final piece of the puzzle ...
<igc> until that final bit is written, the data is on disk by not linked in it seems
<igc> s/by/but/
<NamNguyen> igc: i'm trying to find out if the file is truncated after all
<igc> NamNguyen: so apologies - you could be fine after all ...
<NamNguyen> igc: but that might increase the size of the repo if it's not undone
<igc> Maybe - we do have a gc command though
<NamNguyen> but then, the next time you commit, it will be written over the same place as the discarded commit
<NamNguyen> so i think it all works out
<igc> NamNguyen: my suggestion is to ping abentley in a few hours and get his opinion on precise location ...
<NamNguyen> okay
<igc> he did approve your code *and* he knows the commit code really well
<NamNguyen> he reviewed it twice, but no harm pester him to do it again
<igc> don't ask him to review the code - just double check on that bit and the consequences of ...
<igc> an exception in the pre-commit hook
<igc> I guess he'll say "all ok" in which case ...
<NamNguyen> alright, i'll ask him
<igc> that's great - well done on your first bzr patch!
<igc> I'll be happy to merge it Monday.
<NamNguyen> i look forward to handing in more patches :D
<igc> If you want to update the hook doc though before then, even better still
<igc> I look forward to receiving them :-)
<igc> Well, time to go after another good week in the wonderful world of Bazaar ...
<igc> great to see 0.90 ship and lots of neat stuff coming in 0.91 and 0.92
<igc> Have a good weekend all
<poolie> night all
<mwhudson> so
<mwhudson> is there a way to tell bzr/bzrlib to set a timeout on the sockets it creates?
<mwhudson> or, to ask what i really want to know: not wait for more than some interval (a minute?) for a response from the remote server?
<NamNguyen> mwhudson, with python 2.5, yes
<mwhudson> NamNguyen: ?
<NamNguyen> socket.setdefaulttimeout(60)
<mwhudson> that's possible in 2.4 already
<NamNguyen> maybe you can put it in your sitecustomize.py
<mwhudson> i suppose we could do that
<NamNguyen> oh? hah, my bad
<mwhudson> this is code that calls bzrlib apis, so it could just do that during start up
<mwhudson> this branch: https://code.launchpad.net/~ypodim/teleporter/teleporter keeps tripping launchpad up
<matkor> jelmer: Can you merge one typo fix from  https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? I emailed phanatic but seems be busy, TIA
<jelmer> matkor: sure
<ignas> hi
<hacklberry> hi, where could i get more details about bzr "smart merging"?
<z1pp1ty> i'm looking to use bazaar to do something like this...
<z1pp1ty> working copy -- bzr --> local svn repo -- svn --> remote svn repo
<z1pp1ty> I assume it can be done, but are there docs anywhere on how to do something like this?
<hacklberry>  where could one get more details about bzr "smart merging"?
<bwinton> Hacklberry: Google?
<bwinton> From http://bazaar-vcs.org/BazaarBook#features:
<bwinton> Smart Merging
<bwinton>     * Merge knows and merges only whats missing.
<bwinton>     * Merge minimizes spurious conflicts.
<bwinton>     * Merge is not tricked by identical changes.
<hacklberry> well the reason why i asked is that when i try to merge into a 'main' branch from 2 branches merge is actually 'tricked by identical changes'
<bwinton> Sweet!  Do you have a test case?
<hacklberry> what i tried is quite simple - i really think i misunderstood something
<hacklberry> i merge from branch A where i added 3 lines:
<hacklberry> xxx
<hacklberry> yyy
<hacklberry> zzz
<hacklberry> now on branch B i added 3 lines as well:
<hacklberry> qqq
<hacklberry> yyy
<hacklberry> zzz
<hacklberry> and when i tried to merge branch B
<bwinton> Ahhh...  Well, those aren't exactly identical changes...
<hacklberry> he - as i said i misunderstood it then
<bwinton> If you had committed yyy and zzz in a different step on both branches, then you'ld probably get what you were looking for...
<bwinton> i.e. branch A gets yyy + zzz, then gets xxx.  Branch B gets yyy + zzz, then gets qqq...
<luks> just wondering, what would you expect to be the correct merge here?
<bwinton> (Now, I haven't tried that myself, but my intuition is that that should work.)
<hacklberry> well i was expecting merge to see that those changes are coming from diff sources
<hacklberry> i was trying to add:
<luks> I mean the result
<luks> I personally can see three possible merges: xxxyyyzzzqqqyyyzz or qqqyyyzzxxxyyyzzz or xxxqqqyyyzzz or qqqxxxyyyzzz
<luks> and all of them seem wrong to me
<bwinton> (Psst, luks, that's four merges...)
<luks> er, four :)
<luks> I had only three initially
<hacklberry> int foo() {
<bwinton> Nasty off-by-one error you got there...  :)
<hacklberry> return 0;
<hacklberry> }
<hacklberry> on one branch
<hacklberry> int bar() {
<hacklberry> return 0;
<hacklberry> }
<hacklberry> on second branch (both forked from main branch)
<hacklberry> and then i merged into main from branch A
<luks> so let's say some algorithm would merge them, in what other?
<luks> foo and then bar, or the other way around?
<hacklberry> so when merging from B i was expecting merge to pickup that the changes are different, and mark the whole
<hacklberry> int bar() {
<hacklberry> return 0;
<hacklberry> }
<hacklberry> as a block
<luks> and it marked only the function definition, right?
<hacklberry> so i can then manually merge in some tool like kdiff3
<hacklberry> yes exactly
<luks> hm
<hacklberry> that's how i understood ' Merge is not tricked by identical changes'
<hacklberry> "You may say I'm a dreamer, but I'm not the only one." :-)
<luks> hm, I see
<luks> weave merge marks only the function definitions, merge3 marks whole functions
<luks> but isn't --merge3 the default?
<hacklberry> i tried all 3 algorithms
<hacklberry> but kdiff3 displayed the same
<hacklberry> i thought that bzr uses some unique ids for every change
<hacklberry> so a line of text like abcd from 2 diff sources will be treated as 2 diff entries even if the content is the same
<luks> I think the 3-way merge should do exactly that
<luks> (and it does here)
<hacklberry> ok i m going to try again then
<hacklberry> i mean in the morning :-) it is 1:30am here, i live in Canberra
<radix> whoah
<radix> I just got a warning saying that my Python interpreter doesn't support en_US.UTF-8
<radix> (during a bzr push)
<radix> strangely enough, python -c 'from bzrlib.osutils import get_user_encoding; print get_user_encoding()' prints "UTF-8" with no warning
<dato> was it a bzr push over bzr+ssh? then what matters is if the target system supports en_US.UTF-8, afaik
<radix> ah, interesting, yes
<radix> thanks a lot dato :)
<dato> no problem
<nx> LarstiQ: ping
<synic> after a 'bzr up', how can I see what files were changed?
<james_w> synic: do you remember what revision you were on previously? Do the command tell you how many you just got?
<james_w> if you know then bzr status -r-6.. should tell you
<james_w> another way is bzr log -v and then just read the log messages and see which files were changed.
<synic> k
<jelmer> synic: we also plan to let it output the changes in the future, unless -q is specified
<synic> jelmer: is there any way to output the changes during update with a flag?  -v maybe?
<ubotu> New bug: #136445 in bzr "Please provide an easy way to ask "What did you just do?"" [Wishlist,New]  https://launchpad.net/bugs/136445
<bwinton> Now that's an awesome bug...
<bwinton> bzr wtf-just-happened-there
<jelmer> synic: Not yet
<synic> jelmer: ok
<Peng> That bug is a good idea. Before I fully got into the habit of using 'bzr pull -v', I wouldn't be able to find out what all was pulled.
<Peng> Maybe just printing the old revision during those command would be good enough.
<Peng> Like, where it says "Now on", it could say "Started at" too.
<synic> can you checkout a specific directory in a branch?
<Peng> synic: No.
<mtaylor> anybody know what the status of the visual studio plugin - https://launchpad.net/bzr-visualstudio - is?
<nx> mtaylor: yep
<nx> I'm the developer
<mtaylor> nx: cool. is it ready for people to use/poke at?
<nx> go ahead. it's still lacking some features, but those that are implemented should work well
<mtaylor> nx: sweet. I'll give it a spin then
<mtaylor> nx: should I branch trunk ?
<nx> banquet.status is the latest code
<nx> I haven't managed to create an installer yet; you'll need to have the VSSDK installed to run from the branch
<mtaylor> ok. I think I've got that installed on this box
<mtaylor> nx:  when I try to open the .sln file, I get errors about not being able to open the Project files...
<nx> what's the exact error message? do you have the SP1 installed?
* Janzert semi, sorta remembers running into issues with hardcoded absolute paths
<mtaylor> nx: Unable to read the project file 'Banquet.csproj'
<mtaylor> nx: but I might not have sp1 installed. let me check
<nx> right, i forgot you need to set a environment variable named VisualStudioIntegration that points to the VisualStudioIntegration directory in the VSSDk directory
<nx> sorry
<nx> or just open the csproj file and replace $(VisualStudioIntegration) with that path
<mtaylor> ah, ok
<bwinton> Has anyone here run bzr on Python 3.0 yet?
<radix> aggggggggggh
<radix> it's already started
<dato> hahaha
<bwinton> Hey, give me some credit.  I've had the 3.0a1 announcement page sitting in my browser since 9:00 this morning!
<radix> we are doomed, Guido has killed us all
<bwinton> Heh.  I think you're thinking of Python 4000, with sys.kill_us_all()...
<radix> bwinton: it is impossible to run most existing Python code on python 3
<bwinton> Sure, but the 2to3 tool gets you part (most?) of the way there.  I was wondering how far it got bzr...
<radix> ah. ok. so really you wanted to ask if anybody has ported bzr to python 3 yet :-)
<bwinton> radix: If you want to be technical about it...  ;)
<bwinton> Actually, I think I was even further behind than that.  I really wanted to ask if anyone had looked into porting bzr to python 3 yet.
<lifeless> LarstiQ: ping
#bzr 2007-09-01
<cgdae> hello. apologies if this is already known, but i think that there are some broken links on http://bazaar-vcs.org/BzrUserGuide
<abentley> cgdae: We just switch the extensions from .htm to .html
<abentley> Feel free to update that page.
<cgdae> ah, ok. i'll have a go.
<NfNitLoop> Hmm.  SO I've just been reading up on mercurial.  I see a couple advantages bzr has:  sane shared repositories (instead of hg's hard linking)  and easier command-line interface.
<NfNitLoop> what else am I missing?
<NfNitLoop> The only real advantage I see to hg so far is that it scales better.
<cgdae> i've fixed the broken links on http://bazaar-vcs.org/BzrUserGuide.
<james_w> cgdae: thanks.
<james_w> NfNitLoop: a lot of people like mq.
<james_w> NfNitLoop: they also have the hg book.
<cgdae> all i need now is some unbiased advice about whether to try mecurial or bazaar as a replacement for cvs... :-)
<james_w> cgdae: try either.
<james_w> cgdae: what are your requirements?
<NfNitLoop> james_w: mq?
<cgdae> james_w> we have a developer who has only occasional internet access. we've been packaging up our entire cvs repository for him to download and use locally, then he emails patches to us which we commit. repository is fairly small, 18MB compressed i think.
<cgdae> james_w> so no special requirements really. we use openbsd as server. it doesn't have a bazaar port, but it installs trivially by hand.
<Peng> NfNitLoop: Hg has file copies.
<Peng> s/has/supports/
<james_w> NfNitLoop: mercurial queues, quilt for hg basically
<james_w> cgdae: your project is not too large, so either system should cope fine.
<NfNitLoop> I'm not familiar with quilt.
<james_w> I would guess that bzr is easier to install, but that's just a guess, I may be wrong. hg requires C code I believe, for bzr it is optional.
<NfNitLoop> hg ended up being easier for me to install, since they provide a package for Debian stable.
<Peng> The C code in hg isn't a major issue for installation, unless you're on an odd platform that it doesn't work on.
<NfNitLoop> (though IIRC the latest version was released last june)
<james_w> cgdae: I would suggest that you install both and just play aroung see which you prefer.
<james_w> also chat to the hg folks as well, and see how helpful they seem, you may need some help in the future with something.
<james_w> Peng: thanks for the clarification.
<james_w> NfNitLoop: quilt is for managing multiple patches, it's kind of version control, but a bit specialised.
<james_w> one thing that is odd to me is hg's merging, there's an extra step in there which I find a bit weird.
<cgdae> james_w> that's good advice. thanks.
<NfNitLoop> james_w: well, it seems to be a different approach.
<NfNitLoop> iirc, bzr requires that you commit local changes before merging.
<NfNitLoop> hg doesn't.   So it gives you a chance to do so before you actually merge pulled changesets into the working copy.
<james_w> ah, that's why, thanks.
<NfNitLoop> personally, I think committing your changes separately is a better idea.
<NfNitLoop> But there's something to be said for not requiring that workflow.
<NfNitLoop> on the other hand, because of the way hg does it, you can have several heads in a single branch.   Which ... seems needlessly complex.
<james_w> that will throw a lot of people I guess.
<james_w> you can go all the way to git and just do that all the time. It does win you quite a lot, but some people will take a long way to get their heads around it.
<NfNitLoop> git allows multiple heads in one branch?
<NfNitLoop> (or repo, or whatever they call it?)
<james_w> yeah, in a repo, but a repo is all you have in git, so it's like a bzr branch.
<james_w> ...sort of.
<NfNitLoop> I really like the separation of working copy / branch / repository with bzr.  I haven't seen that with other VCSes.
<james_w> The branch/repository distinction confuses some, and the terminology confuses others.
<NfNitLoop> It confused me at first.
<NfNitLoop> I came from cvs/svn.
<james_w> Also, as a repo is not needed people may not create one when they start, and then they lose a lot if they are branching locally. However most tutorials now start with the 'init-repo' step to avoid this.
<NfNitLoop> where a branch was very much something *inside* the repository, not able to be separated.
<james_w> but that then means you have to get straight in to explaining the differences, before they've even started.
<NfNitLoop> Yeah.  Which may not be a good first impression.  "Wow, this is complex."
<james_w> yeah, you can't separate them in bzr either, but you get a hidden repo if you don't have an explicit one.
<NfNitLoop> I don't know that it's that important, though.   It's always easy to convert to a shared repo later.
<james_w> exactly.
<james_w> yeah, it is. People have talked about adding a command to do that in one step, but I've not seen any code.
<NfNitLoop> Eh.  you don't need another command for that when it's a few simple commands that are easy to remember and not too often used.
<james_w> true.
<NfNitLoop> er, rather, the simple commands are used often.  the single comprehensive command would be rarely used.  You knew what I meant. :p
<sblack> Anybody have any word on .90 windows standalone installer?
<sblack> I was going to try out .90 but have trouble building with Visual Studio 2005 installed
<ekim|irc> How can I setup bzr to work like subverion (to a point)
<ekim|irc> I wanna use bzr to upload my gfiles to a remote server
<ekim|irc> how can I do that
<jkakar> ekim|irc: You can, yes.
<ekim|irc> how ?
<jkakar> ekim|irc: See 'bzr help checkout' for more information.
<jkakar> ekim|irc: Basically, if you have a branch on a remote system and you want to work in the Subversion style where your local changes have to commit remotely you can 'bzr checkout sftp://my-remote-branch'; commits made in the resulting local branch will need to succeed on the remote branch for the commit to complete.
<ekim|irc> someone told me that you can actually use mod_dav_svn to do it
<sblack> Does anyone here have any knowledge of a windows binary distro of 0.90?
<sblack> I've tried working with the source, but I get build complaints about Visual Studio 2003 (I have 2005) and the instructions
<sblack> for "-c mingw32" don't appear to be recognized
<Peng> Oooh. Lightweight checkouts need to contact the server for just 'bzr st' or 'bzr diff'. That sucks.
* Peng wanders off.
<Peng> Hm. bzr co --lightweight grabs .bzr/repository/format four times.
* Peng wanders off.
<encompass> ok, I have a need!
<encompass> I deleted a dirctory and I want to get the latest revision back... how do I do that?
<encompass> my project is here... htp://launchpad.net/memaker
<encompass> is it simply bzr pull?
<luks> deleted as in 'rm DIR' or 'bzr rm DIR && bzr ci'?
<fullermd> Deleted as in your deleted your copy of the branch?
<encompass> yeah
<encompass> I am the only dev right now... and when I commit and push it goes to trunk
<encompass> as in rm DIR
<encompass> well... rm -rf DIR
<encompass> it is my most recent revision that is needed
<fullermd> DIR being a dir _in_ your branch?
<mwhudson> revert should bring it back
<encompass> what is revert?
<encompass> bzr revert?
<fullermd> Yeah, `bzr revert $DIR`
<encompass> let's see
<encompass> thinks... works great now... saved the day again!
* encompass hugs ubuntulog 
<encompass> :P
<CardinalFang> Grr, there's no installer for Fink on OS X?
<sabdfl> hey revisionistas, has any of the HPSS code landed since 0.17?
<james_w> sabdfl: I believe some smaller things have gone in to make the merge easier later, but the main changes are still out.
<sabdfl> okidoki
<sabdfl> thanks james_w
<james_w> I know Martin was trying to get it in to 0.91, but I don't think it's up for review yet and the freeze doth approach.
* sabdfl can't wait for that stuff to land in the code host
<mrtuple> would someone mind lending a hand with baz-import ?
<james_w> mrtuple: what are you stuck with? I'm not sure I can help, but I don't think Aaron is around at the moment.
<mrtuple> oh thanks.
<mrtuple> I have a tla archive ...
<mrtuple> that 'tla archives' reports as khellman@mcprogramming.com--mcp-2005
<mrtuple>     /home/{karchives}/mcp-2005
<mrtuple> khellman@mcprogramming.com--vb-2005
<mrtuple>     /home/{karchives}/vb-2005
<mrtuple> I'd like to convert the whole thing to a bzr repo.
<mrtuple> (The first one by the way, mcp-2005)
<mrtuple> So I go to the path I want the repo to reside at, and try this:
<mrtuple> bzr baz-import mcp-2007 khellman@mcprogramming.com--mcp-2005
<mrtuple> Which I *think* is what http://bazaar-vcs.org/BzrTools says to do.  Of course, I must be thinking wrong, because it doesn't work.
<mrtuple> bzr creates a mcp-2007 repo (at least it has a .bzr file in it), but after that it crashes with a long backtrace.
<mrtuple> The traceback claims OSerror 2 (No such file or dir), but I don't see a line clarifying which argument doesn't exist...
<mrtuple> I can post copies if it helps.
<james_w> yes please.
<mrtuple> couple minutes probably...
<james_w> fine.
<james_w> are you running a recent bzrtools?
<mrtuple> http://rafb.net/p/vJ5ud964.html
<mrtuple> My bzr version is 0.90, how do I determine my bzrtools version?
<mrtuple> (okay, more than a couple of minutes...)
<james_w> bzrtools complains if it is out of date, so you should be fine.
<james_w> are you on Debian/Ubuntu?
<mrtuple> Yes, lenny/sid
<james_w> then you're fine.
<mrtuple> goody.
<james_w> so it looks like it is having trouble exec'ing baz, you do have it installed, it's on your path etc?
<mrtuple> type -p bzr reports '/usr/bin/bzr'
<james_w> no, baz not bzr
<mrtuple> damn spelling :^)
<mrtuple> well, I'll be darned.  its not.
<mrtuple> I thought bzr replaced baz...
<mrtuple> I still need baz for importing?
<james_w> yeah, it exec's baz to get the information and then imports it to bzr.
<james_w> they are completely different systems really, the naming is just historical.
<mrtuple> apt-get'ing baz now...
<mrtuple> I interpretted the log line...
<mrtuple> bzr: ERROR: pybaz.errors.ExecProblem: baz exited with code 3 (expected exit code 0)
<mrtuple> and
<mrtuple> ExecProblem: baz exited with code 3 (expected exit code 0)
<mrtuple> As 'baz' being a helper app that came along with bzr...  Never thought to consider that it was missing.
<mrtuple> OK, the traceback is at least shorter now...
<mrtuple> http://rafb.net/p/uJmgzU38.html
<mrtuple> Looks like baz is being called with an unexpected option.  Perhaps this is a real defect...
<lifeless> what version of baz and pybaz do you have?
<mrtuple> I think I just figured this out.
<mrtuple> The trace shows a pybaz from *my own* python testing tree being used.  Not the pybaz from debian package systesms.  I had installed this version *several* months ago when I was looking at the conversion process.
<mrtuple> I'm removing that one, installing the pybaz debian package, and then the import will probably work.
<mrtuple> I'll keep you posted, sorry for the trouble.
<james_w> no problem, well spotted.
<mrtuple> Oh yes.  It's working now --- complete with progress bar...
<mrtuple> whooho!
<mrtuple> Finally I'll have a superior VCS!  (all the more branches to hang myself on :^)
#bzr 2007-09-02
<Verterok> Hi y'all
<Verterok> beuno: ping
<beuno> Verterok, pong
<Verterok> beuno: Hi!
<beuno> hey Verterok, how are you doing?
<Verterok> working a bit in bzr-eclipse & bzr-xmloutput :D , how are you?
<beuno> Verterok, working on my php<>bzr integration :D
<beuno> what are you working on with bzrxml?
<Verterok> I made some changes that modify a bit (actually extend) the generated xml :P
<Verterok> these are related to merges and affected files (bzr log -v)
<beuno> Verterok, interesting, I'm basing the php integration on your plugin, dos it change the format of the zml at all?
<beuno> *xml
<Verterok> I can pastebin a generated xml, but the change is how the revisions are handled
<Verterok> the current trunk handle all revisions as equals (i.e: don't know about merges)
<beuno> Verterok, would you?  that way I can start crying on all the changes I have to make  :p
<Verterok> sure
<beuno> although it's great you're extending it, if you need a hand, I get along much better with python then with java  :D
<Verterok> maybe this is not too big, basically I added two new tags: <merge> and <affected-files>
<Verterok> both are child elements of <log>
<beuno> Verterok, aren't the affected files already shown?
<Verterok> I don't remember :P
<beuno> hahaha
<beuno> ok ok, well, you already show the deleted/new/modified
<beuno> as a child of <log>
<Verterok> in my branch I added a <affected-files> tag, to group them
<beuno> ah, well, that will probably just me my code cleaner
<beuno> that's the only bit that's a bit... les the ideal  :D
<beuno> what will the merge tag show?
<Verterok> I think that the *other* change 'll take a bit more of work  (sorry for that)
<Verterok> take a look: http://rafb.net/p/thAACb16.html
<beuno> Verterok, I welcome any improvements, I really do :D
<Verterok> great to known, but the <merge> is a big change :P
<Verterok> it group the merge revisions logs
<beuno> aaaaaaah
<beuno> Verterok,I understand  :D
<beuno> I was actually doing that manully in the PHP code
<Verterok> ah, great then! I think your code could be clean up a bit :D
<beuno> I'll probably shave off half the lines of code!  yay!  :D
<Verterok> so, I have your OK to push to trunk? ;)
<beuno> as I imported I chedked if it was a subrevision, and if it was, associated it
<beuno> Verterok, I'm pretty sure you don't need my OK, but I welcome it
<Verterok> I started to work in the same processing (at the java side), but then I changed bzr-xmloutput :D
<beuno> heh, yes, it makes much more sense
<beuno> I wasn't as confident to go in and change someone's else code
<Verterok> you are most than welcome to do it :D
<beuno> I have been playing around with bzr code more lately, even got a few patches in  :D
<beuno> Verterok, cool, thanks, I'll look into what I'm missing/doing on my side that I can do directly in the plugin, branch, and ping you  :D
<Verterok> great! congrats!
<Verterok> sure!
<beuno> I tuhnk I'll be able to release some of my php code in the following weeks, quite a few people have been requesting it, so it doesn't make sense to keep on develpoing behind closed doors
<Verterok> beuno: I just pushed those changes. now at revno: 18
<beuno> (I'm typing horribly today)
<beuno> great, LP just emailed me too  :p
<Verterok> no problem, I type horribly every day :P
<beuno> hahhah
<beuno> do you have any other changes in mind?
<Verterok> no to the log command, but i need to take a look to annotate
<Verterok> I have some plans to implement a few more commands
<beuno> Verterok, if you want to point me at something specific to look into/code, just drop me a line and I'll see what I can do  :D
<Verterok> for the moment I have in mind: 'bzr plugins' and 'bzr info' (maybe I'll do a custom info --xml command with more information), both to aid bzr-eclipse
<beuno> Verterok, ah, that sounds intersting, and bzr status maybe?  or is that implemented already?
<Verterok> it's already there :D
<beuno> how efficient of you  :p   I'm going to need that in the near future
<Verterok> drop me a line if you need something for: status --xml
<beuno> Verterok, will do, thanks!
<beuno> Verterok, what do you think on having a wiki page with ToDo's? that way it might be easier to know what needs to be done
* beuno just thought of bzr missing being useful too
<Verterok> sounds great! maybe in the bazaar wiki?
<beuno> Verterok, yeap, seems like the right place
<Verterok> I never used yet :P
<beuno> heh, I'll create the page real quick, we can both subscribe and spy on what the other one is thinking of  :p
<Verterok> that 'ld be interesting
<beuno> Verterok, http://bazaar-vcs.org/bzr-xmloutput
<beuno> I;ve subscribed
<Verterok> that was fast!
<beuno> and now, I have to leave for a few hours, but we'll be in touch  :D
* beuno waves at vert
<Verterok> seeya
<nvictor> hi guys :)
<nvictor> I just downloaded the windows version of bazaar
<nvictor> can you tell me how it works?
<nvictor> I'm new to version control :)
<NamNguyen> hi
<NamNguyen> in what encoding is NEWS?
<NamNguyen> it shows Lukas Lalinsky as garbage
<fullermd> Looks normal to me, and I'm in UTF-8...
<tonyyarusso> Aren't those things usually gzipped ascii?
<matkor> Hi ! How can make bzr setup.py install man files in /usr/share/man (FHS) instead of /usr/man/ ?
<lifeless> not sure
<lifeless> possibly some setup.py install --help info will help
<matkor> mmm I am gonna check --install-data /usr/share ...
<AfC> matkor: we did a mv ${D}/usr/man ${D}/usr/share/man in the post_inst part of the Gentoo package
<lifeless> I don't suppose you filed a bug ? ;)
<AfC> Against who?
<matkor> AfC: I see similar patch for PLD ;)
<AfC> [I mean, sure, _maybe_ FHS would be a strong enough argument to get Python to change ... but at the cost of breaking every single Python derived package out there? I doubt they'd do it, frankly] 
<james_w> there should be an option to set the mandir though shouldn't there?
<matkor> james_w, Afc : --install-data /usr/share seems to work
<AfC> matkor: neat
<james_w> thanks mak
<james_w> matkor sorry.
<lifeless> AfC: against bzr
<lifeless> AfC: its our problem to make our setup.py do the right thing
<lifeless> or to document how to do it
<AfC> lifeless: ok
<AfC> matkor: do you want to file it, or shall I?
<hsn_> what i need for syntax highlighting in olive?
<dato> in debian and ubuntu, python-gnome2-desktop
<dato> the library is called gtksourceview
<dato> hsn_: assuming you mean highlighting of the diffs
<dato> I have no idea if other highlighting is supported
<hsn_> i get olive errors like: ImportError: No module named dialog or bzrlib.errors.BzrError: must supply file_id or path
<duckx> quicksilver: jelmer = jw ?
<duckx> plop
<duckx> Sorry
<duckx> james_w: around ?
<james_w> duckx: hi
<duckx> duckx = Frederic Brin ;)
<duckx> You are the guy behind bzr-builddeb right ?
<james_w> ah, hi. Thanks for your fixes/
<duckx> No problem, I enjoy tweeking python
<james_w> :)
<duckx> Well, I tried the import-dsc command
<duckx> And I was wondering one thing
<duckx> Well, it is may be the normal behaviour
<duckx> When you import a dsc, the orig.tar.gz is commited
<duckx> But the debian dir is not ....
<duckx> Is that the normal way to go ?
* duckx thinks it is not ;)
<duckx> By the way I was wondering one thing ...
<duckx> What is the easiest way to get python have my bzr co of bzr-buildep be the python module loaded ?
<duckx> Well, currently I hack the installed debian package, and port the tweeks back to my co tree
<duckx> -> that sucks
<james_w> mkdir -p ~/.bazaar/plugins/; ln -s /path/to/co ~/.bazaar/plugins/builddeb
<duckx> k
<duckx> Just fine for me ;)
<james_w> as for the import let me investigate.
<james_w> you're not using --snapshot correct? just import-dsc blah_0.1-1.dsc?
<duckx> yes indeed
<duckx> with the --to flag
<duckx> bzr import-dsc --to gnucash gnucash*.dsc
<james_w> I need to pull your fix first. Shows that I need some blackbox tests :)
<duckx> ;)
<james_w> I've just imported one dsc and there are no uncommitted changes.
<duckx> Hmm, damn
<duckx> What did I do yesterday
<duckx> Works fine for me :(
<duckx> Ok lets try the merge upstream thing
<james_w> ah, merge upstream doesn't commit I think.
<duckx> Yeah, indead, that is the normal workflow
<duckx> But I had a wired thing after doing the following workflow:
<duckx> import-dsc
<duckx> Then  merge-upstream
<duckx> bzr status gives me the following
<duckx> http://www.pastey.net/73292
<james_w> that looks right for the aim of the command.
<james_w> are you confused that it added all of debian/ again?
<duckx> Yes ;
<james_w> ok, so I had the same opinion as you at first, but other convinced me to do it this way.
<duckx> Well, what I don't get
<duckx> Is that I imported gnucash-2.2.1 over a 2.0.5
<duckx> I should see a bunch of file modified
<duckx> nont only 2
<james_w> let me draw it for you.
<duckx> Yeah thx
<james_w> actually drawing it isn't very useful.
<james_w> what it does is really play with two branches in one, but you never see the second. Let's make the second explicit and then it might be clear.
<duckx> My current issue is to get where the debian patch is located ... ,
<james_w> you have an upstream branch and a debian branch.
<duckx> k
<james_w> the upstream branch clearly just has upstream imports on it 0.1...0.2 etc.
<duckx> Yeah That is what I see with bzr log
<duckx> ------------------------------------------------------------
<duckx> revno: 2
<duckx> tags: upstream-2.2.1
<duckx> committer: Frederic Brin <frederic.brin@assonetworx.com>
<duckx> branch nick: gnucash
<duckx> timestamp: Sun 2007-09-02 13:00:17 +0200
<duckx> message:
<duckx>   import upstream from gnucash_2.2.1.orig.tar.gz
<duckx> ------------------------------------------------------------
<duckx> revno: 1
<duckx> tags: upstream-2.0.5
<duckx> committer: Frederic Brin <frederic.brin@assonetworx.com>
<duckx> branch nick: gnucash
<duckx> timestamp: Sun 2007-09-02 12:57:51 +0200
<duckx> message:
<duckx>   import upstream from gnucash_2.0.5.orig.tar.gz
<james_w> so your diff between the 2.0.5 and 2.2.1 lies on this branch.
<james_w> yeah, so you can see the upstream changes with bzr diff -r1..2
<duckx> I get this
<james_w> now your debian changes are based on the upstream code, so that is a separate branch that was "created" with a bzr branch -r 1 upstream debian/
<james_w> and when you import a new upstream you need to merge the changes together.
<james_w> the question is which way you perform this merge.
<james_w> the way you are expecting I guess is that you do 'cd debian/; bzr merge ../upstream/'
<james_w> and then you would see a pending merge of 'upstream 2.2.1', with all of upstream's changes, and whatever changes are made to the packaging.
<james_w> however the plugin does it the other way, so you are currently sat on the 'upstream' branch with the 'debian' changes merged in.
* duckx is trying to understand the workflow ...
<james_w> there is no real difference, you can see upstream changes by following one 'branch' and 'debian' changes by following the others.
<james_w> you can also get the differences by diffing them.
<james_w> if you fire up bzr viz (if you have it), you will see that all of the parent references are 'correct'.
<duckx> Ok, let me investigate
<james_w> the difficulty comes with bzr's distinction that the left parent is special, in this case that is the upstream branch.
<james_w> so bzr log etc. emphasise that, showing the mainline as upstream's code, with all of your debian/ changes merged in to the last commit.
<james_w> but as I say, topographically all is correct, and you have the desired parent links.
<james_w> The left parent distinction is exactly why I was going with 'merge upstream in to debian' at first.
<james_w> However siretart convinced me otherwise.
<james_w> one moment...
<duckx> k
* duckx is going to install viz
<james_w> it's useful to have, as it makes the topography clearer than log.
<james_w> and gannotate is far more useful than plain annotate.
<james_w> let me know when you're up to speed and I'll explain the rationale.
<duckx> Well, I got viz installed
<duckx> I see the same stuff that what I see in the log
<duckx> Ok let's draw a simple example
<james_w> if you click on the commits on the debian branch you should see two parents for each new debian version.
<james_w> they aren't drawn on the graph, but they are shown in the info area.
<duckx> Well, I don't get where the debian revision is ...
<duckx> I muss have miss one stuff
<james_w> have you committed?
<duckx> Nop
<james_w> I don't think viz shows pending merge revisions.
<duckx> Ah
<james_w> you can always uncommit after if you like.
<duckx> But it should have been commited for the first dsc-import ?
<fullermd> Pending merges are figments of the working tree's imagination   ;)
<james_w> yeah, it was, but the merge makes it a pending merge again.
<james_w> you are on the 'upstream' branch, which knows nothing about the debian revisions.
<duckx> Ah
<duckx> That is
<duckx> The reason
<duckx> Ok let me do a commit
<duckx> Ok commited
<duckx> bzr viz is a lot clearer right now
<james_w> yep
<duckx> james_w: well I need to read about dir-state tree first
<duckx> I think it will make the things clearer for me
<duckx> james_w: anyhow, thx for your time, and explaination
<james_w> duckx: no problem. Give us a shout if you want anything else explaining.
<james_w> and thanks for your fixes.
<dennda> hey there
<dennda> http://pastebin.ca/678878 <-- Nice little bug I get. (Pull didn't work, so i was told to merge. That didn't work either, so i tried to push. That's the result.)
<fullermd> Well, the immediate error is that push is a writing op, and you can't write over http.
<fullermd> But push isn't going to solve a problem you're having with pull/merge.
<dennda> The last line indicated it was a bug
<dennda> That's why I ask
<fullermd> Well, in the sense that we should say "Hey, you can't do that" instead of spitting out 30 lines of traceback, it is...
<dennda> You want the whole thing, i guess?
<fullermd> Well, that part isn't really a bug or anything broken; it's expected behavior, for what you tried.
<dennda> What should I try instead?
<fullermd> Well, that would require going into the actual problem you're trying to solve   :)
<fullermd> It's easy enough to adjust that push so it [probably]  works, but if you're starting out trying to pull/merge something, pushing probably isn't what you want to do anyway.
<dennda> Ah that just was the wrong adress to push to
<fullermd> Yah.  To push you'd use a sftp://-ish (or bzr+ssh://-ish) URL.
<fullermd> But what's the problem you have with merge?
<dennda> Yes, i tried that now. It gave me "No new revisions to push.".
<dennda> The actual problem is, that pull doesn't work as I would expect it: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<dennda> So I try merge: bzr: ERROR: Working tree has uncommitted changes.
<fullermd> Ok, let's look at 'em one at a time.  First, the pull.  Do you expect the branches to have not diverged?
<fullermd> (usually, that would mean that you've made commits to your branch that aren't in the upstream)
<dennda> After I changed the file of my branch the last time, I immediately pushed it. (And that worked)
<fullermd> You can try using 'bzr missing' to figure out what revs differ between the branches; that should point you in the right direction.
<dennda> http://pastebin.ca/678893
<fullermd> As for the merge issue, it's just what it says; merge by default will refuse to run if you've got uncommitted changes lying around.
<fullermd> OK, so you made your branch at revno 13.  Since that time, you've made two commits in your local branch (your 14 and 15), and Jason has made two in the upstream branch (his 14 and 15).
<dennda> I would expect pull to grab the below mentioned two missing revisions.
<fullermd> Pull would do that if you were still at rev 13.  But you have local changes.
<fullermd> Pull only moves you "forward", in a sense.  And since his branch isn't "forward" of your branch (it doesn't include your current head rev), it can't do anything.
<fullermd> So, what you need is 'merge', to merge in his revs and create a new revision with joins his changes with your local changes.
<dennda> What would be the command to do that?
<fullermd> That's failing for you for the reason above; you've got other changes your haven't committed yet.  So, either commit them (if you want 'em), or revert them (if you don't), then merge should do its work.
<fullermd> (You _can_ force merge to work over uncommitted changes, but it's almost always a bad idea, because it muddles up your history.)
<dennda> Is it possible to ask bzr what exact changes those are? I can't remember havn't changed anything that I didn't push.
<fullermd> Mmm.  Two different questions.
<fullermd> But this isn't stuff you haven't pushed; it's stuff you've changed but not _committed_.  So, 'bzr stat' or 'bzr diff' will tell you what's sitting around.
<dennda> I just want to know what bzr wants me to commit.
<dennda> Ok I will try that, just a sec
<dennda> ah wll
<dennda> of course
<dennda> My programm changes the contents of the files in a directory that comes from Jasons trunk
<dennda> And to test if my programm worked I ran it. So it changed these files.
<dennda> I don't want to keep them. I just want to take the unaltered files from Jasons trunk. How do I do that?
<fullermd> 'bzr revert' will get rid of uncommitted changes and bring your files back to what they were last time you committed.
<dennda> What if I also changed the files _before_ I committed last time?
<fullermd> Well, then that's something to resolve during the merge.  What we're doing now is making it so your working tree is the same as it was last time you committed, so that we can do the merge.
<dennda> ok so bzr revert. just a sec
<dennda> ok, done
<fullermd> The sitution is something like: http://pastebin.ca/678904
<fullermd> Right now, we're on line 11; There are two 14's and two 15's, yours and his.  We want to create a new 16 that's descended from both of them.
<dennda> Did you draw that right now?
<fullermd> "Draw" is probably an overstatement    ;)
<dennda> Well it's more beautiful than I would have been able to do it.
<dennda> So I do have to always do this merge after I commit a change?
<fullermd> It looks something like a juniper bush being hit by lightning...
<dennda> So I reverted, merged, tried to pull and still get: bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<fullermd> Well, it depends on the situation.  You need to merge when things have diverged.  If you and Jason were both working on a single branch, and alternated commits instead, there wouldn't be any merging.
<fullermd> Right.  There's no way "forward" from your 15 to his 15.
<fullermd> So, now do the 'merge', and let's see what it manages to make happen.
<dennda> As I said: I already merged
<dennda> If I want to do it again it says: bzr: ERROR: Working tree has uncommitted changes.
<fullermd> Right.  Merge doesn't create the new 16; it just merges those 15's in your working tree.
<dennda> So this seems to be quite the same situation as above
<fullermd> Look over the changes ('diff'), and make sure the result is what you want.  Check 'stat' too, to see which files, and maybe if there are any conflicts.
<fullermd> Think you said you wanted his version of a few files, so we may want to adjust those before you commit.
<dennda> Ok it's what I want
<fullermd> 'k.  If it's all how you want it, 'commit' it, which will create the new rev 16 that we want.
<dennda> Well at least I hope so ;)
<fullermd> Well, if it turns out not to be, claim that somebody snuck into your office and did it.  's what I always do.
<dennda> ok i did bzr commit and it opened (to my astonishment) vim, showing me modified files, added files, etc..
<dennda> Sounds like a great strategy for all deeds I want to do
<fullermd> "There's no way I could have made that commit!  I was busy robbing a bank at that time!"
<dennda> Ok, so what do I do with vim?
* fullermd blinks.
<dennda> it created bzr_log.HOrCoV
<fullermd> Put in the log message and all, just like you do on any other commit.
<dennda> and opened it in vim
<dennda> I don't understand this
<fullermd> It's just like any other commit you've made.  It just happens to contain a merge, but that doesn't affect anything else about the process.
<dennda> doesn't commit need a file specified that shall be committed?
<fullermd> Only if you want to commit only a particular file; normally it just checks through the tree for any modified files.
<fullermd> (and partial commits aren't supported on merges anyway)
<dennda> so it is "bzr commit 'comment'"
<duckx> james_w: Well, I need your advice for this
<dennda> isn't it?
<fullermd> Well, "bzr commit -m 'comment'", if you want to specify the log message on the command line.
<duckx> What about chmod 755 debian/rules while import-dsc ?
<fullermd> Without the -m, it spawns off $EDITOR for the log message.  I hardly ever use -m myself.
<james_w> duckx: perhaps that should be added, I'm not sure.
<duckx> Well, currently When doing this
<duckx> bzr import-dsc
<duckx> Then bzr builddeb
<duckx> It fails to build because debian/rules not 755
<dennda> fullermd: Ok. So I do push now?
<duckx> Well, james_w patch is ready , just wait for your agreement to commit ;)
<fullermd> dennda: If you want to push up those combined changes now, yah.
<james_w> yeah, it seems reasonable to me. Can you add a debian/changelog entry please.
<james_w> and one for your last fix as well if you wouldn't mind.
<duckx> Yes shure
<duckx> sure,
<james_w> thanks duckx
<james_w> is there a test for it?
<dennda> fullermd: /me feels uncomfortable.
<fullermd> How so?
<dennda> I pushed now. Pull now tells me: No revisions to pull.
<duckx> james_w: you mean unit test ?
<james_w> duckx: yeah.
<duckx> Nop
<duckx> Don't think so
<dennda> But I do need to pull in order to get Jasons changes, don't I?
<duckx> Ups my mistake :)
<fullermd> Not at this point, no.  Look back at http://pastebin.ca/678904
<fullermd> His branch is now at his [right-side]  15.  Yours is at the 16.  So, you have all the changes from his branch already (though he doesn't have yours)
<fullermd> So there's nothing for pull to do.
<dennda> ok let me see if you tell the truth ;)
<duckx> james_w: by the way, what is the next version number 0.90.1 ?
<dennda> wow!
<dennda> Seems like.
<fullermd> Now, your two branches look a little different, of course.  His is just a straight line, from 1 to 15, like the right side up through line 11.  Yours now has that splitting apart for two revs on each side then the coming back together at 16.
<james_w> duckx: it will probably be 0.91
<duckx> james_w: ok
* dato_ wonders why the chmod is done stat.* instead of just 755
<dennda> fullermd: yes i see. and this will always happen if I change anything from my branch?
<fullermd> Well, it depends on the particulars of a situation.  If we imagine you made your rev 14, but he hadn't done anything, he could pull from you, and you'd both have the same straight 1->14.
<dennda> ah
<fullermd> When you need a merge is when you've _both_ made different 14's, because now the history has split, and merge is needed to bring it back together.
<dennda> I hope I can figure this out on my own next time. (Still seems like "Black wiZzaRdry" to me ;))
<dennda> But I think I understood
<dennda> (roughly)
<dennda> Thank you, fullermd!
<BrianB04> Good morning everyone.
<fullermd> No problem   :)
<james_w> duckx: it would also be good to ensure that debian/rules exists.
<duckx> k
<james_w> hi BrianB04
<duckx> Doing it right now
<james_w> thanks.
<BrianB04> I have a silly question, and despite finding some answers, I'm still a bit lost. I want to put my repo on my website. Now, I know you can copy the files to the webserver, but the problem is I have ignores in there, so it will take the ignored files up. Any other way to put it up on the server?
<duckx> james_w: isn't debian/rules a mandatory ?
<james_w> BrianB04: bzr push
<james_w> duckx: yes, I guess you don't have to add the check, but you never know.
<BrianB04> Now, with push, you have to commit the first time before you push, correct?
<james_w> BrianB04: yes that is correct.
<duckx> ok james_w
<BrianB04> Then, once I push, do I have to pull it from the server, or is it smart enough to know where it was pushed?
<james_w> BrianB04: it will know.
<james_w> if it doesn't then you can bzr pull --remember sftp://... or whatever and it will remember from then on.
<BrianB04> Very cool. Yea, I think I could get into Bazaar. I work a lot with Rails...and I typically work in what are called User Stories, so each chunk is broken up. With subversion, you have to hold back commiting because you don't want to commit untested code, and blah blah blah...pain.
<james_w> :)
<BrianB04> Plus, with Bazaar running so nicely on Windows.
<james_w> thanks duckx
<BrianB04> Now, to get my launchpad account.
<BrianB04> You know, it's sad. NearlyFreeSpeech.net is such a superb hosting company, and they charge you for what you use, while Dreamhost, which is a touch expensive and oversells like nuts, just...is awful.
<ashish987654321> :)
<matkor> Can I force merge with preserving uncommited changes ?
<james_w> bzr merge --force?
<matkor> james_w: Thanks !
<matkor> jelmer: Could you please merge one more fix for olive-gtk from http://bazaar.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? TIA
<jelmer> matkor: Done, thanks!
<matkor> jelmer: Thanks! Are you planning release 0.91 soon  ? This one with context menu was serious bug ...
<aantn> hello
<aantn> how can I check the version of a revision I just downloaded?
<matkor> aantn: You mean revision number ? bzr log -r -1  ?
<aantn> matkor: I need to find out what the number of the lastest revision is
<aantn> and bzr log gives too many results
<aantn> if I just run "bzr log"
<james_w> bzr revno?
<BrianB04> Hello all, again:)
<dato> aantn: `bzr log -r -1` as matkor said, or just `bzr revno`, which wgives you the number and nothing else
<aantn> hello
<aantn> kk
<aantn> thanks
<BrianB04> Okay, another quick question: I pushed up the branch, so it's up on the site, now when I work on the copy on my system, and commit, it commits only to that branch, then I have to push again, and it will merge the changes?
<dato> well, in bzr parlance there will be no changes to "merge", just changes to "push". but yes.
<BrianB04> I'm an old school CVS/SVN user, so this DRCS is a bit of a mind switch.
<james_w> BrianB04: yeah, your local changes are a superset of the remote ones, so you can push no problem, and it will be exactly the same as your local branch.
<BrianB04> Only difference is commiting to my branch will never leave the main repo unstable.
<james_w> if however you logged in to your server and also made a commit there before pushing the branches have 'diverged', i.e. one is not a superset of the other.
<james_w> in those cases you need to merge.
<james_w> if you only ever work on one before sychronising then push and pull will be all you need.
<BrianB04> Well for the moment it's just me working on it, and since it's all based around sftp, I know I'm the only one that will ever push to it.
<james_w> you can also move to a more svn like workflow by running 'bzr bind sftp://remote/'
<james_w> which will mean that all your local commits are pushed up to the server as you do them, but that may not be what you want if you are developing experimentally.
<cnus8n> hi
<james_w> hi cnus8n
<cnus8n> I am looking for setting up bazaar and webdav
<cnus8n> is there any good tutorial for it?
<cnus8n> i have installed the webdav plugin
<james_w> I haven't seen one I'm afraid. Does google have anything useful?
<cnus8n> I want some help in configuring apache
<cnus8n> googling didnt help much
<BrianB04> No, I'm thinking I'm going to do what some suggest, having the main repo, branch off that, add features, then merge.
<james_w> BrianB04: that's the best workflow in my opinion.
<cnus8n> i want to have a central shared repository - but must be able to push changes from outside
<BrianB04> james_w: Yea, that sounds like the best idea. Granted, some stuff like licensing and versioning isn't going to be pulled out because that would be...kind of pointless to branch to put in a text file, but otherwise branch.
<cnus8n> guys, I tried to setup webdav with bzr and I can do a checkout
<cnus8n> but whenever i try to commit, i get an error
<cnus8n> bzr: ERROR: File exists: 'https://foo.com/bzr/.bzr/repository/lock/ou6zj1ct2u.tmp'
<cnus8n> can someone help
<james_w> I've never used the plugin I'm afraid, and I'm not sure how up to date it is.
<cnus8n> ok
<james_w> ah, vila is the author, but he's not around at the moment.
<james_w> it should be reasonably up to date though.
<james_w> cnus8n: can you put the traceback you get in to a pastebin please?
<cnus8n> I get no traceback - this is the only error message i get
<cnus8n> i just changed to foo.com
<cnus8n> after i checkout, i make a change and then try bzr commit
<james_w> run what you were doing with bzr -Derror and you will get a traceback.
<cnus8n> ok
<james_w> also the end of ~/.bzr.log will be useful.
<cnus8n> http://pastebin.com/m1b527125
<james_w> ok, you are getting a 405 from your browser when you access that url.
<james_w> from your server sorry.
<james_w> can you open it in your browser please?
<cnus8n> you mean https://beta.bioask.com/bzr/  ??
<cnus8n> yeah i can open it
<james_w> no the one that is in the error message.
<james_w> 405 is "Method not Allowed"
<james_w> so I guess your dav configuration isn't correct yet.
<james_w> ah, in fact it is doing a MOVE request to the URL in the error, so the browser wont help here.
<james_w> sorry a MKCOL request.
<BrianB04> So, are there any good web frontends to bazaar branches?
<james_w> loggerhead and bazaar-webserve
<james_w> some people prefer the former, but it requires turbogears. The latter is plain python, and can serve an individual branch without apache etc.
<BrianB04> Can bazaar-webserve serve multiple branches?
<james_w> yes, using mod_python or cgi I think.
<james_w> cgi is easy.
<BrianB04> Or, I could just use Launchpad...which I'm not sure how often they update.
<james_w> they pull once an hour when mirroring I belive.
<BrianB04> Can't you use Launchpad to host bazaar branches?
<mwhudson> if your branch is hosted on launchpad, the codebrowse view is live
<BrianB04> Where can I find info on hosting it at Launchpad?
<mwhudson> https://help.launchpad.net/CreatingAHostedBranch
<BrianB04> Now, if I can figure out how to unregister a branch that hasn't mirrored yet...
<grimboy> Hey, I'm having some trouble installing the trac bzr plugin (from https://code.launchpad.net/~jelmer/trac-bzr/aaron ). The exact error is "TracError: Unsupported version control system "bzr". Check that the Python bindings for "bzr" are correctly installed.". I have tracbzr.* = enabled under [components]  in trac.ini. I can import tracbzr and bzrlib in from the python prompt. My path and pythonpath are set up to be identical in the shell and the fcgi script.
<hsn_> grimboy: what version of bzr you have?
<grimboy> 0.90
<hsn_> it worked for me with 0.18
<BrianB04> This is odd, I go to push to /trunk, it says it exists, I use --use-existing-dir and it tells me it doesn't exist.
<grimboy> Ah, hmm.
<mwhudson> BrianB04: strange
<mwhudson> BrianB04: though, hm
<mwhudson> BrianB04: it's probably trying to push to a mirrored branch that's confusing it
<mwhudson> BrianB04: if it hasn't mirrored yet, you should be able to delete it
<BrianB04> Okay, so I finally got one to take, and now it's saying it's not a branch.
<BrianB04> I did the bzr init, added, committed then I bzr pushed, now it's saying it's not a branch.
<BrianB04> It didn't load the files odd.
<BrianB04> All it has is a .bzr directory
<james_w> a bz push sftp:// will only put a .bzr on the server.
<BrianB04> So that's okay?
<james_w> if you do bzr log sftp://... does it show you the whole log?
<BrianB04> Yes
<james_w> then that's ok
<BrianB04> But, when I pull using this address: http://bazaar.launchpad.net/~bbommarito/rbnews/trunk it tells me it's not a trunk, and launchpad is saying it can't import it because it's not a branch.
<BrianB04> Or rather it says: Launchpad could not mirror this branch 30 minutes ago. The error was: Not a branch: sftp://bazaar.launchpad.net/~bbommarito/rbnews/trunk
<james_w> there's a strange error from the http:// url currently.
<BrianB04> Hrmmm, the branch/branch-name is empty.
<BrianB04> Oh, so there is an issue with the http connections right now on launchpad?
<james_w> it looks that way, try opening the http:// url you pasted in your browser.
<james_w> there is a #launchpad if you want to try and sort this out, they will have a better idea than me.
<james_w> I think it's on freenode though.
<lifeless> moin
<BrianB04> Yet, the one I have on my webhost works just fine.
<lifeless> james_w: this channel is on freenode :)
<james_w> lifeless: oh yeah :)
<james_w> morning.
<BrianB04> Yea, I was just gonna say.
<lifeless> so there is no branch ~bbommarito/rbnews/trunk
<lifeless> on the supermirror
<lifeless> BrianB04: ~bbommarito/rbnews/trunk exists, but has not been pushed completely
<lifeless> BrianB04: you, or the owner, needs to push with bzr to the bzr+ssh, or sftp url.
<lifeless> then it will show up on http
<BrianB04> Oh, is that what's happening? I wonder what stopped it from pushing properly. Can that branch be trashed, or can I just go right over it?
<lifeless> just push again
<lifeless> note the error:
<lifeless> https://code.launchpad.net/~bbommarito/rbnews/trunk
<lifeless> 51 minutes ago
<lifeless> ifi this is when you pushed first, there is a race condition that you may have encountered
<lifeless> and if thats the case i don't think we have the 'try now' trigger in place - but it will sort it self out automatically
<BrianB04> Okay, pushing right now.
<yml> Hello
<lifeless> hi
<yml> I am trying to publish some change from a remote host to launchpad.net with bzr. The problem is that on that host I do not have access to /home/me so I had to put my ssh key directly on www/.ssh. Unfortunatly when I try to push I get the following error message:here it is the message : http://dpaste.com/18451/ bzr is looking at the wrong place to find the key do you know if there is a way to explicitely specify the path?
<lifeless> bzr itself doesn't look for the key
<lifeless> openssh does
<yml> could you be a bit more accurate, I am not sure to understand the problem?
<lifeless> bzr uses 'ssh' to connect to launchpad
<yml> ok I understand this
<lifeless> the ssh key is accessed by ssh
<lifeless> its not something bzr has any control over
<BrianB04> Yea...I pushed it again, still not wanting to actually pull.
<BrianB04> Still giving me the error, but bzr said branch created...so...
<lifeless> ok thats an improvement
<yml> lifeless: so I guess I need to find quick how to on ssh. do you have any suggestion?
<lifeless> google?
<lifeless> one thing you could try
<lifeless> is to set HOME to a path you do control
<yml> ok :-)
<lifeless> HOME=somepath bzr ...
<lifeless> BrianB04: ok if it said branch created, I think you should push one more time
<yml> ok I am going to try this
<lifeless> BrianB04: which will trigger a retry.
<BrianB04> Oddly enough, pulling via sftp is working.
<lifeless> thats normal
<lifeless> if you have write access to the branch you go to master copy
<BrianB04> Okay, it looks like it's going to wait an hour to grab it, so we will see if it can mirror it in an hour...because pushing again simply says 'nothing to do'
<BrianB04> Or No new revisions to push
<lifeless> BrianB04: little big huh ?
<lifeless> BrianB04: its probably cloning the public copy now
<BrianB04> Big?
<lifeless> sorrry, I mis-parsed your statement
<BrianB04> Yea, it's showing it couldn't clone it like 15 minutes ago.
<BrianB04> I'm guessing the http doesn't work until it's cloned.
<lifeless> thats right
<matkor> Hmmm What is meaning of word 'triaged' in status triaged ? TIA
<james_w> matkor: it means it's been looked at but not diagnosed yet.
<abentley> Strictly, it means a severity has been picked, but it doesn't mean that the bug has been verified or examined otherwise.
<lifeless> james_w: it does not imply lack of diagnosis
<lifeless> morning abentley
<yml> lifeless : after some investigation I have found out that the $HOME is pointing to the right place
<abentley> lifeless: morning.
<lifeless> yml: I was suggesting changing it to somewhere you can write to so you can use the ssh key
<yml> I mean my key is directly located in this directory .ssh/id_rsa
<yml> my key is already there the pb is that bzr /openssh are not looking in that directory but in /home/yml
<lifeless> oh
<lifeless> well it was a thought
<lifeless> you could try using agent mode
<lifeless> start ssh-agent on your machine
<lifeless> then ssh -A themachineyouarepushingfrom
<lifeless> (you need to do ssh-add on your machine too)
<james_w> lifeless: wouldn't you use confirmed if you had diagnosed it?
<BrianB04> Yep, there was a race condition on the push, and it will be remirrored in about 5 hours.
<yml> lifeless : ok I am going to find a how to ssh  :)
<BrianB04> There is a fix in the works, but it won't be out until 1.1.9
<lifeless> james_w: you can't triage until you can decide impact within the community
<lifeless> its unfortunate that the lp devs put it in a spectrum
<james_w> I thought that the definition of triage (in a wider sense) was a quick best estimate before you had all the facts that you wanted to make the full decision.
<lifeless> triage is about allocation of resources based on likely benefit
<lifeless> dictionary.reference.com/browse/triage
<lifeless> but in bug systems its a little misused
* dato blinks.
<lifeless> triage in bug systems is focused around the importance to the project, not the probability of fixing the bug easily
#bzr 2008-08-25
<SmileyChris> how do I set up the default maintainer email so that "bzr send" doesn't need an email address?
<lifeless> SmileyChris: according to the help, submit_to is the configuration key to set
<SmileyChris> lifeless: yep, i got that far... how do you set configuration keys
<SmileyChris> the help wasn't very clear on that
<lifeless> the user guide has documentation about that
<lifeless> basically just edit a config file depending on where you want the setting to apply
<lifeless> globally/url/branch are the three choices
<SmileyChris> lifeless: thanks for the explanation. So I can attach this setting to the branch itself or is it a client-side only configuration?
<jelmer> Hmm, that reminds me
<jelmer> I wonder if it makes sense to have a UI command for modifying the branch configuration?
<jelmer> including some way to list the available settings
<SmileyChris> hrm... i see there's a .bzr/branch/branch.conf - i wonder if that's where it should go
<SmileyChris> the guide isn't very clear on this
<jelmer> SmileyChris, yep, that's where it should be
<SmileyChris> jelmer: cheers
<SmileyChris> jelmer: does it need to be in a [DEFAULT] block?
<jelmer> SmileyChris, yep
<SmileyChris> good to know
<SmileyChris> actually, i see in my local branch.conf there isn't a default block
<SmileyChris> probably doesn't need it, it's a branch specific conf anyway
<SmileyChris> :(   bzr: ERROR: No mail-to address specified.
<SmileyChris> seems it can't be server-side, unless i'm doing something wrong
<SmileyChris> which is more than likely :P
<jelmer> SmileyChris, it can be server side
<jelmer> set child_submit_to on the server side
<SmileyChris> ah
<lifeless> only affects new branches though I believe
<mwhudson> how do i create a branch of a particular format in a test?
<mwhudson> make_branch only takes a format for the bzrdir, unless i'm misreading things
<mwhudson> i guess make a bzrdir and initialize a branch of the desired format on it?
<lifeless> mwhudson: format=knits etc
<lifeless> mwhudson: tests/test_repository.py shows nearly every variation
<lifeless> some fugly, some not
<mwhudson> thanks
 * mwhudson reads
<mwhudson> bzrdir.format_registry.get('knit')() seems reasonably clear for this purpose
<lifeless> self.make_branch('foo', formamt='knit') is the most pithy
<mwhudson> ok
<markh> The bzr user's guide says "Checkouts are source trees that are connected to a branch" - is that strictly accurate?  Isn't a checkout a "bound branch"?
<markh> (it doesn't qualify with 'lightweight')
<lifeless> markh: its strictly accurate
<lifeless> bound branches are still connected to a branch
<markh> "source tree" implied "working tree" to me
<markh> what is a "source tree"?
<lifeless> I'd guess a tree you edit your code in ?:)
<lifeless> note that a bound branch with no tree object is not a checkout of any shape or form
<markh> hrmph - the docs for "bound branches" define it as being exactly a "checkout"
<markh> (I'm trying to get my head around a few of the subtleties I've been happily glossing over)
<markh> so I'm not trying to be painfully pedentic.  Given that http://bazaar-vcs.org/BzrUsingBoundBranches defines "bound branch==checkout", I'd expect the user's guide to be stated as "Checkouts are branches that are connected (or "bound") to another branch"
<bob2> bound branch + working tree = checkout
<markh> right.  So the users guide is slightly misleading ("source tree" is vague) and BzrUsingBoundBranches is also slightly misleading (makes no reference to working trees) ;)
<markh> is there a ane usecase for a bound branch without a working tree?
<markh> sane
<lifeless> markh: yes
<lifeless> markh: one in particular is quite fun:
<lifeless> master
<markh> how about s/sane/common/?
<lifeless> mirror bound master (no tree)
<lifeless> lightweight checkout of mirror
<lifeless> I think that one is quite common for shared trunks
<lifeless> on C style projects where you want only one tree and to reuse build products
<markh> right - so I'm thinking of "bound" as being mainly useful for checkins.  Why would 'mirror' use a bound branch, rather than just pulling from masteR?
<lifeless> markh: so that you can checkin to trunk when you want to, but still access what trunk looks like offline
<markh> right - "mirror" is writable.
<teratorn> does anyone use graphical diff/merge tools w/ bzr? if so, which ones?
<AfC> teratorn: Not very often, but `meld` comes in handy once in a while.
<teratorn> was just looking at meld.. gotta try it out
<teratorn> ideally I would like a tool that can also let me do cherry-picking and then shelve or commit those selections
<bob2> emacs!
<teratorn> huh what that's crazy talk
<markh> I see 'info' agrees that a bound-branch must have a tree to be reported as a 'checkout'.  On a similar vein, when would be come across a 'branchless tree'?
<lifeless> a branchless tree does not exist
<lifeless> to open a branch you must have a reository object
<lifeless> to open a tree you must have a branch object
<markh> right - "info" explicitly handles that case, but it should never hit it in real life?
<markh> or only upon misused of that api I guess...
<lifeless> the API won't let you construct this
<lifeless> checkout --lightweight generates a branch references
<markh> I mean misuse of 'info.describe_layout(), which takes the repo, branch and tree as 3 sep args. but thanks for confirming that isn't another state I need to worry about :)
<Verterok> markh: ping
<markh> Verterok: hi
<Verterok> markh: hi
<Verterok> markh: are you building the standalone bzr.exe?
<markh> yep
<Verterok> markh: I'm wondering if it's possible to include SimpleXXMLRPCServer in it
<markh> Verterok: I'm sure it would be for 1.7 I guess.
<Verterok> markh: some bzr.exe users, also use bzr-eclipse and xmloutput plugin (that need SimpleXMLRPCServer)
<Verterok> great!
 * Verterok dances
<Verterok> markh: if I can help, just drop me a line. I'll be glad to ;)
<markh> how will I know if it works? :)  I can add that line to the 'includes' option to py2exe, but I'm not sure what to do after that...
<markh> I know - once 1.6 is out, just ping me and I'll hack up a binary and you can test it ;)
<Verterok> markh: bzr branch lp:bzr-xmloutput and bzr start-xmlrpc :-D
<markh> heh - ok
<Verterok> markh: if that is the only py2exe trick, I can try to build a binary and run some tests
<markh> its likely to also need 'xmlrpxlib' nominated in 'packages'
<markh> rpclib
<markh> it would help if you could do that - then just submit a merge request and I won't need to do anything at all ;)
<markh> but if you don't and I remember, I'll have a go when 1.7 is getting closer
<Verterok> markh: I can try :). do I need a custom enviroment to build bzr.exe?
<Verterok> markh: easier, any wiki/doc telling how to build it? :)
<markh> theoretically not :)  It might complain about a few things missing, but should succeed
<markh> 'make installer' if you are *really* lucky ;)
<markh> obviously need py2exe installed, but most other things are optional
 * Verterok fires up virtualbox and waits
<markh> xmlrpclib appears to be a simple module and is already in the package.
<markh> as is SocketServer - so if you are extremely lucky, you could just stick SimpleXMLRPCServer.pyo in library.zip and it would work ;)
<Verterok> nice :)
<Verterok> I'll give py2exe a try, if I'm lucky enough...I'll send the patch
<Verterok> markh: thanks for the guidance :)
<markh> np
<Spaz> hello
<Spaz> does bzr support checkouts of only portions of a source tree? or do you have to get the whole thing?
<Spaz> i haven't been able to get a straight answer :/
<bob2> no
<bob2> where source tree = branch
<Spaz> we host multipule projects in our suppository, it would be possible to create branches for each of the projects, right?
<Spaz> *repository
<Spaz> i genuinely typo'd that >_>
<bob2> yes
<Spaz> ah i see.
<Spaz> bob2, and you can check out each branch independently if my understand is correct, right?
<bob2> yup
<Spaz> horray
<Spaz> thanks
<Verterok> markh: bzr.exe with xmloutput, worked like a charm :D
<markh> Verterok: excellent ;)
 * Verterok sends the patch
<lifeless> Verterok: cool
<Verterok> indeed :-D
 * Verterok heads to bed
<Verterok> seeya later
<lifeless> abada abada abada, thats all folks
<vila> finally, hi all
<Leonidas> How to get the changes from the initial revision?
<Leonidas> (using the bzrlib api)
<lifeless> Leonidas: current tree vs revision 1?
<Leonidas> lifeless: but that does not show me what was added in revision 1. I need to use something like:
<Leonidas> bzr diff -r ..1
<Leonidas> so I need the first revtree and the revision 1 revtree
<lifeless> repository.revision_tree(NULL_REVISION)
<Leonidas> ahh! Where is NULL_REVISION defined?
<Leonidas> bzrlib.revision.NULL_REVISION, ok
<jpds> Hello all, can someone please tell me what's happening here? http://paste.ubuntu.com/40393/
<Kamping_Kaiser> bad stuff :P
<Kamping_Kaiser> (hi mate)
<jpds> Kamping_Kaiser: hi.
<RAOF> jpds: You can't upgrade over bzr+ssh
<jpds> RAOF: So what do I do?
<RAOF> jpds: You can over sftp, but that takes quite some time; there's an open bug on the bzr-launchpad integration for a "upgrade this branch" button.
<RAOF> Be warned: remote upgrades over sftp aren't exactly lightning fast.  Bring a packed lunch :(
<Stavros> hello
<Stavros> whenever i do bzr upgrade i get this error and a corrupted repo: bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
<luks> you want to upgrade to --rick-root-pack (probably)
<luks> and corrupted repo in what way?
<Stavros> luks: i move .bzr.backup back to .bzr and it doesn't recognise it as a repo
<Stavros> so my only option then is to delete the whole thing
<luks> "doesn't recognise" isn't very specific
<Stavros> bzr: ERROR: Not a branch
<luks> it upgrade corrupts anything it's a serious bug
<Stavros> let me do it again
<luks> what's inside the .bzr directory?
<luks> *if
<Stavros> let me reupgrade to tell you for sure
<Stavros> oh it works now
<Stavros> that's odd
<Stavros> well, not the upgrade, but the backup
<Stavros> is rich root pack better than the one i have currently?
<Stavros> i don't understand why it fails, though
<Stavros> it succeeded upgrading to that, if i push will the other repo also get upgraded?
<bob2> it isn't better
<Stavros> why upgrade to that then?
<bob2> but if you need to support branches from bzr-svn, you need to use it
<Stavros> oh
<Stavros> is it worse?
<bob2> no
<Stavros> ah, okay then
<bob2> it just supports a feature needed by bzr-svn
<Stavros> ah
<bob2> eventually the default format will support something like that too and everyone will stop getting confused :)
<luks> Stavros: and no, push will not upgrade it
<Stavros> luks: ah, thanks
<Spaz> hello
<Spaz> i'm made a branch trunk/foo, but when i go to do something like bzr co http://example/trunk, foo doesn't show up
<lifeless> if your branch is trunk/foo, you should checkout trunk/foo :)
<Spaz> lifeless, i want the whole thing though (trunk/foo included)
<luks> no, it doesn't work like svn
<Spaz> :(
<Spaz> is there any way i can make a branch that behaves that way?
<lifeless> Spaz: you want a branch that contains other branches?
<Spaz> lifeless, yes, but i want those branches to also be able to be checked out not just individually, but all at once
<lifeless> Spaz: bzr really isn't gear to do that
<lifeless> *geared*
<Spaz> :(
<lifeless> (none of the modern DVCS's are)
<RAOF> "bzr multi-pull" can help.
<RAOF> On the client side, at least.
<Spaz> RAOF, is this a plugin of sorts?
<luks> lifeless: well, git and hg can do that, but it's not as streamlined as in svn
<RAOF> It's in bzrtools, I believe.
<RAOF> bzr multi-pull will pull all the branches under the current directory.  At least that's how I use it :)
<luks> having a bzr extension that does something like http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html would be nice
<RAOF> Isn't that subtree support?
<Spaz> another question
<lifeless> luks: they don't do the same thing
<RAOF> I may have got that wrong, though.
<lifeless> luks: gits nested tree is similar to bzr's, hg's is very different
<Spaz> wait nvm
<lifeless> luks: and none are analagous to svn's system
<Spaz> i was going to ask if bzr had plans for arbitrary checkouts, but i'll just use nested branches for now
<luks> lifeless: git's submodules are not bound to specific revision, as far as I know
<lifeless> luks: they are refs
<luks> so it works kind of like svn:externals
<RAOF> Ah, so submodules appear to be svn externals.  Which isn't what he's after, anyway.
<Spaz> bzr multi-pull works :)
<lifeless> luks: "Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit."
<luks> uh oh
<luks> sorry then
<lifeless> its ok :)
<luks> so it's the same principle as bzr subtrees, but not as integrated
<Spaz> while it's kind of an "argh >_<" thing for me, it's not like "argh let's go back to svn" kind of thing
<lifeless> but I'm not prone to random wrong statements:>
<lifeless> actually I think git and bzr subtrees/submodules will be nearly identical
<lifeless> we've got very similar model in this regard
<luks> I'd like more something like svn externals
<lifeless> yeah, we have a second iteration planned that will be closer
<lifeless> Spaz: we have plans for arbitrary checkouts
<luks> shouldn't be hard to do as a plugin using git submodule's UI though
<Spaz> lifeless, :o
<lifeless> Spaz: 'views' is what we'll call them
<Spaz> hrm views?
<Spaz> sounds like it's read-only
<Spaz> >_>
<lifeless> no more than any other operation
<Spaz> oh nice
<lifeless> it will just select a subset of the tree to put on disk
<Spaz> :D
<lifeless> the same amount of history will be needed locally etc etc
<Spaz> ah ok
<lifeless> because to merge full trees you need access to the full tree metadata
<Spaz> any clue about what version this might happen? (i'm asking for mere speculation, i'm not asking for "when will it be done" etc.)
<lifeless> its *why* DVCS works efficiently
<lifeless> 1.8/1.9
<Spaz> ah ok
<enquest> can somebody quickly help... I installed bzr on my server. I can commit my files... But an other user when he want to commit gets  "Cannot lock LockDir" How can I solve this?
<lifeless> enquest: permissions I would say
<lifeless> enquest: does he have write permission ?
<enquest> I made a group "admin" and added him and me to that group
<enquest> what should I do more?
<lifeless> check the permissions on the contents of .bzr/
<lifeless> I bet its wrong group or some such
<enquest> lifeless, the permissions on the .bzr is drwxr-xr-x
<enquest> and enquest:admin
<enquest> so I should give write permissions to admin?
<enquest> is that correct lifeless
<lifeless> I would say so :)
<stani> hi
<stani> The bzr faq says that there are other version control systems better suited for binary files (such as images), but it gives no references. Does anyone has a good suggestion?
<luks> I don't know of anything that has a smart delta compression of compressed data
<stani> luks: thanks. Just the way the FAQ is written, it suggest that such tools exist. I use bazaar for coding, but I want something similar for my projects which consist of only images.
<luks> there are systems that handle binary data better in general
<luks> but for compressed content, such as images or video, it doesn't help much
<stani> luks: are some of these systems free? could you give some names?
<luks> svn does binary xdelta compression
<luks> but what exactly are you doing?
<stani> well, I am a visual artist, so the result of my projects consist of images
<stani> some are generated by self written code, some are manipulated in gimp, ...
<luks> what format are they in?
<stani> I mostly use png for generated images, as it is compressed without quality loss
<luks> anyway, I don't think you will see any significant differences between most VCSes
<stani> but some are also in svg
<bob2> are svg files typically gzipd?
<luks> no
<stani> I generate svg through pycairo
<luks> I'd personally just use bzr if you already know it
<luks> I wouldn't use bzr only if the files are huge
<luks> it doesn't handle that well
<bjacques> Hi. I have a local branch from a shared repository and I would like to add the branch to the main repository, while keeping it a branch. How do I do that?
<luks> not sure what do you mean by that
<luks> that is 'the main repository'?
<luks> *what
<bjacques> by main repository I mean the remote, shared repository which contains the trunk branch
<luks> just push it there
<luks> if you push it to a location under the repository, it will automatically use it
<bjacques> I see, thank you
<bjacques> So do I specify bzr push sftp://remote/reporoot/mynewbranch or do I omit "mynewbranch"?
<luks> including mynewbranch, the command is correct
<bjacques> thanks again
<cfchris6> I have a problem using bzr-gtk, namely the visualize command, on my gentoo box. I am using bazaar 1.1.0 with bzr-gtk 0.94.0 I installed it by extracting the tarball into /usr/lib/python2.5/site-packages/bzrlib/plugins/gtk Error is pasted here: http://rafb.net/p/P9TdMc24.html
<luks> you need newer bzr
<cfchris6> luks: Ok, I will try, just thought it should work with these versions cause http://bazaar-vcs.org/bzr-gtk said bzr-gtk 0.94.0 should work with >=1.0
<luks> 1.5, probably
<luks> looks like a lie :)
<luks> hm, no
<cfchris6> looks like the personal taste of gentoo developers prevented a stable program to get into stable tree, once more :/
<luks> iter_ancestry was added earlier
<cfchris6> hm...
<luks> still worth a try to upgrade
<luks> there is a bzr overlay for gentoo
<pickscrape> https://launchpad.net/bzr-gentoo-overlay/
<cfchris6> bzr 1.5 is already in the portage tree, but tagged as ~x86 not x86
<pickscrape> Easy to just add it to portage.keywords
<cfchris6> I know gentoo, and I did so, but it is not a nice solution because mixing arch with ~arch sometimes breaks things
<pickscrape> My package.keywords is as long as my arm :)
<pickscrape> I prefer to use stable generally, but push certain things along as I need them.
<luks> what does the ~ mean?
<pickscrape> arch-masked
<pickscrape> Effectively the 'unstable' branch
<luks> so, "doesn't work on x86"?
<pickscrape> More like they're not confident, not sufficiently tested, they can't be arsed etc
<pickscrape> gnome basically stays in ~ for about six months after release
<cfchris6> pickscrape: it's more a question of the maintainers taste. e.g. pidgin 2.4 was already very long in portage (~x86) but it became x86 not because it was said to be stable enough but just because 2.3 did not work anymore
<pickscrape> cfchris6: == can't be arsed :)
<Freaky> just ~x86? what about all the other platforms?
<cfchris6> Freaky: In general it was ~arch, for more exotic ones I don't know
<pickscrape> Other arches could be quicker or slower. They have dedicated arch teams, so it depends on how on the ball they are when compared to the maintainer of the package itself.
<cfchris6> anyway, with bzr-1.5 it works now, thank you
<pickscrape> The only downside of the bzr gentoo overlay is that it includes beta packages. It would be nice to have a stable version of the overlay
 * vila wonders who put water into his gusty -> hardy upgrade after midnight
<jam> vila: I put sugar in the tank, but I didn't have time to get water. Must have been someone else.
<vila> I guess so, but the last gremlin needed a .xmodmaprc to get killed. though one :-/
<pickscrape> Check the power cord to your clock.
<vila> lightbulb ! The clock damn it ! Skewed again !
<jam> vila: I'm just waiting for your next hhtp patch
<vila> :-)
<jam> hm... it seems beuno isn't around yet
<jam> time to get the 1.6-final out the door
<jam> anyone have any blockers?
<jam> Last chance
<vila> the last days were all about reorganizing my hardware and the associated softs, I just have to commit now.
<jelmer> siretart, thanks, much appreciated :-)
 * jelmer hopes this is also the first step towards loggerhead on bzr.debian.org..
<james_w> jelmer: well, we almost got webserve on there, but it missed etch, and then the project seemed to stall, so I refrained from packaging it
<jelmer> ahh
<jelmer> so it looks like we'll be out of luck again, since we're already past freeze time :-/
<james_w> yeah, though they may be willing to use a backport once it is actually in
<jelmer> james_w: ah, cool, that's definitely worth asking for
<james_w> I agree
<siretart> jelmer: I think they prefer packages from backports.org, but asking might be a good idea anyway
<jelmer> bug 5
<ubottu> Launchpad bug 5 in rosetta "Plone Placeless Translation Service metadata missing from po files" [Wishlist,Fix released] https://launchpad.net/bugs/5
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | 1.6-final is out !!! |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<luks> yay :)
<luks> no more RCs
<radix> whoah
<Peng_> Woah.
<Peng_> Wait, so there was no rc7? Damn!
<Peng_> Congrats on the release. :)
 * Peng_ has to run.
<RichW> I'm trying to merge this branch https://code.launchpad.net/~richies/hypernucleus/richie into this branch https://code.launchpad.net/~manuq/hypernucleus/manuq but the two branches have different revision histories (I creaed mine wrong!). How do I merge them?
<RichW> It gives me this error: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<jelmer> RichW, the two branches you're trying to merge are not related
<jelmer> RichW, are you really sure you'd like to merge them?
<jelmer> RichW, if so, just specify -r0..-1 to "bzr merge"
 * mw starts his bzr 1.6 for opensuse packages
<jam> So... what is the proper debian string for the 1.6 release?
<jam> "1.6~bazaar1" sorts before "1.6~rc5..."
<jam> Should it be "1.6-1~bazaar1"
<luks> 1.6-1~bazaar1
<jam> or "1.6~1~bazaar1" ?
<jam> thanks luks
<luks> 1.6~bazaar1 would mean a native debian package
<elmo> err, surely it's just 1.6-1 ?
<luks> yes, but not for ppa packages
<elmo> oh, right, PPA
<RichW> jelmer: ok il try it, some things happened and it all went wrong :)
<luks> RichW: honestly, with such branches I think diff/patch is the best you can do
<jam> luks: ok, I tried your method to build the package, care to try it out?
<jam> It is in my ppa
<luks> one sec
<jam> https://launchpad.net/~jameinel/+archive
<luks> did you upload the packages?
 * luks doesn't see them
<jam> jelmer, james_w: If you want to give it a poke, too. I'm using bzr-debbuild for this
<jam> luks: upload just finished
<luks> ah, it will take a moment then
<jelmer> jam: I just uploaded 1.6-1 to Debian sid
<jelmer> s/sid/experimental
<jelmer> jam: What branch is the ppa build created from? I can't instal the package here, but I can look at the changes.
<jam> jelmer: it is built from the tarball
<jam> Or you mean the "debian" branch?
<jam> I just have that locally
<jelmer> jam: yeah, the debian branch
<jam> It is originally branched from luks work
<jam> because I'm just playing with it for now
<jam> I'll switch to the "official" ones later
<jam> jelmer: I'll push it real quick
<luks> well, I didn't change anything but fixing the watch files
<jam> jelmer: when it finishes: lp:~jameinel/+junk/packaging-hardy
 * jelmer wonders if the ppa branch shares any ancestry with the pkg-bazaar debian team  branch
<jam> luks: well, and you "released" ~bazaar2
<jam> etc
<jelmer> jam, thanks
<luks> oh, yes :)
<jelmer> ah, looks like it was based on the Debian packaging branch, it's just diverged since then
<jam> luks: LP has just accepted my submission and is building now
<jam> jelmer: seems like we should mostly keep them in sync
<jam> lamont: I know you had concern about our earlier packaging, would you care to take a look at my attempt at a 1.6-final package?
<lamont> jam: my build just finished. :-)
<jam> luks: Would you know why, export FOO="a b c"; for foo in $FOO; do echo $foo; done always gives them all at the same time?
<jam> luks: I'm trying to use your documentation
<jam> but it seems ZSH doesn't do "for" like bash/sh
<lamont> jam: gives me 3 lines of output....
<jelmer> jam, package looks good to me
<jam> lamont: I don't know if that is good or bad
<lamont> jam: it's correct. :-)
<lamont> and yeah, package looks fine
<jam> yay \o/
<lamont> the 3 lines was wrt $FOO above
<jelmer> jam, there's not a lot of differences with the debian debian package
<jam> lamont: using zsh or bash?
<jelmer> jam, (try diffing with http://bzr.debian.org/pkg-bazaar/bzr/unstable to see)
<jam> jelmer: I see a lot of differences in the changelog, but I guess that is because you don't actually include the upstream release information in changelog
<jam> So it only has your changes
<jam> jelmer: also, do you still have the "contrib/bash/bzr" bug?
<jam> I see this line: contrib/bash/bzr	etc/bash_completion.d/
<jam> in your unstable branch
<jelmer> no, that's been fixed (though differently from the ppa branch)
<jam> ah, ok
<jam> ah, and you don't remove ones that are already there
<jam> as part of post-install
<jelmer> We never uploaded a package with the broken file in it, so there's no need to do that for us
<jam> jelmer: should we be merging your changes for stuff like "overrides/bzr" which sets "script not executable" on a few files
<jelmer> jam: Yeah - the overrides are no longer necessary
<lamont> jam: bash
<jelmer> you may also want to import the change to the watch file, which makes sure that betas for a release are not considered newer than the release itself
<jam> so for changelog, is it meant to be only the changes for that "branch" of packaging?
<jam> jelmer: I think luks did a similar change
<jam> opts="uversionmangle=s/(rc|b)/~$1/" \
<jelmer> ah, right
<jelmer> jam: I'm not sure what the right policy is wrt merging changelogs
<radix> does anyone know if launchpad supports stacked branches now? (no response in #launchpad)
<lamont> jam: IOW, zsh isn't posix.
<lamont> see also the behavoir of dash
<jam> lamont: it seems like it, though it is a bit odd
<jam> lamont: it prints it out 3 times for me
<jam> It prints "a b c" 3 times
<jam> which is a bit silly
<jam> ah no, that was because I was using: FOO='a b c'
<jam> and bash does the same
<jam> This is just strange: bash -c "FOO='a b c'; for x in $FOO; do echo $x; done"
<lamont> in zsh I get 'a b c'
<lamont> in dash and bash, I get a\nb\nc\n
<jam> yeah, same here lamont, except for the one I just posted, where I get "a b c\na b c\na b c\n"
<lamont> scripts shouldn't use zsh :-)
<fullermd> Unless they're zsh scripts  ;)
<lamont> if you need that rich a language, you don't belong in a shell
<jelmer> radix, I think so
<jelmer> radix, It is running bzr 1.6 IIRC
<jam> lamont: Well the specific issue was that it is a "step by step of what to do to release" not a real script, and I couldn't follow it because zsh is my interactive shell. I can always workaround that
<lamont> heh
<jam> such as by turning it *into* a script :0
<lamont> FTW!
<gour> congrats to all devs for 1.6!
<gour> jelmer: bzr-svn will follow-up shortly?
<jelmer> gour, 0.4.11~rc1 is already in Debian
<jelmer> or do you mean the 0.4.11 release?
<jam> jelmer: can we get 0.4.11 into the bzr ppa/beta ppa?
<gour> jelmer: 0.4.11
<jelmer> gour, In the next couple of dayus
<gour> great. ta
<gour> it no longer requires svn-1.5?
<jelmer> no, just svn 1.4 or higher
<jelmer> no patches
<gour> that's great
<jelmer> jam: Sure, I'm happy to help with that
<jam> We'd also like to get bzr-gtk put there
<gour> finally, one will be able to completely replace fetching all svn repos with bzr-svn :-)
<jam> whatever works with 1.6
<jam>  lamont: so do you know about "merging changelog" files? I would like to sync up our various packaging branches, and don't want to do something stupid. I can just revert "changelog" when I merge in the other changes.
<gour> bzr will return to monthly-releases now?
<jam> gour: well I'm in charge of 1.7, so *it* will be a time-release, I can't say beyond that :)
<jam> I do believe everyone wants to return
<lamont> jam: increasing chunks in time is always a good merge there... shame to lose history, unless it's pointless history
<jelmer> jam: I would rather not do the uploads myself though, since I can't promise I'll be able to upload regularly
<lamont> for my packages, I tend to just not change debian/changelog, and then generate it at release time... less pain that way
<lamont> since debian/changelog _never_ merges cleanly
<gour> jam: thank you for great work. i'm (slowly) learning python..hopefully be able to help a bit in the future
<lamont> (for values of never approaching zero)
<jam> jelmer: well, if we can streamline the process, I'm fine with documenting it and having a standard "release 1.X" include packaging the important plugins.
<jam> lamont: well all of our "debian/changelog" entries are "* New upstream release"
<jelmer> jam, should we have a look at doing that now?
<gour> it's interesting experience to switch between haskell & python...
<jam> And we have one entry for each ~hardy1, ~gutsy1, etc.
<jam> jelmer: That would be nice. I'd like to get bzr-1.6 and associated plugins
<jam> Everyone complains when they go to upgrade bzr and lose all of their deps
<lamont> jam: all of the "package for $SUITE" are (IMO) boring and can be tossed - pretty much any ~ debian version (as opposed to ~upstream versions, which are interesting)
<lamont> although more so if they have more meat to them than "new upstream release"
<jam> lamont: that is what "bzr log --short" is for :) [or NEWS]
<jelmer> jam: Pushing to ~bzr/bzr-svn/ppa-hardy
<jelmer> jam: Can you see if that uploads correctly to ppa?
<lamont> jam: bzr log
<lamont> bzr: ERROR: Not a branch: "/home/lamont/chroots/a/bzr-1.6~rc5/".
<lamont> changelogs _should_ have some history in them.  source packages _shouldn't_ have VCS trees in them.
<jam> jelmer: so you want me to package that? or just check if a package shows up in ~bzr/+archive ?
<lamont> then again, I expect that the upstream changelog is in the binary package
<jelmer> jam: It should already be packaged for hardy in the ppa
<jam> jelmer: the only package I see is: https://edge.launchpad.net/ubuntu/hardy/+source/bzr-svn
<jelmer> jam: It's finished now, lp:~bzr/bzr-svn/hardy-ppa
<jam> and ~bzr-svn doesn't have a ppa
<jelmer> jam: Sorry, I meant I hadn't uploaded it yet, but all the right bits are in the bzr branch I pushed to
<jam> jelmer: so you want me to "bzr debbuild -S" it ?
<jelmer> jam, yep, please
<jam> (currently grabbing it)
<jam> should I be uploading to the ~bzr-beta-ppa or is it ready for ~bzr ?
<jelmer> To whatever you uploaded 1.6 I think
<jam> jelmer: sure I just wanted to know if it was "stable" enough for the official ppa
<jam> I haven't uploaded anything to a public ppa yet
<jelmer> jam: Probably beta for now then
<jam> and that is a regular bzr-svn branch right, not just a packaging branch
<jam> how do you manage that across multiple targets?
<jelmer> jam: It's a regular bzr-svn branch that includes the debian/ dir
<jelmer> makes it easier to do debian-specific source changes
<radix> I guess the bzr deb packages aren't built yet?
<jelmer> radix, jam is working on uploads to the ppa
<radix> sweet
<radix> thank you jam :)
<jelmer> radix, I've uploaded packages to debian experimental
<radix> can't wait to try it out with lp
<james_w> jelmer: did you file a sync request as well by any chance?
<jelmer> james_w, not yet - shouldn't I wait for it to actually hit experimental?
<james_w> jelmer: it's normally safe as they have to get a sponsor's ACK first
<jelmer> james_w, ah, cool - I'll request one then
 * jelmer hugs ubuntu-dev-tools
<jelmer> now if only somebody would package it for debian...
<Spaz> night
<jelmer> james_w: I've modified "bzr mu" to support merging from branches rather than just tarballs/directories
<jelmer> james_w, It'll now also default to using the export-upstream location if in export-upstream mode
<jelmer> james_w, and retrieve the upstream version number automatically from tags and revnos
<jelmer> james_w, It would be nice though if it could automatically add a draft entry to debian/changelog though
<ToyKeeper> Is there a recommended bzr way to include one project inside another?  (for example, project/mylib/ has its history tracked separately)
<jelmer> ToyKeeper, "bzr join" can import one project in another and makes merging in the future easier
<jelmer> ToyKeeper, there's no way to reference another project by location yet - that's what nested branches will bring
<ToyKeeper> I have a common library I'd like to include with other projects, and basically would like 'bzr branch lp:myproject' to include the shared lib if possible.
<ToyKeeper> Bringing the lib in at 'make dist' time is trivial, at least.
<jam> You could also look at the "bzr-merge-into" plugin. As long as the merge is "1-way" (you do the devel in the plugin branch, and then merge it into the project branches) it works pretty well.
<james_w> jelmer: yeah, it doesn't do that for any mode
<james_w> I stayed away from writing more code
<ToyKeeper> I could just 'bzr export' the lib into a subdir and pretend it's part of the base project, until nested trees are working.
<jelmer> james_w: It suggests the right command to run, but I'm getting very lazy :-)
<ToyKeeper> Hmm, I've used merge-into for one-time imports, but it doesn't seem to like merging a second time when the original branch changes.
<jelmer> ToyKeeper, if it's a subdir, I would recommend using bzr join
<ToyKeeper> Yeah, I'm just trying to figure out how to merge changes after the initial join.
<jelmer> just "bzr merge <location>" should work I think
<ToyKeeper> Nope.
<ToyKeeper> Maybe it's supposed to, though.  I'm getting a traceback when I try.
<lamont> jam: mutter.'  and here I thought you'd just uploaded rc5-1~mumble, not that the release was out and that the sources weren't in the ppa yet.
<ToyKeeper> looks like the same thing as bug 203376
<ubottu> Launchpad bug 203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/203376
<ToyKeeper> Weird.  Some of the paths listed in the traceback don't exist.  It's printing a different path than the file it's using.
<ToyKeeper> It seems like it's been broken since bzr 1.2 or maybe earlier.
<jam> lamont: :) no, have a couple other things I'm trying to get out, and then I'll upload
<jam> jelmer: hardy-ppa wants to sign the archive with *your* key, does that matter?
<lamont> jam: no worries... if you happen to feel like it, poke me with something pointy when you upload, eh?
<lamont> jam: debsign -m$yourkey foo_ver_source.changes
<jam> lamont: well, there is one in https://launchpad.net/~jameinel/+archive but I should have 1.6 final uploaded to ~bzr in about an our
<jam>  *hour*
<jelmer> jam: You should probably just sign it with yours
<jam> jelmer: builddeb doesn't like that
<lamont> jam: -m
<jam> jelmer: And I'm not enough of a deb guru to really know the point to do it at.
<lamont> to override the maintainer in debuild
<jelmer> jam, Perhaps just change the name in the last entry in debian/changelog
<lamont> jelmer: or pass in "-uc -us" and then manually "debsign -m$MYID foo_ver_source.changes"
 * lamont usually does the last of those, so he could be completely wrong about debbuild taking a -m argument :-(
<jam> Well, builddeb defaults to -uc -us
<jam> But the config that luks suggested has me configure it to actually sign them.
<jam> Does LP require signing?
<jam> I know it doesn't sign the binary packages
<jelmer> jam, it requires signing on uploaded source packages I think
<jam> jelmer: hm... it seems to actually connect to lp:bzr-svn, is there any way to get it to use my local repo instead?
<jelmer> jam: Yep, use --export-upstream=../path/to/local
<jam> jelmer: thanks, that helps a lot. Now... what about APR?
<jam> It seems to cause a warning
<jam> but doesn't actually fail the build process
<jelmer> jam: What sort of warning?
<jam> jelmer: "make" seems to be failing
<jelmer> in what way?
<jam> Exception: apr-config not found. Please set APR_CONFIG environment variable
<jam> make: [python-clean-2.5] Error 1 (ignored)
<jam> cd . && python2.4 setup.py clean -a
<jam> sh: apr-config: not found
<jam> jelmer: but it doesn't actually stop the build
<jam> I'm installing libapr1-dev now
<jelmer> jam, Oh, that's actually correct
<jelmer> it should be a little bit less verbose
<jam> now, of course, it needs the svn devel files
<jelmer> there's different names the apr config utility can have
<jelmer> the first name in the list doesn't exist on your system, but the second one probably does
<jam> jelmer: well, I didn't have the libapr1-dev at all
<jam> installing it made it happy
<jam> my bigger problem is that the build should *fail*
<jelmer> jam, You do have libapr-dev probably
<jam> if it can't actually build
<jam> I didn't have libsvn-dev or libapr1-dev
<jam> I don't know if you still need svn-dev
<jam> but the build process *thinks* it does
<jelmer> yeah, you need libsvn-dev
<jam> jelmer: so there seems to be a problem that "make" isn't causing the builddeb process to fail
<jam> so I would probably have built a bogus patch if I didn't check the traceback
<jelmer> jam: I don't think it should've failed
<jelmer> jam: It searches for apr-config first, then apr-1-config
<jam> jelmer: why is that, or more importantly, why do you need to do make if you don't need it to succeed
<jam> jelmer: I didn't have svn-dev either. I'm pointing out that "make" failed, but builddeb did not
<jelmer> ahhh
<jam> It seemed to think the package was fine
<jelmer> jam, it was the clean step that failed
<jelmer> that's probably allowed by cdbs
<jelmer> jam, not the build step
<jam> ah
<jam> ok
<jam> well, installing libapr1-dev and libsvn-dev and it builds "cleanly" so I'll stick with that for now
<jam> lamont, jelmer: 'dput' requires the file to be signed. Thanks for giving me the "debsign -mXXXX" command
<lamont> jam: dput, and the backend processing both. :-
<lamont> )
<jam> jelmer: your .debs have been uploaded to ~jameinel/+archive, I imagine it will be a little while for them to build and be available
<jelmer> jam: cool
<jam> jelmer: I can copy them to ~bzr-beta-ppa if you want to give them a once over and make sure they are valid
<lamont> and clean failing isn't necessarily an error... although it does bear wondering about
<jam> jelmer: also, what about builds for ~gusty and ~intrepid?
<jam> and even ~dapper
<jelmer> jam: sounds like a good idea to me :-)
<jam> jelmer: I just don't know what it actually *entails* I get the branches handed to me for bzr
<jam> my deb-fu is *very* week
<jam> weak
<jelmer> jam: it should be a matter of just taking the ppa-hardy branch and replacing hardy with intrepid/dapper/gutsy in the top-level entry of debian/changelog
<jam> jelmer: ppa just accepted my submission
<jam> also, what do you guys think. Should these be ~bzr/bzr/packaging-hardy, or should they be ~bzr/bzr-packaging/hardy branches?
<jam> As it is just the "debian" directory, they seem like they should be separate branches
<jam> But someone mentioned that most of the "ubuntu" packages are not done that way.
<jam> (separate projects)
<jelmer> in the case of bzr-svn, it really is a bzr-svn branch
<jelmer> in the case of bzr, I would prefer seeing that move to the same approach as bzr-svn >-)
<jam> jelmer: "packages failed to build" for amd64
<jam> http://launchpadlibrarian.net/17067514/buildlog_ubuntu-hardy-amd64.bzr-svn_0.4.11%7Erc1-1%7Ebazaar1%7Ehardy1_FAILEDTOBUILD.txt.gz
<jam>  /bin/sh: python2.4: not found
<jelmer> hmm same thing for which a debian bug was filed
<jam> Seems hard to build packages when you don't have python
<jelmer> looks like a cdbs problem to me..
<jelmer> jam, it installs python2.5 but then tries to run python2.4
<jam> weird
<LarstiQ> python-central/foo?
<jelmer> LarstiQ, probably
<jelmer> james_w, does the bzr-builddeb testsuite fail for you atm as well?
<james_w> jelmer: which branch?
<jelmer> james_w, the main one
<james_w> what's the failure?
<jelmer> a bunch of failures in the changelog parsing bits - apparently there's now two extra spaces and a newline
<jelmer> and index out of range errors parsing the version
<james_w> what's your python-debian version?
<jelmer> ii  python-debian                        0.1.11                              Python modules to work with Debian-related data formats
<james_w> jelmer: yeah, I see that too
<jelmer> james_w, thanks for checking, I'll submit a fix for it
<jelmer> ... once I figure out what's actually going wrong
<jam> jelmer: i386 just failed as well, do you want the log?
<jelmer> jam: No, thanks. I just need to figure out how to fix this
<jelmer> jam: Please merge again
<jelmer> jam: I think the fix I applied now should take care of this
<jam> jelmer: what am I merging?
<jam> the ~bzr/bzr-svn/hardy-ppa branch doesn't seem to have anything new yet
<jelmer> jam: the bzr-svn debian branch, http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable
<jelmer> jam: Ah, sorry
<jam> ah, I haven't merged that one yet
<jelmer> the hardy-ppa branch is based on it
<jam> jelmer: well, merging that brought in about 50+ revisions
<jam> is that expected?
<jam> though it only had 1 conflict in "changelog"
<jelmer> jam: It's harmless, though not intentional
<jelmer> I was playing with "bzr mu" in that branch
<jam> "mu" ?
<jam> (maintainer upload?)
<jam> Or the Godel Escher Bach "not an op" mu
<LarstiQ> is that the same as the zen mu?
<jam> GEB mu is the 'zen mu', yes
<jam> IIRC, it has been a long time since I read it.
<jelmer> jam: "bzr mu" is an alias for "bzr merge-upstream" from bzr-builddeb
<jam> jelmer: So... I seem to be still exporting the same bzr-svn revision_id, is that correct?
<jelmer> jam: Yep
<jam> where is that set, by the way
<beuno> jam, hi!  Congrats on the 1.6 release!
<jam> thanks beuno
<jam> I'm putting together new docs that use bzr-builddeb
<jam> Should be a lot easier
<beuno> did you manage to package it?
<jam> as it ends up being "run these 4 scripts"
<jam> beuno: documenting as I package
<jam> so I don't forget anything :)
<jam> beuno: I have it in ~jameinel/+archive
<jam> But I'm documenting a proper version for ~bzr-beta-ppa
<beuno> jam, very cool. Let me install that and give it a spin...
<jam> jelmer: I'm trying to upload again. Will I need to repackage with a foo....~2 ?
<jam> (aka, bump the packaging number?)
<jelmer> jam, not sure if ppa requires that
<jelmer> jam, can't really hurt though
<jam> well, so far nobody has complained
<jam> but I'll wait for ppa to tell me
 * jelmer has now reduced packaging a new upstream version to: "bzr mu -d <path> && bzr tag && bzr builddeb"
<mwhudson> so branching stacked branches over the hpss appears to have issues :(
<jam> mwhudson: good thing it isn't set up in the default branch format :)
<mwhudson> yeah
<jam> mwhudson: is it because of format inconsistencies?
<jam> that the Smart Server always says it is the default format?
<jam> or something along those lines
<mwhudson> jam: maybe, but i don't think so
<mwhudson> jam: let me set up a test again and -Dhpss it
<nandersson> Swedish Techmag TechWorld Open Source congrats on the 1.6 release :) Hope to see it in Hardy soon
<jam> jelmer: I need to bump the number, otherwise the "md5" sum does not match one already in the archive
<jelmer> jam: You'll need to bump the upstream version number actually
<jelmer> jam, That's because of a bug in bzr export (which uses now() as the timestamp for all the files in the tarball)
<jelmer> jam: Alternatively, you can use debuild rather than "bzr builddeb"
<jam> jelmer: so I need to make rc1-2 ?
<jelmer> jam: +1 probably ("-" is special)
<mwhudson> jam: http://pastebin.ubuntu.com/40506/
<jelmer> so something like rc1+1
<jam> jelmer: can you spell it out for me
<jelmer> something like 0.4.11~rc1+1~bazaar1~hardy1
<mwhudson> it seems maybe the fetch logic is busticated ?
<jam> mwhudson: of course, there you have 2 bzr processes fighting to log to ~/.bzr.log, which makes it a bit ugly
<mwhudson> jam: huh, indeed
<jam> I would have thought that fetch() wouldn't actually fetch anything for a stacked branch
<jam> so I'm not sure what is broken.
<mwhudson> well, no, bzr branch stacked-branch local
<mwhudson> should copy all the revision data into local
<jam> mwhudson: ah, you are branching *from* a stacked, and expecting it to pull everything from both
<jam> sure
<mwhudson> jam: yes
<mwhudson> maybe it's just a missing activate_fallback_repositories somewhere, i dunno
<jam> well, after I actually get these packages built, maybe I can poke at it a bit
<mwhudson> thanks
<jelmer> jam: sorry, something like 0.4.11~rc1+1-1~bazaar1~hardy1
<jam> jelmer: not rc1-1+1 ?
<jam> I would think the official upstream number would come first
<jelmer> jam: You need to update the upstream version number since every time you run "bzr builddeb" the timestamps in the upstream tarball change
<jam> jelmer: I understand that, I'm just trying to understand debian version numbering
<jam> and it seems like "rc1-1+1" would be better than "rc1+1-1"
<jam> but my knowledge is *very* weak
<jelmer> everything after the - is debian-specific
<jelmer> s/debian/packaging/
<jelmer> the stuff before the - refers to the upstream version
<jam> and you need a new upstream version
<jam> sure
<jam> ok
<jam> jelmer: of course now I get "no such tag ..." but i'll shove one in
<jam> I assume we should use the same version again, right?
<jelmer> jam: or specify --export-upstream-revision=tag:0.4.11~rc1
<jelmer> sorry, --export-upstream-revision=tag:bzr-svn-0.4.11~rc1
<jam> jelmer: well, I went the tag route, since it makes it obvious what version is uploaded since the numbers don't match anymore.
<jam> Kind of odd to do "bzr tag -r tag:XXX XXX-1" :)
<jelmer> heh :-)
<jam> anyway, new packages are built and uploaded
<jam> again to ~jameinel/+archive, LP hasn't responded yet
<jam> ok, I'm currently uploading the bzr packages to ~jameinel/+archive
<jam> Unfortunately, I'm likely to be done for the night (have to pick up my son now)
<jam> So if someone can play with them to make sure they are good
<jam> and then I'll copy them to ~bzr-beta-ppa and ~bzr
<jam> beuno: you may want to check out http://bzr.arbash-meinel.com/branches/bzr/1.7-dev/packaging
<jelmer> looks like it built succesfully
<jam> jelmer: that is probably the one I uploaded this morning
<jam> I'm doing all of gutsy/feisty/intrepid/etc right now
<jam> I'm a bit worried about multple .orig.tar.gz uploads
<jelmer> jam, I mean the new bzr-svn uploaded successfully
<jam> but at least the md5 sum should match
<jam> jelmer: ah yeah, I think that did
<jam> it should be building
<jelmer> jam: the export-upstream option in bzr-builddeb is the only bit that generates different tarballs each time
<jelmer> jam: if you don't use that, you should not have any problems
<beuno> jam, the branch is enourmous. Does that include the bzr branch?
<beuno> anyway, off to bed n' stuff
<jelmer> beuno, g'night
<jelmer> beuno, loggerhead is in NEW, btw, thanks to siretart
<beuno> jam, scripts look good  :)
<beuno> jelmer, really?  yay!
<beuno> did -search get re-uploaded?
<beuno> jam, just need to feed the scripts the information instead of hard-coding it, and we're in business
<jelmer> beuno, no, Ididn't see a re-upload of search
<beuno> jelmer, I'll keep on insisting then. Thanks for the lh packaging  :)  I may upload it to bzr's PPA too, so we can update it more frequently
<lifeless> moin
<jelmer> hey lifeless
<mwhudson> hi lifeless
<jam> beuno: what information is hard-coded in the scripts? You supply the version number
<jam> I just give some help text so *I* can remember what format they should be in
<jam> I guess I hardcode lp:~bzr/bzr/packaging-XXX
<jam> but that is because those are the official locs
<jam> the files have been copied to ~bzr-beta-ppa, if people like them, I'll put them in ~bzr tomorrow (except bzr-svn)
<jelmer> jam: cool
<ronny> hi
<ronny> i just started a merge, now i got some files with conflicts, is there any nice wrapper around fireing up kdiff3 or something like that
<bob2> there's a plugin
<bob2> merge-tool or something
<bob2> oen sec
<bob2> extmerge
#bzr 2008-08-26
<jml> grats on the release!
<jam> jml: thanks
<ronny> bob2: thanks
<jam> lifeless: with my "add_node" update and my "single-pass" update to btrees, it is actually faster to write out a btree index of my mysql repo than it is to *read* (_buffer_all) the graph index
<lifeless> nice work
<jam> 36s to 28s
<jam> s/to/vs/
<lifeless> you have quite a knack for micro-tuning
<lifeless> has any of the btree stuff landed in dev yet?
<jam> lifeless: The initial btree code has landed
<jam> none of my follow up patches
<jam> There are 2 right now, but one is superseded once I finish this benchmark run
<lifeless> ok
 * mwhudson points at 6895
<mwhudson> no
 * mwhudson points at https://bugs.edge.launchpad.net/bzr/+bug/261315
<ubottu> Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Undecided,New]
<muntyan> could someone help me fix this error on fast-import: bzr: ERROR: Bad repository size - 3639 revisions found, 3637 expected
<muntyan> i imorted a hg repo using fast-import, all was good; but then i committed a change in the bzr repo and now i get that error when trying to use fast-import again
<muntyan> and i got to fix this bzr repo because i pushed it to yet another remote location, so i can't just throw it away and convert the mercurial repo again
<bob2> isn't fast-import only for one-shot imports?
<muntyan> no, it seems to work fine for synchronizing
<muntyan> but apparently you must not touch the bzr reop in between
<muntyan> here: As long as the fastimport-id-map file is not deleted and the front-end generates an export which begins with the same content as the previous import, bzr-fastimport can be used to maintain a Bazaar mirror of a foreign repository.
<bob2> can you branch your broken trunk, from a couple of revs back to new-trunk, and continue th import against that?
<muntyan> i can, but the problem is that it breaks my push to remote repo
<muntyan> so i need to fix this bzr repo in-place
<muntyan> i think
<bob2> what breaks your push?
<muntyan> err, nevermind
<muntyan> i didn't try that indeed
<fullermd> Erm.  Hm.  This is odd...
<fullermd> lifeless: ping
<lifeless> yo
<fullermd> If I can pull a --long --strict testment of a revision, that means the revision is present and accounted for, right?
<lifeless> EPARSE
<fullermd> OK, I've got this knit branch, that I need to de-knit now that we're on 1.6.
<rocky> jelmer: don't suppose you worked on the speed stuff anymore for 0.4.11 ?
<jelmer> rocky, It should've improved quite a bit
<fullermd> I have 3 different repos with it, on 2 different boxes.  All of them 'check' just fine.  All of them, though, blow up on upgrade claiming a given rev is not present in "<bzrlib.knit.KnitVersionedFiles object at 0x89e3fec>".
<rocky> jelmer: oh? so i should try again?
<jelmer> rocky, yeah, please do
<fullermd> I can pull the testament of that rev fine, though.  It's right there in log.  diff -c is right.
<rocky> jelmer: i'm sitting on dial-up this very second so i'll have to be creative ;)
<fullermd> reconcile doesn't do anything to help
<lifeless> fullermd: testaments don't access filecontents
<lifeless> fullermd: whats the missing rev?
<lifeless> also, pastebin your check output
<fullermd> What in what sense?  The revid?
<lifeless> fullermd: it will have printed a tuple
<lifeless> fullermd: whats the tuple; also, what is the output of check
<fullermd> What pastebin is it you can reach well?
<lifeless> all these days, ipv6 tunnel is repaired
<fullermd> lifeless: http://pastebin.com/m5908d8d6
<fullermd> Testament pulls the rev fine, as does diff'ing, or cat'ing the file it changes.
<lifeless> fullermd: testament doesn't mean jack
<lifeless> fullermd: it just means 'can read the inventory'
<fullermd> Well, what is there to the rev aside from the inventory and log message and timestamp and yada yada, and how can I access it other than via 'upgrade'?
<lifeless> that tuple is a single revid, so its either a revision or an inventory issue
<rocky> jelmer: should i get the bzr 0.4 branch or try the latest 0.4.11 rc ?
<lifeless> or a signature
<fullermd> No signatures, so that part's clear.
<lifeless> fullermd: bzr 1.6 ?
<jelmer> rocky, there's only one rc :-)
<fullermd> 1.6 and bzr.dev
<rocky> oh
<jelmer> rocky, you need th 0.4 branch
<rocky> gotcha
<lifeless> fullermd: ok, in python
<lifeless> import bzrlib.repository
<lifeless> r = bzrlib.repository.Repository.open('...')
<lifeless> r.lock_read()
<lifeless> r.revisions.get_parent_map([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)])
<fullermd> {('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',): (('fullermd@over-yonder.net-20080425022841-hkrtkho705s4m5hr',),)}
<lifeless> r.inventories.get_parent_map([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)])
<fullermd> {('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',): (('fullermd@over-yonder.net-20080425022841-hkrtkho705s4m5hr',),)}
<lifeless> r.signatures.get_parent_map([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)])
<fullermd> {}
<lifeless> list(r.revisions.get_record_stream([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)], 'topological', True))
<fullermd> [<bzrlib.versionedfile.FulltextContentFactory object at 0x8a365ec>]
<lifeless> list(r.inventories.get_record_stream([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)], 'topological', True))
<fullermd> [<bzrlib.versionedfile.FulltextContentFactory object at 0x8a3ac2c>]
<lifeless> ok
<lifeless> emystified
<lifeless> try running the upgrade with BZR_PDB=1
<fullermd> The upside is that it does out pretty quick at least...
<fullermd> 'k
<fullermd> > /home/fullermd/src/bzr/bzr.dev/bzrlib/knit.py(229)get_bytes()
<fullermd> -> raise errors.RevisionNotPresent(compression_parent, self._basis_vf)
<lifeless> print basis_entry
<fullermd> <bzrlib.versionedfile.AbsentContentFactory object at 0x8dbca0c>
<lifeless> print self._basis_vf
<fullermd> <bzrlib.knit.KnitVersionedFiles object at 0x8aac7ec>
<lifeless> print self._basis_vf._index
<lifeless> print self._basis_vf._access
<fullermd> _KnitGraphIndex(CombinedGraphIndex())
<fullermd> <bzrlib.knit._DirectPackAccess object at 0x8aac62c>
<lifeless> you're upgrading from knits
<lifeless> ?
 * fullermd nods.
<lifeless> ok, wtf
<lifeless> uhm, bt ?
<fullermd> http://pastebin.com/m2efbcdf1
<lifeless> up
<lifeless> print adapter_key
<rocky> jelmer: new traceback :(
<jelmer> rocky, please pastebin
<fullermd> (I'm on 3644 of bzr.dev btw; think I'm a day or two back, if it matters)
<fullermd> ('knit-delta-gz', 'fulltext')
<lifeless> ok
<lifeless> so we got a knit-delta-gz
<lifeless> print record.storage_kind not in native_types:
<lifeless> erm
<lifeless> print record.storage_kind not in native_types
<rocky> jelmer: http://cluebin.appspot.com/pasted/803
<fullermd> True
<lifeless> print native_types
<fullermd> set(['knit-ft-gz'])
<rocky> jelmer: this time it's svn 1.4, bzr 1.6 (final), and bzr-0.4 branch
<lifeless> ok
<lifeless> thats truely bizaare
<lifeless> I know whats happening
<fullermd> My specialty   8-}
<lifeless> please file a bug, I'll comment on it
<lifeless> you have a revision record which is a delta
<lifeless> we're not meant to delta revisions
<fullermd> OK.  That rev would have been made with bzr.dev of around the timestamp of the rev (T-0 to a few days behind)
<jelmer> rocky, one sec, I'll add another assertion
<lifeless> still, we can fix by asking for revisions in topological order
<jelmer> rocky, please try again with r1657
<lifeless> whats failing is that the revision *after* the one the error shows is a delta, and the one the error shows has not been copied yet
<rocky> jelmer: sorry, disconnected, did you see my pastebin paste?
<jelmer> rocky, yep
<jelmer> rocky, any chance you can try again with r1657?
<fullermd> bug 261339
<ubottu> Launchpad bug 261339 in bzr "Upgrade from knit to pack fails on revision not present" [Undecided,New] https://launchpad.net/bugs/261339
<jelmer> rocky, it should give a better indication of what's wrong now
<rocky> jelmer: yep
<muntyan> it's not my commits, hg-fast-export.py | bzr fast-import simply doesn't work more than once!
<fullermd> Well, that's neat.  Usually, I only break dirstate; I've never done revisions before.
<rocky> jelmer: http://cluebin.appspot.com/pasted/804
<muntyan> is it possible to import a changeset, i.e. have a patch automatically applied and committed?
<jelmer> rocky, please try r1658
<rocky> tsk tsk ... someone's not running their unit tests... :)
<rocky> jelmer: http://cluebin.appspot.com/pasted/602 ;)
<lifeless> muntyan: you can script that obviously
<jelmer> argh, another 1.4/1.5 inconsistency
<jelmer> rocky, please try yet again :-)
<jelmer> r1659
<rocky> jelmer: http://cluebin.appspot.com/pasted/603
<jelmer> argh
<jelmer> thanks for testing with svn 1.4 :-)
<jelmer> please try again :-)
<rocky> lol
<rocky> no revisions to pull
<jelmer> r1660
<jelmer> it should be pushed
<rocky> that got it
<jelmer> you'll have to run make again
<rocky> jelmer: it committed my file that time... and it was quite fast ... but unfortunately it's not a very good speed test from me because the only remote http+svn server i have to test against is the only server i can actually test bzr on (ie the commits are going to the local box through http+svn)
<rocky> i can see that it still made a ton of requests
<jelmer> rocky, how much is a ton ?
<rocky> checking
<rocky> jelmer: my apache log shows 164 requests for a commit of one empty text file
<rocky> jelmer: would it help if i gave you a svn dump of that repo? you could test commits against it yourself?
<jelmer> it's still doing the checks of all paths
<jelmer> there's just some other things that have improved performance
<jelmer> rocky, Have you compared this to doing a similar commit with Subversion?
<rocky> jelmer: no? didn't think that would be terribly relevant
<jelmer> rocky: Any chance you can try running the bzr commit with -Dtransport ?
<jelmer> That should write the high level svn operations to ~/.bzr.log
<rocky> sure
<jelmer> there are several svn operations that translate into multiple http requests
<jelmer> I bet svn itself does also requires a significant amount of http requests
<rocky> i'm pretty sure it doesn't actually
<rocky> several per commit
<rocky> jelmer: the log appears huge
<rocky> jelmer: http://paste.plone.org/23383
<jelmer> rocky, only r1030 is from the last run
<rocky> ah
<jelmer> rocky, the log output doesn't look too bad
<muntyan> is there a command to remove files which are deleted on disk? like 'bzr add' but for removed files
<lifeless> bzr rm
<bob2> they'll be removed when you commit, if they are no longer on disk
<lifeless> I don't know if the automatic version is in 1.6, its definitely in bzr.dev
<lifeless> you can just type 'bzr rm' and any absent files are removed
<muntyan> lifeless: ERROR: Specify one or more files to remove, or use --new.
<muntyan> bob2: cool, thanks
<lifeless> muntyan: right, only bzr.dev then
<nmb> I'm working on bug 239523 and I've got a question about how bzr uses stdout and stderr...Anyone here have any opinions?
<ubottu> Launchpad bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed] https://launchpad.net/bugs/239523
<mwhudson> abentley: ah, i'm glad you've seen the default_stacked_on mess thread...
<Verterok> nmb: what is your question? (I'm not an expert, but I'll try to help :)
<nmb> Verterok:  Currently, messages like "Now on revision 2." when you pull go to stdout and status information like """M  file
<nmb> All changes applied successfully."""
<nmb> goes to stderr.
<nmb> In order to make all of the commands obey the --quiet option, I want to use the logging framework to print messages like "Now on revision 2".  But the way it is currently set up, if we use the logging framework we go to stderr.
<lifeless> nmb: we send messages with the response to the users query to stdout
<nmb> So I guess my question is:  should all informational messages go to one stream?
<lifeless> nmb: and messages about progress/general chatter/progress bars to stderr
<nmb> lifeless: then does bzrlib.trace need to grow a new function in addition to note() that writes to stdout?
<lifeless> nmb: why?
<lifeless> std out is on self.outf on command objects, thats where it should be
<nmb> Because the current way of getting there, self.outf.write, doesn't respect --quiet
<Verterok> nmb: in the commands you have access to self.outf/to_file
<lifeless> nothing should be writing to sys.stdout anywhere in the code base
<lifeless> because that may not be encoded correctly
<Verterok> nmb: commands should check trace.is_quiet() (If I remember ok)
<nmb> Verterok:  that's very ugly with lots of "if trace.is_quiet()"s appearing in builtins.py.  It seems like it is screaming for a function that does exactly that.
<Verterok> nmb: is_quiet() or not is_quiet() is passed to the method/function that do the real work
<nmb> Verterok: that's not what I see.  For example, if not is_quiet():
<nmb>                     self.outf.write("Using saved parent location: %s\n" % display_url)
<lifeless> well, global state is bad
<lifeless> more global state referring functions is more bad
<lifeless> I could see a method on Command
<nmb> lifeless:  It seemed that when Ian made --quiet a global option we assented to the existence of global state information...
 * Verterok was looking to cmd_add 
<nmb> currently we refer to that global state in lots of different places when we need to make sure that we obey the option...
<lifeless> nmb: We can always improve the quality of the code base
<lifeless> 'we do it this way currently' just means that we have code we can learn from.
<nmb> I think it's cleaner if we refer to that global state in a central location, so that callers simply need to say "I would like to tell the user X"
<nmb> and the global state controls how that telling works.
<lifeless> So, remove the global state
<Verterok> nmb: something like logging levels?
<lifeless> ugh no no no, python logging is nuts
<nmb> Verterok: --quiet is implemented with logging levels
<nmb> See trace.py for the gory details.
<Verterok> nmb: ok, I get it now
<nmb> If I talk out loud about what would be ideal...
<nmb> It seems we need some global state in order for --quiet to apply globally...
<lifeless> I'll repeat my design input - less global state is massively preferred.
<nmb> I'll agree with that as a design principle...any ideas on how to implement a global option without having to pass around is_quiet options to everything that does output?
<lifeless> self.outf on command objects is already non-global, I'm extremly strongly against making it global, or causing it to be used globally by requiring global state for it to work well
<lifeless> I suggested a method on Command before
<nmb> Hmmm.  Where does one get an actual instance of Command where one could set the self._quiet attribute so that a method self.feedback could respect it?
<lifeless> nmb: its created by the setup code for running the command - the same stuff that parses options and detects -q
<markh> when would changes_from be preferred over iter_changes (or vice-versa)?
<lifeless> markh: iter_changes is generally preferred; changes_from is implemented on iter_changes
<Verterok> nmb: commands.run_bzr
<lifeless> markh: but if you need a in memory delta, changes_from is that
<lifeless> nmb: I would start just by having the code you want on Command
<markh> I think we just need simple status to build a listbox of "modified" items, for example.  Current code uses changed_from, but iter_changes has a better api
<nmb> Verterok: got it, get_cmd_object, etc.
<markh> (its in qbzr)
<lifeless> nmb: don't duplicate state - that is don't have a _is_quiet that is separate from the current is_quiet state, because that allows skew
<lifeless> nmb: instead, refer to the current state, but from a non-global location; then we can work on reducing the global stuff separately
<lifeless> markh: then use iter_changes
<nmb> lifeless:  makes sense, two steps
<markh> I will, thanks :)
<lifeless> :)
<nmb> off to hack, thanks all
<mwhudson> hmm
<mwhudson> i'm writing a test involving remote branches and the test runner is complaining about threads being left behind
<mwhudson> they seem to be smart server 'connection threads'
<mwhudson> hnnh, dropping the branch objects and running gc.collect() makes the message go away
<lifeless> branch objects hold transports, transports hold sockets, sockets hold servers
<mwhudson> and there is no transport.close
<lifeless> right
<lifeless> even if there was, you'd be breaking the branch object state
<mwhudson> well yes
<lifeless> bzr tests clean their state during tearDown
<lifeless> perhaps you're not tearing down
<mwhudson> no, i am
<mwhudson> lifeless: here's my TestCase: http://pastebin.ubuntu.com/40570/
<mwhudson> (which is more complicated than i would like in at least two ways...)
<lifeless> line 4 can be in the body
<mwhudson> oh right yes
<lifeless> oh I see
<lifeless> so, theres probably a cycle in there or something
<lifeless> and python gc ftl
<mwhudson> well
<mwhudson> i don't think there are any gcs that do prompt collection of cycles
<mwhudson> lifeless: i also don't really get why make_branch isn't returning a RemoteBranch
<lifeless> you haven't set a format
<lifeless> so you're making a default format branch on a VFS that happens to be remote
<mwhudson> ah
<mwhudson> lifeless: http://pastebin.ubuntu.com/40573/
<mwhudson> lifeless: ^ saner, by your book?
<lifeless> uh
<lifeless> self.make_branch('.') is cleaner
<mwhudson> well, that creates a BzrBranch on a RemoteTransport (i think...)
<mwhudson> seems a slightly strange beast
<mwhudson> but sure, it works
<lifeless> A RemoteTransport is a Transport
<mwhudson> true enough
<Verterok> mwhudson: I started hacking on Bug #243415
<ubottu> Launchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/243415
<mwhudson> Verterok: oh cool
<Verterok> mwhudson: I already have a working wsgi middleware to log the tracebacks
<Verterok> do you have any particular idea on this topic?
<mwhudson> Verterok: nope, that sounds sane, generally speaking
<mwhudson> Verterok: for the one on launchpad we want to do Something Else (tm) with unhandled exceptions, so middleware makes sense
<mwhudson> (we'll just use our own, rather than whatever you write that ends up in loggerhead itself)
<Verterok> mwhudson: ok, ATM it's just log the error and shows the traceback to the user :P (now trying to figure out how to use a template to show a nice message to the user)
<mwhudson> it could be a little awkward because loggerhead streams it's output
<mwhudson> if the error happens after the headers have been sent, there's a limit to what you can do
<Verterok> mmm, I see
<Verterok> so, adding a fallback (standalone) template/html should do the trick
<Verterok> ah, adding launchpad specific magic should be fairly easy, just overriding loggerhead.apps.error_app ;) (that's the idea)
 * mwhudson gives his wireless a good kicking
<markh> In http://bazaar-vcs.org/Integrating_with_Bazaar, it says about smart_add: "Paths can either be absolute or relative to the workingtree".  Does this mean that even if the cwd() isn't in the tree, relative path names should still be taken as if they are from the root of the tree?
<markh> cos if it does, I think I can demonstrate it doesn't work :)
<lifeless> uhm
<lifeless> smart_add needs a path from cwd into the tree
<lifeless> its an API buglet
<markh> worth reporting a bug, or just work around it? :)
<markh> well - *and* work around it ;)
<lifeless> no
<lifeless> either a patch to fix it
<lifeless> or not :)
<markh> well, I could see it being ambiguous.  If the cwd is *inside* the tree, should a relative name still be from the root?
<lifeless> tree apis should not depend on cwd
<lifeless> thats the bug
<lifeless> cwd is bad and fragile
<markh> yeah - today a relative name is taken from the cwd.  So that could break peoples code?
<lifeless> on some platforms its not thread safe
<lifeless> markh: yes, it would break peoples code to change it
<markh> but it would still be approved you think?
<markh> (btw - I resurrected the branch that allows 'bzr up -r' too :)  I hope it doesn;t languish...)
<lifeless> markh: I'd review a fix to smart_add
<lifeless> probably want to rename+deprecate to provide a transition path
<markh> how about one for 'up -r'? ;)
<lifeless> I'd like to fix the double-merge bug first
<lifeless> so that it stops if the first merge conflicts
<lifeless> I think cleaning that up will make the overall code cleaner
<lifeless> morning visik7
<lifeless> erm sorry
<lifeless> I mean vila
<em1> hi
<lifeless> damn completion bugs
<lifeless> hi em1
<vila> hi robert :)
<visik7> ola lifeless
<visik7> asd
<visik7> typo
<lifeless> :P
<lifeless> jam: :( AssertionError: Somehow we ended up with too much compressed data, 4012 > 3976
<lifeless> jam: I'd like to make that impossible.
<em1> AttributeError: 'module' object has no attribute 'symlink'
<em1> why?
<james_w> em1: are you on windows?
<gour> em1: have you fetched that openerp sources?
<gour> james_w: he was on xp last time
<james_w> then without more context I would guess that it is bug 81689
<ubottu> Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Confirmed] https://launchpad.net/bugs/81689
<em1> yes
<em1> im on windows and fetching openerp source
<gour> cool ;)
<em1> how to fix this bug?
<em1> or i can ignore this error ?
<lifeless> em1: get the windows symlink plugin
<em1> how to get, lifeless?
<gour> em1: or use windows less often :-)
<em1> gour, which linux disto is better?
<lifeless> than windows? Any
<gour> em1: i'm running arch linux (http://www.archlinux.org/), but if you're new with linux i recommend ubuntu
<lifeless> em1: http://bazaar-vcs.org/BzrPlugins
<em1> but, after all, window is used for years
<gour> moving to linux will be like liberation from the prison :-)
<luks> if you get used to the crashing apps :)
<em1> im afraid of linux is another prison, lol
<em1> 'No download files exist for this project. '
<gour> ??
<em1> seems that no files can been download to install at that site
<lifeless> what site
<em1> https://launchpad.net/bzr-win32symlinks
<em1> gour, you still know me and last time on windowsxp, good enough
<lifeless> em1: click on code
<gour> em1: https://code.launchpad.net/bzr-win32symlinks
<gour> em1: same as with openerp ;)
<em1> got it, thank all
<gour> em1: don't forget to switch to (ubuntu) linux ;)
<em1> yes, must do after finishing work on hand
<gour> ok. cool. see you then in some #linuxdistro :-)
<em1> ok, you are there waiting my question
<gour> :-)
<gour> em1: download something like free Virtualbox plus e.g. Ubuntu CD and try installing it under XP
<em1> ok, i will try
<gour> em1: what kind of apps you use on xp?
<em1> gour, im developing a erp project and a voip project
<em1> two proj all be huge enough , so i dare not conver into linux at once
<em1> after all, both are java project
<em1> downloading openerp is just for fun or study
<gour> ahh, java isn't multi-platform :-)
<em1> i feel svn is good enough, but met bzr, have to try it.
<em1> gour, it is said that java is cross-platform
<gour> bzr is definitely better and you can use bzr-svn if you need to work on svn repos
<gour> em1: then you can  install linux to test your app there ;)
<em1> basiclly, java app need not test under kinds of os
<lifeless> em1: actually, VM differences mean you do
<lifeless> em1: IME
<em1> lifeless, what means IME?
<lifeless> in my experience
<em1> good, ime, at end, when want to deploy it, i will test it,
<em1> at end stage
<em1> at develop stage, no more time to test over and over in other platform
<thumper> Odd_Bloke: ping
<james_w> thumper: I think he started his job today
<thumper> james_w: ah, ok, thanks
<cammoblammo> I have a set of changes I want to make to a file versioned with bzr, but down the track I'm going to want to revert to it's original form. However, I'll still want to be able to have access to the changed file if needed. Is there a magic way of swapping between lines of development, or is it easiest to simply copy the file to a different location and treat it separately?
<lifeless> cammoblammo: yes, we call it branching :)
<cammoblammo> I thought that might be the way to go. I've never used VC for anything other than strictly linear work. Looks like I have some reading to do!
<em1> got to go, by all
<jam> lifeless: is that with existing btree or with my updates? My new predictor is much less susceptible to it
<jam> It uses an estimated compression of "1" and then updates that as we SYNC
<jam> so all new bytes are assumed to not compress until we sync
<jam> and then we see how much more we can fit
<lifeless> good
<lifeless> that was with bzr.dev, with a chk index
<^_-> hmm
<^_-> i just upgraded to 1.6, and i'm having this problem with loggerhead (i'm a python coder, but still somewhat new to bzr):
<^_->     self._revision_graph = branch.repository.get_revision_graph(self._last_revid)
<^_-> AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'
<^_-> was something removed/changed in 1.6 to cause this? :/
<^_-> i would normally browse the source but i don't even know where to begin heh
<thumper> ^_-: which version of loggerhead are you using?
<^_-> thumper, latest from trunk
<beuno> ^_-, are you sure?  That has been fixed in trunk months ago
<lifeless> whose trunk?
<beuno> loggerhead's
<beuno> is there anither one I'm not aware of?
<lifeless> beuno: I was asking ^_-
<^_-> beuno, i believe so
<lifeless> URL
<beuno> lifeless, ah, good point  :)
<^_-> http://www.lag.net/robey/code/loggerhead/
<^_-> maybe i'm using the wrong trunk @_@
<beuno> ^_-, https://code.edge.launchpad.net/loggerhead
<lifeless> exactly as I thought
<lifeless> :P
<beuno> lifeless, you have a real nack to identify those things
<beuno> ^_-, https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk  to be more exact
<^_-> ah, thanks ^_^
<beuno> we also have a full release
<beuno> if you prefer tarballs
<lifeless> beuno: assume anything that can go wrong, has
<beuno> lifeless, I have a lot to learn  :)
<lifeless> soon the student shall exceed the teacher
<pasky> sounds very epic
<pasky> will there be lightsaber battels?
<^_-> ergh
<zartosss> hi all
<zartosss> i have a noob question ( ;) )
<zartosss> i follow a project on launchpad, i create a repository with bzr init-repo myproject
<zartosss> i go to /myproject
<zartosss> i use bzr branch lp:myproject
<zartosss> it's download sources
<zartosss> but i can't use bzr diff or bzr status ...
<zartosss> it's write 'not a branch' for diff and 'no WorkingTree exists ...' for status
<zartosss> smb can help me?
<james_w> zartosss: "cd myproject" again
<james_w> so that you are inside the branch you just got, not the shared repository you created first
<zartosss> i try this two command in and outside the repository (with add myproject when i am outside)...
<zartosss> but its the same
<bob2> the repository isn't the problem
<bob2> none of the comands will do anything unless you are in the /branch/
<bob2> which is myproject/myproject, in your case
<gnomefreak> have we upgraded bzr to 1.2?
<zartosss> i use bzr 1.5 i think
<gnomefreak> sorry i meant server
<gnomefreak> zartosss: me too but im still getting warning sort of
<gnomefreak> Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<zartosss> it's launchpad, i suppose they are more geek than me :P
<gnomefreak> ok this branch is small and its taking forever to pull i would think its unrelated to the above
<zartosss> ok bob
<zartosss> its good
<zartosss> i just start my brain ;)
<zartosss> thx for the help
<muffinresearch> Hi, does anyone know the current status of nested tree support. Does it work reliably? I found this reference which suggests that it's still experimental but it's not all that up to date: https://lists.ubuntu.com/archives/bazaar/2007q2/026807.html
<zartosss> if there is no diff between my local repository and lauchnpad , bazaar doesn't write smg ? it's normal ?
<lifeless> gnomefreak: high, check in ~/.bzr.log for irregularities
<lifeless> muffinresearch: its not up todate, LarstiQ has more details
<lifeless> zartosss: what do you mean?
<^_-> hrm i keep getting this error with loggerhead: bzrlib.errors.NotBranchError: Not a branch: "/usr/home/bzr/bzr-repos/libost/.bzr/branch/".
<zartosss> i use bzr diff, and after bzr juste rewrite the repository where i am
<^_-> here's the relevant portion of my loggerhead.conf file: http://pastebin.ca/1185262
<zartosss> C:\Program Files\Bazaar>bzr diff gephibzr/gephi
<zartosss> C:\Program Files\Bazaar>
<zartosss> its juste write that
<zartosss> its want to mean there is no diff ?
<lifeless> ^_-: is libost a repository?
<lifeless> ^_-: or a branch?
<lifeless> zartosss: tat means there is no diff yes, you can also use 'bzr st' which can tell you more info
<^_-> lifeless, libost is a repository yes
<lifeless> ^_-: so, there is no branch there, only under it ? :)
<^_-> lifeless, there is trunk
<^_-> under it
<gnomefreak> lifeless: i cant see anything wrong but i also cant compare it to anything since most of that file is trace backs http://pastebin.mozilla.org/525889
<lifeless> gnomefreak: are you using http or bzr+ssh? http logs some stuff, can detect network packet loss
<lifeless> we've had some weird network interactions recently
<gnomefreak> im using bzr lp: hold on ill get you exact commands
<lifeless> ^_-: right, but you are telling loggerhead that libost itself is a branch, which its not
<gnomefreak> bzr branch lp:~gnomefreak/firefox-extensions/firegpg.upstream
<lifeless> ^_-: put the actual branch path there
<^_-> lifeless, ah i see
<lifeless> ^_-: for that simple a config though, just use serve-branches, its much easier
<lifeless> e.g. server-branches /usr/home/bzr/bzr-repos/libost
<^_-> lifeless, what does server-branches do?
<lifeless> serve-branches sorry, it serves out branches
<zartosss> bye all thx for speed help !
<^_-> lifeless, is there an example anywhere? :)
<lifeless> ^_-: I just gave you the example
<lifeless> ^_-: serve-branches /usr/home/bzr/bzr-repos/libost
<^_-> lifeless, i mean in the conf file
<^_-> wait nvm
<lifeless> no conf file
<^_-> i'm stupid
<^_-> lifeless, but i'm serving multipule branches
<^_-> actually multipule repos
<^_-> that was the one that was causing an error though
<lifeless> are they all in a single root folder?
<lifeless> ^_-: if so, perhaps serve-branches /usr/home/bzr/bzr-repos
<lifeless> is all you need
<^_->   File "/usr/local/bin/serve-branches", line 28, in <module>
<^_->     from loggerhead import __version__
<^_-> ImportError: cannot import name __version__
<lifeless> is loggerhead in your normal python path?
<lifeless> if its not, make sure you export PYTHON_PATH appropriately
 * ^_- facepalms
<^_-> hm i got it to work
<^_-> thanks lifeless :D
<lifeless> ^_-: no probs
<lifeless> ^_-: hope you like the new version :)
<pygi> ^_-, what a nick xD
<Leonidas> hmm, I have trouble finding some revision in the bzr source
<jam> ugh, lifeless you still around?
<lifeless> jam: yes
<Leonidas> bzr log -r revid:john@arbash-meinel.com-20050709180338-33e3b5a778df9104
<Leonidas> can someone tell me, where it is? There had to be such a revision.
<james_w> Leonidas: where did you get the revid from?
<james_w> I think that revision is a ghost
<Leonidas> james_w: I was walking the tree via hg convert (I'm trying to create a bzr plugin for it) and it somehow found that revision.
<Leonidas> james_w: so the bzr source contains revid that do not exist (anymore)
<Leonidas> ?
<james_w> Leonidas: yeah I imagine it is one of the ghost's in bzr's history
<Leonidas> james_w: how do such ghosts happen (so that I can reproduce such a repository using a unittest)?
<lifeless> Leonidas: bzr's history cannot be fully represented by hg
<LarstiQ> Leonidas: you can grep for ghost in bzrlib/tests/
<Leonidas> lifeless: every conversion looses some information (like directories, which hg does not track at all), but I'm trying to get it to convert as accurately as possible
<lifeless> Leonidas: bzr ghosts - references to history not present locally - require a hash to be included in hg repositories, and the hash is representation specific -> it can't be synthesised without the history, and thats whats missing in the first place :)
 * Leonidas is reading http://bazaar-vcs.org/GhostRevision - nice, it has some docs :)
<lifeless> as to how they can be created, just do a commit with an absent parent
<chombee> Hey, does bzr have an equivalent to GitHub?
<Leonidas> lifeless: is there a way to do this using the ``bzr`` command or do I have to use bzrlib?
<lifeless> chombee: sure, launchpad, or savannah, or alioth
<lifeless> Leonidas: bzrlib
<Leonidas> oh, ok.
<Leonidas> speaking about launchpad, does it support stacked branches already?
<lifeless> kindof, there are some glitches
<lifeless> look for an announcement soon
<lifeless> jam: so, did you and vila *both* totally miss the point of my email about ContainerWriter ?
<jam> lifeless: your summary message was a bit... terse
<Leonidas> lifeless: uhm, so how does bzr handle such ghosts? As far as I saw, it is pretenting that there is no such revision at all.
<lifeless> Leonidas: often yes
<lifeless> Leonidas: but we keep the pointer and can join up later
<lifeless> jam: so, the writer add method requires a buffer; this causes high memory use
<vila> lifeless: I think we both missed the context and just jumped the gun on seek(0, 2) :-)
<lifeless> vila: context is all there
<jam> Yeah, you already use .tell() here and there, I'm a bit surprised you need seek
<jam> I don't really see what prevents you from writing it spooled
<jam> And if packs are defined as length-prefixed, I don't see how you can get away with not needing to know the size of a page before it is written
<lifeless> bzrlib.pack.ContainerWriter
<lifeless> is length prefixed records
<Leonidas> lifeless: hmm, thats cool, so if I somehow join two repos I could get the parents of the revision, right?
<lifeless> you can seek cheaply on a finished BTreeGraphIndex, because there is a local tempfile
<lifeless> Leonidas: yes
<lifeless> Leonidas: but it also handles deliberate expunging much the same
<lifeless> (where there is no ability to join cause its really gone :))
<lifeless> jam: I don't know why you are talking about pages
<Leonidas> Is there some way to find the revision which references my ghost revision as parent? I'd like to take a look at the parent revision in IPython and play with it a bit.
<vila> lifeless: sry, I meant I misunderstood *indices* as referring to big blobs instead of indices *being* the big blobs
<lifeless> vila: right, that explains some of the confusion
<jam> lifeless: I'm calling a page a "length-prefixed bytes"
<jam> I'll try not to use confusing terms
<lifeless> jam: please, as I don't consider 300MB a 'page'
<jam> lifeless: so... how would you write out a length-prefixed page if you don't know the length, are you proposing to get rid of length-prefixed entries?
<jam> Or at least, make it optional?
<lifeless> jam: I'm proposing an additional method that takes a file object which supports seek(0,2); tell()
<lifeless> jam: which thus supports knowing the length
<lifeless> jam: these things are called records
<lifeless> thats the official termin the code, please don't call them apges
<jam> lifeless: ok, so the confusing part for *me*. You aren't changing Writer to support seek(0, 2) .tell()
<jam> but that you are *passing in*
<jam> an object that can do thta
<jam> that
<lifeless> right
<vila> lifeless, jam: some confusion for me
<lifeless> I'm requiring the parameter to the new method to support these two methods
<jam> vila: s/some/same/ ?
<vila> jam: yes, *same* :-/
<jam> lifeless: right, I think the statement "I'm thinking of requiring a file object" sounded more like *underneath* CW
<jam> not *above*
<jam> So are you thinking to spool to a local file then?
<lifeless> it wouldn't make sense to do it under CW, it would be inefficient
<lifeless> jam: if you want to use this method, yes
<jam> I'm just curious how you would support seek(0, 2).tell() without buffering
<jam> lifeless: I'm saying that we both read what you wrote
<jam> and thought you were talking about underneath
<jam> not above
<lifeless> jam: I'm not proposing to change code that uses the current interface, like I said, I'm proposing that I add an interface
<jam> which is why we were confused
<jam> So... your proposal seems fine to me
<jam> now that I actually understand it
<lifeless> :P
<jam> lifeless: so you know, if you would review my proposed changes, you could get a Btree index that will probably not fault for your bzr-search indices ... :)
<jam> ;)
<lifeless> jam: its high on my list
<lifeless> I've been merging path_info
<lifeless> its thousands of conflicts
<lifeless> :(
<jam> "path_info" is that the tokens stuff?
<lifeless> yeah
<lifeless> C stat-and-process in one hit
<lifeless> sorry, no, not 'path tokens'
<lifeless> fast-stat
<lifeless> no objects etc
<jam> Ah, ok. I remember that being around a while ago. I'm surprised it has so many conflicts
<jam> It seemed rather self-contained
<jam> I wonder if it is a bad merge base
<jam> you might try --weave :)
<lifeless> well, midnight, time for beauty sleep
<BasicPRO> hmm
<jam> lifeless: be pretty :)
<BasicPRO> never try to do serious work from a coffee house hotspot!
<jaypipes> Hello Bzr gurus!  I'm having reports of performance issues when branching the lp:mysql-server repo from bzr clients 1.6 and below.  1.3 is apparently taking hours to complete whilst 1.6 is taking approximately 80 minutes.  Does anyone know of any known performance issues with either the Launchpad bzr server or slowdowns for *very large* repos like the mysql server one?  Thanks in advance!
<^_-> 09:19 < lifeless> ^_-: no probs
<^_-> 09:19 < lifeless> ^_-: hope you like the new version :)
<^_-> i do :D
<^_-> 09:20 < pygi> ^_-, what a nick xD
<^_-> hah
<^_-> :P
<gnomefreak> sorry lifeless i had to get up due to phone, what did you mean by the following:
<gnomefreak> 08:59 <      gnomefreak > bzr branch  lp:~gnomefreak/firefox-extensions/firegpg.upstream
<gnomefreak> 08:59 <        lifeless > ^_-: put the actual branch path there
<james_w> gnomefreak: I don't think that comment was directed at you
<gnomefreak> james_w: ah thanks
<Leonidas> how do I get changes from a ghost revision?
<Leonidas> I mean, I have the revision now, which has two parents:
<Leonidas> one is an actual revision and the other is a ghost revision. What to do? Just ignore the latter?
<james_w> Leonidas: yeah, I think that's all you can do for the conversion
<Leonidas> james_w: so, there are no changes from the ghost?
<james_w> well, there presumably are, but you can't know what they are without the revision
<Leonidas> uh. An add via ghost and a rename of the added file in a non-ghost revision would break the conversion totally.
<james_w> how so?
<james_w> you would just assume that the file was added in the child of the ghost
<james_w> just treat ghost parents as though they don't exist
<Leonidas> james_w: because the source file that was contributed by the ghost would not be included into the converted repository
<Leonidas> ok, I'll do that. Is there any better way for checking for ghosts than doing get_revision(id)?
<james_w> well, it obviously breaks if it's not included, but it can be included
<Leonidas> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.dirstate.DirState.html#get_ghosts
<james_w> graph.get_parent_map() does something with ghosts
<james_w> I can't remember right now, but that allows you to detect ghosts without having to extract revisions
<james_w> you are presumably extracting revisions anyway, so it may not be a big win
<Leonidas> james_w: thanks, I'll look into it.
<jam> jaypipes: I wouldn't be surprised to see pre 1.6 clients a bit slower with launchpad's 1.6 process. I *would* be surprised if bzr-1.6 clients were also slower.
<jam> I don't know of any specifics
<Leonidas> james_w: {'mbp@sourcefrog.net-20050711064100-c2eb947e0212f487': ('mbp@sourcefrog.net-20050711063455-0f0b87a770873373', 'john@arbash-meinel.com-20050709180338-33e3b5a778df9104')}
<jam> But I know we got rid of a smart request that clients 1.2-1.5 were using
<james_w> Leonidas: that's get_parent_map output?
<jam> it didn't scale particularly well, and we have a better method in 1.6
<Leonidas> james_w: this is what get_parent_map() returns
<jam> and clients 1.2-1.5 fall back to a pre 1.2 form.
<Leonidas> james_w: repo.get_parents_map()
<james_w> Leonidas: call it on the john@arbash-meinel.com-20050709180338-33e3b5a778df9104 one
<james_w> Leonidas: you'll get {} I believe
<Leonidas> james_w: yeah, you're right - thanks.
<james_w> Leonidas: "revid not in map.get_parent_map([revid])" indicates a ghost
<Leonidas> james_w: I am extracting revisions, but hg commit uses two phases: first it gathers all revisions and then it extracts them. So I'd either need to extract it twice otherwise or to cache them. But then memory rises and converting 40k revisions would propably use up quite a lot of memory.
<jaypipes> jam: yeah, that's true.  However, I am seeing reports of 1.6 clients taking 80+ minutes to branch from lp:mysql-server.  Myself, it only takes about 20-30 minutes on a good connection, but wondering if you'd heard anything of that nature?
<jam> jaypipes: Why aren't these people using shared repos... it would go down to like 1-2 minutes anyway
<jam> I haven't heard of any specific regressions like that, no.
<jam> well, until now :)
<jaypipes> jam: this is definitely using a shared repo (I assume you mean init'ing with bzr init-repo?).
<jam> jaypipes: so.. why isn't there any data pre-seeded in the repository?
<jam> Certainly if it took even 20minutes with a pre-seeded repository, I would be surprised
<jam> jaypipes: If you can reproduce it at all, you might try a "bzr -Dhpss" run to see if there is something obvious going on.
<jam> Though that is going to be a large log file
<jam> I'll be back in a few minutes
<jaypipes> jam: ok, thx for the pointer.
<Leonidas> james_w: the conversion fails pretty quickly, because it encounters files from ghost revisions which it has never seen before.
<Leonidas> maybe I can capture the changes in some other way...
<james_w> Leonidas: it sounds like your conversion is structured in an odd way
<james_w> both the ways I can think of to do it wouldn't hit this problem.
<Leonidas> the problem looks like this, I had this 4 days ago already where I was overlooking some revisions:
<Leonidas> http://paste.pocoo.org/show/82984/
<Leonidas> <pmezard>       Leonidas: the error is it cannot find the copy source file in either changeset parent
<jam> Leonidas: so you are converting *from* bzr *to* hg?
<jam> And, I presume, trying to do it so you can round trip?
<Leonidas> jam: yeah, bzr->hg currently. Most things work, just the bazaar repo is currently not working.
<jam> Leonidas: well, probably most repos don't have ghosts
<jam> one issue is that hg and git cannot handle ghosts
<jam> their revision ids are chained sha hashes
<jam> so they don't have a way to represent a ghost
<jam> Well, I suppose they could know about the sha value
<jam> and just not have it stored
<jam> but regardless, I'm pretty sure that isn't supported
<jam> so you have to figure out how you want to represent it
<Leonidas> no, it isn't.
<jam> One possibility is to just ignore parents that are ghosts
<jam> just pretend they never existed
<Leonidas> thats what I'm doing now
<jam> That would cause some issues with round-tripping
<jam> but if you have to keep an alias map anyway
<jam> (this revision id maps to this sha1 hash)
<jam> you might be able to also keep a list of ghosts, and track what revisions pointed to them.
<jam> Leonidas: if you have to grab the whole ancestry in order to convert, you may want to look at
<jam> Graph.iter_ancestry()
<jam> It has a slightly different api, in that it returns ('revision_id': None) for ghosts
<jam> rather than silently omitting them
<jam> But it would be a way to collect all the revision ids for the ancestry, and determine ghosts in one pass
<jam> and then you could start using "get_revision(revision_id)" to actually extract the revision texts
<Leonidas> jam: is there anything else besides ghosts that could make problems?
<Leonidas> (ok, directories)
<jam> Leonidas: we track directories and they don't
<Leonidas> jam: i'm already filtering out directory changes
<markvandenborre> I'm developing a simple web app (using the django framework), and I wonder about the best way to put that into version control
<markvandenborre> it's mostly a very simple thing
<jam> Leonidas: also we represent renaming a directory as just that "mv dir/ dir2/"
<jam> Leonidas: I believe hg represents it as a contents move
<jam> so mv dir1 dir2 => mv dir1/* dir2/*
<markvandenborre> but I wonder what I should do about server specific configuration information
<jam> so there is a bit of translation you have to do
<Leonidas> markvandenborre: heh. I'm doing the same :)
<jam> Again, if you are planning a 1-way conversion, it is a lot cheaper than if you plan on round-tripping the data
<jam> markvandenborre: So the common way to do it
<jam> is to have a "foo.conf.template" file
<jam> and version *that*
<Leonidas> jam: It probably is a file move.
<jam> and then individual people copy that to "foo.conf" and modify it
<markvandenborre> jam, thx for that suggestion
<jam> Leonidas: I just wanted to point out that you have to translate it. And if you wanted to *round-trip* the information, then you need a way to detect it on the way back
<jam> Especially given that you can rename a directory with no contents...
<jam> But if you just want to get the data out
<jam> I'm curious why "bzr fast-export | hg fast-import" is not sufficient
<Leonidas> jam: But I am not sure whether I am really going for roundtrip functionality, because somehow I would never get the same repo out as the one I started with.
<Leonidas> jam: no hg fast-import.
<Pilky> is there any particular reason why the "Branched x revision(s)" text at the end of a 'bzr branch' operation is sent as an error and not output?
<Pilky> *not regular output
<Leonidas> jam: at least nothing integrated. There is hg-fast-export by the git folks and hg-fast-import by someone else.
<Leonidas> jam: after I get the convert bzr to run fine, I might thing about fastim-/export. Maybe it can be plugged into the ConvertExtension, which would be quite elegant.
<Leonidas> (but probably everything but fast)
<jam> Leonidas: I think the big win is having a common stream format
<jam> which allows everyone to play together
<jam> even if it can be a bit lossy
<Leonidas> jam: I agree. This is why I'd like to plug it in into ConvertExtension, which is the common conversion API in mercurial.
<CardinalFang> Hi all.
<CardinalFang> On the machine that holds our "trunk" branches, I have some automated voodoo that scans the trees occasionally and updates our bug database.
<CardinalFang> My problem is that new work on the trunk, where the developer has to run "bzr merge", changes the order of the revisions, and I can't easily tell what is new.
<luks> are you using bzrlib directly for this?
<CardinalFang> Do I have to keep state?  seen_revision_ids = load_from_history()
<CardinalFang> luks, No, I'm not.
<CardinalFang> luks, Though, I'm not above that.
<luks> hmm, I'm not sure how to do that using the command line
<james_w> CardinalFang: you store the revision id of the tip last time you scanned?
<CardinalFang> james_w, yes, I have that.
<luks> using bzrlib you have basically two options: use the post tip change hook (if you are using a smart server), remeber the revision id you last scanned and then check the difference in ancestries
<james_w> CardinalFang: and what info do you want? is log sufficient?
<james_w> does "bzr log -r last_revid.." do what you want?
<james_w> ah, but that will give you last_revid again
<luks> I wouldn't expect ranges to work "correctly" on non-mainlien revisions
<CardinalFang> james_w, I get too much.  A dev branches trunk, works for a while, commits.  Tries to push, then merges from trunk, commits, pushes.  The "log" output has everything between branch and merge-commit as part of his change history.
<james_w> CardinalFang: I'm not how to do it from the UI
<Discerer> hey! is there a trac-like alternative for bzr?
<Discerer> except launchpad
<luks> there isn't, as far as I know
<luks> but there is a bzr plugin for trac
<sohail> anyone know the cause of this: C:\ssci-code>bzr pull -v
<sohail> Using saved location: sftp://sohail@10.0.2.101/home/sohail/bzr/code/master/
<sohail> bzr: ERROR: Unable to connect to SSH host 10.0.2.101; EOF during negotiation
<james_w> sohail: "ssh 10.0.2.101 true"
<james_w> oh, windows, sorry
<sohail> james_w, huh?
<luks> and also sftp, not ssh
<sohail> yes windows...
<james_w> I'm not sure how to debug that.
<luks> bzr version should give you a location of a log file, anything interesting in thate?
<james_w> sohail: can you see if there is anything relevant at the end of ~/.bzr.log
<sohail> james_w, luks http://rafb.net/p/Az9DVs62.html
<luks> plink might be the problem
<luks> try `set BZR_SSH=paramiko`
<luks> and then run bzr pull
<luks> at least I know sftp uses this variable too
<luks> er, s/I know/I think/
<sohail> ok let me try
<sohail> luks, http://rafb.net/p/xkyUoi65.html :-)
<luks> parimoko
<luks> it should be paramiko
<sohail> oops
<luks> but I wonder what are the " I'm still here waiting for something to do..." lines :)
<sohail> luks, probably tortoisebzr
<sohail> that worked!
<luks> oh
<sohail> so I guess I should set the environment variable
<luks> I thought it was supposed to use paramiko by default
<sohail> I vaguely remember futzing around with BZR_SSH before
<luks> I'm not sure why it doesn't
<luks> there were some problems with using plink
<sohail> well atleast there is a workaround! thanks for your help :-)
<luks> no problem
<james_w> was it someone here who wrote setuptools_bzr?
<luks> barry warsaw wrote that, no?
<james_w> ah yes, apparently
<Leonidas> james_w: I still have issues with the ghost revisions which introduce unknown changes. Take the example of revision 2 which has two parents: rev 1 and a ghost revision
<Leonidas> ghost revision adds a file; revision 3 renames this file.
<Leonidas> so how to get the file?
<luks> it will probably appear in r3 as added
<james_w> Leonidas: you should consider it added in r2
<james_w> how do you detect when files are added?
<luks> oh, right, r2
<james_w> if you import revisions as snapshots then it should guess that it was added in r2
<luks> I misread the original sentence
<Leonidas> james_w: I am doing iter_changes between the revision and its parents.
<james_w> if you import then as diffs then you provide a diff from r1 to r2, which will show the file as added, even though it was really added in the ghosts
<Leonidas> james_w: so when I ignore the parent that is a ghost, I'm not doing that particular iter_changes that includes the rename
<james_w> Leonidas: I don't see how you are missing the rename by ignoring the parent
<james_w> doesn't iter_changes(r1, r2) show the file being added?
<Leonidas> james_w: I'm not sure. I have to construct such a repo with ghosts first, because bzr.dev is too big to be used for testing.
<james_w> Leonidas: just tree.add_parent_id('ghost')
<james_w> tree.commit("message")
<james_w> I think
<james_w> after an inital commit I think
<Leonidas> james_w: but I need to add the file in the ghost revision...
<james_w> Leonidas: ah, true
<james_w> though bzr is snapshot based, so I don't see what difference that makes
<abentley> jelmer: ping
<jelmer> abentley, hi
<abentley> Hi jelmer.  How bad would it be if BzrDir.sprout didn't use Branch.sprout?
<jelmer> abentley, it would mean I would have to overload BzrDir.sprout, probably :-)
<jelmer> abentley, other than that, shouldn't be a big deal (for bzr-svn, at least)
<abentley> This is a problem related to stacking.
<jelmer> what are you trying to use instead?
<abentley> We want to be able to branch from a format that doesn't support stacking into a format that does.
<Leonidas> james_w: the problem is that I am missing some changes and I suspect this is due the fact that I ignore all changes that come from ghosts. I'm currently reading the tests on how to create such a small repo for testing.
<abentley> But Branch.sprout will use the source branch's format.
<abentley> jelmer: I am using Repository.fetch, BzrDir.create_branch, Branch.copy_content_into, Branch.set_parent_info.
<jelmer> abentley: In my case, I'm using a different format
<abentley> I guess that's actually BzrDirFormat.create_branch
<jelmer> abentley, But still using sprout
<jelmer> abentley, cloning_metadir() returns 'rich-root-pack' for svn BzrDirs
<abentley> Cool, and we'll respect that unless user passes --stacked, and we have to upgrade the format.
<abentley> jelmer: So is SvnBranch.sprout creating a BzrBranch6?
<jelmer> abentley: it's calling self.bzrdir.create_branch()
<jelmer> (so doesn't bother with formats at all)
<abentley> jelmer: I would expect that to create a subversion branch.
<jelmer> abentley, you can't create a standalone subversion branch
<jelmer> not in a .bzr/ parent dir, at lesat
<abentley> jelmer: sure.  So why doesn't that raise an exception?
<jelmer> abentley: sorry, my bad
<jelmer> abentley, it calls target.create_branch()
<jelmer> not self.bzrdir.create_branch()
<jelmer> and target will be whatever it's copying into, usually a rich-root-pack bzrdir
<abentley> jelmer: That's basically what I want BzrDir.sprout to do, but the Bazaar implementation uses the source metadir format, not the target.
<abentley> jelmer: So maybe we should just break compatibility and require Branch.sprout to take a format parameter?
<jelmer> abentley: Sounds sensible to me
<Leonidas> james_w: is it possible that a ghost does introduce any changes? I took a look at test_revision.py, make_branches() and the B tree does not seem to get any actual changes from the A tree, just a seemingly random parent_id.
<james_w> Leonidas: well, there is no point in specifying any changes, as there is nowhere to store them
<abentley> Leonidas: It's possible for any revision does not introduce any changes.  This includes ghosts.
<james_w> Leonidas: and as it's snapshot based you can just consider any changes to be included by the child in your case
<Leonidas> james_w: sounds logical. Maybe the problem is somewhere else.
<hsn_> what are stacked branches?
<jam> jelmer: since you have a 0.4.11 release, do you need me to package it?
<jelmer> jam, it's probably worth waiting for the final release (only released rc2)
<jam> oh, I guess it is 0.4.11rc2
<jam> I'll give it a shot anyway
<jelmer> there was a typo in the announcement saying it was 0.4.12
<jelmer> sending out release announcments at 5 AM is a bad idea, apparently
<jam> a lot of things are a bad idea at 5 AM
<jelmer> wasn't that the whole reason for dvcs in the first place?
<jam> To not send release announcements at 5 am?
<jam> :)
<jelmer> (-:
<jelmer> I meant being able to commit drunk without bothering anybody
<jam> jelmer: I just merged lp:bzr-svn and I don't see a 0.4.11-rc2 tag
<jelmer> looks like I forgot that as well at 5 AM..
<jelmer> please try again
<jelmer> or use -r1667
<jelmer> not sure how lp mirrors these days
<james_w> jelmer: what versions do you want in Intrepid?
<jelmer> james_w, I assume the aim is to have 1.6 in intrepid?
<jam> jelmer: if you pushed to bzr+ssh, I should get the same copy, I believe
<jelmer> in that case, 0.4.11
<james_w> jelmer: bzr 1.6, bzr-gtk 0.95, latest of everything else
<jelmer> james_w, yeah, 0.4.11 then
<james_w> jelmer: cool, if you could get that in experimental tonight it would make things much easier.
<jam> well, he'd have to actually *release* it :)
<james_w> I can get all the sync requests filed tonight, and then find a bzr fan with upload rights to ack them all, and then should sneak in for FF.
<jam> jelmer: "bzr tags --show-ids -d lp:bzr-svn" shows no 0.4.11~rc2
<james_w> ah, I misunderstood.
<jam> He has 0.4.11~rc2 released
<jam> so he's close
<jam> And it *is* the one that matches bzr-1.6
<jelmer> james_w, I might not make 0.4.11 tonight, but rc2 should be fine as well (and is already in experimental)
<jelmer> jam: I'm pushing to http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<james_w> jelmer: cool, thanks, it's just sorting out -gtk then I think
<james_w> we should also consider backporting fixes to 1.6 as they come up so we have something solid
<jelmer> james_w, bzr-gtk should already be ok in experimental
<james_w> yeah, but there was an ubuntu upload, I need to check we can overwrite it
<jam>  jelmer: did we get packages for bzr-gtk?
<james_w> I think you had all the fixes upstream
<jelmer> jam, in ppa, not anymore I think
<jelmer> james_w, Yeah, I think I looked them up at one point
<jam> jelmer: I'd like to get the basic plugins packaged into the ~bzr ppa if possible. I was told that you were the one who did bzr-gtk last time.
<james_w> I would have stopped the upload, but it was his first contribution, so I let it go
<jelmer> james_w, That's one of the things that could really improve, Ubuntu developers should send patches upstream (to Debian and further upstream)...
<james_w> jelmer: yeah, I agree
<jelmer> jam: I do most of the uploads of bzr-gtk for debian these days, it's been a while since I've uploaded it to ppa
<jam> jelmer: it would be nice to have it done one way or another
<jam> I seem to be taking up a bit more ppa activity lately if you need me to
<jelmer> jam: I'm happy to help out now, but I'd rather not commit to keeping it up to date
<jelmer> jam, Would updating it be a part of the bzr release process or is there somebody responsible?
<jam> I don't know of anyone strictly responsible
<jam> I'm considering doing it as part of the bzr packaging
<jam> Though some of it still falls to the individual groups
<jam> The big ones are bzr-svn, bzr-gtk, and bzrtools
<jam> I'd like to at least get those packaged together
<jelmer> yeah, I agree that'd be useful
<jam> I keep using a bogus debian version for your code... :(
<jam> First I used "bzr-svn-*"
<jam> and then I forgot the "-1"
<jam> I'm glad I wrote "bzr uncommit"
<jelmer> btw, you may want to merge from the debian branch instead rather than the main bzr-svn branch - that should get you the packaging changes as well
<jelmer> jam: :-)
<jam> jelmer: where is the debian branch?
<jam> (IMO, this is one of the reasons to have *separate* branches for code versus packaging, but I somewhat understand your ideas)
<jelmer> http://bzr.debian.org/pkg-bazaar/$PACKAGE/unstable
<jelmer> jam, I've uploaded bzr-gtk to the hardy ppa
<jelmer> and lp:~bzr/bzr-gtk/ppa-hardy
<jam> jelmer: your unstable package lists: +bzr-svn (0.4.11~rc1-3) experimental; urgency=low
<jam> I'm a bit surprised it isn't ~rc2-1
<jelmer> Looks like I've forgotten to push it out to bzr.d.o yesterday night
<jelmer> r312
<jam> lots of things missed at 5 am, I guess :0
<jelmer> Yeah, I'm surprised it didn't turn out to be a brown bag release (-:
<jam> jelmer: so how do we get packages for feisty/gutsy/dapper for bzr-gtk?
<jam> Are there packaging branches for it?
<jelmer> not yet, I got distracted into fixing autoppa again :-)
<jam> jelmer: so why is the branch "ppa-hardy/debian" when there is no source tree, (so it is like the packaging-hardy in bzr)
<jelmer> jam: hysterical raisins
<jelmer> or perhaps it's an evil plan by james to make sure all corner cases in builddeb get tested :-P
<jam> so... I'm willing to clean things up and create the gutsy/intrepid packages
<jam> But I'm not 100% sure what that entails
<jam> the dependencies would all be the same, right?
<jam> And how do you decide between "hardy-ppa" "ppa-hardy" and "packaging-hardy" ?
<jam> (My personal pref is probably ppa-hardy so that the branches show up together in listings)
<jelmer> jam: Yeah, the dependencies should be the same
<jam> and ppa is shorter that "packaginG"
<jelmer> jam: ppa-hardy seems like a better choice to me as well
<jelmer> also makes it clearer to distinguish from the packaging branches used for debian and ubuntu
<jam> I wonder what the deps change to for ~dapper1, I suppose I can peek at the ~dapper packages for bzr
<Odd_Bloke> jam: Just caught up with email, good job on 1.6. :)
<evarlast> anyone using sftp on win32? I installed pycrypto  and paramiko, but it just hangs when I push.
<jam> evarlast: do you have putty installed and on your path?
<jam> You might try using
<jam> set BZR_SSH=paramiko
<jam> before running your command
<jam> (otherwise it may detect plink and try to use it)
<aidos> hello everyone
<aidos> i was wondering, is there a smarter way to remove a remote branch than ssh -> rm -f myBranch/ ?
<evarlast> jam: thank you.
<aidos> about my branch question, no ideas?
<jam> jelmer: Is there any reason to have these packages depend on "quilt" ? We don't use it at all
<evarlast> jam: I think it was defaulting to paramiko, because I do have plink and cygwin ssh in my path, but initially it was not using those and was complaining about failing to import paramiko
<jelmer> jam: When there are changes that are not upstream, we use quilt
<jam> evarlast: You have to have paramiko for *sftp* support, but it is also an *ssh* provider
<jam> jelmer: but... this is bzr-gtk and bzr
<jam> When are there changes that are not upstream?
<jelmer> jam: Yes, but the Debian packages have all carried patches that weren't upstream at some point
<evarlast> plink would be ideal, since I do have putty ssh-agent running
<jam> evarlast: paramiko can talk to pageant
<jelmer> jam: Sometimes Debian-specific, sometimes important bugfixes that were cherrypicked
<jam> And plink has some known issues handling user interaction
<luks> I wonder why it's enabled by default again
<luks> this is the second person today having a problem with it
<jam> luks: we've talked about getting rid of that, just haven't gotten there
<evarlast> "plink host ls " works perfectly and shows me a directory listing, so that is a great first step.
<evarlast> will more -v's on my bzr push command give me more verbosity?
<luks> well, it was disabled for some, and then enabled earlier this year
<luks> *for some time
<jam> luks: we added "-batch" because it at least doesn't hang prompting for a password, and people thought it was "safe" again.
<luks> ah
<jam> jelmer: any idea what the depends line would look like for bzr-gtk~dapper
<jam> luks: now, it just fails right away
<jam> which at least isn't hanging...
<jelmer> jam, not sure - the same one as in hardy doesn't work?
<jam> evarlast: generally no
<jam> jelmer: python-central versus python-support I believe
<jam> jelmer: I know it doesn't for bzr
<jelmer> ah, right
<jam> The history of bzr-gtk/ppa-hardy doesn't seem to include any time of python-support
<jelmer> not of the top of my head, would be worth checking what's different between bzr/ppa-{dapper,hardy}
<jelmer> yeah, bzr-gtk's package in Debian was created after the python policy changes
<jam> yeah, I checked on that
<jam> I'll do something
<jam> and if someone complains, I'll fix it
<jam> I don't have a dapper install anywhere
<jam> and not really worth a virtual host
<jelmer> yeah, same here
<jam> well, ~dapper1, ~gutsy1, ~intrepid1 all uploaded for bzr-gtk
<jam> We'll see if I've made mistakes
<jam> Intriguing that nobody complains about no bzrtools other than ~hardy1
<Odd_Bloke> I guess it's because bzr and bzrtools are so often out of sync (IME) that people have started installing bzrtools in ~/.bazaar/plugins.
<Odd_Bloke> Out of sync in terms of packaging, of course.
<jam> jelmer: so is 'autoppa' meant to automate some of this stuff?
<jam> (releasing a package for multiple platforms, etc?)
<jelmer> jam, yeah
<jam> wow, 1 day and already bug #261614
<ubottu> Launchpad bug 261614 in bzr "Stand-Alone version for 1.6 for Windows" [Undecided,New] https://launchpad.net/bugs/261614
<jelmer> jam, it still doesn't work for me though
<jam> sombody is antsy
<jam> Not sure I would claim that as a bug...
<jam> Maybe I should mark it "won't fix" ;-)
<luks> well, it's a missing feature :)
<jam> ah, so wishlist then
<evarlast> jam: thanks for the help.  I thik paramiko was finding cygwin ssh before it was finding plink. I run in a cmd.exe instead of a cygwin shell and I was able to push my branch successfully.  thank you so much for your help.
<jam> mark1: bug 261614 is for you, btw :)
<ubottu> Launchpad bug 261614 in bzr "Stand-Alone version for 1.6 for Windows" [Undecided,New] https://launchpad.net/bugs/261614
<evarlast> jam: this is the second time you were great help to me, so IMO, you are a selling point to use BZR over another DVCS :)
<jam> thanks evarlast, always happy to help
<jam> jelmer: You have 0.4.11-final now?
<jelmer> jam: Yeah; no code changes though
<jam> sure, but a new package
<jam> hmm... it seems you haven't pushed your changes yet
<james_w> thanks jelmer
<jelmer> jam: yeah
<jam> vila: just pointing you at something I thought would be good for your review: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080718.152135.44280555651435908.Christophe.Troestler%40umh.ac.be%3E
<jelmer> jam, I was waiting for gnome playground to do an import of evolution to see if the speed improvements really helped
<jelmer> jam: Hopefully this means we can have 0.4.11 in Intrepid rather than having to request an exception for it later
<jelmer> jam: new 0.4.11 now pushed to bzr.d.o as well now
<jelmer> jam, sorry, I wasn't trying to create more work for you...
<james_w> jelmer: thanks for the upload
<lifeless> jam: I'd like more feedback on log
<james_w> jelmer: hey, what do you think to http://paste.ubuntu.com/40773/ ?
<james_w> jelmer: not the changelog, but the actual patch.
<jelmer> james_w, ah, I remember
<james_w> sorry you're only getting it now, I should have pushed him more to do it at the time
<jelmer> james_w, I encouraged that guy to submit it upstream, I think it's already been merged there (post 0.95 though)
<james_w> ah, post 0.92
<james_w> *5
<jelmer> yep, it's already upstream
<james_w> indeed, I've just grabbed a branch to submit it to you
<james_w> cool, so you're happy for it to be in the Ubuntu package until the next release?
<jelmer> -r597.1.1
<jelmer> james_w, yep, looks good to me
<james_w> jelmer: great, thanks. I'll try harder to avoid this in future.
<jelmer> james_w: Thanks
<jam> jelmer: I'm missing a bzr-svn-0.4-11-1 tag
<jelmer> james_w, Is seems to generally happen when people are not familiar with upstream
<vreixo> hi guys!
<vreixo> do any of you knwo how to sign a revision in bzr with a gpg key?
<james_w> jelmer: yeah, and that's more of a problem in Ubuntu as there is less concentration on specific pacakges.
<jelmer> jam: Sorry - should be there now
<james_w> jelmer: I've done bzr, bzrtools, working on bzr-gtk, and wating for bzr-svn to hit the archive, is there anything I am missing?
<jelmer> I've still got a bunch of sync requests open:
<jelmer> bzr-avahi, bzr-stats, bzr-upload, bzr-dbus, bzr-cvsps-import
<jelmer> it would be nice to have loggerhead in, once it hits experimental (not likely to happen today though)
<jelmer> loggerhead is in NEW currently
<jam> jelmer: there seems to be an "0.4.11-1" but not a "bzr-svn-0.4.11-1"
<james_w> yeah, it's a bit late, otherwise we could have gone directly with loggerhead.
<james_w> jelmer: have your requests been ACKed yet?
<jelmer> james_w, yep
<jelmer> jam, fixed
<james_w> cool, so hopefully there will be a sync run tomorrow.
<jelmer> Guess we can always request an exception for loggerhead, can we?
<james_w> jelmer: we can
<jelmer> Cool
<james_w> jelmer: do you have a copy of the .dsc you dput for bzr-svn?
<james_w> I want to check that it builds in Intrepid before filing the sync request
<james_w> or if you have a chroot, could you test?
<jelmer> james_w, http://samba.org/~jelmer/debian/experimental/bzr-svn_0.4.11-1.dsc
<james_w> perfect, thanks
<james_w> lifeless: hi.
<jam> jelmer: so... I can't build multiple distro packages, because it always regenerates the orig.tar.gz
<james_w> lifeless: do you feel like using your ubuntu-dev membership?
<jam> How do I get it to re-use one it already built?
<jelmer> james_w, I wonder if that's as hard as getting him to use his debian-dev membership ;-)
<jelmer> jam: Run just debuild (with the tarball in the parent directory)
<jam> jelmer: but I need to do it for 3 releases.... I get no help ?
<james_w> ah, and we need a core-dev really, I assumed Rob was one.
<jelmer> jam, this is the original reason I stopped uploading to ppa
<jam> jelmer: It works fine if you use a tarball rather than a tree export
<jam> I use it for bzr
<jelmer> jam: You should be able to uncommit export-upstream in .bzr-builddeb/default.conf
<jam> I just don't know how to trick bzr-builddeb into using it
<jelmer> s/uncommit/uncomment/
<jelmer> james_w, Would it perhaps be an idea to skip export-upstream if there's a tarball already there?
<james_w> jelmer: I was just going to say that it did that, but it doesn't make any sense
<james_w> it could do, the reason it doesn't is if you set "export-upstream = branch"
<james_w> then it doesn't know whether it should regenerate as the branch has moved on
<james_w> it works fine if export-upstream-revision is set, assuming the revision history of the upstream branch doesn't change in a way to break that
<jelmer> ah, right - or if you changed the tag set in export-upstream-revision
<jelmer> hmm
<james_w> yeah
<james_w> it works for the magic case you added
<vreixo> nobody knows how to sign revisions in bzr?
<vreixo> is that supported?
<jam> james_w, jelmer: What about this patch: http://rafb.net/p/yS3cLT40.html
<AfC> There's no command to fork a file into two files (with common history as far as Bazaar is concerned, right?)
<AfC> vreixo: sure it is
<jam> It means if you do --export-upstream=''
<jam> It overrides
<jam> and says you don't want to export
<jam> just use a tarball
<jam> (rather than "accidentally" using the current directory)
<vreixo> AfC: that is what we need (a bzr copy)
<vreixo> AfC: do you know how to sign revisions?
<james_w> jam: reasonable
<pygi> vreixo, :)
<james_w> not pretty, but reasonable
<pygi> vreixo, you need to have patience :P
<jam> james_w: well I could do "if export_upstream in (None, '')" if you prefer
<vreixo> pygi: hi!
<vreixo> I have...
<james_w> jam: well I mean --export-upstream=''
<pygi> vreixo, what are you trying to sign? xD
<james_w> jam: also, your patch misses a test
<jam> Well, the other is "--no-export-upstream" but it is a bit hard to wedge in
<vreixo> none, I just want to know how to sign my commits...
<lifeless> jam: minor rant on list; its not aimed at you, but its a reply to your comments so it might appear so - its not!
<lifeless> james_w: hmm?
<james_w> jam: --use-existing-tarball ?
<jam> lifeless: thanks for the heads up
<james_w> lifeless: we're trying to push bzr 1.6 and associated packages in to Intrepid, I'm after someone to confirm the sync requests so we don't miss the boat
<lifeless> james_w: link me up baby
<james_w> lifeless: we could do with a core-dev for bzr and bzrtools
<lifeless> james_w: yes, I would like to be a core-dev
<lifeless> ETIME
<james_w> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/261653
<ubottu> Launchpad bug 261653 in bzr-svn "Please sync bzr-svn 0.4.11 (universe) from Debian experimental (main)" [Wishlist,New]
<james_w> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-gtk/+bug/261645
<ubottu> Launchpad bug 261645 in bzr-gtk "Please merge bzr-gtk 0.95.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed]
<lifeless> james_w: I'll click through after brekkie
<james_w> well, the second is an upload
<james_w> thanks
<rockstar> http://pyside.blogspot.com/2008/08/quick-hgbzr-timings.html
<AfC> I take it that http://bazaar-vcs.org/BzrFileCopies implies that `bzr copy` does not yet exist?
<lifeless> AfC: right, doesn't exist yet
<AfC> lifeless: pity
<AfC> lifeless: ok, thanks
<jam> jelmer: bzr-svn-0.4.11-1 uploaded for ~gusty, ~hardy, and ~intrepid
<jam> But "~intrepid" just failed to build
<jam> http://launchpadlibrarian.net/17103846/buildlog_ubuntu-intrepid-lpia.bzr-svn_0.4.11-1%7Ebazaar1%7Eintrepid_FAILEDTOBUILD.txt.gz
<james_w> jam: probably archive skew
<jam> james_w: It seems "libsvn-dev" doesn't exist in intrepid
<jam> james_w: it seems to say "libsvn-dev depends on libsvn1-dev but that package will not be installed"
<jam> Why wouldn't it install the dependency?
<jam> Do I just need to update the "Build-Depends: " to get it to work?
<james_w> libsvn-dev 500 http://archive.ubuntu.com intrepid/main Packages
<jam> james_w: Is that supposed to mean something to me?
<jam> It looks like an apt source, I guess
<jam> but the 500 is unknown
<james_w> jam: rmadison is clearer
<james_w> libsvn-dev | 1.5.1dfsg1-1ubuntu2 |      intrepid | amd64, i386
<james_w> it was supposed to show that libsvn-dev does exist
<james_w> I'm looking in to why it is uninstallable
#bzr 2008-08-27
<jam> just to mention, it seems to say that it needs "libsvn" but that isn't going to be installed
<jam> So perhaps it doesn't install dependencies of Build-Deps ?
<jam> So you have to explicitly enumerate all of them?
<james_w> ah lpia
<jam> I don't quite understand why it wouldn't complain on ~hardy, but maybe the packages already exist there?
<james_w> subversion hasn't built on lpia in Intrepid
<jam> james_w: well, it also failed for amd64
<james_w> so it can't install the packages
<james_w> with the same error?
<jam> but it could be the same reason
<jam> james_w: essentially
<jam> http://launchpadlibrarian.net/17103816/buildlog_ubuntu-intrepid-amd64.bzr-svn_0.4.11-1%7Ebazaar1%7Eintrepid_FAILEDTOBUILD.txt.gz
<james_w> the packages are there for amd64, so it shouldn't be the same
<jam> james_w: well, it did fail, but I see what you mean from "rmadison" the packages *are* available for amd64
<james_w> strange it has built on lpia, but rmadison doesn't list them
<james_w> and it built ages ago, so it shouldn't be archive skwq
<james_w> skew even
<jam> I prefer skwq
<jam> I think that is the root cause
<jonnyde1> vreixo: regarding signing commits -- you can find information here: http://bazaar-vcs.org/ConfiguringBzr
<james_w> heh :-)
<LaserJock> does anybody know of any docs on how one might use looms with packaging?
<james_w> LaserJock: I don't think there are any yet
<vreixo> ï»¿jonnyde1: The main doubt I have is how to choose the key used to sign
<james_w> LaserJock: the NoMoreSourcePackages page gives an idea
<jonnyde1> it is chosen by your configured bazaar identity
<vreixo> sure? and it takes the email into account?
<jonnyde1> it must be exactly the same as used in your key
<jonnyde1> yes, AFAIK
<vreixo> I've tried bzr sign-my-revisions and it uses a different key
<vreixo> my identity is bzr whoami, no?
<jonnyde1> yes, it is
<james_w> it uses your default key I thought
<james_w> I think there was a bug opened on this the other day
<LaserJock> james_w: hmm yes, that does have some ideas on workflow. It seems a bit complicated though
<jonnyde1> maybe it's the default key... but I think I've read somewhere that you should have the right whoami
<jonnyde1> in fact, I'm doing it like this and it works....
<jonnyde1> but try to set it as the default key in your keystore
<vreixo> ok
<james_w> LaserJock: complicated where? perhaps we can do better?
<james_w> or just overall?
<jonnyde1> vreixo: make sure you've set the whoami identity like: "Your Name <your.name@host.com>"
<vreixo> ï»¿jonnyde1: I have
<vreixo> I had
<jonnyde1> ok
<vreixo> ï»¿jonnyde1:  $ gpg --list-keys
<vreixo> pub   1024D/1635CB33 2008-02-20
<vreixo> uid                  Vreixo Formoso <vformoso@udc.es>
<vreixo> ...
<vreixo> pub   1024D/66A4028A 2008-08-16
<vreixo> uid                  Vreixo Formoso <metalpain2002@yahoo.es>
<LaserJock> james_w: maybe complicated isn't quite the right word
<vreixo> $ bzr whoami
<vreixo> Vreixo Formoso <metalpain2002@yahoo.es>
<vreixo> but it uses the other key!
<LaserJock> james_w: maybe it's not very "packaging-like" but more "vcs-like"
<jonnyde1> so maybe it's indeed an issue with the default key....
<james_w> LaserJock: yeah, I guess. Does that apply to the "wrapped" command set outlined as well, i.e. "new-patch fix-2345" or whatever it is called?
<LaserJock> james_w: I don't think that's on NoMoreSourcePackage, but that might help
<jonnyde1> vreixo: in your ~/.bazaar/bazaar.conf you should find your identity set by whoami, I think...
<james_w> LaserJock: ah in the HCT stuff, so it's not quite the same thing
<vreixo> ï»¿ jonnyde1: it is right
<james_w> LaserJock: at the moment we are trying to build a set of VCS "primitives" that will allow us to model the workflow, and then we can evolve a set of tools on top that are more task-oriented for packaging.
<james_w> LaserJock: or, that's my hope anyway :-)
<LaserJock> mhm, makes sense
<james_w> so loom does this quite well I think
<jonnyde1> vreixo: sorry, but that's the only advice I can give you... for me it worked right from the start...
<james_w> perhaps topgit is better, but I think it's too complicated, and the task-oriented stuff will be harder
<vreixo> ï»¿jonnyde1: tanks anyway, I will try with the deafult key idea
<LaserJock> james_w: do you know of any efforts for sort of an inbetween flow, between no VCS and NoMoreSourcePackages?
<LaserJock> james_w: it seems like such a huge jump
<jonnyde1> good luck! :)
<james_w> LaserJock: well, NoMoreSourcePackages is kind of two things, there's the "No more source packages" part, which I hope we will reach by getting to a point where we don't want them in our workflow as they are more hassle than they are worth
<james_w> LaserJock: for the command set parts it will be an evolution to get those commands (possibly there will be several tools along the way), so it won't be an instant thing
<LaserJock> james_w: right, at some point we just replace, debuild -S && dput *_source.changes, with bzr push
<james_w> LaserJock: and in the mean-time you can avoid loom and use bzr if you like, handling .diff.gz as the diff between two branches, which is much the same as you have now.
<james_w> LaserJock: I hope so
<LaserJock> james_w: one of the parts that's kind of making me wonder is that, in Ubuntu at least, many developers only upload a package once or twice
<LaserJock> so I wonder what advantage all this workflow/vcs work is to them
<james_w> I'm not sure
<LaserJock> in essence, many developer may not care at all about history, feature branches, tracking patches, etc.
<james_w> but if it makes their work easier and more efficient they will "care"
<LaserJock> which makes NoSourcePackages possibly turn into a burden
<LaserJock> well, that's the part that I'm trying to get my head around
<LaserJock> how would it make their work easier and more efficient?
<james_w> so an example from an hour or so ago
<james_w> I had a sponsorship request open on lvm2 for a while, and in the meantime there were uploads to Ubuntu
<james_w> I had the packages in bzr from dogfooding my work, so I spent a couple of minutes importing the new uploads (which no-one else will have to do)
<james_w> I ran bzr merge, and got everything merged, with a couple of merge conflicts
<james_w> then committed and regenerated the request
<LaserJock> ok, so in that the advantage was bzr's merging abilities
<james_w> so, I noticed the problem and ran one command to merge the work. It was done using history, not 2-way, I got easier to deal with conflicts (in my opinion), and had the history there in e.g. annotate to work out what to do.
<james_w> if I hadn't I would have had to have download the new packages, generate a diff, apply that, got .rej files, worked out what had gone on from reading changelogs
<james_w> *I* think that is so much easier
<james_w> I know that I'm very comfortable with bzr though
<LaserJock> it is, although i'm not sure how often we get conflicts
<LaserJock> most of the time it's just download new package, re-apply patch, re-debdiff
<james_w> but when it's not it's much harder
<LaserJock> for sure
<james_w> we have e.g MoM to automate this for merges
<LaserJock> hmm, MoM-as-bzr would be interesting
<james_w> we could build similar tools for all of the cases where things fall down, like the above case of the archive moving underneath you, or we could build on top of a framework that allows to more easily do it for anything
<LaserJock> if we could just grab current Debian version, branch from MoM and work on the merge all in a bzr repo that'd be pretty sweet
<james_w> and gives the same benefits whether we are in the easy case or the hard case
<lifeless> jam: did you want a standup?
<james_w> in phase 2 we will have Debian in bzr, so it would be simply "bzr merge lp:debian/unstable/gcc" or something
<james_w> and MoM can do dry runs and publish results in the same way as now
<LaserJock> james_w: sound quite interesting
<LaserJock> can bzr make "quiltable" patch series? not sure if my terminology is quite right there, I don't use quilt
<james_w> we need to do better at explaining these benefits, as I don't think many people see where we can go with this
<james_w> yeah, it could, there's a couple of ways
<james_w> it may be a good way to go.
<LaserJock> I wonder how good collaboration with Debian would go
<james_w> one problem at the moment that merging debian/patches/* really screws you up, we need to improve that somehow.
<james_w> so converting to bzr on the way in, and then converting back when building the source package would be one way
<LaserJock> I'm kinda getting to the point where perhaps just sharing patches rather than debdiffs or DVCSs is the way to go
<james_w> so something we can easily do is provide easy ways to spit out various sorts of patches, so you would fix something in bzr, and then spit out e.g. a dpatch to forward to Debian. We can then improve on that
<james_w> thought generating plain patches is good for 90% of cases or more
<LaserJock> hmm, yeah
<LaserJock> if I were to be able to look at what the Debian maintainer is using (say dpatch) and then run something like gen-patch --dpatch that'd be really cool
<lifeless> if you use looms to manage the Ubuntu branch, thats totally doable
<lifeless> probably 20 lines of python to add a command to do that to loom
<LaserJock> rockin'
<lifeless> james_w: so the gtk one, what do you need from me? I can't upload to main..
<james_w> is -gtk main?
<james_w> nope, universe
<lifeless> oh huh universe
<lifeless> can't you upload it then ? :)
<james_w> nope
<lifeless> hmm, syncs are meant to be done by archive anyhow
<james_w> lifeless: yeah, but I needed a sponsor to ACK it for the archive admins to look at it
<james_w> well, confirm it and subscribe ubuntu-archive
<lifeless> I've commented on both
<lifeless> hmm, am I still in sponsors
<james_w> you don't need to be in the team as far as I know
<LaserJock> I'm in ubuntu-{universe,main}-sponsors if you need anything
<james_w> thanks LaserJock
<lifeless> LaserJock: if you could process https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/261653
<ubottu> Launchpad bug 261653 in bzr-svn "Please sync bzr-svn 0.4.11 (universe) from Debian experimental (main)" [Wishlist,New]
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-gtk/+bug/261645
<ubottu> Launchpad bug 261645 in bzr-gtk "Please merge bzr-gtk 0.95.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed]
<james_w> LaserJock: would you be willing to ack a couple of main sync requests as well then please?
<lifeless> I don't do enough syncs to keep it all paged in, I was just checking the current procecss
<lifeless> james_w: where is the bzr 1.6 sync request?
<LaserJock> james_w: depends on how many ;-)
<james_w> lifeless: bug 261636
<ubottu> Launchpad bug 261636 in bzr "Please sync bzr 1.6-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/261636
<lifeless> LaserJock: 3
<lifeless> LaserJock: I think thats all
<james_w> LaserJock: that one, and bug 261644 to go with it
<ubottu> Launchpad bug 261644 in bzrtools "Please sync bzrtools 1.6.0-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/261644
<lifeless> 4
<lifeless> :P
<james_w> then bzr-svn sync for universe, and bzr-gtk merge
<LaserJock> ok, so bzr-* ? :-)
<james_w> jelmer has already done all the lesser plugins and got acks, so with these four we get most-recent everything, with everything compatible
<lifeless> jam: ping
<jelmer> lifeless, if you feel like uploading bzr-search, maybe that can make it into intrepid as well
<jelmer> almost made it earlier but got rejected because of incorrect debian/copyright
<lifeless> jelmer: garh
<lifeless> jelmer: url me up I guess
<lifeless> packaging is so 1960's though
<jelmer> lifeless, http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=bzr-search
<jelmer> lifeless, are you calling me oldfashioned? :-P
<lifeless> damn thats a fugly url
 * jelmer gives lifeless a gentoo ebuild
<lifeless> shudder
<james_w> jelmer: don't you want sponsor-packages?
<lifeless> jelmer: is the package anywhere that doesn't suck arse?
<jelmer> lifeless, try http://mentors.debian.net/debian/pool/main/b/bzr-search/ instead
<lifeless> jelmer: cause that site wants me to log in 'first'. IDIOTS
<jelmer> yeah, sorry, I gave the link inside the login area
<lifeless> hmmm, I'm not in the most forgiving-of-the-universe modd today
<jelmer> lifeless, http://mentors.debian.net/debian/pool/main/b/bzr-search/ should work better
<lifeless> oh yay
<jelmer> now what ? :_)
<lifeless> stupid robots.txt defeats wget
<lifeless> manually copying urls now
<lifeless> *this* is why I don't sponsor much
<lifeless> its about 4 billion times harder than it should be
<jelmer> well, at least you *can* sponsor
 * jelmer just lost another application manager
<lifeless> !
<lifeless> are you a MOTU yet?
<jelmer> no - I don't do much Ubuntu stuff, I always work in Debian and then request syncs
<lifeless> jelmer: because its so much easier, apparently ? :)
<jelmer> it is, once the initial package is in. I probably wouldn't be using or developing for Debian if that hadn't made it
<LaserJock> if you've got packages that can be just synced it's nice to just maintain in Debian
<lifeless> jelmer: there will be a delay
<lifeless> I need to update my sid
<lifeless> oh
<lifeless> crud, other machine
<lifeless> ETOOHARD
<lifeless> the packaging looks ok, though the reference export command is stale
<LaserJock> bzr done
<jelmer> lifeless: It's mainly there to make ftp-master happy, I'll add a get-orig-source target later
<lifeless> jelmer: also it looks like you've got a bzr 1.5 deps, but it requires 1.6
<lifeless> Build-Depends-Indep: bzr (>= 1.5~)
<jelmer> lifeless, it only build-depends on 1.5, the actual dependency is on 1.6
<jelmer> I'll fix the build-dep, it should be harmless though
<lifeless> That needs a comment if its deliberate, or not to be different
<lifeless> well, the sid chroot is updating
<jelmer> lifeless: Yeah, I'm fixing it here; it's cosmetic though
<lifeless> be quite a while
<jelmer> lifeless, thanks for looking into this
<lifeless> jelmer: I'm about given up on it; another headache and it will be ETOOHARD - too much to do
<jelmer> lifeless: :-(
<lifeless> there is _so_ much beauracracy involved its insane
<lifeless> you'll still have to wait for NEW
<jelmer> please don't get me started
<lifeless> we practice crunchy shell security as far as copyright honoring goes
<jelmer> NEW's been pretty quick in the last few weeks
<lifeless> it may catch a bunch of stuff; but as all debian/copyright does is duplicate whats in the package already, it doesn't help anything
<jelmer> ...  and if a new upstream release adds weird stuff, there's no review at all from ftp-master
<lifeless> thats what I mean by crunchy shell
<jelmer> ah
<lifeless> once you're in, you're in.
<jelmer> When I think of shell, I think of "shell script"
<lifeless> its a standard description of certain risk management techniques
<jelmer> ah
<jelmer> well, nothing's perfect, but it can indeed be pretty frustrating at times..
<jelmer> lifeless, any luck getting it to build?
<lifeless> chroot still updating
<LaserJock> bzrtools done
<LaserJock> bzr-svn done
<lifeless> jelmer: sorry, I'm going to have to leave bzr-search
<jelmer> lifeless, :-(
<jelmer> beuno, ping
<lifeless> the reason I do nearly everything I do do for ubuntu is source uploads
<LaserJock> james_w: you need to remember to update the Maintainer field in debian/control :-)
<lifeless> only takes a few minutes fighting pbuilder + debbuild & deps etc and my tolerance for incoherent toolchains is exceeded
<james_w> LaserJock: damn, thanks for catching it.
<james_w> LaserJock: I presume you don't need a new debdiff?
<LaserJock> james_w: no, I just run update-maintainer
<james_w> cool, thanks
<LaserJock> however, it does dep on the newer bzr
<LaserJock> so I'm not sure if I should upload until that's sync'd
<LaserJock> I guess I could just let it fail and then somebody can hit the retry button :-)
<jelmer> lifeless, I can provide you with a pre-built package... :-)
<lifeless> jam1: are you back ?
<lifeless> jelmer: I can't upload that
<jelmer> siretart: Could you perhaps sponsor bzr-search?
<jelmer> lifeless: Why not?
<lifeless> jelmer: thou shalt not upload binaries thou didst not build thyself
<james_w> LaserJock: it should just auto-depwait shouldn't it?
<LaserJock> james_w: well, one would hope but I'm not 100% positive
<james_w> or at least manual depwait
<jelmer> lifeless: Why? Yes, I could've tampered with the binary but once the package is in sid, I can upload newer versions without intervention.
<james_w> I'd suggest just getting it in, and then fixing if we need to, but you're the sponsor
<lifeless> jelmer: its part of the stuff I agreed to when I became a DD
<jelmer> lifeless: hmm, ok
<LaserJock> james_w: uploaded
<james_w> LaserJock: great, thanks a lot
<LaserJock> james_w: though I sort of disagree with the "no longer uses a patch system" part. It still build-depends on dpatch even though it's not using it ;-)
<james_w> true, I saw that afterwards
<james_w> it's already committed upstream though, so it's not a long-term problem
<LaserJock> but without a patches/ it's just an extra dep
<james_w> yup
<LaserJock> anywhere, there's a complete bzr set
<LaserJock> which makes me happy, i got to do more than complain about things being out of sync :-)
<james_w> perfect, that puts Intrepid in good shape
<jelmer> well, the packaging spree was nice while it lasted
<jelmer> uni starts again on friday, so I guess I'll changing the remaining ones back to RFPs for now
<markh> I think I'm suffering branch overload.  One of my working trees is 4 branches away from its ultimate upstream...
<lifeless> markh: you might like looms
<lifeless> jelmer: how far did bzr-git get?
<markh> I'm not sure I need *more* bzr workflow options at this point... ;)
<jelmer> lifeless: I ended up working mostly on fixing bugs in bzr-svn
<markh> I only just use shelve for the first time the other day - wonderful :)
<jelmer> lifeless: bzr-git can now do clone/pull from git -> bzr
<lifeless> cool
<lifeless> does git keep a hot refcount for each hash?
<lifeless> or is gc a global operation ?
<jelmer> lifeless: also, tags can be set, info works and log works again
<jelmer> afaik its global but I'd have to check to be sure
<james_w> you mean does it walk the heads to find unreferenced objects?
<lifeless> james_w: if it has a list of heads that is always accurate and race free, then it has a hot refcount for objects with refcount 0
<lifeless> james_w: doing race free with loose objects will be quite a challenge though
<james_w> ah, I see
<james_w> I think
<james_w> I don't know how it does that
<jdong> May I make the suggestion for more user-friendly release notes?
<jdong> I think users are interested in something more readable than the release notes format, which seems to appeal to developers of bzr more.
<jdong> I'm thinking something in the form of Ubuntu's tours would cater better to end users (highlighting major improvements, new features, etc)
<lifeless> would you like to help write something like that? That would be really nice
<jdong> I'd certainly be glad to contribute to such an effort
<lifeless> I think we'd be happy to have release notes in such a form, as long as its contributed :)
<jdong> :)
<lifeless> jam1: ping
<abentley> jelmer: Why did handle-patch stop being a command?
<abentley> jelmer: And have you noticed it's full of tabs?
<frikazoyd> Howdy
<frikazoyd> Anyone around who can answer a quick question?
<bob2> go for it
<frikazoyd> Cool
<frikazoyd> So, I discovered Bazaar through a friend, and was thinking about moving my development/playtesting team to it.
<frikazoyd> (Mod team)
<frikazoyd> I tried installing 1.6, and everything I can find says TortoiseBZR comes with the windows install.
<frikazoyd> However, I don't see the TortoiseBZR shell integration, even after a reboot.
<frikazoyd> Is there anything special I have to do to get it working?
<frikazoyd> Ahhh, I think I found my answer.  I'm using XP 64, and an included sub-readme says that the 64 doesn't work due to packaging issues.  I guess that's my problem.
<frikazoyd> Takes asking it before you figure it out I guess, heheh.
<bob2> http://bazaar-vcs.org/WindowsDownloads doesn't seem to mention tortoisebzr, though
<lifeless> markh: what's needed for win64?
<markh> py2.6 on windows
<markh> apart from that, not much ;)
<markh> bashing the required extension modules into shape
<lifeless> is py 2.6 not on windows yet ?
<markh> pywin32 is already there
<markh> earlier py versions use MS compilers with sucky/no support for 64bits
<markh> py2.6 is using the latest MSVC and makes life easy
<markh> py2.5 on windows is at the same place on windows as any other os roughly...
<markh> 2.6
<markh> stable in my experience
<markh> FWIW, a 64bit native exectable can often see 15%ish perf improvement over running a 32bit version of the exe on the 64bit os.
<markh> frikazoyd: ah, sorry, I didn't see your comments.  Yes, 64bit toirtoise will need to wait a little while
<markh> there is a hacky work-around
<frikazoyd> Ok
<frikazoyd> Well I don't mind running the 32 bit
<frikazoyd> to be honest
<frikazoyd> but the 32 bit installer didn't install tortoise bzr
<markh> IIRC, executing "\windows\syswow64\explorer.exe /separate" should start a new 32bit version of explorer that works with toirtoise
<frikazoyd> for some reason
<frikazoyd> or it just isn't showing up
<markh> didn't install, or didn't register?
<frikazoyd> Ah, ok
<markh> right - it registered as a 32bit extension
<frikazoyd> Well it said it registered tortoise in the installer
<frikazoyd> AAAhhhhhh
<markh> only 32bit executables will see it
<lifeless> gotta love that old MS style
<frikazoyd> and my explorer is 32 bit
<markh> hrmph
<lifeless> thunk layers? We're tired of that, WoW blew chunks, lets not do that again
<frikazoyd> Yeah, I'm not a fan.  However, my hands are tied since I'm a Source modder
<lifeless> frikazoyd: oh cool.
<markh> windows supports 32bit processes via a "wow" (windows on windows) layer, which is basically a thunking playground.  It *does* support loading 32bit binaries into 64bit executables
<markh> which is what COM and shell extensions are all about
<frikazoyd> Hm
<markh> bugger
<lifeless> markh: yes, YHBTHANDHTH
<markh> s/*does*/*does not*/
<frikazoyd> Hrm, the workaround didn't let me see the shell extension
<frikazoyd> ah well, I don't mind using command line
<lifeless> markh: the 16-32 bit wow did allow OLE to work across boundaries IIRC
<frikazoyd> the bottom line is I have a ton of playtesters who will complain about using a command line, but if they can use the extension in 32 bit windows I can just write a batch script for the ones that run 64 bit.
<lifeless> markh: which is what my mini-troll was about
<markh> lifeless: yess, out-of-process COM can be marshalled
<markh> we are inproc
<lifeless> markh: can't you just set an oop registration anyway?
<lifeless> :)
<markh> frikazoyd: I admit I've never tried that workaround on 64bits - I will before the next release though.  This whole problem will go away once we move the shell extension code to c++ anyway
<frikazoyd> Okay
<markh> lifeless: shell extensions only work in-proc unfortunately
<frikazoyd> Well I've played with installers quite a bit, so if you need a hand let me know.  But I'm not much of a windows programmer, so I don't know how much help I'd be in general.
<frikazoyd> Though I'm not bad with C++ itself
<markh> a .msi would be good :)
<markh> but we need to sort out other internal packaging issues before we take on a different installer
<frikazoyd> ok
<lifeless> man
<lifeless> I so love how COM is inconsistent
<lifeless> 'its totally generic' -> except that its not
<markh> heh - for sure.  Plenty of scope for tuning etc.
<markh> but the rate of calls made to shell extensions and the blobs passed around would make an out-of-proc system struggle
<lifeless> markh: thats no reason not to -permit- it
<lifeless> markh: (also, they could fix the interface to do less work more sanely)
<markh> All the interfaces would need custom marshallers iiuc
<markh> and there are *lots* of them
<markh> all the interfaces are defined in terms of c++ structs, not nice little COM variants etc
<markh> its really just using COM as a "plugin" mechanism in some ways :)
<markh> I'm not defending things, just trying to add perspective ;)
<lifeless> markh: remember, I'm an ex-cygwin-core dev :P
<markh> lifeless: ahh, never knew that :)
<lifeless> search for robert collins cygwin :)
 * markh wonders what else has can come up with by putting various words after "robert collins"...
<lifeless> beware my evil clones
<lifeless> theres a rc writes for dr dobbs journal
<lifeless> and another in a uk python-using research job
<markh> oh - another as a porn star I see! ;)
<lifeless> oh really? cool
<lifeless> now I can get a real hackergotchi
<lifeless> :P
<fullermd> They're everywhere these days.  I think there's one stealing my name too.
<em1> good morning
<em1> cant donwload openerp's source by running 'python bzr_set.py',
<em1> wait long time and no file is downloaded
<em1> last time i can download all files
<em1> but this time after installed symlink plugin, it become calm down very much
<em1> seems that python run into a dead loop or no connection for ever
<em1> it do create a directory, but no files
<bob2> what is bzr_set.py?
<em1> bob2, it is from lp:openerp
<bob2> the 'openerp's default branch on launchpad doesn't contain openerp?
<em1> do you means the trunk?
<bob2> yes
<em1> yes, it contains only two files
<em1> one is bzr_set.py, other is a readme
<bob2> bizarre
<em1> readme file say need run bzr_set.py to fetch source
<em1> bob2, what?
<bob2> that's a bit baroque
<em1> bob2, do you have advice to detect where it go wrong?
<bob2> well, it will take a while
<bob2> you could just try checking out the code manually
<em1> how to do manually?
<bob2> look in the file, bzr_repository lists the urls it is fetching
<bob2> just "bzr branch" them
<em1> .bzr\repos...\upload have a big file sized of 27M, is it ok?
<jam> lifeless: pong
<lifeless> jam: hey
<lifeless> jam: trade you a review of log [rather than a comment] for a review of btree ? :)
<jam> sure
<em1> i report a bug justnow, dont know if it is a bug:  Bug 261733
<ubottu> Launchpad bug 261733 in bzr "crashed after i intall symlink" [Undecided,New] https://launchpad.net/bugs/261733
<jam> lifeless: btw, you asked for me to factor out the common code, but the loops really aren't the same.
<jam> I'm I misunderstanding what you are asking me to refactor?
<lifeless> oh
<lifeless> the add_node method looked like a extract from the base class, verbatim
<jam> lifeless: no, self._nodes contains different things in each
<jam> BTree doesn't need to track absent nodes
<lifeless> ok
<lifeless> have a look, see if there is enough to do something common
<lifeless> otherwise ok
<jam> I could probably extract the "_check_node" into a helper
<em1> until now, the source is downloaded but not over, why so slowly, my adsl bandwidth is 2mbps
<lifeless> em1: what url is the source coming from?
<em1> that is lp:openerp
<bob2> http://bazaar.launchpad.net/%7Eopenerp/openerp/package-script/annotate/9?file_id=bzr_set.py-20080708192342-trihj558tjhh9549-2, line 22
<bob2> (lp)
<lifeless> have you logged into launchpad?
<lifeless> in bzr
<em1> me?
<lifeless> yes
<em1> no, i dont know how to log into lp
<lifeless> ok, then it will be doing http requests
<lifeless> it should stream fast
<lifeless> if its not, its likely a ISP problem; e.g. a broken intercepting proxy
<em1> i try bzr antherproj, it finished quickly
<em1> all project do host on the same computer?
<mwhudson> yes
<em1> maybe because of openerp have very much codes to download
<em1> for nearly 2 hours, it still not finish downloading
<em1> not wonder there is a virus somewhere
<jam> Well, http://bazaar.launchpad.net/~openerp/openerp/package-script/.bzr/repository/packs/
<jam> is only a few K
<jam> but that is just the packaging?
<bob2> yeah, it then scripts branching 5 other ones
<lifeless> jam: just sent you a toy
<gour> didn't know that python is considering bzr..today on reddit http://pyside.blogspot.com/2008/08/quick-hgbzr-timings.html
<gour> is this another 'apples & oranges' benchmark?
<LaserJock> I wonder why 1.6 is often slower than 1.5
<LaserJock> although the branch time looks like a big improvement
<RAOF> jml: Oooh.  Is bzr upgrade over bzr+ssh substantially faster than sftp?
<gour> clone time is showstopper, at least, it was for ghc evaluation
<RAOF> Really?  It's essentially a one-off time, though.
<jml> RAOF: I don't have any data on that. My guess is "yes".
<jml> RAOF: because there should be fewer roundtrips and much less data being transferred.
<lifeless> LaserJock: memory
<lifeless> theres a peak memory use bug in 1.6
<gour> RAOF: yeah, it is, but although having many advantages over candidates, it was ruled out due to speed - mostly based on 'clone'
<lifeless> upgrade over either will be the same
<jml> my understanding of clone time is that 'time to branch' and 'time to build working tree' should be measured separately.
<RAOF> jml: Given bzr+ssh requires a server-side copy of bzr (IIUC), theoretical maximum performance would seem likely to be very fast.
<jml> lifeless: it just uses vfs methods?
<gour> jml: right
<lifeless> yes
<vila> jam: I'm already working on it, but thanks for the reminder
 * jml types 'bzr record "hello robert"'
<lifeless> hello jml
<jml> :)
<jamesh> apparently the command is useful for something
<lifeless> jamesh: why 4 the troll?
<jamesh> lifeless: I see value in recording the thread name -> revid state at a point in time, but the current plugin doesn't really do much with those records
<lifeless> jamesh: thats true
<lifeless> jamesh: really need 'merge' implemented
<jamesh> and I guess it'd be nice if it happened automatically at relevant points in time
<lifeless> I'm less sure about that; 'bzr push' doesn't do an implicit commit
<lifeless> I think it would weird people out majorly if it did :)
<jamesh> perhaps committing to the top thread would be worth recording
<lifeless> I'd like to have merge working robustly before looking at that sort of automation
<jamesh> or recording every commit
<jamesh> (that is slightly dubious, due to possible conflicts in higher threads)
<lifeless> right
<lifeless> or in lower threads for that matter
<jamesh> so I guess my complaints are (1) it is one more thing to remember to do during development and (2) it provides no obvious benefit right now.
<lifeless> jamesh: I agree with both
<lifeless> but trolling doesn't get merge written
<lifeless> there are benefits right now, in that is does allow revert-loom
<lifeless> but its not a great benefit
<jml> and it's made less by the fact that the only time I remember to do a record is when I'm about to push.
<jml> which basically means "before meals".
<siretart> jelmer: bzr-search uploaded, but I wasn't able to commit my changes: http://paste.debian.net/15695/ - what's going on here?
<techtonik> Does bzr support branching from subtrees of original repository or I always need to copy whole directory tree when branching?
<lifeless> thumper: always full tree
<siretart> jelmer: and I uploaded to experimental, since it seems to depend on bzr 1.6, which is not available in unstable
<lifeless> techtonik: ^
<thumper> lifeless: morning
<techtonik> lifeless: Thanks for quick reply. But if the whole tree is too big to copy and I need only a small part (plugin) to work on - what should I do?
<james_w> siretart: you would need a --rich-root-pack repo for the local checkout of bzr-search, as the alioth repo is in a rich-root format
<james_w> siretart: would you be available for an upload of builddeb later today?
<lifeless> techtonik: you can skip copying all the deep history by using branch --stacked, or checkout --lightweight; if the current tree is simply too big; well buy a new hard disk?
<lifeless> techtonik: we have a planned feature to help, but its planned not implemented
<lifeless> hi thumper
<lifeless> ok, bzr-search rockage :)
<lifeless> robertc@lifeless-64:~/source/baz/log$ time ./bzr log ../bzr.dev -m "robert" > /dev/null
<lifeless> real    0m12.357s
<lifeless> robertc@lifeless-64:~/source/baz/log$ time ./bzr log ../bzr.dev -m "\brobert\b" > /dev/null
<lifeless> real    0m4.706s
<siretart> james_w: sure
<james_w> siretart: great, thanks
<techtonik> lifeless: The current tree is about 900Mb (lp:codeblocks) - not much for an HDD, but too much for my internet limits.
<lifeless> 900MB for the working tree? or the full history?
<techtonik> Working tree only/
<bob2> they eclipsed eclipse!
<lifeless> jeepers
<lifeless> thats...insane
<techtonik> Actually 450 Mb as it is SVN checkout, but still too much.
<bob2> how on earth is it all in one branch?
<bob2> the full linux binaries are 20MB
<siretart> james_w: just tell me what is the up-to-date branch I should upload. and do you want it for unstable or experimental?
<techtonik> SVN import - that is.
<james_w> siretart: experimental and intrepid, if you don't mind, to save a sync delay.
<james_w> siretart: I don't have a branch yet though, I still have some work to do.
<siretart> james_w: ah, okay.
<techtonik> UFO:AI repository with media files takes even more than 1Gb
<techtonik> I've got a problem with bzr merging. Since I didn't want to copy whole repository I just recreated directory structure, manually copied files for the plugin from the main trunk and started my own branch.
<techtonik> Now I can't merge changes from the main trunk into my branch, because they do not have any common ancestors in bzr.
<techtonik> When I supply some "-r BASE..LAST" revision argument to merge, then bzr comes up with a lot of conflicts. http://pastebin.com/m75a6caa6
<techtonik> I wonder how can I resolve them? The ones about unversioned directories, for example.
<bob2> well, you could start over and re-add everything with the same id's as are used in the trunk
<bob2> but that's not a huge amount of use
<techtonik> Does that mean I will lose all the history?
<bob2> which history?
<bob2> well, yes, either way
<techtonik> Ok, I suppose it is the only way. So, how can I add everything with different id's so that the subsequent merge will be successfull and will not pull all other files from main trunk into my subtree?
<lifeless> jelmer: done a 1.6 bzr search release
<jelmer> abentley, was required to be able to register it as a mime type handler
<jelmer> siretart, thanks!
<jelmer> lifeless, ok
<techtonik> So, Bazaar doesn't have partial checkouts? =/
<lifeless> the answer hasn't changed from earlier :)
<lifeless> its planned
<lifeless> not implemented
<awilkins> ls
<awilkins> Oops
<lifeless> ['.', '..']
<awilkins> Is there a plugin that will snapshot a workspace of multiple trees so you can check out the same thing elsewhere?
<lifeless> multiple trees?
<awilkins> Multiple branches or checkouts
<lifeless> like nested, or same project or ...?
<awilkins> Say - an eclipse workspace containing multiple branches
<awilkins> The workspace is not a branch, but the projects inside are
<siretart> awilkins: check 'config-manager'
<awilkins> I knew I'd seen something
<awilkins> Isn't that your project, lifeless?
<lifeless> yes
<lifeless> but its about trees, not branches :P
<lifeless> awilkins: probably needs some love to do what you want, but yeah config manager is what you'd want for N branches of the same project
<awilkins> It's more 1 branches of N projects
<lifeless> that sounds more like nested trees to me then
<awilkins> Not in the same tree
<lifeless> cm still applicable
<awilkins> Siblings in a container
<awilkins> Like an eclipse PSF file
<awilkins> psf == cm recipe
<awilkins> Is it just a straight file?
<awilkins> Or is it versioned so you can do things like merge it from other workstations?
<lifeless> cm doesn't care
<lifeless> you can version if if you want :P
<awilkins> Would it handle switches?
<awilkins> e.g. you switch the branch on your workstation, you sync cm recipe on laptop, cm switches to same branch ?
<lifeless> it has a switch command
<lifeless> its not well maintained cause I've been putting it of for nested trees
<awilkins> Fair enough
<lifeless> but I may need to give it some love
<lifeless> anyhow, yeah poke at it
<Peng_> beuno: Shouldn't Loggerhead's /static/ URLs generate Expires headers and stuff?
<beuno> Peng_, maybe. I don't know that much about http voodoo
<lifeless> Peng_: they all should; mwhudson is working on it
<Peng_> lifeless: Yeah, I just saw that bug. Maybe I should add a comment to remind him about the static stuff?
<lifeless> sure
<Peng_> Wow, changing that is actually a one-line patch.
<Peng_> Is there any point to GPG-signing a very trivial email, with an untrusted key? :)
<EarthLion> erm i have an issue where bzr doesn't seem to be recognising 2 new files that have been created
<luks> which command specifically?
<EarthLion> when i commit it says there are no changes
<EarthLion> when there clearly are
<luks> and diff shows changes?
<luks> or status
<EarthLion> diff shows no changes
<luks> er, wait
<beuno> maybe they're ignored?
<luks> they are new files, did you add them?
<luks> `bzr add`
<EarthLion> nope they were created by a web application
<luks> then you need to add them first
<EarthLion> expression engine saves new templates as templates
<luks> bzr add path/to/file
<EarthLion> i thought it did that automatically though?
<Peng_> It does not
<luks> no, it doesn't
<luks> bzr status should also tell you about unknown files in the working tree
<EarthLion> thanks i can see the file now
<EarthLion> can you set it up to automatically add new files?
<luks> I think there was a patch to add an option to bzr commit to do that, but it was rejected
<EarthLion> that seems v.odd that it isn't there
<EarthLion> i presumed it did that automatically
<EarthLion> in a project files are always being added...
<luks> I don't know about others, but I usually have files in the working tree I don't want to version
<EarthLion> so I have to manually add all new files?
<luks> you can just run 'bzr add'
<luks> it will add all unknown files
<EarthLion> ah ok thanks luks
<EarthLion> excellent thanks for the concise information :)
<luks> http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/45138 is the ML thread, btw
<EarthLion> thanks a lot :)
<techtonik> If I can't make a partial ceckout, can I download a part of a tree without version history?
<lifeless> I think my patch allowing 'export target branch/subdir' is in 1.6
<techtonik> doesn't seem so
<techtonik> bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk
<techtonik> bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src
<techtonik> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src/".
<techtonik> Bazaar (bzr) 1.6
<techtonik> lifeless: Is there other way to get some subdir (which is not branch) from repository without redownloading whole repo or manually downloading separate files one by one from web interdace?
<lifeless> techtonik: well, bzr.dev should do bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src
<lifeless> and there will a new loggerhead sometime soon that can export subdirs
<luks> techtonik: is it really a problem to download ~60MB of data?
<techtonik> luks: Yep. 1.5$ for every 60Mb is too much if you are on ADSL and 3.5 hours is too long if you are using Dial Up or GPRS modem
<luks> ouch :(
<luks> and I thought my connection was expensive
<jam> vila: Just to make sure, Robert is discussing a "trie" not specifically a "tree". http://en.wikipedia.org/wiki/Trie
<jam> I haven't gotten through all of your email yet, though.
<vila> jam: hmm, did I missed the *whole* picture again ? AIUI he want to use hash tries or B+ trees, but in both cases the inventory is still represented as some sort of tree, so I think hash trees (as I called them) are still more or less in the subject even indirectly
<vila> wtf ? plugin.gtk.test prompting me during selftest ???
<vila>  (55, 'select/poll returned error') now, some have decided to die *today* :)
<vila> s/some/some bugs/
<lifeless> vila:  a trie is a radix tree
<jam> vila: Just to discuss my understanding of his proposal... lifeless proposes that you can use "apply_delta" to update a hash trie without needing to look at the whole tree
<jam> So if you already have one built
<lifeless> vila: a hash trie is variation of a trie
<jam> you can build the next without doing O(tree)
<jam> lifeless: are you even really proposing a "hash trie" ? I thought it was just a trie using paths and file_ids as the keys
<jam> not the hashes of those
<vila> yet the proposal want to address some performance issues for operation that are O(tree) instead of O(changes) which, has we discussed in London can be addressed with hash trees (as *I* called them).
<vila> If I'm wrong on that point, then forget the related remarks in my review :)
<lifeless> jam: I'm investigating the properties of several designs
<lifeless> jam: one is a radix tree of the hashes of the file ids
<lifeless> one is a plain radix tree
<lifeless> on the full paths of the entries
<lifeless> another is directory based, with large directory decomposed into internal trees
<jam> vila: I think what you call "hash tree" lifeless calls "recursive validators" which he plans for any of them
<jam> CHK == content hash key
<jam> So the individual pages are referenced
<jam> based on their content hash
<jam> lifeless: so why use hash(file_id) just to get a more even distribution?
<vila> jam, lifeless: CHK haaa, then the document needs to define the term
<jam> vila: "validator(x)" is generally just secure_hash(x)
<jam> he mentioned it earlier
<jam> I don't know if it missed the last draft
<jam> Who just built and uploaded the windows installers?
<jam> Did Markh do it overnight?
<markh> not over my night ;)
<jam> I just see "TommiVainikainen" updating the wiki, which isn't a name I recognize
<markh> over my day tho, yeah
<jam> thanks markh
<jam> Just make sure to make a note of it :)
<markh> I did rc5 and noone complained it didn't work for them, so I figured it was good to go!
<markh> where? :)
<LarstiQ> hehe :)
<markh> I'm afraid noone pointed out a process I should follow - martin just said "upload it there" :)
<markh> hi LarstiQ!
<LarstiQ> heya markh
<jam> markh: well, sending an email to the list is reasonable, updating http://bazaar-vcs.org/Download and WindowsDownload
<LarstiQ> markh: I've still got to figure out that list of music for you, it's pending, sorry :/
<jam> also, I linked a bug to you yesterday
<jam> someone filed a complaint that the installers took longer than a day to build...
<LarstiQ> what?
<LarstiQ> as in, start the build, and wait for a day?
<LarstiQ> Or are they complaining the installers are uploaded a day after the release?
<LarstiQ> If so, pssh.
<jam> bug #261614
<ubottu> Launchpad bug 261614 in bzr "Stand-Alone version for 1.6 for Windows" [Undecided,New] https://launchpad.net/bugs/261614
<lifeless> jam: hashes give a homogenous fan out, which is good
<jam> not sure whether to mark it Invalid because it isn't a bug, or Fix Released because we have the installers
<jam> I went with Invalid for now
<markh> jam: so I'm in trouble for not doing it fast enough, or not waiting long enough to follow the correct processes? ;)
<jam> markh: well, I feel like reporting a bug for it, versus just an email/request is a bit ... excessive
<jam> markh: I just didn't have anything alerting me that it happened
<markh> jam: right, yeah, I agree - but you know users - we have nothing better to do than serve them :)
<markh> yeah - we probably need a slightly more formal process, and I'd be happy to follow it
<markh> I wasn't sure exactly when you "turned the crank" for the release etc.  For the sake of a day or so, we could probably coordinate more closely next time
<jam> markh: Well "doc/developers/releasing.txt" is my checklist for tarballs, and ".../ppa.txt" is what I use to make debs
<jam> markh: I'm fine with a 1-2 day turnaround
<lifeless> jam: also, it caps the depth of the keys, tries have a property of O(1) for a given key set - its a high, but constant number of steps (read every bit in the key)
<jam> We could certainly create a "windows_installer.txt" file and put it in there
<lifeless> so capping the key length reduces the constant
<jam> lifeless: It would be interesting to do comparisons between hash(file_id) and file_id
<jam> as one allows a bit of grouping
<jam> Which may or may not give locality of reference
<jam> also, bzr's default algorithm for file ids is
<jam> NAME-DATE-RANDOM-COUNTER, where DATE-RANDOM is fixed for everything during one "bzr add"
<jam> which probably means you just end up with a long string that doesn't help, because NAME has already messed up your common prefix
<lifeless> jam: right
<lifeless> jam: thats one reason I am looking at hashed file ids as keys
<jam> Yeah, I wonder if the 1/256 fan-out is going to be optimal in all cases
<lifeless> a CHK pointer
<lifeless> a kind
<lifeless> say another 4 bytes
<lifeless> so 45-50 bytes per pointer
<jam> would you use binary/hex/base64 for the serialized key?
<lifeless> for now, lets say yes
<jam> :)
<gimaker> add benchmarking of different trie-types, and will have lots of fun benchmarking a billion different combinations :p
<lifeless> jam: say 50bytes per ref
<jam> lifeless: and 256 refs per node?
<lifeless> 256 way fan - 12K
<jam> lifeless: 256-way fan out... gives 16.7M in 3 levels
<jam> its what we saw with b-trees
<lifeless> jam: yes
<jam> it takes a *lot* of keys to hit a 3rd level
<lifeless> which is fine
<jam> (and there it is more like 100-way)
<lifeless> because we don't need 256 way fan out
<lifeless> where there are no children, we trim
<lifeless> a wider prefix in a node - less fan out (counter-intuitive, but true)
<jam> lifeless: Sure, but I wonder if hash() is going to tend to enforce it
<abentley> jelmer: I don't understand why the shell script I provided wasn't sufficient to register it as a mime type handler.
<lifeless> only the very root nodes will be so dense; and it may be we want to optimise for a smaller root page size
<jam> it makes me *wonder* if we would rather have a node pointer for [a-c] => THIS_PAGE
<jam> but then it isn't strictly a radix tree
<lifeless> OTOH 12K per commit isn't impossible to handle with, if we also are compressing those nodes
<lifeless> jam: we need a well defined canonical form
<lifeless> jam: well, look closely at the fan out rules; I think we cam make the description more clear with a bit of effort
<lifeless> I think the current rules may be very pleasantly surprising
<lifeless> also, give that toy I sent you a spin
<jam> will do
<Ng> how does one upgrade a remote branch, specifically one on launchpad? I've tried all the URL variants I can think of, lp:, bzr+ssh://bazaar.launchpad.net, etc. to no avail
<jam> Ng: with 1.6 or bzr.dev, lp: or bzr+ssh: should work (earlier ones you need to use sftp://bazaar.l.n)
<jam> However, once you've upgraded it leaves a 'backup.bzr' directory
<jam> which may be in the way for another upload
<jam> s/upload/upgrade
<Ng> jam: is that roughly a suggestion that I not do it? ;)
<jam> Ng: well, you have to delete the backup.bzr directory, and LP doesn't give you an easy way to do it
<jam> You can use an sftp program that lets you do recursive delete
<jam> Ng: I highly recommend that you do, just letting you know where it may fail
<jam> rather than telling you "do X" and having you come back with "X failed"
<Ng> jam: fair enough, thanks :)
<lifeless> hitchhiker will let you delete it now
<lifeless> as the launchpad sftp server doesn't work with lftp recursive delete
<Ng> hitchhiker?
<lifeless> yes
<jam> Ng: it is a program written by abentley to act like an "sftp/bzr+ssh/etc" client by using the bzrlib Transport code
<Ng> ah
<jam> not a particularly *good* ftp/sftp client, but the *best* bzr+ssh:// client available :)
<abentley> jam: :-)
<jam> abentley: wasn't that even your tag line
<jam> abentley: does hitchhiker use get_transport() such that "lp:foo" should work, as well as ":parent" ?
<abentley> jam: Okay...
<abentley> abentley: :-)
<abentley> jam: Yes, lp: specs and all plugins should work.
<vila> hmm, bitten by bug #225020, hard. Even bzr.dev exhibits the bug
<ubottu> Launchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Confirmed] https://launchpad.net/bugs/225020
<jam> vila: bite back
<jam> or apt-get remove pycurl
<jam> I've been happily using your urllib code for a long time now
<vila> I intend too, this bug seems hard to reproduce and pycurl have been removed from pqm for lack of reproducing and fixing it
<vila> s/too/to/
<jam> well, IIRC spiv could reliably reproduce it just by installing pycurl
<vila> Regarding urllib/pycurl I doubt we can just drop https certificate validation
<vila> depending on the branch I run selftest the first failing test is different...
<vila> and of course running the tests alone make them pass
<jam> vila: well, I would just create a http stress test
<jam> just GET the same URL repeatedly
<jam> (It certainly sounds like a plain bug in pycurl)
<jam> vila: though it may be a POST issue
<vila> that or leaked sockets
<jam> well, all of the reported bugs are about POST
<jam> And I could imagine that POST code gets less testing than GET code
<jam> You might also consider that these may be a 404 on POST
<jam> as a side question, if you have a DFA, do you usually represent that as a 2D table in memory? Or do you collapse it somehow
<vila> jam: is that for me ? what is a DFA ?
<jam> Deterministic Finite Automata
<jam> or automaton
<jam> I was reading about Trie's and they link over to DFA's
<jam> http://en.wikipedia.org/wiki/Deterministic_finite_automaton
<jam> I've heard about them before, but never dug deep into them.
<lifeless> uhm
<lifeless> there are a bunch of DFA representations
<lifeless> in parsing its  often a graph
<vila> Well, on my last project I write an automaton generator for simple ones so we went for a 2D table in flash memory (read-only) but when automaton grow you need to compress the table (which is most of the time very sparse)
<vila> otherwise most of the time I use them through scanner and parser generator which compress the tables heavily
<lifeless> vila: used antlr?
<vila> lifeless: never had the occasion but it was on my radar :-) I used [f]lex/yacc/bison heavily though and a bit of perl Parse:RecDescent module in the end
<vila> I even port lex/yacc sources on DOS and Mac OS 7 (or 6 ?) :D
<lifeless> I've written a dirstate antlr3 grammar
<lifeless> well, most of
<vila> lifeless: and your feedback is ?
<lifeless> mmmm
<lifeless> C runtime is immature
<lifeless> rest is out on judgement still
<lifeless> oh, and I hate lexers
<lifeless> lexers are the universes way of punishing us for parses that are too slow
<jam> lifeless: so, of course, you need to answer the question... is it *faster* ?
<vila> Hmm, I've seen parsers suffer really badly from bad scanners, but that's more the exception than the rule IME
<vila> of course it depends of the tool chain but the one I used the most (C/C++ by Flex) were ok (including parsers for > 1M files)
<vila> i.e the parsing itself was in the noise compared to the associated semantics
<lifeless> vila: my point is I don't like writing scanners
<lifeless> '0-9' for instance can match far to much
<lifeless> foo01
<lifeless> valid path
<vila> lifeless: ok, that's different then, but years of perl experience tend to help here too :)
<lifeless> also matches 01 if you don't force a whitespace in the scanner
<lifeless> worse, consider whole numbers vs ints
<ryanakca> I'm having trouble checking out an lp branch, could someone help me out please? bzr branch lp:ubuntu-dev-tools gives http://ryanak.ca/~ryan/bzr-error ... Someone gave me a fix to this a few months ago, but I never jotted it down :/
<jam> ryanakca: you have bzr-svn installed, and a containing .svn directory
<lifeless> vila: I'll reply tomorrow
<jam> so the branch command seems to be trying to re-use it
<vila> lifeless: are you still in AU, your hours seems unusal ?
<jam> But there is something odd in that bzr-svn is actually unable to open your .svn directory
<ryanakca> jam: svn: warning: '.' is not a working copy
<jam> ryanakca: short answer, disable bzr-svn
<jam> longer answer
<ryanakca> jam: how can I disable plugins during a command ?
<jam> bzr branch --no-plugins bzr+ssh://bazaar.launchpad.net/~ubuntu-dev ...
<jam> (the problem is the 'lp:' prefix is a plugin as well)
<jam> ryanakca: I would also try to figure out why we can't open "/home/ryan" as an SVN working directory, as then you won't have to workaround this all the time.
<ryanakca> jam: ah. ok, thanks. But why would it try to open /home/ryan if I'm trying to branch in /home/ryan/work/ ?
<jam> ryanakca: We search for a possible shared repository in containing directories
<jam> you could do "bzr init-repo ~/work" and then we would find that one instead
<Freaky> hm, is 1.6-rich-root supposed to be more bloaty than rich-root-pack?
<jam> (or just bzr init there if you didn't actually want to shared downloaded data)
<ryanakca> jam: thanks
<jam> Freaky: I'm pretty sure the stored form is supposed to be the same.
<jam> It is more of a config flag
<Freaky> I'm doing a bzr upgrade, the original .bzr is 211MB, the new one is 259MB and still growing after 85 minutes
<Pieter> it's creating a new pack file for your upgrade
<Pieter> you can delete the old files afterwards
<Pieter> so the growth is just temporary
<Freaky> ah, repository is 48MB, repository.backup is 210MB
<Freaky> and it should grow to be roughly the same?
<Pieter> who knows?
<Peng_> Freaky: Probably. Wait and see. :)
<Freaky> be waiting a long time then ;)
<gour> bzr-svn-0.4.11 is released?
<jam> gour: yes, it should be in the ppa
<jam> I don't think jelmer gave an official announcement
<jam> but he created the tag and published it to debian
<jam> and had me publish it to bzr-ppa
 * gour is on archlinux
<gour> great...no more svn :-)
<jam> there should be a tarball somewhere
<gour> i got it. ta
<gour> it's here http://samba.org/~jelmer/bzr/bzr-svn-0.4.11.tar.gz
<rocky> here's a question, is it safe to create a rich root repo on one box, do a bzr-svn co of a remote svn url beneath that repo, and then copy that repo to some other machine and use it there?
<LarstiQ> rocky: I _think_ so, but I haven't tried it.
<luks> it's perfectly safe, people are using even repositories on usb sticks and more them between computers
<luks> *move
<rocky> oh yeah? now that's interesting
<gour> jelmer: thank you for 0.4.11
 * gour is doing his first fetch of svn repo via bzr-svn
<gour> hmm bzr crashed - http://rafb.net/p/dkYRIG77.html
<gour> am i doing something wrong?
<jelmer> gour: no, that should work fine
<jelmer> gour: did this work previously?
<gour> jelmer: dunno. my first fetch from the repo and first use of bzr-svn plugin
<jelmer> gour: please file a bug
<gour> jelmer: for bzr?
<jelmer> gour: bzr-svn
<gour> ok
<jelmer> gour: it could be a serverside thing as well, google's svn may not like how we're using it
<dlee> This just happened to me; wondering if it's worth worrying about:
<dlee> BZR 1.5:  Repo created in Unix, checkout in Windows.  One file name ends with a space!  (It came from a cab file!)
<Peng_> ok?
<dlee> It works in Unix, but in Windows, you can't check out properly:  there's always a "Remove file" in bzr diff.  You can't merge into it because it's an unresolvable uncommitted change.
<dlee> I think Windows ignores the trailing space on file creation.  Interestingly, bzr diff shows "remove file" but no diff contents.
<dlee> If you actually remove the file, you get the listing of contents per usual.
<gour> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/261878
<ubottu> Launchpad bug 261878 in bzr-svn "bzrlib.plugins.svn.core.SubversionException" [Undecided,New]
<dlee> Theory:  This means Windows matches the file during that process too; it just can't make the name match.
<jelmer> gour: thanks
<dlee> I'm guessing bzr could ignore the trailing space in the repo name and make everything work on Windows, but I may not know what I'm saying. :)
<jelmer> dlee: you should be able to just remove the trailing whitespace in unix
<jelmer> dlee: commit then and then update in windows
<jelmer> dlee: I think bzr should be refusing to check out files with trailing whitespace in their name on Windows, just like it should refuse to check out files with certain other characters in their names
<dlee> True, but the file set is auto-generated (and regenerated) by a process.  Basically I'm using Bazaar to version-control the contents of a set of files (including cab file contents) produced by someone else.
<dlee> But yes, I can write a sort of post-processor that de-spaces the nasty filename before commit.  It's a cab, for Windows anyway, so no one will care. :)  Let me know if you want a bug filed on this or if it's just too obscure to worry about though.
<jelmer> dlee: please file a bug
<dlee> will do.
<jelmer> dlee: We do plan on warning when you add a file that can't be checked out properly on other platforms
<abentley> jelmer: We don't deliberately refuse to check out any files on Windows, and I don't think we should.
<jelmer> abentley: some files simply can't be checked out on Windows because of their name
<abentley> jelmer: I think we should handle it as a conflict.
<jelmer> abentley: that's an interesting thought
<abentley> jelmer: So we check them out with a different name, and tell the user what we did.
<abentley> jelmer: That way, Windows users (who are the only ones likely to care) can fix such problems themselves.
<jelmer> abentley: yeah, that's nicer indeed than having to go back to unix to fix it there..
<rocky> jelmer: as you might imagine, bzr-svn over dial-up is useless ;)
<rocky> that is, push commits and the like to the remote svn using bzr-svn over dial-up is useless ;)
<dlee> As a rule (and with CVS, Svn, and Bzr all three), I find the process of juggling between Unix and Windows in a single project to be loaded with problems.  In Bazaar, files and folders get .moved mostly.  But I use Bazaar for a few irregular purposes, like backing up/post-versioning web sites...
<jelmer> abentley: I would really like to see a warning system on unix rather than forbidding certain characters
<abentley> jelmer: I'd like that, too.
<jelmer> rocky: yeah, I wouldn't attempt to do that (yet)
<jelmer> rocky: what will help is having only one svn repo per project
<LarstiQ> there was a time when you couldn't even make a branch of something that had a revision with 'con.txt' in the inventory
<jelmer> LarstiQ: ah, the good old days
<LarstiQ> yes, very fun.
<rocky> jelmer: well ... that's mostly what i do, but that "project" sometimes has several sub-projects
<jelmer> rocky: yeah, the subprojects is what I mean
<LarstiQ> abentley: excellent idea on the conflict for such a situation btw
<rocky> jelmer: having to create a separate svn repo for each subproject is a bit overkill on these projects i'm working on ;)
<jelmer> abentley: oh btw
<jelmer> abentley: bzr-handle-patch.sh relied on something being in "/home/abentley"
<jelmer> abentley: so instead of fixing the shell script I just changed it to use python directly
<abentley> jelmer: Removing a command seems like a rather extreme way to fix that.
<jelmer> abentley: wasn't the command just for internal use (by mime-type handlers and the like) anyway?
<jelmer> abentley: If it's not, I misunderstood and we should look at reintroducing it.
<abentley> It's not just for internal use.
<jelmer> abentley: Sorry
 * gour is fetching from another svn repo
<jelmer> gour: works better this time 'round?
<rocky> jelmer: what happens if i bzr co a remote svn folder into my bzr 1.6 rich root repo ... and then *check out* that same folder from the bzr rich root repo into some local place? i mean, what happens when i committ locally?
<jelmer> rocky: afaik bzr won't let you create a checkout of a checkout, but I'm not entirely sure
<LarstiQ> it will.
<abentley> It was meant to be a regular Bazaar command.  With a wrapper because mime-type mechanisms are so primitive.
<gour> jelmer: it is still copying...unfortunately, i've cinelerra's rendering job in the background, that's why it's going slower
<loxs> hello. as far as I see from the docs, bzr uses only one .bazaar config directory per project. Does this mean that I cannot use only a part of the repository (let's say only the trunk/)?
<gour> loxs: part of repo or one branch?
<jelmer> LarstiQ: what will it do when you commit though?
<loxs> gour, I want to co and up only the trunk (the main branch) on my server, so that it is always up to date. But I don't want the document root there... only the trunc/myapp/ directory, because that must be in the python path
<jelmer> loxs: ah, you mean partial checkouts
<jelmer> loxs: (in bzr terminology)
<loxs> yes jelmer, that's very easy with svn
<jelmer> loxs: they're planned but not implemented yet
<gour> loxs: see http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=(layouts) as well
<loxs> nah, gour, you say I need a different philosopy ;) i like this kind of answers :)
<rocky> don't suppose anyone has a script lying around that will produce a commit msg that includes a listing of all the merged rev msgs that you're about to commit?
<gour> loxs: sure, every tool has its own recommended workflow. i came from darcs and cannot expect bzr to work in the same way :-) that's why i 'm adjusting to bzr. same with different programming languages...it is nnot smart to write C in Python, nor Haskell in Python, but use Python idioms in Python
<awilkins> rocky: The log contains that information anyway, why do you noe extract it the other way (iterate the sub-revisions of your merge revision)
<dlee> jelmer:  Filing as a comment to bug 3918
<ubottu> Launchpad bug 3918 in bzr "bzr can be caused to error with filenames containing newlines" [High,Confirmed] https://launchpad.net/bugs/3918
<jelmer> dlee: thanks!
<rocky> awilkins: well, this is merging using bzr-svn which i don't think will track that info in the svn log
<awilkins> rocky: Fair do's
<jelmer> rocky: if you have svn 1.5, bzr-svn will store the merge info
<jelmer> rocky: that should allow svn ("svn log -g" I think) to display what revisions were merged
<rocky> jelmer: i had to revert to svn 1.4 unfortunately ... mostly because of setuptools inability to deal with svn 1.5 properly
<loxs> hm, gour, you say it's possible to have project root being my python package root, and have the branches as directories? o_O... that's new :)
<jelmer> rocky: how do you mean?
<jelmer> rocky: setup.py in bzr-svn?
<rocky> jelmer: no... i'm a python coder by trade ... and i use setuptools to manage all of my own projects... well setuptools cannot deal with svn 1.5 checkouts properly with any release version of setuptools
<gour> loxs: i wasn't speak about python projects, but in general considering how svn projects are laid out
<jelmer> rocky: ahh, ok
<rocky> several bugs
<rocky> jelmer: and stuff where setuptools will inspect files and auto-include them with "setup.py sdist" fails with svn 1.5 checkouts
 * Odd_Bloke is getting http://paste.ubuntu.com/40944/ when trying to run bzr-svn trunk with bzr.dev.
<Odd_Bloke> Anyone know what's going on?
<rocky> so, i've reverted back to svn 1.4.6 since i have no good reason to upgrade to 1.5 anyways
<jelmer> Odd_Bloke: you need to build bzr-svn
<jelmer> back in ~30min
<Odd_Bloke> jelmer: Anything more than 'make'?  Because I've done that.
<Odd_Bloke> jelmer: NM, there were a number of weird interactions going on.
<Odd_Bloke> Fixed now. :)
<loxs> I read quite a lot and I still wonder is it a good idea if my working tree root and my python package root are the same directory.... and then put branches in subdirectories?
<luks> perhaps a terminology issue, but by 'working tree' you mean a bzr working tree?
<loxs> sure, luks
<luks> well, technically you can't put branches inside branches, but I don't think it's a good idea
<luks> er, can, not can't
<luks> if this is a single package, it should be a single branch, IMO
<loxs> well, the reason I want this thing is because of the lack of partial checkouts in bzr
<luks> and normally you put the package into a directory, not to the root
<loxs> and I want to update my server from the repository
<luks> loxs: but then you lose the ability to checkout the whole package
<luks> if it's split into several branches
<loxs> I dont' get what you mean
<luks> let's say you have myproject/trunk and myproject/trunk/subpackage where both trunk and trunk/subpackage are separate branch
<loxs> no, i don't want that
<luks> then by running "bzr branch myproject/trunk" you will not get myproject/trunk/subpackage
<luks> oh
<loxs> I mean the following:
<loxs> I want project/ to be the trunk/
<loxs> and a project/branches/ subdirectory to hold the branches
<luks> ah, that's not a problem
<loxs> i mean, that when my server checkouts the repository, it goes straight into the python path... and it works out of the box, because I co it in the python path
<loxs> if there is project/trunk, then trunk is no more accessible as a python package
<luks> I meant that project/trunk/ is a branch
<luks> not that you have a branch project/ with a directory trunk/ in it
<loxs> I will not have a trunk/ directory at all... the root of the project will be the trunk
<loxs> is it ok?
<luks> yes, location of branches usually doesn't matter in bzr
<loxs> and do you think it is a good practice luks?
<luks> loxs: well, I personally wouldn't put the package root to a root of a branch
<rocky> are there any other deployments for bundle buggy out there other than the bzr one at aaronbentley.com
<luks> because then it's harder for me to do setup.py and other things
<luks> (if by package you meant a python package)
<luks> ah, yes
<loxs> you say  you would prefer to use setup.py and install from the repository instead of using the program from the repository directly?
<luks> depends on the situation, but I prefer all python packaged to have setup.py
<loxs> it's a django site
<luks> if you want to use the working tree for deployment, I'd probably just symlink it
<loxs> hm, yes, it's probably a good idea too...
<luks> I don't know what's the usual layout of django projects
<luks> but I would be surprised if they had python files in the root directory
<loxs> the thing there is that there are quite a lot of non-python files that have to be used... html, css etc.
<luks> there must be templates, some static files, maybe some unrelated data files and scripts
<luks> exactly
<loxs> but the main part is a python package
<loxs> that must be on the python path
<luks> is this for develoment or production deployment?
<loxs> deployment
<loxs> for development there is a dev server that does'nt care where it is... it is run via a script from the project
<loxs> but for deployment the project is called via mod_python and it must be in the python path
<luks> you can modify sys.path from mod_python
<luks> so I'd point it to the working tree
<loxs> I know, but I sill prefer to have my project in site-packages
<loxs> and I planned to have a cron job to sync the repository there
<luks> then a symlink, I don't like the idea of mixing python code with data files in the same directory
<loxs> yes, I'll probably go with a simlink
<loxs> thank you for the conversation :)
<luks> np, I like having these kind of conversations :)
<loxs> and what is your personal preference for a repository layout?
<loxs> i read this http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=(layouts) and can't choose :)
<luks> I like a flat list of branches in the repository
<luks> so repo/trunk/ repo/branch1/ etc.
<luks> and separate repositories for separate projects
<loxs> you mean the good old svn style? :)
<luks> no, svn does repo/trunk/ repo/branches/branch1/
<luks> I don't like the branches/ directory
<loxs> aha, I see
<loxs> doesn't it get quite cluttered then?
<luks> I delete branches after they are merged, so it doesn't
<loxs> I need some place where inexperienced "wannabeadeveloper"s make their own little chaos :)
<loxs> so probably I'll go with something like developer/whatever he chooses/
<jelmer> luks, where do you put tags then?
<luks> jelmer: bzr tag :)
<jelmer> luks, ah, I thought you were talking about your preferences for svn (-:
<luks> I wouldn't dare to delete svn branches
<luks> even with the 1.5 merge tracking
<mpt> Heeeeeeelp ... I tried to upgrade my remote repository, but it hung because of bug 256757. Now that the remote server is updated to bzr 1.6, I've tried "bzr upgrade" again, but it reports "The branch format Bazaar-NG meta directory, format 1 is already at the most recent format", when I know it's not.
<ubottu> Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Critical,Fix committed] https://launchpad.net/bugs/256757
<jam> mpt: which branch
<mpt> (After the previous failed attempt I replaced .bzr with the backup.bzr it had made when it started.)
<mpt> jam, no branch in particular, this is at the project level
<mpt> Do I need to do it for each branch separately?
<jam> mpt: sure, I was just hoping to poke at it and make sure
<jam> is it somewhere I could get to it?
<jelmer> jam, any chance you can comment on https://lists.ubuntu.com/archives/bazaar/2008q3/046309.html ?
<jam> It doesn't seem like enough of anything to really comment on
<jelmer> jam: Ok, no objections to it though?
<jam> No specific objections, though your VCSMapping object is just information about the mapping, it doesn't do any actual mapping
<_stink_> i'm trying to do 'bzr branch lp:sendoff', and getting an error: http://paste.ubuntu.com/40966/  This is with bzr 1.5.  Is there some kind of config problem that could cause this, or should I go to 1.6?
<jelmer> jam: That's all implementation-specific, this is just infrastructure shared between bzr-git and bzr-svn
<jam> _stink_: well, it looks like the ssh connection is failing. you could try: bzr branch lp:sendoff -Derror
<jam> which gives a  full traceback
<jelmer> I wanted to check before I did any more work on this, since I was a bit surprised when my VirtualSignatureTexts patch was vetoed
<jam> jelmer: well VST was an inversion of layering
<jam> which was a bit odd
<jam> For your Mapping stuff, it doesn't seem like a problem, but it also doesn't seem to provide much yet
<jam> so perhaps at least a little discussion about why you want to use it, and how
<mpt> thanks muchly for your help, jam
<jam> np mpt
<jam> happy to help
<_stink_> jam: http://paste.ubuntu.com/40968/ for output with -Derror
<jam> _stink_: what hapens if you do: "sftp bazaar.launchpad.net" ?
<jam> (It at least seems like a ssh connection error)
<jam> you just have to use sftp because launchpad only allows bzr+ssh or sftp
<_stink_> jam: http://paste.ubuntu.com/40969/ still publickey connection error.
<jam> _stink_: you should be able to do "sftp -v"
<jam> It sounds like something between you and LP is preventing you from connecting
<_stink_> jam: ah, i think i know. just realized i had uploaded a separate ssh key for LP, and i'm not telling it which one to use.  i did this when i was just playing around. i think i can fix it now. thanks
<tethridge> if I have a branch on a server and I create a new branch from it.  Then I make a change to the new branch and "push" to the old branch can I assume that the old branch will be a copy of the new branch?
<tethridge> I'm not sure if that is an acceptable thing to do
<luks> yes, it will be
<luks> and if there is a reason why it can't be, bzr will complain
<luks> (complain and not perform the push)
<tethridge> that's cool
<tethridge> I would like to think that it would work that way, but not all software "just works"
<jaypipes> jam: query window...
<pickscrape> Would I be right in thinking that bzr bundle is the same as bzr send without the mail client integration?
<james_w> pickscrape: yes, you would
<pickscrape> james_w: thanks, it's just what I'm after :)
<luks> I don't think it is
<abentley> pickscrape: bzr bundle is a hidden command and may be removed at a later date.  "bzr send -o" is *also* the same a bzr send without the mail client integration.
<abentley> james_w: Please encourage people to use bzr send.  There's nothing bundle can do that send cannot.
<pickscrape> abentley: ooh, I had actually looked for such an option in bzr send but for some reason completely missed that one... Thanks!
<abentley> pickscrape: no problem.
<jelmer> abentley, do you have any idea what could be causing bug 203376 ?
<ubottu> Launchpad bug 203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Medium,Triaged] https://launchpad.net/bugs/203376
<abentley> jelmer: Which bzr version did you confirm it on?
<jelmer> current bzr.dev and bzr 1.6
<jelmer> Good point, I'll put it in the bugreport
<abentley> jelmer: So, I would guess that two codepaths are causing the creation to be cancelled, but a creation can only be cancelled once.
<jelmer> abentley: What could cause that though?
<jelmer> abentley, the actual join worked fine and committing it also worked fine
<jelmer> the first merge of the joined branch after that fails
<jelmer> the merge would only change a file text, nothing else
<jelmer> abentley, why would it need to call fix_root() in this case?
<abentley> jelmer: look, it's a bug.  If I'd expected it to happen, I'd have fixed it too.
<abentley> jelmer: We always call fix_root, for regularity's sake.
<abadger1999> If there's any Fedora users here that would like to become Fedora packagers for parts of the bzr stack, I'll be happy to sponsor you and help to review your packages :-)
<jelmer> abentley: I'm just trying to understand what's happening since I'm not very familiar with this code
<jelmer> abentley: ah, ok
<abentley> fix_root should only have an effect when you've got a tree with two roots.
<abentley> Join shouldn't give you a tree with two roots, it should make one tree's root into a subdir of the other.
<abentley> I suppose you could do conflicting joins.
<jelmer> abentley: Thanks, that helps
<jelmer> abentley: The problem is somewhere in fix_root, skipping it fixes the problem
<abentley> So that one tree claims that x is a subdir of y, and another tree claims x is a subdir of z.
<Odd_Bloke> abadger1999: I'd suggest mentioning this on-list, if you haven't already.
<abentley> That would cause merge to give you a tree with two roots.
<abentley> But it's actually intended for the case where you're merging two unrelated trees.
<jelmer> abentley: the problem appears to be that merging another branch whose root is not the root of the tree we're merging into breaks things
<jelmer> not the root of the tree we're merging into, but present as regular directory in that tree
<abadger1999> Odd_Bloke: I'll do that eventually.  It's much easier to mentor someone to be a good packager if they're active on IRC, though.
<abadger1999> So I thought I'd start here.
<jelmer> abentley: I think I know enough now anyhow to try and get this fixed
<jelmer> abentley, thanks!
<abentley> jelmer: You're welcome.
<james_w> jelmer: hey, did you send me your merge-upstream changes?
<jelmer> james_w, No, I requested merges in lp
<jelmer> james_w, I'm happy to send them to you as well if you prefer
<james_w> ah, I'm obviously not subscribed
<james_w> I can look
<james_w> I've just completely re-written the code though, sorry
<jelmer> james_w, where's your code these days?
<jelmer> Last change I see here is from quite a while ago
<james_w> yeah, it's been in flux for a long while
<james_w> bzr+ssh://bzr.debian.org/bzr/pkg-bazaar/bzr-builddeb/2.0
<james_w> your change will still apply, but have no effect, I haven't deleted the unused code yet
<james_w> wow, you have been busy
<james_w> so, you want it to degenerate to "bzr merge" sensibly, but do some other things as well?
<jelmer> yeah, with all that packaging I did I used bzr-builddeb a lot :-)
<jelmer> james_w: Yeah, basically "bzr merge" and figure out the new Debian upstream version string
<james_w> I'd like to leave these out of this release
<james_w> it's already huge, and I need to get it done in the next hour or two
<james_w> I can merge then straight after though
<james_w> well, not *straight* after, I'd like some sleep :-)
<jelmer> james_w: No problem
<jelmer> james_w: Are you interested in conflict-free versions of these branches?
<james_w> no, that's fine
<james_w> it will be far more work for you to understand the new code than for me to make your changes to it
<james_w> I would love it if you could test that branch for a few of your usual operations though.
<james_w> the 2.0 branch I mean
<jelmer> sure
<jelmer> Any commands in particular?
<james_w> builddeb has changed a couple of default locations
<james_w> i.e. .. instead of ../tarballs and the results end up in .. as well
<james_w> but it should fall back for the first, and not break too much for the second
<james_w> merge-upstream and import-dsc have been completely re-written, so anything you can do with them would be great.
<jelmer> builddeb itself is still doing the right things wrt paths
<james_w> good
<james_w> these changes set us up much better for the future.
<james_w> siretart: hi, sorry it's late, are you still around?
<jelmer> james_w, I can't find anything otherwise wrong doing some simple tests
<Odd_Bloke> I want to push a bzr branch into an SVN repo using the space currently occupied by an empty directory.  Am I best off removing that directory and pushing the branch in, or is there some way I can avoid that?
<james_w> jelmer: good to know, thanks. The test coverage has dropped a bit recently, so there could have been holes.
<jelmer> Odd_Bloke, yes, you'll have to remove that directory and push using svn-push
<Odd_Bloke> jelmer: Thanks. :)
<loxs> folks, is there a way to make bzr write some "standard stuff" in the beginning of all of my files?
<LarstiQ> loxs: keyword expansion I suppose?
<loxs> LarstiQ, i have no idea what is this, where is it in the docs?
<loxs> i found it, thank you
<jelmer> james_w, one comment
<jelmer> james_w, any chance target_distribution and version can be options rather than arguments to merge-upstream?
<james_w> why's that?
<jelmer> james_w, That makes it a lot easier to make either optional
<james_w> ah, for the later work?
<jelmer> yeah, if it ends up in a release now it's going to hurt more people if it's changed later
<james_w> yeah
<james_w> they are at the end, so you can drop them off without breaking things
<james_w> though they are probably the wrong way round for that
<james_w> doing it now
<jelmer> james_w, yeah, though I can also imagine target_distribution being optional (perhaps default to the distro the user is running?)
<james_w> perhaps
<ronny> how can i pull a single revision from one branch into another for merging?
<Odd_Bloke> ronny: 'bzr merge -c <revspec> <source>'
<acemo> when using bzr in command line on mac am getting this error for every command i type in.. "bzr: warning: unknown encoding . Continuing with ascii encoding." is there anything i can do to fix this?
<LarstiQ> acemo: is LANG/LC_CTYPE one of such set to something the system doesn't have?
<LarstiQ> acemo: see `locale` output
<acemo> its UTF-8
<LarstiQ> acemo: that should be fine
 * LarstiQ falls asleep
<LarstiQ> acemo: you could look at ~/.bzr.log
<ronny> hmm, why cant i just pull revs from other branches into a branch ?
<acemo> LarstiQ: http://rafb.net/p/gWsCmO64.html heres my ~/.bzr.log
<jdobrien> LarstiQ: re: bug #31059 it will be a while before i can get back to it
<ubottu> Launchpad bug 31059 in malone "Empty comments and empty emails generated" [Medium,Confirmed] https://launchpad.net/bugs/31059
<jdobrien> LarstiQ: er bug #30159
<ubottu> Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] https://launchpad.net/bugs/30159
<ronny> whats the name of the extension for graphical logs?
<awilkins> ronny: Because Bazaar uses a Directed Acyclic Graph model ; to pull revs from other branches, you have to have the same ancestry. You can merge revs (if you don't have their ancestors, it's cherry picking though)
<awilkins> ronny: qbzr and bzr-gtk both provide graphic logs
<awilkins> ronny: qbzr has the superior log view in most people opinions
<ronny> awilkins: in my case they have the same ancestery, but bzr just errors telling me to use merge instead
<awilkins> ronny: Have you committed revisions that the merge source does not have?
<ronny> yeah
<awilkins> ronny: If you don't want to merge, rebase is your option (but I've yet to see a genuine reason to use it)
<ronny> i dotn see what should prevent a pull tho, it would just add a new head
<awilkins> Rebase would be what you are aiming at ;; "just insert the revisions from the other branch before my new ones"
<awilkins> Not a good idea if you've pushed it elsewhere though
<ronny> but i just want to do get the revs into my branch, ONLY that
<awilkins> ronny: You want to get rid of your new revisions?
<ronny> no
<awilkins> Then you merge, or you rebase
<awilkins> Merge does only merge the revisions you need
<awilkins> ronny: Are you an existing SVN user?
<ronny> no
<ronny> monotone, git, mercurial
<acemo> is bzr 1.6 on mac still having the problems with utf-8?
<ronny> they all allow me to do what the heck i want, bzr is the only one getting into my way
<jelmer> james_w, --snapshot went away?
<james_w> jelmer: yeah
<james_w> it was completely broken by snapshot.debian.net dying
<james_w> and I hadn't ported it to the new code, and it didn't seem worth it when there was nothing to get the packages from
<james_w> it will come back when there is a new service
<jelmer> ah, ok
<jelmer> pity, I didn't know snapshot.debian.net had died
<jelmer> I never used --snapshot, just noticed that the arguments list had gotten shorter :-)
<james_w> yeah, apparently they ran out of diskspace
<james_w> it's going to become an official debian service
<james_w> and hopefully that will still have all the history
<fullermd> ronny: Er, AFAIK, both git and hg will have the same behavior as bzr (though commands may be named differently).
<fullermd> ronny: mtn is the only one of the four that allows branches to have multiple heads.
<fullermd> (well, there's that half-multi-head, half-named-branch, half-whatever thing that hg half does, but I don't know much about it)
<ronny> fullermd: hg allows me to have as many heads as i wanat in the same branch, git just needs different refs to them, but in general they wont force a merge on pull ever
<fullermd> Yes, but if they're different refs, they're not in the branch.  They're different branches (or pseudo-branches)
<ronny> in hg its valid in the same branch
<jam> fullermd, ronny: I think the confusion is that hg/git use "pull" to just mean "fetch" but have no statement about actually doing anything with the revisions
<jam> which causes multi-heads in hg
<jam> and another branch pointer in git
<jam> in bzr terms
<jam> it would be "bzr branch other" into a shared repository
<jam> to get the same behavior
<ronny> for me thats just an unacceptable workflow enforcement
<clemente>  
<clemente>  
<clemente>  
<clemente>  
<clemente>  
<lifeless> clemente: I see blank lines
<clemente> lifeless: sorry, problems with my client. Hopefully I didn't send hundreds of lines a moment ago
<lifeless> only 5 :)
<clemente> Ok, so if you paste hundreds of lines, apparently you get kicked by the server :-)
<awilkins>  -!- clemente [n=Daniel@89.6.42.98] has quit [Excess Flood]
<clemente> I won't do it again
<ronny> is there any way to go to a previous version?
<uws> ronny: Read  "bzr help revert"
<ronny> uws: that doesnt exactly look like "go back to rev x"
<awilkins> Your question is vague
<lifeless> ronny: do you want your tree reverted to x, or your branch ?
<ronny> the tree
<uws> bzr revert -r123
<lifeless> then revert is what you want; it changes the tree and leaves the branch untouched
<uws> That does EXACTLY look like "go back to rev x"
<lifeless> ronny: give it a go, tell us if its what you're looking for
<lifeless> ronny: then, if it is, I'd like to understand why you felt it wouldn't be
<ronny> works
<lifeless> (and if it isn't, well, we can talk about what you really want)
<[cliff]> hi all
<[cliff]> is there any progress on nested tree support?
<lifeless> not that I know of
<awilkins> Short answer ; no
<ronny> lifeless: looks weird, first if all i expect a revert only to change my workdir (not alter its parents or anything else)
<awilkins> ronny: The command is global to your tree by default ; try bzr revert . -r X instead
<ronny> second i skiped to the long text, it just talks about reseting files to the orginal stuff, and how to get rid of stuff using merge
<lifeless> ronny: well, it hasn't changed parents
<[cliff]> one more question: what is configmanager? how does it work? the page is kind of vague: http://bazaar-vcs.org/ConfigManager
<awilkins> lifeless: I think he means `pwd` not `branch tree`
<ronny> oh, it really didnt
<ronny> sorry there
<lifeless> [cliff]: its a script I wrote quite some time ago ;) - it takes a list of relative-path:branchurl mappings, and then branches then for you, or updates them
<ronny> so there is bascially nothing like the stuff for git/hg/monotone that allow to go back to a previous rev and commit based on it other than a new branch ?
<lifeless> ronny: oh, so you *do* want to change the branch :)
<ronny> ok, dammit, yet another set of terms
<awilkins> git/hg/monotone are making a new branch, they are just doing it implicitly and are able to because they either store branches in a DB or in their repository folder
<lifeless> ronny: there shouldn't be any new terms here. But for clarity, let me lay them out:
<[cliff]> lifeless, hmmmm I'm checking the sample config, looks useful for deployments. can I tell it to grab a specific revision/tag?
<lifeless> repository - could of history data
<lifeless> [cliff]: it needs some love for its bzr support, 'probably' is the best answer offhand
<lifeless> repository - cloud of history data (same meaning as git/hg/monotone/svn/cvs/etc)
<lifeless> branch - a specific line of development in that cloud. its tip *may* be a head, or not. Same meaning as CVS/svn/git; same as hg named branches, not the same as monotone which is different to everything else
<lifeless> ronny: anyhow, 'commit' adds a new revision onto a branch, updating its tip in the process
<ronny> hg named branches may have more than one head
<lifeless> ronny: can they? I misunderstood them then. garh, I'll go read the code later
<lifeless> anyhow, bzr branches are an explicit pointer to a revision id
<lifeless> to commit on a different revision than the branches tip, *either* change the tip first, *or* make a new branch with a different tip
<lifeless> to do the former : 'uncommit -r X' or 'pull --overwrite . -r X' will do what you want
<lifeless> to do the latter, 'bzr branch -r X . ../newbranch'
<ronny> so i either kill later revs, or i need a new directory ?
<uws> be careful since "uncommit" may make you lose code
<uws> (and history)
<awilkins> ronny: You could put your branch in a repo and use switching
<jam> uws: no more than pull --overwrite
<jam> uws: and with latest bzr, 'uncommit' will tell you how to get your pointer back
<lifeless> uws: uncommit doesn't do an automatic gc
<awilkins> You still have to make new directories for branches, but you can keep one working folder
<uws> jam: well, pull implies there's some history elsewhere :)
<uws> jam, lifeless: ah ok. didn't about recent developments
<jam> uws: "bzr pull .- rXXX"
<ronny> oh pain :(
<lifeless> ronny: uhm
<uws> jam: (oops, missed the . )
<lifeless> ronny: I suspect we're seeing the tip of your needs
<ronny> that basically killing most of my workflows
<lifeless> ronny: perhaps you could give us a quick brushstroke picture, and we can then point you at either a guide, or give you a quick sketch now
<lifeless> because I suspect we support your work flow just fine, but its spelt a little differently than you may be used to
 * awilkins suspects it's similar to this : http://www.g2one.com/quickcasts/movies/gitGrailsScreencast_web_final_compressed.mov
<lifeless> awilkins: its similar to a proprietary format video?
<fullermd> Easy creation of multiple branches/heads on the fly is handy if you're doing a lot of DAGgy-fixes'ing.
<awilkins> THe video is one of some guy using git to rapidly switch between branches
<lifeless> so shared repo & switch, or loom
<awilkins> Someone posted it in here and I said the same thing
<ronny> i dont just switch betwen branches rapidly, but also betwen different parts of the history
<awilkins> (apart from looms)
<lifeless> ronny: go on
<ronny> i usualy pull from a few people at once, then just jump betwen the various revs and take a look on what to merge
<lifeless> so, I need to translate this into raw mechanics I think
<lifeless> you create a bunch of unmerged tips in your history store
<lifeless> and then examine each one to see if you want to merge it
<lifeless> and finally merge some onto your actual current branch tip ?
<ronny> yeah
<lifeless> ok
<lifeless> I can tell you how I'd do this, which isn't the only way
<lifeless> let me just pastebin a small scenario
<lifeless> ronny: http://pastebin.com/d53f46e8
<lifeless> ronny: this will be network and local space efficient
<ronny> any way to turn a normal repo to something like that?
<lifeless> the easiest way is just to branch your current tree into a shared repo
<lifeless> but if its GB's in size and you need to avoid having two copies temporarily, I can tell you how to flick bits to do it by hand
<ronny> nothing big here
<ronny> guess i could just use that
<ronny> still puts having tonns of dirs on me
<fullermd> Can't reconfigure do that?
<lifeless> fullermd: probably, I haven't internalised it enough
<lifeless> ronny: each branch dir is tiny
<fullermd> It's got a --use-shared and --standalone.
<lifeless> ronny: it doesn't have a checkout of your code; so its only got a pointer, and configuration data
<ronny> lifeless: i know they are tiny
<lifeless> ronny: ok :)
<lifeless> ronny: uhm, is there some scaling issue with directories for you? Or its a taste thing?
<uws> the fact that branches ARE directory helps visibility
<ronny> its still extra management (i hate having dozens of dirs) and selecting special versions (that arent any tip) is still odd
<uws> that helps a lot of users
<lifeless> ronny: ok, well, it sounds like dirs are more in your face than just names in a file?
<ronny> yeah
<ronny> all the branches and revisions are completely irelevant to me, till i actually want to take a look/merge
<ronny> hmm, does bzr 1.5 choke on tailing whitespace conflicts ?
<ronny> (appearantly someone left them, and someone else has an autofix for those in the editor)
<lifeless> oh
<lifeless> I don't think we have a special-case flag for whitespace
<lifeless> but if its a clean 3-way it wont' conflict anyhow
<lifeless> or you could use --lca which will likely do a better job
<ronny> hmk
<ronny> at least im done with that merge now
<fta> is there a way to improve usability of bzr between 2+ computers ? i mean, a user is working in a branch on computer A, then move (or commute) and wants to continue on computer B, but the last changes are not committed (not ready)
#bzr 2008-08-28
<lifeless> fta: just commit them
<lifeless> fta: then pull them onto B, uncommit, and keep editing
<fta> i used to do that but it's not very handy
<lifeless> fta: what would you like to be able to do
<lifeless> ?
<fta> both A and B push to a central repository (not a working tree), so i have to uncommit there :(
<lifeless> well, you can just push --overwrite
<lifeless> when you're done on B
<lifeless> or push to a temp branch in the central repo, rather than your trunk
<fta> but if someone else pushed on central, it breaks
<lifeless> use a temp branch for sure then
<fta> i would like to export uncommitted changes from A to B or vice versa, without going to central, yet with preserving the resolve/conflicts facilities
<fullermd> merge --uncommitted would do that.
<fullermd> (though you can get ugly going back and forth with it; doing it once would be reasonable)
<fullermd> It would similarly benefit from a super-shelf that used real revisions to hold the shelved stuff.
<fta> A and B are owned only by the same user, central is shared
<awilkins> fta: I have a repo on a thumb that I commit to ; if I need to put that in a central repo I push from there
<awilkins> fullermd: Isn't "loom" a sort of super-shelf?
<lifeless> fta: uncommitted changes have no real representation in bzr
<lifeless> other than 'working tree'
<lifeless> fta: do you have NFS or similar between these two machines?
<lifeless> I think there is a valid use case here, in two different dimensions, but we don't have a good offering today
<lifeless> and it will take thought to avoid making a bad one :P
<lifeless> the two dimensions are collaborative conflict-resolution-in-N-steps
<fta> i used commit/uncommit/push override for a while, i ended up with lost commits. i also used scp/rsync between A and B, better but not very handy.
<lifeless> and helping people deal with transient commits more easily, I feel the two combined would do what you want
<lifeless> jam: so did I get a review of log ?
<jam> lifeless: I certainly hope so
<jam> I did it last night
<lifeless> ah yes found it
<lifeless> thanks
<lifeless> I've done one of your btree patches
<lifeless> other shortly
<fullermd> fta: merge --uncommitted would be much more handy than scp/rsync...
<jam> lifeless: I didn't get a chance to play with the toy, I've been debugging the fetch issues
<lifeless> jam: I integrated bzr-search with my patch last night - bzr log -m "\brobert\b" went from 12 seconds to 4 seconds
<jam> nicely done
<fullermd> awilkins: Not really, especially if you're not already using looms and on top of one...
<lifeless> jam: primary fetch issue is no streaming verb
<lifeless> jam: that I know of
<lifeless> (I mean, other than being-silly-with-object-lifetimes)
<jam> yeah, but there are oddities in the specifics
<jam> branch locally is 2+ times faster
<awilkins> fta: How about * Branch to no-trees repo in USB thumb * A and B take checkouts of branch in thumb * commit when changing location and take thumb with you * update at the location you moved to * keep working ?
<fta> fullermd: thanks. i'll give it a try for a while. thing is i'm an avid user of --remember so push/pull/merge are going to central by default.. merge --uncommitted will force me to specify A or B each time.
<fullermd> fta: Aliases and/or the bookmarks plugin can be a help there.
<awilkins> fta: This works well for me (I was pushing and pulling between network shares on my laptop and desktop for a while and I too got my knickers in a knot)
<lifeless> jam: try with btrees :P
<fta> awilkins, i'm not organized enough to depend on usb ;) it will stay connected on the other side, or i will simply forget. I expect bzr to do that for me as i can reach always reach A from B (reverse is not true)
<fta> fullermd, yep, one more alias, i like that
<awilkins> fta: How about keeping the branch on A and taking a checkout of it on A and B
<awilkins> If you use a heavy checkout you can still commit to one offline and merge it later
<awilkins> Here's one - operations on network shares on windows are treated just like local filesystems ; to the point where the client will do things like copy files from the tree rather than unpacking them from the content texts ; copying from the tree is slower over a network drive in many cases
<awilkins> It will also do heinous things like repacking an 11MB repo over a 256KBit/s link
<bob2> you're using smb over adsl?
<awilkins> bob2: VPN
<awilkins> bob2: and cable not DSL (256 kbit is my upstream)
<awilkins> Short of setting up an HPSS (or even just SFTP), would it be possible to have a --network option or similar that had it do things like * not update remote tree when pushing * not repack * not copy files from remote branch but unpack them from local content texts
<fullermd> Well, if it helps, it would repack the 11MB repo over a 256Kb link if you were using SFTP too   ;)
<awilkins> fullermd: That's nasty too :-)
<awilkins> I had the Windows bzr+ssh support all nicely patched and IT services refused to open port 22
<awilkins> Alas, I've not quite cracked HPSS over IIS 6 (works nicely with IIS 7)
<fullermd> Well, it would repack the 11MB repo over a 256Kb link with bzr+ssh too...   I mean, how consistent can you GET!
<awilkins> Yes, but the repack happens locally with an HPSS
<fullermd> No it doesn't.
<awilkins> Urgh!
<awilkins> You mean even on HPSS it pipes 22MB of data to the client?
<awilkins> (and from
<fullermd> Oh, no.  I'm sure there's enough missing entropy that it can compress down to 21.5MB or so.
<awilkins> Surely that's a bug - it's hardly high-performance-optimized if the thing is asking the client to do all the work and abusing its bandwidth
<fullermd> FSVO 'bug'.
<awilkins> What happens if you access a MySQL repo over bzr+ssh and it decides to repack? Grit your teeth and wait a day?
<awilkins> (AFAIK you can just abort and nothing is hurt)
<bob2> yes
<awilkins> Yuck
<fullermd> Well, if you get a big enough repo, you'll only ever have to do it once, 'cuz a repack verb (or better, elimination of a need for one) will have been added before it finishes...
<bob2> hahaha
<awilkins> Why the hell would a client get to decide that the server needs to repack?
<awilkins> Screw repack verb, it's the servers job to manage it's own damn storage
<fullermd> That's crazy talk.  Next you'll be saying the client shouldn't have to understand the low-level details of the server's repo format.
<awilkins> You could just have the server play back bzr-fast-export tapes :-)
<awilkins> Heck, you could write bzr HPSS servers for git
 * fullermd summons jelmer    :p
 * awilkins summons Bahamut
<fullermd> See, if bzr-git just gets fast enough, we can just use central git repos and avoid all that unnecessary HPSS work.
 * fullermd repacks a repo while waiting for the cutscene to finish.
<bob2> you just need a hpss-optimisation montage
 * awilkins takes 7 damage
<fullermd> Gotta remember to stop by a commit-point.
 * awilkins takes a USB key and commits in the field
<lifeless> awilkins: spiv has a patch to repack remotely
<awilkins> Is it part of HPSS?
<lifeless> awilkins: but note that repack only repacks small packs most of the time; to repack the deep history of mysql you need to commit 10 times as many revisions as there are already
<lifeless> awilkins: yes, but not merged to bzr.dev yet
<lifeless> awilkins: so, to trigger a repack of the deep mysql history, commit, oh, 500000 times
<awilkins> I have a branch I'm using to deploy .jar files ; it only has about 10 revs and it go repacked into one pack over the VPN which is my 11MB case :-)
<lifeless> awilkins: ok, the next repack of those 10 will occur at 100 revs
<lifeless> and then at 1000
<awilkins> I hope the deltas are nice and small now then, it's mostly one 1.2 MB jar that's changing incrementally
<awilkins> Would you get better packing by unzipping archives and them packing them>
<lifeless> a zip compresses badly unless you use --rsyncable, and as we don't use rdiff, we don't gain much then (though we may gain some - I haven't tested)
<lifeless> jars are zips
<lifeless> (delta compress obviously)
<lifeless> so yes, deltaing the contents would probably be a size win; though .java files may be questionable etc
 * AfC wonders a bit why someone would ship .jar files with a version control system (unless this is a matter of using it to deploy artifacts to a production system, but even then)
<awilkins> Because it's easier to just have my users `bzr pull` than expect them to download an archive, unpack it, and not wipe out any of their own little scripts and things
<ToyKeeper> Some of the stuff ronny brought up would be nice to have in bzr...  like repo-level pull/push, and the ability to make new branches implicitly (like...  "hg up -r 123 ; hack hack; hg commit" would make a new head)
<ToyKeeper> A repo-level vis tool would be nice too.
<awilkins> I thought extending switch would be good
<awilkins> Let switch also push a new branch
<awilkins> bzr switch bar --branch
<ToyKeeper> Instead of switching branches in-place like in that .wmv earlier, I find myself keeping an 'active' symlink in the repo to point at the branch I want to use.  That doesn't quite work the same, though.
<awilkins> bzr switch bzr --branch -r 123
<bob2> hm, how about bzr switch --create newbranch?
<awilkins> THat might be clearer
<fta> fullermd, seems i can't merge --uncommitted from a bzr+ssh url
<bob2> what's the rationale for not just commiting all these changes?
<awilkins> fta: sftp may work
<bob2> not wanting them to show up in logs?  no automatic handling of syncing multiple branches?
<fta> awilkins, same, "is not a local path"
<lifeless> awilkins: branch --switch would be my preference
<lifeless> ToyKeeper: bzr viz can do multiple branches
<fullermd> Oh, I forgot about that.  WT access doesn't work remotely...
<fullermd> Well, so much for THAT beautiful idea.
<bob2> that would be complicated with branch's existing positional arguments
<lifeless> ToyKeeper: but repos are just storage access, not semantic; I can buy 'viz all branches under URL'
<awilkins> lifeless: Would you include the current "sibling" logic that's in switch ; this seems to be something that those git people really like, the one-element-name of branching
<bob2> bzr branch --switch . ../newfeature, and loses switch's "sibling" support
<lifeless> awilkins: yes, there is a bug open to propogate that
<lifeless> also, are you aware of cbranch
<lifeless> which already does much of this
<awilkins> No
<lifeless> ToyKeeper: we have 'repo' level push/pull with multi-push/multi-pull
<awilkins> cbranch is not mentioned on the BzrTools page
 * markh hopes to hear someone lamenting the lack of a -r option to 'bzr up'...
 * awilkins found that really counter-intuitive after using SVN for so lon
<markh> me too - and I have a patch - which is why I'm hoping to hear someone complain ;)
<markh> I resurrected a patch that was initially targetted at version 1.3!  I fear it will similarly languish now...
<markh> would it do that in response to 'bzr up -r'? ;)
<fullermd> Oh, yeah, we need a VSS mode.  %bzr commit      Warning: This setting will store your changes without any corruption.  Are you sure you want to proceed?  (y/n)
<jam> lifeless: bzr+ssh:// uses the _create_pack_from_packs code, isn't that the same as local?
<markh> actually, my first response to a merge was "OMG, why does bzr think 1/2 this file is in conflict?".  lifeless kindly then pointed out '--reprocess' which has become invaluable for me
<awilkins> I liked the merge I did from a branch that didn't even have a shared ancestry (but was a very similar tree) :-)
<markh> I've seen the awesomeness of bzr merging since then ;)
<awilkins> My users are getting to like it
<awilkins> Time for sleepsicles
<lifeless> markh: if its not in bundlebuggy, it won't get reviewed
<lifeless> being attached to a bug report is essentially useless
<markh> ok, I'll try that - thanks
<lifeless> jam: were you happy with my reply-to-your-review?
<lifeless> jml: please send your addCleanup improvements to bzr, or is that done ?
<lifeless> is there an operator.attrsetter I wonder...
<lifeless> bope
<lifeless> nope
<lifeless> there should be
<ToyKeeper> Hmm, speaking of not using launchpad features...  where should I send changes to bzr-merge-into?
<bob2> functools.partial + setattr!
<lifeless> oh eep
<jml> lifeless: they were approved, but maybe not landed?
<ToyKeeper> It appears to be jam's plugin, but I'm not sure what he uses for merge requests.
<jml> lifeless: I don't have commit privs.
<lifeless> self.addCleanup(functools.partial(setattr, bzrlib.btree_index, '_PAGE_SIZE'), original_size)
<lifeless> bob2: ^evil
<lifeless> ToyKeeper: I'd file a bug and attach a branch and propose for merging
<ToyKeeper> I did.
<lifeless> cool
<ToyKeeper> It was a month ago, and there was no response, so I thought maybe it needed to go through BB or some other channel.
<lifeless> oh
<lifeless> hey may not be subscribed to the branch; when reviews were added that was not set as the default
<lifeless> drop him a mail ;)
<ToyKeeper> ... just came to mind because of the mention earlier about not attaching patches to bug reports.  :)
<lifeless> ToyKeeper: yah, plugins are not all in BB though
<lifeless> I saw some merge-into work last week or so
<lifeless> possibly he just missed your patch?
<jml> lifeless: do you want me to chase up whether the patch landed or do you want to?
<lifeless> jml: no need
<jml> ok.
 * jml goes away
<lifeless> 11:15 < lifeless> self.addCleanup(functools.partial(setattr, bzrlib.btree_index, '_PAGE_SIZE'), original_size)
<lifeless> ^ thats too evil anyhow
<ToyKeeper> Hmm, the last rev looks like it implements part of what I changed.  I'll bug him about it later.
<jam> ToyKeeper: I certainly don't remember seeing any patches/branches for bzr-merge-into
<jam> lifeless: Your response to the log review was fine
<jam> lifeless: I would like a little bit more feedback on the btree stuff
<ToyKeeper> jam: https://bugs.launchpad.net/bzr-merge-into/+bug/252188
<ubottu> Launchpad bug 252188 in bzr-merge-into "subdir is always from repo root, not current dir" [Undecided,In progress]
<jam> ToyKeeper: hm... never saw that one. But I think it is already "fixed"
<jam> when I changed it to support the "canonical" form
<jam> ToyKeeper: can you check?
<jam> ToyKeeper: I think I did it by doing "WT.open_containing(join(this_location, subdir)) rather than the other way around
<jam> which also lets you do
<ToyKeeper> jam: Just checked, and trunk r7 seems to fix that issue.
<ToyKeeper> I fixed a couple other things too:  I made the subdir parameter optional (default to basename of LOCATION), and added missing '\n's on the output.
<lifeless> jam: well, I'm happy - thus the :tweak
<lifeless> I've replied and said roughly that
<jam> lifeless: sure, just trying to get some ideas about how to actually update it
<lifeless> righto
<lifeless> uhm, see if my mail helps
<lifeless> otherwise, I'm probably missing what you're asking :)
<jam> ToyKeeper: sure, I'll merge it and then revert out the one change, it will probably conflict anyway
<jam> ToyKeeper: did you ever "request a review" ? Or just propose it for merging?
<jam> lifeless: And BB is still much better for code reviewing, as you can see the whole diff
<lifeless> jam: you're probably not subscribed to the branch fully
<jam> Though I guess abentley is improving that
<lifeless> jam: yeah it is
<jam> lifeless: yeah, I just "subscribed" to my branch
<jam> ToyKeeper: though you didn't add tests for your functionality :)
<ToyKeeper> Hmm, I haven't used LP's code review features much yet.  I thought making a merge request automatically requested review from the owner of the target branch.
<jam> well, it would probably send me an email if I was subscribed to the branch
<jam> (which i am now)
<jam> but it isn't quite the same
<jam> request-review is a bit more focused on a specific person to review
<jam> as opposed to "anyone who is around"
<jam> anyway, your changes are merged
<ToyKeeper> I know they're pretty trivial changes...  I had forgotten all about it until lifeless said something to remind me.
<ToyKeeper> Anyway, thanks for the plugin.  It's handy.  :)
<ToyKeeper> Now I just need a way to do the opposite of merge-into...  split a subdir into a new branch with only that subdir's history.
<jam> ToyKeeper: with or without rebasing?
<jam> There is already "bzr split" which is a core command (it may only be exposed if you have -subtree formats)
<jam> But it still preserves *all* history
<jam> as you can't do otherwise without regenerating the history for those files
<ToyKeeper> Doesn't matter to me.  'bzr split' plus 'bzr remove-revision' would be fine, except the latter doesn't work.
<jam> i don't know what 'remove-revision' would even be trying to do
<ToyKeeper> It's at http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk/
<jam> ToyKeeper: that wouldn't do what you want anyway
<jam> It is only a "garbage collect" for unreferenced revisions
<jam> these are all referenced
<ToyKeeper> Ah.
<jam> as part of the history of the split out branch
<jam> You would really need to rebase, in which case the split out project could no longer be merged back into the old project
<jam> which is still good enough for what some people want
<jam> it wouldn't be strictly hard to do, though you have to get a little bit tricky at merge times
<fullermd> Well, if you rebuilt the history with the same file-id's, you could do a null-merge right off the bat, and it would work going forward.
<jam> fullermd: yeah, I think so, but I wouldn't bet on it :)
<fullermd> Well, I've used --file-ids-from to do similar things on a smaller scale.
<ToyKeeper> Yeah.  I just wanted to break a branch into pieces, because it included things which shouldn't have been together.
<jam> lifeless: your final review is what I was looking for, thanks
<jam> ToyKeeper: then again, it would still be in the history of the parent project, unless you regenerated all of *those* revisions
<lifeless> jam: cool
<ToyKeeper> I've occasionally seen svn people put every project into a giant shared repo, with /repo/trunk/project*/...  seems better to do one repo per project instead.
<ToyKeeper> I ran into something like that in bzr, and wanted to split the projects into completely independent repos.
<lifeless> I'd really like to be able to do bzr search -s "foo -bar"
<lifeless> but I need to think some more about how to do that elegantly
<lifeless> food first
<jam> lifeless: would you want a way to "refine" searches interactively
<lifeless> jam: like loggerhead does ? :)
<jam> union, intersection, etc
<jam> give me the revisions that match X
<jam> and then the subset that also match Y
<lifeless> meh, I meant to type 'bzr log -s "foo -bar"'
<jam> and as you mentioned
<jam> but *don't* match bar
<lifeless> jam: I am happy with google level complexity in the searches
<lifeless> jam: which is not much
<lifeless> jam: 'bzr search robert -collins' already works
<lifeless> back in 10, must eat food
<lifeless> so
<lifeless> jam: bzr search - I want to grow search types of date: (with before/after) and revision: etc, as well as handling NEWS and src/Makefile.am to match paths
<lifeless> ETIME
<rocky> jelmer: what is "bzr svn-branching-scheme" for exactly? :)
<jelmer> rocky, it's what determines what in the repository bzr-svn considers a branch (a place where bzr revision can be found)
<jelmer> changing it will break your existing imports though (you'll get DivergedBranches errors) so you'd want to stay away from it
<jelmer> it'll be replaced by something simpler in 0.5
<rocky> well, the output from:  bzr svn-branching-scheme https://dev.serverzen.com/svn/cluemapper/ClueMapper   shows just ClueMapper which is odd since ClueMapper isn't a branch
<jelmer> rocky, it determines what branching scheme it'll use based on what location you branch
<jelmer> you'd probably want "bzr svn-branching-scheme https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk"
<jelmer> since you're branching trunk
<rocky> right
<lifeless> man
<lifeless> I want marks so bad
 * lifeless starts on marks
 * RAOF_ ponders what "marks" could mean in a lifeless-bzr context...
<mwhudson> is it missing an apostrophe and "lovely hair" ?
<lifeless> https://lists.ubuntu.com/archives/bazaar/2008q3/044481.html
 * RAOF brushes his lovely hair.
<fullermd> Shoulder length or longer?
<RAOF> About sholder length.  Slightly longer.
<spm> lifeless: (ref 'marks' vs hair) - sounds (hand wavy) loosely like my experience with svn merge conflict handling via eclipse? Sorta thing. ???
 * RAOF contends that his internet will _eventually_ connect to lists.ubunut.com.
<mwhudson> ubunut ?
<RAOF> Yeah.  It's like ubuntu, but for squirrels.
<mwhudson> cool
<fullermd> So there are lots of long-term support releases, but you can't remember where you buried them?
<lifeless> spm: I don't know what your experience is
<jml> lifeless: marks?
<RAOF> Heh.
<jml> oh, link
 * jml reads
<RAOF> Yes!  I have lists.u.c connection.
<lifeless> jml: what do you think
<jml> lifeless: I think you should have someone who follows you around finishing the awesome stuff you start :)
<RAOF> That does look rather cool.
<lifeless> jml: that would be nice
<jml> lifeless: the design looks pretty good to me.
<jml> lifeless: IIUC, there are multiple named subsets of changes, one of which is selected?
<lifeless> some of which are
<lifeless> -Mreviewed,tests
<jml> lifeless: right, so what I mean is that I could select the 'tests' set of changes?
<lifeless> yes
<lifeless> or exclude it
<jml> right.
<lifeless> I'd love a web review ui for this
 * jml is busy on other Bazaar hosting issue
<jml> *issues, rather
<lifeless> well
<lifeless> it needs core code first
<lifeless> but as an end goal
<lifeless> imagine going to launchpad
<lifeless> doing half a review
<jml> yeah, that'd be sweet.
<jml> or in emacs
<lifeless> ya
<jml> lifeless: the plugin I should use to perhaps improve my push speed, what was it called again?
<lifeless> index2
<lifeless> which needs pybloom as well
<loxs> folks, probably i dont write it right, but I can't create a branch... i use the following syntax: bzr branch trunk/ tags/version1.6
<lifeless> and what happens?
<loxs> in windows bzr: ERROR: Not a branch: "D:/MyProject/MyProject/"
<lifeless> well, is it a branch?
<loxs> I have no idea, I'm a newbie :)
<loxs> I init-ed the project
<loxs> and commited it
<lifeless> ok
<loxs> now I want to create a branch
<lifeless> where did you init ?
<loxs> in the directory containing trunk/
<lifeless> so the directory containing trunk is your first branch
<lifeless> init creates a branch
<lifeless> (the first one in a project)
<loxs> so how do I create a branch tags/version1.6?
<lifeless> bzr branch <path to your current branch> tags/version1.6
<lifeless> what does bzr info show ?
<loxs> ok, parent of bersion1.6 doesn't exist
<loxs> after I create the dir tags, to I add it via bzr add?
<lifeless> no
<loxs> then I just md and create the branch?
<gour> loxs: reading of http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#concepts might help you
<loxs> I read that, but it's quite general :(
<lifeless> loxs: yes, you mkdir dir tags if it doesn't exist
<lifeless> loxs: then branch <current branch> tags/version1.6
<loxs> and when I commit, the version1.6 branch won't go to the central repo?
<loxs> hm, I think I start to understand the concepts now
<loxs> ok, thanks folks
<gour> it's not svn ;)
<loxs> yeah, i'm starting to realise it gour :)
<gour> loxs: yesterday, i tried for the first time bzr-svn...it's great. now i can use bzr to fetch from svn repos :-)
<gour> loxs: it's much more flexible when you get in. you'll see. good luck ;)
<loxs> thanks :)
<shodges> hey all, is there an equivalent to "svn status -u"? I want to see the changes on the remote branch before I pull them
<shodges> for bazaar, of course :)
<RAOF> shodges: I'm not entirely sure what 'svn status -u' does.  'bzr missing' will give you the log between the current tree and the remote tree, though.
<RAOF> (bzr missing will check against the default pull branch, or you can 'bzr missing $OTHERBRANCH')
<lifeless> RAOF: or diff -rbranch:other
<lifeless> shodges: or status -rbranch:other
<gour> missing might be the right thing...
<shodges> thanks everyone, i'll have a play around
<shodges> ok i've had a go, bzr missing is definitely useful, but what I want right now is something that will tell me which files have been modified, rather than the pending commits
<lifeless> shodges: 'bzr st -rbranch:URL'
<lifeless> shodges: as I said before :P
<shodges> yeah i thought so too lifeless, so i tried bzr status -rbranch, and i it threw a nasty stacktrace
<lifeless> really?
<shodges> i typed: "bzr status -rbranch:../test/src"
<shodges> which is a modified local branch i created for testing this out on
<lifeless> can you pastebin the traceback?
<shodges> sure can, just a sec
<shodges> this is the traceback: http://pastebin.com/d29ae0346
<gour> shodges: can you upgrade bzr?
<luks> gour: will not help
<luks> it's an old bug
<luks> (design issue)
<gour> luks: using absolute path?
<luks> no, -rbranch: is broken
<gour> ahh
<shodges> gour, i tried an absolute path as well, same output
 * gour wonders why would lifeless recommend it then
<shodges> i could try upgrading bazaar, but would i assume if the break is in my .bzr index then it will still throw the same error?
<shodges> I found a work-around: bzr merge --preview ../test/src | grep "==="
<shodges> not elegant, but does the job
<gour> shodges: at least, you can create alias for it :-)
<shodges> good idea gour :) i like "bzr missing" tho, will find them both useful in the future
<shodges> thanks for the help everyone
<lifeless> hmm
<lifeless> Its not a design bug
<lifeless> just needs to be fixed
<lifeless> either by upgrading the lock, allowing status to read from two sources, or similar
<luks> lifeless: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/35853
<lifeless> FF just bit it
<lifeless> I only saw the start of the page
<luks> jam had a similar fix for it, never merged too
<luks> I'm personally surprised that broken code is considered better than working code, even if following a bad design, but it's not my decision :)
<lifeless> uhm
<lifeless> you have a choice of break
<lifeless> broken on read only media
<lifeless> and broken when pull-is-needed
<lifeless> so its not 'broken vs working'
<lifeless> its 'broken in case A vs broken in case B'
<lifeless> and I think you're being rather judgemental saying the design is broken, when its not clearly a design issue
<jml> hello #bzr
<luks> lifeless: I was told that by jam and abentley
<luks> lifeless: the code needs to be rewritten to allow reading from remote repositories
<jml> I've got a branch, and I want to take one of the revisions and get rid of it.
<lifeless> luks: uhm I don't know if you're aware, but saying 'bad design' provokes a certain response
<lifeless> which is either agreement, or defense. I think the design is fine, thus you are getting defense
<lifeless> if you have a specific issue in the design, that would be worth talking about
<lifeless> jml: tip ?
<luks> lifeless: if two core devs tell me that it's was a bad choice to allow write operation on RevisionSpec, then I think it is a bad design
<jml> lifeless: is that a plugin?
<lifeless> jml: no, I'm asking if the revision is the tip revision
<jml> lifeless: oh, no.
<lifeless> in which case rebase is probably your easiest bet
<jml> lifeless: I know about uncommit :)
<lifeless> there was a thread recently
 * jml searches
<lifeless> luks: you've just doubled the granularity from 'bad design' to 'write operations on revisionspec is a bad design choice'
<lifeless> thats massively more informative
<lifeless> anyhow, as another core dev, I don't think it was a bad choice
<lifeless> I don't think its ideal
<lifeless> and I think we can do better
<lifeless> but given the constraints of the time, and the performance issues around the area, I think it was the right choice at the time
<luks> of course I meant the 'bad design' before only regarding to write operations in revisionspec
<luks> sorry for not beeing clear enough
<lifeless> I had no idea what you meant
<lifeless> and given, at last count, something over 50% of the core is ascribed to me by gannotate, a little clarity really helps :)
<luks> :)
<jml> also, another thing I'd like to do is review the diff of each commit in a range of revisions
<luks> well, anyway, I fully understand that there are better ways to fix it, but I don't understand why reject the lock upgrading as an interim fix
<lifeless> luks: because it breaks another not-uncommon use case - doing status in a tree where you can't write lock the repository
<jml> I guess it wouldn't be too hard to whip up a script
<lifeless> jml: yeah, or merge + commit-reviewed each individually
<luks> lifeless: it's already broken in that case
<jml> lifeless: well, it's more that I just want to look at them one by one
<luks> so it would be no worse
<lifeless> luks: how is it broken ?
<luks> lifeless: try bzr st -r branch:path/to/different/repo/branch if you don't have write acces to the local tree
<lifeless> luks: I didn't say tree, I said repository
<lifeless> luks: and I'm not talking about -r usage, plain ol 'bzr st'
<luks> lifeless: my patch used lock_write only if the revisionspec requires it
<luks> so in plain bzr st it would use lock_read
<luks> and in case lock_write is not available, st -rbranch is broken anyway
<luks> so yes, there are still cases where it's broken, but it would fix the main use case
<lifeless> luks: well, I've just replied with a small change to allow status to work
<luks> hm, as_revision_tree is a good idea
<lifeless> probably < 2 hours work if you're interested in doing it, and its straight forward
<lifeless> or even 'as_tree'
<lifeless> for a possibly better/more useful interface
<luks> I realise that, but there are some cases where the remote branch instance is required as well
<luks> so it would need one more interface for those cases
<lifeless> for status?
<luks> no
<lifeless> well, details then, and I can comment
<luks> what I was primarily interested in was adding a global lock around diff
<luks> I see that revisiontree has _repository, which would be enough, but that's private
<lifeless> what do you need a repository object for ?
<luks> oh, wait, I don't
<luks> yeah, you are right
<luks> I will probably look into this over weekend
<luks> as_revision_tree is really a good way to solve this
<lifeless> I think I'd call it as_tree
<lifeless> to allow real and revision tree objects
 * jml gets confused by rebase
<lifeless> jml: it is confusing
<lifeless> jml:  you want replay
<lifeless> jml: and to skip the revision you don't want
<lifeless> jml: or just do cherry pick merges all the way up
 * jml finally has a happy branch
<jml> this is the danger of learning in front of Idol
<gour> are looms better than using rebase?
<jml> gour: yes.
<luks> they are something different
<jml> fsvo 'better' :)
<jml> lifeless: so, I've got a testresources branch without those licensing changes. do you want any other changes before re-review?
<lifeless> uh, anything else I said my mail
<lifeless> jml: if there isn't a NEWS file, we should add one that describes how existing users need to change their resources to accomodate the patch
 * jml adds one and resubmits
<gnomefreak> how would i remove a push i made. i used uncommit but now i need to merge them but i dont want that push to be htere
<gnomefreak> there
<luks> you can push --overwrite
<luks> but double check you are not overwriting something you don't want to
<gnomefreak> will try it
<luks> also, this is a bad thing to do on a public branch
<luks> if there is a possiblity other people have branched/pulled from it
<^_-> hm
<^_-> what's the main difference between a repository created with --no-trees and one that isn't?
<^_-> er rather
<^_-> what's the advantage and disadvantage of creating a repository with --no-trees ?
<siretart> you have no trees, that is, you save space for the checkouts, and branching is a bit faster, since you don't need to build them
<^_-> siretart, so this should be used for central servers?
<^_-> er would be best used
<lifeless> ^_-: or if you want to reuse a single tree
<lifeless> which C style languages often want to
<lifeless> because compilation is slow
<^_-> heh
<luks> lifeless: can I please get a review of http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1219921582.6859.3.camel%40nemo%3E (it's really trivial, and introduced by your change)?
<Peng_> Is it just me, or is bzr-search broken on bzr.dev?
<lifeless> shouldn't be broken, works for me
<Peng_> Hmm
<Peng_> I just pulled bzr.dev and bzr-svn for the first time since yesterday or so, and bzr-search exploded.
<Peng_> bzr.dev r3652 (the log filtering stuff) broke it.
<Peng_> If I revert to the revision before that, it's fine.
<james_w> where's the heads plugin?
<Peng_> Where?
<james_w> I can't find it on the plugin page, nor via google
<Peng_> james_w: Oh. bzrtools, apparently
<james_w> ah, thanks
<Peng_> It was merged into bzrtools in May.
<thumper> lifeless: is there a package for bzr-svn?
<thumper> or anyone for that matter
<thumper> jelmer: ?
<Jc2k> thumper: there is one in PPA i think
<thumper> Jc2k: thanks
<thumper> Jc2k: which one?
<Jc2k> thumper: https://launchpad.net/~bzr/+archive
<thumper> Jc2k: thanks
<Peng_> lifeless: r3652 breaks bzr-search on another computer too (where I have the exact same plugins, but..)
<james_w> Peng_: with a traceback, or just "not work"?
<Peng_> Hm
<Peng_> james_w: Just "Unable to load plugin 'search'"
<james_w> Peng: -Derror?
<beuno> the traceback goes to .bzr.log  (hi)
<Peng_> Yeah, I was just looking at .bzr.log. Hold on, I'll pastebin.
<james_w> bey beuno
<james_w> I find -Derror more convenient, but they both work
<Peng_> http://paste.pocoo.org/show/83610/
<beuno> james_w, aaah, interesting. It is much more convinient
<Peng_> I've never used -Derror before. I'll try to remember it.
<lifeless> Peng_: you need 3653 perhaps ? :)
<lifeless> Peng_: sorry, rev 55
<lifeless> Peng_: and then you can try log -m '\bfoo\b' and go oooo at speed
<lifeless> luks: can you drop me a mail please
<lifeless> luks: I will review tomorrow
<luks> lifeless: thanks
<Peng_> lifeless: Eh?
<lifeless> Peng_: bzr-search rev 55
<lifeless> Peng_: committed 8 or so hours back; grab it :)
<Peng_> I am on that revision, though I didn't know it.
<lifeless> hmm
<Peng_> I pulled bzr-search at the same time as bzr-svn and bzr.dev, and the first time I pulled, there was a traceback, but I wasn't able to reproduce it.
<lifeless> all the references I can find ot make_search_filter are _ prefixed in bzr-search rev 55
<lifeless> Peng_: try 'bzr update' or 'bzr revert' in your search branch
<lifeless> I bet the tree is out of date, if search was borked
<Peng_> lifeless: You are correct.
<Peng_> Now it works.
<Peng_> How did that happen? I needed to run "bzr update". I guess that traceback did it?
<lifeless> so pull updates branch, then tree
<lifeless> I bet that search crashed on the branch update after the tip changed, before the tree is update
<lifeless> d
<Peng_> Hah, the exact same thing happened when I pushed the new revisions of bzr-search to the other computer.
<Peng_> Same traceback, and it didn't run "update".
<Peng_> But I ran update and now it's okay.
<lifeless> now
<lifeless> grab an indexed branch
<lifeless> and run bzr log -m '\bSEARCHTERM\b'
<Peng_> I guess I shouldn't update software while it's running.
<lifeless> try it again with --no-plugins
<lifeless> the traceback was because I pushed rev 54 yesteday
<lifeless> which added log -m support with my custom branch
<Peng_> I was on rev 53.
<lifeless> then bzr.dev broke than when the reviewed code landed
<Peng_> I think.
<lifeless> where you? I doubt it
<Peng_> Yeah, I was.
<lifeless> oh
<lifeless> I forgot 55 was trivial
<lifeless> yeah 53 would do it
<Peng_> ok
<lifeless> its just a case of 'you ran trunk'
<Peng_> :)
<lifeless> anyhow
<lifeless> how does the log acceleration work for you ?
<Peng_> I don't have any large branches with indexes.
<lifeless> ah, k
<lifeless> should still be faster on small branches
<Peng_> On one branch, it takes ~0.7 seconds either way.
<lifeless> oh yeah, thats under threshold :P
<Peng_> It bothers me that you can do "bzr pull -v", but if there's a traceback at the wrong time, you'll have no idea you pulled anything.
<lifeless> mmm
<lifeless> probably has to do with how pull -v is hooked in
<Tak> is it recommended to use --hardlink when branching locally?
<ricardokirkner> hi. I am trying to check out  a project from launchpad, and I am getting a connection timeout (I am behind a http proxy). I have set up the http_proxy variable, so I dont understand why I am gettig the timeout. how can I debug this issue?
<techtonik> ricardokirkner: add -Dhttp to command line
<techtonik> also bzr help global-options
<lifeless> ricardokirkner: is your proxy squid 2.6stable23 or less ?
<techtonik> lifeless: How can I specify proxy for bzr+ssh connection?
<lifeless> techtonik: bzr+ssh doesn't use http at all
<lifeless> techtonik: it uses ssh
<techtonik> I know.
<ToyKeeper> techtonik: I'd suggest using ~/.ssh/config to configure bzr+ssh details.
<techtonik> I am on windows.
<techtonik> My proxy supports CONNECT, but I need to bzr somehow to use it.
<lifeless> techtonik: unless you can find a ssh http-tunnel (there are some) for windows ...
<ricardokirkner> lifeless, might be.. it's squid for sure. i don't know about the version
<lifeless> ricardokirkner: there was a bug in squid, which we fixed, that is exacerbated by bzr's use of range requesws
<techtonik> That's bad. Without proxy bzr+ssh worked without problems without any special tools except pageant for storing keys  (I suppose through paramiko). Now I just need to specify proxy. Should I fill a bug report?
<lifeless> ricardokirkner: it leads to very long delays in someoperations
<lifeless> ricardokirkner: alternatively, if you've logged into launchpad, it may be trying to use bzr+ssh and if you have a firewall preventing ssh, timing out on that - so not http related at all
<ricardokirkner> should I try to log out from launchpad? I am logged it, but haven't yet uploaded my ssh key
<lifeless> ricardokirkner: you ran 'bzr launchpad-login' ?
<lifeless> techtonik: uhm, you can file a bug, but there isn't anything bzr can do - here's why
<lifeless> techtonik: we already support bzr+http and plain http - they proxy just fine.
<ricardokirkner> lifeless, no.. do I need to do that in order to branch a lp project?
<ricardokirkner> is it not possible to branch a project without having a user in lp?
<lifeless> techtonik: bzr+ssh, to tunnel over http proxy, will need ssh support, and bzr calls out to ssh, its not something bzr has any deep control over
<lifeless> ricardokirkner: its totally possible, I was just trying to check I understood your setup; if you _have_ logged in with bzr to lp, you can get a different network protocol used
<ricardokirkner> lifeless, ok. no I haven't logged in
<lifeless> ricardokirkner: so ifyou have not run launchpad-login from bzr, then its going to be using plain http I expect
<ricardokirkner> via bzr
<ricardokirkner> I am logged in in the web ui
<lifeless> ricardokirkner: make sure you have exported the http_proxy and https_proxy variables
<lifeless> techtonik: anyhow, its not the proxy that is the problem, its any related firewall :)
<Tak> if I unbind, then rebind, what happens to the uncommitted changes in my local branch?
<techtonik> lifeless: i am using SVN without any problems and even without any additional tunnels. i am wasting yet another day trying to push a change with bzr =(
<techtonik> If I use https it fails - Transport operation not possible: http does  not support mkdir()
<techtonik> If I use bzr+ssh - it also fails with 10060 timeout.
<lifeless> techtonik: svn+ssh would have exactly the same problem. What bzr service are you pushing to ?
<techtonik> launchpad
<techtonik> http://bazaar.launchpad.net/%7Etechtonik/codeblocks/devpak-plugin
<jelmer> james_w, Sorry, I couldn't leave the merge-upstream-branch code alone; it's now updated against latest bzr-builddeb trunk
<james_w> jelmer: well, no need to be sorry, I'm not going to complain about that.
<james_w> I'll merge the four outstanding branches when I get a free minute, thanks for your help.
<jelmer> james_w: Cool, thanks!
<james_w> and I'll subscribe to the branches so that I don't miss things again.
<ricardokirkner> lifeless, ok, the proxy setting was fine, because I could branch the project using the http address directly, instead of using the lp: address
<ricardokirkner> so, maybe using lp: uses a non-http port? (which is surely filtered by our firewall)
<Necoro> ricardokirkner: iirc, if you are "logged in" into LP on your machine, it uses bzr+ssh instead of http
<lifeless> ricardokirkner: it does a XMLRPC check, which is https, first.
<lifeless> I'd bet that that is what failed
<lifeless> ricardokirkner: or you're logged in :)
<ricardokirkner> so, if i am logged into the web ui, then it tries to do bzr+http
<ricardokirkner> ok
<Peng_> lifeless, james_w and beuno: Since I forgot to mention it, thanks for the help with bzr-search earlier. :)
<ricardokirkner> I will try to log out from launchpad.net
<ricardokirkner> thank you
<Necoro> ricardokirkner: no
<Necoro> logged in on your machine
<Necoro> i.e.: having run launchpad-login
<ricardokirkner> Necoro, ok, I didn't login using launchpad-login
<ricardokirkner> so that's not the problem
<Necoro> ricardokirkner: than it is probably as lifeless said ;)
<ricardokirkner> I will check it on some other machine that is not behind the firewall... I guess it's a firewall related problem
<orospakr> Hey, how does one refer to a given commit in a project across all branches?  It seems that commit numbers differ (even for the same commit!) depending on what branch you're on.
<Necoro> orospakr: use the rev-id
<onox> how can I remove just a specific revision? for example I have rev 1,2,3,4 and I want to have rev 1,2,4
<orospakr> ah, I see
<orospakr> onox, nuclear launch codes? ;)
<onox> lol, no
<onox> I just want to get rid of some revisions that contain some .tar.gz files
<onox> is that possible?
<abentley> onox: Revisions are states.  The state of revision 4 is based on the state of revision 3.  So you would have to create a new revision 3, with only the changes made in revision four.
<abentley> You can do that with merge, e.g. "bzr merge -c 4 ../my-old-branch".
<uws> abentley: ...but that isn't tracked. Is merge tracking planned?
<uws> for cherry-picking, that is.
<abentley> uws: Yes.
<uws> it would be GREAT to have for many projects.
<onox> abentley: how can I do merge revisions 4 and 6? -c 4,6 doesn't seem to work
<abentley> You want to combine revisions 4 and 6 into one revision?
<onox> no, just 2 merges
<uws> onox: just do it twice
<uws> merge -c4; merge -c6
<onox> then bzr complains about uncommitted changes
<uws> commit in between
<uws> in bzr, you need to commit your merges
<ToyKeeper> well, it's possible to merge more than once without committing between...  but strongly discouraged.
<onox> I want to do 1 commit of (in this case) 2 pending merges
<uws> onox: afaik, you can't do that with cherry picking, only with regular merges
<onox> hmm
<abentley> onox: That would mean committing 4 and 6 as one revision.
<onox> yes
<onox> if I use -c I don't see "pending merges" in bzr stat
<abentley> onox: That is true.
<abentley> You are creating a new revision, as I said from the start.
<abentley> In this cause, merge is just a way of applying the changes you made in 4 & 6.
<ToyKeeper> Is the cherrypick merge data recorded but not used?
<ToyKeeper> ... because, if not, you could just apply the patch from r4 and then apply the patch from r6, and commit.  It'll look like an entirely new revision, but ...  it would anyway.
<abentley> ToyKeeper: No, the cherrypick merge data is not recorded.
<onox> so with bzr there's no way to get rid of a specific rev?
<ToyKeeper> You could uncommit it, if it's on top.  Or possibly do something clever with rebase.
<onox> rebase command doesn't exit
<ToyKeeper> ... exist?
<onox> yes, exist :p
<ToyKeeper> It's at 'bzr branch lp:bzr-rebase', I think.
<abentley> onox: There's no way to get rid of a specific rev while keeping the following revs.
<abentley> rebase command has the same effect as merge -c.  Which is also true in Git.
<onox> is it possible to just merge the revisions of some directory of some branch?
<onox> it seems it's possible, but bzr stat doesn't show "pending merges"
<abentley> onox: Correct.
<onox> why no "pending merges"?
<onox> because it cherrypicks again?
<abentley> onox: A "pending merge" is only shown when you apply all changes.
<onox> and why not if I apply all changes to some directory?
<abentley> Because that would mean you applied all the changes, and then removed the changes that didn't apply to that directory.
<abentley> And when someone merged from you, it would remove all those other changes.
<onox> is it safe to just merge everything, remove some .tar.gz files I don't want, and then commit?
<jam> vila: in trying to follow lifeless's response about the trie. He uses the abbreviation "HP" do you think he means "PH" for Partion Hashing? Since that seems to be the closest term I've found in the paper he referenced
<Hydrogen> so..
<lifeless> jam: hash partition
<jam> lifeless: sure, but the only place the abbreviate is PH not HP, though they say each node tracks its "hash partition"
<jam> anyway, you didn't define the term :)
<Hydrogen> I'm trying to create a bzr branch from a svn+ssh login'd server on windows.  I've installed bzr-svn and bzr, but when I run the command bzr crashes... is there a way to make it not crash? :)
<jam> which made the paragraph a bit tricky, but to understand it anyway, I'll read the paper
<abentley> onox: You should not make any unnecessary changes when merging.  That can mess up later merges.  So merge, commit, remove, commit.
<jelmer> Hydrogen, what versions?
<onox> abentley: k, thx for the advice
<jam> On first pass, I agree that HP doesn't look like it plays well with partial updates and a "canonical" representation
<Hydrogen> bzr 1.6b3... maybe I should update to 1.6 final :)
<vila> jam: he said " The tree we build is essentially a tree of hash partitions" at the start of the paragraph he first mentioned HP
<Hydrogen> mm, still crashing after updating
<Hydrogen> 1.6 final
<vila> lifeless: ho, you're still there ! Are you still in AU ?
<lifeless> yes
<jam> ah, k
<jam> I guess that part didn't "stick".
<jam> I *did* read it
<jam> Hydrogen: can you give any more info than "it crashes" Like run with -Derror and pastebin a traceback?
<jam> ubottu: 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)
<Hydrogen> well, I would, except the silly windows crash handler pops up without being helpful
<jam> Hydrogen: so you are getting something like a segfault? Rather than a traceback + exception
<Hydrogen> yea
<jam> sounds like something wrong with the svn bindings
<jam> as we don't have a lot to segfault in the bzr code
<jam> Hydrogen, jelmer: Could it be an issue with the subversion libraries?
<jam> Does 'bzr-svn' on windows bundle the subversion library?
<jelmer> jam: I'm not sure, haven't ever tried it. Mark packaged it
<jam> Hydrogen: my initial guess would be lib/dll skew. Where bzr-svn is compiled against say svn-1.4 and you are using 1.5
<Hydrogen> hmm
<Hydrogen> that could very well be it
<jam> jelmer: there doesn't seem to be a 0.4.11-svn, just 0.4.9
<jam> Does 0.4.9 *work* with 1.6?
<jelmer> no, it won't
<jam> jelmer: but would it segfault?
<jelmer> I think mark packaged it as part of bzr itself though
<jelmer> jam, It would probably warn you first
<Hydrogen> hmm, using svn 1.4.6 or 1.5.0, both crash
<jam> jelmer: I know he brought in some other stuff, I didn't think he included bzr-svn, I could be wrong
<Hydrogen> however, I may not have the python-subversion bindings... but not sure where to put them
<jelmer> Hydrogen, what did you install exactly?
<Tak> btw, I'm successfully using bzr 1.5 with the bzr-svn windows package and svn 1.5
<Hydrogen> bazaar is in c:\program files\bazaar; subversion is in c:\program files\subversion :)
<uws> bzr 1.6.x + bzr-svn works well with svn 1.4  as well
<jam> Tak: that is the 0.4.9 version of bzr-svn?
<Hydrogen> I have 0.4.10 of bzr-svn
<Tak> 0.4.10
<Tak> I also have the python subversion bindings installed
<Hydrogen> bzr-svn-0.4.10-svn-1.4.6-setup-0.exe
<jam> Tak: here did you get that from?
<Hydrogen> where do I install the python subversion bindings to :)
<Tak> jam: which?
<jam> 0.4.10
<jam> I don't see it on the LP download page
<jam> so I'm wondering where it is
<jelmer> Hydrogen, 0.4.10 won't work with bzr 1.6
<Hydrogen> ah
<Hydrogen> I need 0.4.9 then?
<jam> Ah, it seems someone has "unofficial builds": http://d5190871.u44.websitesource.net/bzr-svn/
<jelmer> Hydrogen, no, 0.4.11
<Hydrogen> oh
<Hydrogen> okay
<Hydrogen> :)
<jam> Hydrogen: no, you need 0.4.11, but either way they shouldn't be segfaulting
<Tak> http://d5190871.u44.websitesource.net/bzr-svn/ , linked from the Subversion page
<jelmer> Hydrogen, there's no need for python subversion bindings to be installed anymore
<Hydrogen> okay
<jelmer> Yeah, that's Kevin Lights' page
<Hydrogen> thanks
<jam> I'm hesitant to trust a website at "d5190871.u44...."
<Hydrogen> I'll grab the new version
<jam> sure looks like a scammer :)
<jam> Hydrogen: unfortunately, 0.4.11 doesn't seem to be packaged yet
<jelmer> markh, ping
<jam> markh is in AU time, and is probably sleeping right now
<jelmer> ah, ok
<jelmer> Mark did say he intended to package bzr-svn
<jelmer> and we spent some time improving things in bzr-svn on Windows
<Tak> pff, timezones
<Tak> jam: it's linked from http://bazaar-vcs.org/BzrForeignBranches/Subversion#windows-setup
<Hydrogen> jelmer: It can't be too impossible to build though, right? :)
<jam> Tak: yeah, I found it that way. I'd rather have "official" builds :)
<jelmer> Hydrogen, if you have a C compiler, it should be doable
<Hydrogen> huzzah
<Hydrogen> we're safe then!
<Tak> hmph, I spent about 5min trying to build it on cygwin, then gave up and went back to bzr1.5
<jam> jelmer: well, and the svn dev libraries
<jam> and some other bits
<jam> jelmer: so the 1.6-setup.exe just gives "Default plugins" which is a 7.2MB install, but doesn't give any more details.
<jelmer> ah
<Tak> afaict, no svn plugin dir was created by the 1.6 installer
<jelmer> according to Mark's announcement, bzrtools, qbzr and bzr-svn are included in the setup for the rc
<jelmer> (1.6rc3)
<Hydrogen> well, that didn't help :)
<jelmer> Hydrogen, what did you try?
<Hydrogen> downgrading to 1.6rc3 with the bundled one
<jelmer> still segfaults?
<Hydrogen> aye
<jelmer> are you trying to checkout a public svn branch?
<Hydrogen> It crashes on a public or a not public
<Hydrogen> well
<Hydrogen> a public (anonsvn) or one that requires svn+ssh credentials
<jam> markh: what are you doing awake?
<awilkins> How hard would it be to make the HPSS 100% smart? (at the moment a large percentage of it is still dumb, i.e. makes plain HTTP GET requests)
<abentley> The HPSS does not make HTTP GET requests, because it runs on multiple protocols, including http(bzr+http:) ssh (bzr+ssh:) and direct tcp(bzr:)
<jam> abentley: I think it still does a couple GET requests for stuff like .bzr/branch-format
<jam> awilkins wants "bzr branch" to only POST to .bzr/smart
<jam> with no other GET requests
<awilkins> That's essentially it
<jam> apparently IIS 6 is hard to configure correctly
<awilkins> Having problems getting it to run on IIS 6 because it's awkward to get it to serve files AND direct requests to QSGI
<awilkins> WSGI
<abentley> awilkins: And this behavior is observed with bzr+http, not the autodetection?
<abentley> jam: i would have expected those to go over the HPSS vfs layer.
<awilkins> abentley: Yes, I've got a proxy sniffer and I can demonstrate it's behaviour ( I think I posted a session as an attachment to an IIS bug)
<awilkins> The other option I have is to patch PyISAPIe which is the extension I'm using to serve it
<awilkins> There is supposedly a mechanism to "pass to next handler" which could be used, but I'm a bit rusty on C and exposing it in Python
<abentley> jam: But in fact, if HPSS is making a cacheable request, it would make sense for it to use a GET.
<jam> awilkins: just to mention, it may be easier to have the "wgsi" server serve out GET requests
<Okkin> Hi,
<awilkins> jam: That would also be a reasonable idea
<jam> awilkins: is there any chatter on GET after the initial connection?
<Okkin> How can I get a pending merge message to use it as my commit message ?
<jam> (I don't think HTTP transport as-a-medium changes the HPSS requests back into HTTP ones, but I was hoping for confirmation)
<abentley> jam: Ooh, branch-format being the bzrdir format file.
<awilkins> jam: I'll set an HPSS up on my local box and trace a few sessions
<jam> abentley: right
<abentley> I guess it makes me a bit nervous to start posting before we even know we're looking at a Bazaar control directory.
<jam> Okkin: "bzr log -r-1 ../old-branch" ?
<jam> abentley: though if you already have "bzr+" ...
<jam> certainly we don't do a different access
<jam> for bzr+ssh or bzr://
<Okkin> jam: the merge came from a merge directive file
<Okkin> jam : I fdon't have acces to the branch it came from
<jam> Okkin: ATM, we don't have a good way to grab it, you could "bzr branch . ../other; cd ../other; bzr pull --overwrite ../merge_directive; bzr log -r -1"
<jam> It isn't great by any means
<jam> but it would get you there
<jam> Okkin: there is an alternative
<jam> just a sec
<jam> grab the revision_id from the merge directive (it is in the top)
<jam> and do
<jam> bzr log -r revid:XXXXX
<Okkin> jam : ok I'm trying
<abentley> jam: if you have a CGI script "http://example/foo.cgi", POSTING to "http://example/foo.cgi/.bzr/branch-format" will usually invoke it.
<jam> abentley: well we GET that URL, not POST
<jam> but I would imagine it is still invoked
<rockstar> abentley, did you ever finish your work with PreviewTrees?
<abentley> jam: awilkins is proposing that we post to it.
<abentley> rockstar: No.
<jam> rockstar: it was pending a review from Ian, who is only just now out of hospital, and he didn't seem to think my :approve was enough :)
<abentley> jam: actually, I've just been slack.
<jam> abentley: I'm pretty sure he is proposing that we post to .bzr/smart
<jam> and use smart requests
<jam> to do the probing
<abentley> jam: Before looking at .bzr/branch-format?
<rockstar> jam, abentley, doh!  I can see the functionality being helpful.
<jam> abentley: Again, we don't look at files before bzr+ssh:// or bzr://
<jam> we probe using the smart server
<jam> So for "bzr+http://" we could do the same
<jam> I agree that doing so for "http://" isn't as reasonable
<abentley> jam: The possibility of accidental damage seems much lower over bzr: or bzr+ssh.
<Okkin> jam: Too bad, it's not working
<jam> The possibility for accidental damage over "bzr+http://" isn't very high
<jam> Okkin: what is happening?
<Okkin> jam: bzr: ERROR: exceptions.ValueError: list.index(x): x not in list
<jam> Okkin: sounds like an old bug which has been fixed
<jam> are you using "--short" or "--long" for log
<jam> And what version of bzr?
<abentley> jam: We can POST to a random CGI script.  That seems troubling to me.
<Okkin> jam: bzr 1.6
<Okkin> jam: I follow exactly your command
<Okkin> jam: no --short or --long
<jam> Okkin: that is *after* doing the merge?
<jam> weird, because it would have needed to pull the revision in
<Okkin> jam:yes
<jam> let me check
<Okkin> jam: I can see the begining of the message in the pending merges section of "bzr status"
<jam> crummy, I forgot about the -rrevid: bug when revision_id isn't in your ancestry...
<jam> Okkin: ok, here's a nasty workaround
<jam> bzr commit -m "bogus"
<jam> bzr log -r revid:XXX
<jam> bzr uncommit
<jam> It will work fine
<jam> just is unfortunate
<Okkin> jam: lol good idea
<Okkin> jam: It worked, thanks a lot
<gour|away> jelmer: hello. just saw your email that you cannot reproduce #261878...any hint what to do?
<awilkins> HPSS on IIS 6 : I think that protocol behaviour may have changed by the time 1.6 was out
<awilkins> I just ran a bzr ls bzr+http:// and it was all /smart requests
<jam> awilkins: I would guess "bzr ls http://" would have an initial GET and then the rest would be smart requests
<awilkins> jam: Nope, it does the smarts first
<jam> that certainly could be something new
<jam> in 1.6 or so
<awilkins> jam: Then it hits branch-format, pack-names, indices
<awilkins> THe "meat" of the request is non-smart
<jam> awilkins: so even if the smart request *succeeds* it still does non-smart requests?
<awilkins> jam: Looks that way
<jam> that is a bit surprising
<awilkins> jam: I'm not sure it's succeeding, theres a lot more hits
<awilkins> jam: Tell you what, I'll trace both and upload the sessions to a file bin
<jam> awilkins: I have a strong suspicion it failed
 * awilkins cannot understand why it works fine for explicit bzr+ but not for plain
<Peng_> Is there a 1.6-subtree format? If so, due to bug 262333, is it identical to 1.6-rich-root?
<ubottu> Launchpad bug 262333 in bzr "--1.6-rich-root uses wrong serializer" [Critical,Confirmed] https://launchpad.net/bugs/262333
<awilkins> http://filebin.ca/uahmt/bzr_smart_ls.saz
<awilkins> http://filebin.ca/uahmt/bzr_smart_ls.saz
<awilkins> Bum
<awilkins> http://filebin.ca/eywnh/bzr_dumb_ls_smart_server.saz
<jam> awilkins: and .saz is?
<awilkins> These are zip archives with a little website in each
<awilkins> .saz "session archive zip" the output of Fiddler2 which is an MS proxy debugger
<awilkins> The sessions are straight from a branch of lp:bzr/1.6 on windows doing an ls on IIS 7.0 on Vista, running a BZR HPSS via PyISAPIe in tandem with a dumb service via traditional "serve them files"
<awilkins> The branch is the current tip of lp:bzr-java-lib
<jam> awilkins: well, it gets to the point where it finds the Branch.last_revsion via smart requests
<jam> and the containing repository
<jam> but then it seems to connect a second time
<jam> when opening the repo
<awilkins> Hmm.
<jam> so it finds a RemoteBranch and a RemoteRepository
<jam> grabs RemoteBranch.last_revision_info()
<jam> and then re-opens a Repository
<jam> directly
<jam> and grabs the last-revision content
<awilkins> Why does it step up the tree to the repo? The first session doesn't
<jam> awilkins: care to put some debug statements in bzrlib, or are you using the standalone?
<awilkins> jam: I don't use the standalone, can't hack it
<awilkins> That was from a branch ; my installed version is getting the "pycurl read bytes notimplementederror" problem
<awilkins> Suggestions where to shove debug?
<jam> awilkins: the interesting command here is going to be BzrDir.open_containing_tree_or_branch
<jam> awilkins: and the actual probing is in bzrdir.py around line 779 for "open_from_transport"
<awilkins> find_format ?
<jam> and at line 1604 is where it is supposed to be probing for the smart format
<jam> RemoteBzrDir should be the first object it probes for
<jam> line 2591 is where it is actually POSTing to the remote host
<jam> in the medium.protocol_version() is the first POST
<jam> which I see happening
<jam> and getting a valid response
<jam> hmm... it would seem the auto-probe does something weird
<jam> in that it probes, finds a RemoteBzrDir
<jam> but then using a regular Transport object for the final format.open()
<jam> awilkins: so, the actual Transport object is different between "http://" auto probing
<jam> and "bzr+http://"
<awilkins> Ok, that's weird
<jam> HTTPTransport.get_smart_medium() returns 'self'
<jam> because technically it can proxy the POST commands
<jam> but it *doesn't* use the VFS
<jam> of the smart server
<jam> awilkins: so one possibility
<jam> is to edit bzrlib/transport/http/__init__.py
<jam> @ line 172 in "get_smart_medium()"
<jam> and change that to
<jam> from bzrlib.transport import remote
<jam> return remote.RemoteHTTPTransport(self.base, http_transport=self)
<jam> awilkins: that should prevent you from getting mixed GET and POST
<jam> the way it stands if you use plain "http://"
<jam> it will serve all FS requests via plain http
<jam> but any smart protocol requests via POST .bzr/smart
<jam> If you use bzr+http:// then even the FS requests go through POST
<awilkins> That seems to cause infinite recursion
<jam> abentley: what do you think, it almost seems valid to do it this way, as you say "cachable things get requested directly". But I can understand why in messes up awilkins
<jam> awilkins: you might also need to supply "_from_transport"
<jam> so it would be
<jam> RemoteHTTPTransport(base, self, self)
<jam> or put a bit cleaner
<awilkins> bzr: ERROR: exceptions.AttributeError: 'RemoteHTTPTransport' object has no attribute 'should_probe'
<jam> RemoteHTTPTransport(base, self, http_transport=self)
<jam> awilkins: that's just a bug in RemoteHTTPTransport, I'll check in a sec
<jam> awilkins: change line 46 of bzrlib/transport/remote.py
<jam> to: class RemoteTransport(transport.ConnectedTransport, medium.SmartClientMedium):
<jam> so that it looks the same as HTTPTransport
<jam> (that may break some of the super(self).__init__ calls
<jam> but we'll try it first
<abentley> jam: It seems unnecessarily complex to have bzr+http and http behave differently in smart mode.  I would prefer using real HTTP, not VFS, but it's not critical.
<jam> abentley: well, obviously awilkins prefers if we can get all-VFS
<jam> since IIS6 doesn't like doing both
<jam> and our WSGI server doesn't implement GET requests
<awilkins> The alternative is to work out how to "pass" the request to the next handler in the ISAPI extension I'm using
<awilkins> Which I think means changing the C code for it
<abentley> jam: If IIS6 is going to be a thorn in our side, I can support using all-VFS.
<awilkins> Although I've not seem definitive documentation for it my hypothesis is that you need to call ServerSupportFunction with HANDLE_URL (or whatever the magic const is)
<abentley> jam: But it seems kinda strange to forbid plain http.
<awilkins> IIS 6 does support multiple "wildcard" handlers in a chain (including itself, one presumes) so it shouldn't be impossible
<jam> awilkins: of course, you could just say: "use bzr+http://" if you want all smart requests
<jam> and use "http://" for "mixed" mode
<jam> awilkins: do you have a bug open for this, it seems worthwhile to add some commentary
<jam> about what we've found
<jam> I also think that RemoteHTTPTransport *not* subclassing SmartClientMedium is a plain bug
<awilkins> jam: Yes, that is a viable workaround for me now I've discovered it forces all-smart
<jam> that just hasn't bit us yet
<awilkins> jam: ServerGuide/IIS discusses this now a little
<awilkins> IMHO it's more a bug in IIS 6 vs 7, or a missing feature opportunity in PyISAPIe
<jam> awilkins: sure, though I would also like it documented about "mixed mode" since it is unclear whether it is intentional or a bug
<awilkins> Bug going up now
<awilkins> The other possible nasty frig would be to allow it to use URLS that ended /smart.bzr
<awilkins> Because IIS6 can field things with file extensions, just not blunt ended URLs
<awilkins> Bug #262366
<ubottu> Launchpad bug 262366 in bzr "Smart server uses mixed mode for HTTP URIs" [Undecided,New] https://launchpad.net/bugs/262366
<fbond> Hi, I don't really get what the record command is for.  I've been using looms for a while and I've never touched record.
<fbond> Anyone care to explain it?
<mwhudson> fbond: it's like 'commit' for the whole state of the loom
<fbond> So I can pull an entire loom after I've recorded?
<mwhudson> fbond: given that the code hasn't been written yet for much of the stuff to do with sharing looms, it's a bit of an oddity right now
<mwhudson> fbond: that's the idea, at least
<fbond> mwhudson: Ah.
<fbond> mwhudson: So it might fit with future commands like "pull-loom"?
<mwhudson> fbond: and merge-loom! (which would be pretty cool)
<fbond> mwhudson: merge-loom sounds scary.  I, for one, am not that interested in parallelizing conflicts. :)A
<mwhudson> i'm not entirely sure what it would mean
<abentley> fbond: pull-loom already exists, as "pull".
<abentley> This is why you have to record your loom before pull works.
<kiorky> jelmer: ping
<Leonidas> is there a way to specify a date for a commit?
<kiorky> jelmer: i may have a bug for you with the bzr svn plugin
<kiorky> jelmer: when pulling from svn i got : http://www.friendpaste.com/quxKN9rQ
<kiorky> jelmer: look for the 'tgz' file
<kiorky> jelmer: i think this is this one causing the trouble
<kiorky> jelmer: someone of my team commits a 'tgz' in the tags directory ...
<fbond> abentley: Does pull bring in every thread from the loom?
<kiorky> jelmer: *s/commits/commited/
<abentley> fbond: I believe so.
<fbond> abentley: So what does record actually --well-- record?  Does it mean "the current state of the loom is the state that I would like pullers to receive." ?
<kiorky> jelmer: so the repo is something like trunk/ branches/ tags/a tags/File.tgz , moreover i tried to move the tgz elsewhere, but the problem persists
<kiorky> jelmer: (problem is that i cant pull from svn anymore :p)
<abentley> fbond: Yes.  At least, when people ask when they should record, lifeless says "right before you push".
<kiorky> jelmer: i removed .bzr/branch/tags, then re pull, it seems to be working, can you confirm it is safe ?
<fbond> abentley: Hmm.  I probably don't use looms that way.  I'm wondering what the overall workflow that ends with "record" followed by "push" looks like.
<kiorky> jelmer: if you want a full bug report for that problem, just tell me.
<kiorky> jelmer: but i m a bit in a hurry for now.
<abentley> fbond: I have no idea.  This is an aspect of looms that I find frustrating.
<Leonidas> or is there a way to specify a commit timestamp via bzrlib. I cannot find the implementation of workingtree.commit
<Leonidas> (neither does IPython)
<james_w> mutabletree.commit
<james_w> I think
<james_w> but yes, you can
<jam> Leonidas: "commit(timestamp=seconds, timezone=seconds_offset)"
<jam> It forwards the **kwargs on to bzrlib.commit.Commit.commit
<jam> where you can see the actual argument
<jam> and later on the
<jam> if timestamp is None: timestamp = time.time()
<Leonidas> james_w: yeah, I just found it after digging deeper, thanks.
<Leonidas> jam: thanks, that was what I was looking for.
<hsn_> can i push entire shared repo by single command?
<hsn_> i would like it for backups
<jam> hsn_: there is a multi-push command provided by bzrtools, IIRC
<lifeless> abentley: do you have bzr-search installed?
<abentley> lifeless: I don't think so.
<lifeless> ok, cool
<jam>  /cheer
<jam> I just made "bzr branch bzr+ssh://" about 3x faster on my local machine
<jam> turns out we were doing bad things with string reallocations during readv
<jam> *very* bad things
<mwhudson> yay, in some sense
<mwhudson> yay for the improvement, not so much for the fact of the bug
<jam> Yeah, it might even make a 1.6.1 in my book
<jam> As it may solve a lot of the regression in fetch
<lifeless> jam: cool
<lifeless> jam: we have another regression too, marked critical in malone
<james_w> yeah, I was going to ask about that.
<pickscrape> malone?
<lifeless> launchpad bugs
<james_w> not sure whether we'll end up with 1.6 or 1.7 in Intrepid, but I'd like to keep track of important bugs in case it's the former
<pickscrape> As in Bugsy Malone?
<jam> lifeless: which one, I see a few Critical bugs
<jam> The "wrong serializer" I'm not sure that we can actually fix
<jam> since it would break anyone who is *using* 1.6-rich-root repos
<jam> I think we would actually have to create a new repo format, and recommend people switch to it
<lifeless> jam: the missing revision knits to packs
<jam> lifeless: Upgrading encounters revision not present, that one I knew about, and you need to use bzr 1.5 to upgrade
<jam> because it uses .join()
<jam> and then you can reconcile
<jam> and things will be happy
<lifeless> its still a pretty severe regression
<lifeless> I mean, same logic, people can use 1.5 to pull
<lifeless> :)
<jam> lifeless: what would you suggest, you got rid of VF.join() and VF entirely
<jam> I don't think we want to always request full texts
<lifeless> jam: the bug has suggestions at the end of it
<jam> Or is this the other regression
<jam> Where Revision objects would have 'delta' entries
<jam> Because we have the same problem with the old "Knits are referencing an delta entry that isn't in the file revision history"
<lifeless> well, I'm not entirely sure what do to; I'm thinking perhaps to make checK+reconcile on knit repos fix this
<lifeless> Revision objects having delta entries
<jam> we fixed bug 217701, though I suppose it may have regressed again
<jam> (not that it is creating deltas, but that we are having problems fetching them)
<jam> Ah, maybe it is because You and I changed the knit => pack fetcher
<jam> If it is *only* revisions.knit, I would be fine with changing that one to use "include_delta_closure=True"
<jam> fullermd: any chance you could test the patch I just uploaded?
<jam> jaypipes: ping
<jaypipes> jam: pong. still haven't upgrade to 1.6 yet.  But I do have the .bzr.log to send you...
<jam> jaypipes: sure, but I think I just wrote a patch which may help the performance for 1.6
<jam> At least over the local network
<jam> it drops my "bzr branch" time by about 1/3rd
<jaypipes> wow, that's awesome.  Code in 1.6 already?
<jam> jaypipes: well, it would be 1.7 now :)
<jam> But no, I just proposed it on the mailing list
<jam> If it is valid
<jam> I might do a 1.6.1 for it
<jam> jaypipes: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48B71D9E.6080104%40arbash-meinel.com%3E
<jam> is the patch if you care to follow its status
<jam> I'm trying to get someone who specifically saw the problem
<jam> to test it
<jam> lifeless: on the good side, it makes bzr branch locally 2x faster than bzr1.5 as well
<jam> well, over bzr+ssh
<jam> branch locally was already faster
<lifeless> jam: its only that one
<lifeless> (only that knit)
<jam> lifeless:  care to comment on my possible patch
<lifeless> for fetch ?
<jam> lifeless: yes
<jam> basically, just force revisions and signatures to use fulltexts
<jam> since they should anyway
<jam> also, you would probably have more knowledge for the discussion on bug #257637
<jam> I'm off for now
<lifeless> gnight
<bratsche> Is there an easy way to see what revision is the current ancestor of a particular branch?
<mwhudson> abentley: yay for the 3661 landing
<abentley> mwhudson: Yay indeed.
<mwhudson> only two more horrific bugs i can think of (the stacked branch over hpss and wrong serializer ones)
<rocky> jelmer: got a new error with bzr 1.6 + bzr-svn 0.4.11 today ....  http://cluebin.appspot.com/pasted/1001  ... not sure if it's specific to bzr-svn tho
<james_w> http://www.ubercart.org/docs/developer/629/bazaar
#bzr 2008-08-29
<abentley> mwhudson: I think we have to introduce a new format to fix that serializer problem.
<lifeless> if people have used it, for sure
<lifeless> abentley: can we just rename 1.6-rich-root 1.6-subtrees, and add 1.6-rich-root?
<abentley> lifeless: I don't think it makes sense to call it 1.6 if it wasn't introduced in 1.6
<lifeless> abentley: true
<lifeless> abentley: I was thinking 1.6.1
<abentley> lifeless: Yeah, that would be tolerable, I think.
<abentley> I'll have to go back and see whether it ever claimed not to support subtrees.
<abentley> lifeless: It claims not to support subtrees, but has a serializer that does.  I think it's a lost cause.
<lifeless> agreed
<lifeless> lets make it say its bad in 1.6.1
<lifeless> and get 1.6.1 out there asap; intrepid is in feature freeze, and has 1.6
<abentley> You know, it's funny how little I hear about the Ubuntu dev cycle.
<abentley> Anyhow, I agree we should do that.
<fullermd> jam: Well, the upgrade completes, and it seems to work out right...
<awilkins> Can Bazaar do client cert auth over http(s)?
<lifeless> awilkins: I don't know, but if you can find the right magic to give pycurl, I can help you hook it in
<awilkins> CAn it do basic/digest?
<awilkins> I really can't open this up too far ; I now have IIS 6 running an HPSS (as long as you don't want any dumb service too!)
<fullermd> jam: check is happy (of course, it was happy on the knit before too)
<awilkins> Options for IIS 6 are - SSPI (not an option here), basic, digest, anonymous. You can also restrict connections to specific IPs, domain names, and posession of a client certificate
<awilkins> You can map client certs to user accounts which would be one way of enforcing ACL
<lifeless> awilkins: https + basic yes, I think we support digest already too
 * elmo growls at #262450
<awilkins> lifeless: That's great
<awilkins> I must sleep but I can try configuring that tomorrow. I'll probably update my WSGI gateway script to support multiple repos too
<awilkins> bug  #262450
<awilkins> bug #262450
<mlh> bug 262450
<jelmer> kiorky, hi
<jelmer> kiorky, it looks more like a bzr problem to me
<jelmer> kiorky, the tgz file appears to contain a newline
<LarstiQ> hey jelmer
<jelmer> hi LarstiQ
<LarstiQ> are you in .nl?
<jelmer> yep
<LarstiQ> jelmer: I failed in letting you know there was a python-nl meeting today :/
<jelmer> LarstiQ, well, I was busy this evening anyway
<jelmer> LarstiQ, how was the meeting?
<LarstiQ> jelmer: great!
<LarstiQ> jelmer: steve pointing me out swamped me with people for the rest of the evening though ;)
<jelmer> (-:
<LarstiQ> but that was partly what made it good, talking to lots of people
<abentley> jam: Thanks for all the reviews.
<jam> abentley: yeah, well I'm the 1.7 RM , I figure I need to get the review queue down, right?
<jam> abentley, lifeless: So I just had jaypipes test my patch with the mysql tree
<jam> and it drops the "bzr branch" time from 80+minutes down to 23min
<jam> So I'd like to get that patch, and a possible patch for the bug lifeless mentioned
<jam> and do a 1.6.1
<jam> probably 1.6.1rc1
<jam> Are you guys able to review it so I can get it turned around by tomorrow?
<abentley> jam: my time isn't really my own 'till next week.
<lifeless> jam: make sure they're in BB?
<lifeless> jam: I'll do a review pass after lunch
<jam> The fetch regression is
<jam> I'll polish the other fetch bug
<jam> bugfix and submit it
<lifeless> jam: theres a critical format bug too;
<lifeless> jam: 1.6-rich-root isn't
<jam> lifeless: except that is a finalized format
<jam> I don't think we can do anything but change the name to it
<jam> as people are already using it as-is
<lifeless> jam: we have to remove it
<lifeless> jam: have bzr complain, and introduce a good one, because it won't work correctly for people
<jam> I'm pretty sure people have already upgrade to it, I think I have at least one branch here
<jam> I can understand "complain and ask to upgrade" or whatever
<jam> but I think we need to leave it as a "supported" format
<jam> (I don't care a lot for my own branch, as I can trivially get rid of it)
<jam> but it has made it to an official release
<lifeless> jam: no, we don't have to keep it supported
<lifeless> its a brown paper bag bug
<lifeless> I think we have to let people upgrade away from it sure, to prevent data loss, but it won't push or pull properly
<jaypipes> jam: awesome work, mate :)  91 minutes -> 23 minutes.
<jam> lifeless: that was more my point
<jam> I would really like it if someone else could take over that one
<jam> I don't have a lot of "work" time left today
<lifeless> jam: right
<jam> I'm mostly just sending in fixes I've already done
<jam> lifeless: would you be able to do a patch for a --1.6-real-rich-root ?
<lifeless> maybe, I'll see what I can do
<jam> k
<jam> worst case I'll get to it tomorrow
<lifeless> no promises - I've got a few too many balls in the air this week
<jam> but the turn-around time for reviewing a patch is a bit long
<jam> with everyone gone
<jam> I might give a poke at it right now
<jam> to catch your post-food reviews
<jam> abentley: just to be clear, we should use serializer v6, right?
<abentley> jam: yes.  It needs to be the same serialiser as rich-root-pack uses.
<jam> abentley: interestingly the docstring for RichRoot5 *does* say it supports external refs
<jam> Maybe a copy paste bug?
<jam> ah, it means Stacked branches rather than subtrees
<abentley> RichRoot5?  We have one ofthose?
<jam> "external lookups" confused me
<jam> abentley: RepositoryFormatKnitPack5RichRoot is the class
<abentley> jam: yeah, I find that one a bit confusing too.
<jam> "results in non-truncated ghosts after reconcile" doesn't really seem to characterize it
<jam> also, "get_matching_bzrdir" returns "bzrdir.make_format(development1-subtree)" what is up with that?
<abentley> jam: RepositoryFormatKnitPack5RichRoot was copied/pasted from Development1, perhaps a bit too quickly.
<StyXman> hi all. I just converted a svn repo into a bzr ... repo? I didn't use the --tree option. the faq says I should bzr co, but when I try I get: bzr: ERROR: No repository present: "file:///home/mdione/src/projects/psync/new/"
<Verterok> Hi StyXman, using bzr-svn?
<jam> lifeless: there are 3 patches for 1.6.1 review, which should all be in BB
<lifeless> jam: what was teh 1.5 mysql clone time?
 * Peng_ notices this discussion.
<Peng_> Shush, Bundle Buggy. I know I don't have voting rights. It was a joke!
<ptx> hi all. got a quick bzr question... is there a way to list branches / tags that are present in a remote repository?
<ptx> (remote shared repo)
<bob2> bzr branches url
<ptx> ah I guess I need a more recent version of bzr then... my ubuntu got 1.3.1
<ptx> bzr: ERROR: unknown command "branches"
<ptx> thanks for the info. will try a later version.
<Peng_> Actually, it's a part of the bzrtools plugin.
<ptx> oh
<ptx> thanks. going to d/l and check it out.
<bob2> ah, sorry
<jam> lifeless: "bzr branch lp:mysql-server" was ~90 minutes with bzr1.5, ~80 ish with 1.6, and 23min with the patch
<jam> also, what is your feeling about --1.6-rich-root and renaming the old format?
<lifeless> jam: we don't want users reading docs that say '1.6-rich-root' and getting the broken on
<lifeless> one
<jam>  ok, so you prefer --1.6-rich-root-broken and new and improved --1.6-rich-root?
<lifeless> I prefer
<lifeless> --1.6-rich-root-broken
<lifeless> or better yet, the broken one not registered at all
<lifeless> and --1.6.1-rich-root
<jam> I think we at least have to register it as a repo format
<jam> but we may not need to do a bzrdir format
<jam> I'll try that route
<lifeless> yes, thats right
<Peng_> So it would be possible to upgrade from the broken format, but it wouldn't be visible in any way, outside of the code? That sounds nice.
<Peng_> Or...I dunno. :)
<Peng_> How easy was it to create something in the 1.6-rich-root format? "branch --stacked" from some rich-root-pack branch?
<jam> lifeless, abentley: hmm... we have some stacking tests that assume stacking formats are all the same
<jam> and development-subtree uses serializer 7
<jam> versus 1.6-rich-root using 6
<jam> (the new one)
<lifeless> Peng_: yeah
<jam> Should I just disable the development-subtree from being tested?
<lifeless> Peng_: ebrownbag
<lifeless> jam: uhm, no, lets fix it right
<lifeless> jam: or it will just bite us later
<jam> k, it is only "test_stack_checks_compatibility" at the moment
<jam> But I'll poke at it a bit
<jam> ah, the problem is that "development" still uses serializer 5
<RAOF> Ow!  bzr, kindly don't consume 650Mb res.
 * RAOF watches as bzr attempts to consume more memory than all other processes combined.
<fullermd> Well, if you're just going to leave it lying around where bzr can find it...
<lifeless> RAOF: what are you doing, and what version precisely?
<RAOF> Oooh, so close.  It made it up to 998MB res.
<RAOF> There shall be a brief haitus while my system is paged back in...
<RAOF> bzr versoin 1.6, running "bzr multi-pull" in a repository with...6 branches
<RAOF> lifeless: I heard bzr 1.6 had a memory problem.  I wasn't aware that extended up to 1gb resident :)
<lifeless> RAOF: actual released version?
<RAOF> lifeless: As packaged in Ubuntu Intrepid, yes.
<lifeless> RAOF: same repository format?
<RAOF> Yup.  All pack-0.92
<lifeless> damn
<lifeless> thats just wrong, it shouldn't spike like that
<lifeless> can you reproduce with bzr.dev?
<RAOF> It seems like each branch was stacking its own memory on the last; as if there was no GC going on.
<RAOF> Let's have a try with bzr.dev.
 * RAOF rather wishes firefox wouldn't spawn so many empty windows
<RAOF> lifeless: The easiest way to run bzr.dev will be to just run 'bzr' from my branch, right?
<lifeless> yes
<RAOF> Progress bars almost uniformly suck.
<RAOF> bzr's is no exception :(
<lifeless> yes
<lifeless> progress is ard
<RAOF> Which is why they always suck.
<RAOF> Yay!  We now have bzr.dev head.
<RAOF> ...and we're up to 600Mb resident before it gives any output at all.
<lifeless> RAOF: please file a bug
<RAOF> And we break the 1/2 of my physical memory barrier!
<lifeless> RAOF: having enough data to reproduce will be important
<lifeless> also, hit ctrl-\
<lifeless> and get a back trace
<RAOF> Ah.  While bzr is multi-pulling.  Check.
<RAOF> Hm.  That's new and different.  I've never used pdb before.
<lifeless> later all, sluggish stuff
<jml> RAOF: really?
<jml> RAOF: let's switch lives
<RAOF> Heh.
<RAOF> Oh, that's rather interesting.  It seems that the horrible memory use requires the presence of non-branch directories.
<gour> jelmer: hello, in regard to bug #261878 the problem is that svn can fetch the repo...
<ubottu> Launchpad bug 261878 in bzr-svn "bzrlib.plugins.svn.core.SubversionException" [Undecided,Incomplete] https://launchpad.net/bugs/261878
<jonnydee> Hi :) I just wanted to ask if somebody could maybe set the importance of https://bugs.launchpad.net/bzr/+bug/255656 to at least medium? I fear that this bug gets forgotten, otherwise, in spite of the availability of a bugfix branch from lifeless. Our set up at work requires us to use a windows network drive for hosting our repository. And it's really an annoying bug...
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New]
<jelmer> gour, svn doesn't fetch as much data as bzr-svn, it just fetches the last revision
<gour> jelmer: still, i can do svn log and see the history...the point is that for quite some time i fetch and update pandoc repo and build the package, but bzr-svn fails to replace the need for svn
<jelmer> gour, the problem appears to be that the svn server is unreliable
<jelmer> gour, bzr-svn has to do far more requests than svn
<jelmer> since it fetches every revision in history
<jelmer> and the server occassionally fails with http errors
<gour> i understand bzr-svn does more...however, i'd like to use bzr instead of svn and dunno what to do in this case
<jelmer> gour, the problem really is in the reliability of google code, that's out of my control :-(
<jelmer> if you're trying to do a one time import, you can branch into a shared repository and repeat when it fails
<gour> well, i want to constantly fetch from the repo..
<LarstiQ> jelmer: how well do stacked bzr-svn branches work?
<jelmer> gour, as long as you're ok with retrying occasionally, that shouldn't be a problem
<jelmer> LarstiQ, they're not layered appropriately enough in bzr yet for it to work well
<gour> jelmer: ok. let me try to re-do and continue with that process
<jelmer> LarstiQ, they do work, but all files have to be fetched individually atm, which doesn't make the process any faster
<LarstiQ> jelmer: ah
<Jc2k> .wg 3
<Jc2k> gah
<Jc2k> fail
<jelmer> 'morning Jc2k :-)
<Jc2k> morning jelmer :)
<gour> jelmer: the problem is that if i retry with 'bzr pull', bzr says it's not a branch, so i've to try 'bzr branch' again which fails
<gour> jelmer: it looks like catch-22
<lifeless> gour: bzr init' then pull
<uws> Is it possible to extract a part of a branch into a new branch?
<uws> E.g. I have this "subproject" that I want to promote to a real project
<lifeless> jonnydee: I think its merged and fixed in 1.6
<lifeless> uws: bzr split
<uws> lifeless: what will happen with revisions touching both files inside and outside this subproject directory?
<lifeless> uws: it keeps all the history, as that lead into the project
<lifeless> uws: it just creates a fork in the road, where one side is the subdir, and the other side is all but the subdir
<uws> lifeless: so basically it's a new branch, removes everything not in that dir, and moves everything in that dir to the branch root?
<lifeless> yes
<lifeless> which lets you merge branches from before the split smoothly and so on
<uws> lifeless: Ok thanks. will investigate
<uws> lifeless: the "move" line in bzr status is a bit strange
<uws> renamed:
<uws>   subproject =>
<uws> perhaps a / at the end helpt ;)
<uws> helps*
<lifeless> :P
<lifeless> this is rarely used; please do file bugs :)
<uws> lifeless: I cannot be bothered in this particular corner case ;)
<lifeless> ok
<jelmer> lifeless, this is how I ended up solving the sharing of VirtualSignatureFiles btw
<jelmer> lifeless, A project "bzr-foreign" that is joined to both bzr-svn and bzr-git
<lifeless> jelmer: and you merge from it twice?
<jelmer> lifeless, yeah
<lifeless> kk
<jelmer> it's not optimal - by-reference nested trees would be awesome! - but good enough for now
<jonnydee> lifeless: I just have had a look at the source code of 1.6 -- it seems like the bugfix is not merged inti bzr 1.6...
<gour> jelmer: don't know how many times i've tried, but 'pull' fails 100%
<gour> jelmer: here is the trace of bzr pull http://rafb.net/p/myafQi40.html
<jonnydee> Hi, when I try to push a new branch to a repository on a windows network share thaen this command fails with a "bzr: ERROR: Could not acquire lock "B:/ProjektM/vendor/.bzr/checkout/dirstate""
<jonnydee> Is it a bug? BTW, the branch seems to be pushed to the network share. I can checkout from there
<james_w> that's just failing to create the working tree
<jonnydee> but a lock seems to exist anyway and I have todo a  break-lock
<james_w> OS locks are used for that, meaning that the share probably doesn't support them
<fta> the builddeb plugin changed the default result-dir to ".." and the help message refers to --result-dir to change it but it doesn't seem to work. I get bzr: ERROR: no such option: --result-dir
<jonnydee> but when I browse the working tree on the share it exists...
<james_w> fta: try --result please
<fta> james_w, seems ok, the help is wrong then.
<fta> thanks
<james_w> fta: thanks, I'll fix it for the next upload.
<james_w> fta: are you setting --result back to ../build-area?
<fta> it's building...
<fta> james_w, well, didn't work for me. I wanted to revert to the previous default, ie, keep debs in ../build-area but if i set --result=../build-area , i get a traceback when it tries to move the files on themselves, which is obviously wrong.
<james_w> fta: ah, thanks, I'll fix that too.
<fta> either there should be a test to detect src = dst, or a way to disable that move
<james_w> yeah, I'll do the former I think
<jonnydee> lifeless: are you aware that bug 255656 is not merged in 1.6?
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656
<jonnydee> lifeless: sorry, if I'm bothering you, but I'm trying to convince my development team to use Bazaar and I am constantly experiencing problems with using a network share (which is our setup); the last error I stumbled over today is: bzr: ERROR: Could not acquire lock "B:/ProjektM/vendor/.bzr/checkout/dirstate" when I pushed a new branch.
<james_w> fta: http://bzr.debian.org/pkg-bazaar/bzr-builddeb/2.0 has a fix if you need it.
<lifeless> jonnydee: the bugfix is approved; it may not be in 1.6, but I was sure it was in bzr.dev. If its not I'll make sure it this week
<lifeless> as for the lock problem, well, its after 11pm for me right now, way to tired to be thinking about it
<lifeless> jonnydee: please file a bug to provide a discussion point about it
<StyXman> hi all. I just converted a svn repo into a bzr ... repo? I didn't use the --tree option. the faq says I should bzr co, but when I try I get: bzr: ERROR: No repository present: "file:///home/mdione/src/projects/psync/new/"
<james_w> jelmer: I just merged your directory branch, should it check whether bzr-svn is available before trying to checkout Vcs-Svn?
<Stellaris> Hey, I am currently looking into how to ignore certain files from being monitored and got the User Guide open. I don't understand how the syntax for ignoring files down a file tree works (recursive stuff). I've got a .bzrignore file created.
<james_w> StyXman: hi, what command did you use to do the conversion?
<james_w> Stellaris: if you "bzr ignore dir/subdir/file" it will add an entry to the file, which should give you a hint
<Stellaris> james_w: ah, thanks, will try that
<Stellaris> james_w: thanks!
<jelmer> james_w: Hi
<jelmer> james_w: Yeah, it may be nice to check whether bzr-svn is present and give a more understandable error
<jelmer> james_w: Otherwise, it'll just say "Not a branch" if you try to check out a svn branch
<beuno> hey mwhudson
<beuno> can you take a look at: https://code.edge.launchpad.net/~beuno/loggerhead/1.6.1/+merge/806
<beuno> when you have time?  :)
<abentley> lifeless: do you remember why cloning, unlike other operations, inits the branch and tree formats itself?
<abentley> lifeless: For Pre-split-out bzrdirs.
<rocky> jelmer: ever see anything like this ?  http://cluebin.appspot.com/pasted/1201   (bzr 1.6 final, bzr-svn 0.4.11 final, svn 1.4.6)
<sabdfl> do i need to do anything with a branch to get the new b-tree index capability?
<sabdfl> bzr upgrade is saying it has nothing to do
<Jc2k> rocky: https://bugs.launchpad.net/bzr-svn/+bug/250480
<ubottu> Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [Critical,Fix released]
<rocky> Jc2k: awesome, thanks
<jelmer> Jc2k, I'm pretty sure this is different
<rocky> oh
<jelmer> since this is about a revision object, not a file text revision
<Jc2k> ah
 * Jc2k has definitely seen NoSuchRevision before, though
<james_w> hi sabdfl, I'm not sure the b-trees in bzr.dev are hooked up to a format yet, certainly not a default one.
<james_w> jelmer: is a "try: import bzrlib.plugin.svn; except ImportError:" suitable for that?
<rocky> jelmer: in that paste ... ClueMapper-rocky is a regular bzr branch of ClueMapper-trunk which is a bzr-svn checkout ... and "repo" is a "bzr init-repo -1.6-rich-root" repo
<jelmer> james_w, yep, that should take care of it
<james_w> jelmer: cool, I'll add it
<jelmer> rocky, The revision it fails on, what sort of revision is that?
<Kinnison> The btree stuff is wired up as --btree-plain and --btree-rich-root etc.
<Kinnison> but they're not default afaict
<rocky> jelmer: i'm not sure, how do i tell?
<dudus> I want to use bzr to version some college papers also I want to have a central repository on a server where I commit all changes so I have a backup if something bad happens. I'll be the only user... Should I use this binded mode?
<jelmer> rocky, that revision id, is that of a revision in the current branches' history (iow, does "bzr log --show-ids" list it?)?
<jelmer> dudus, yeah, that sounds like the right approach
<james_w> jam: are you familiar with git's recursive merging? Does/could bzr do something similar? Would it help at all?
<rocky> jelmer: yes it does
<rocky> jelmer: http://cluebin.appspot.com/pasted/1002
<sabdfl> Kinnison: does --development include that?
<dudus> james_w: thx
<jelmer> rocky, Any chance you can paste the full "bzr log --show-ids" output?
<jelmer> rocky, this looks like a bug in bzr not being able to cope with ghosts
<rocky> sure
<jelmer> rocky: Thanks for finding so many bugs :-)
<rocky> lol
<emmajane> How is the CVS integration? It's not as good as SVN, right?
<rocky> jelmer: http://paste.plone.org/23470
<Kinnison> sabdfl: Not sure, sorry
<emmajane> (just in a session at DrupalCon, Lenz Zimmer is talking about bzr, we're all stoked)
<jelmer> emmajane: yeah, correct
<Kinnison> sabdfl: btree-plain is just pack-0.92 with btrees turned on
<Kinnison> iirc
<jelmer> emmajane: it's possible to do a one-way conversion, roundtripping is not possible
<fbond> abentley: Hm.  Not sure about push/pull with loom.  Doesn't seem to take the recorded state of the loom into acount at all (from what I can tell).
<james_w> emmajane: it's not as good as svn, no. There's no "foreign branch" plugin like bzr-svn, but there are several reasonable converters
<fbond> abentley: Rather, it pulls from the currently selected thread (I think).
<jelmer> rocky: Thanks
<emmajane> Thanks, jelmer and james_w.
<jelmer> rocky: This does indeed look like a bug in the ghosts handling
<abentley> fbond: Are you pulling from a loom into a loom?
<emmajane> git has sub-projects, is there an equivalent in bzr?
<fbond> abentley: in fact, it's not clear to me that `bzr record` has any value at all, currently.
<fbond> abentley: yes
<rocky> jelmer: if/when you need me to switch to the bzr-svn branch lemme know
<fbond> abentley: I have two looms that are mirrors of each other, but one is beind the other.
<fbond> abentley: Be nice to have a single command that brings all the changes from one into the other (in all threads).
<abentley> fbond: That's suprising.  last time I tried pull, it was definitely broken.
<fbond> abentley: You are surprised it's still broken, then?
<abentley> fbond: It was broken because it was trying to behave as pull-loom.  I would have thought when it was fixed, it would have.
<fbond> abentley: Well, I'm currently using 1.3.1...
<james_w> emmajane: "nested trees", there's experimental support for them, but nothing solid yet. I hope it will be a 2.0 feature, i.e. this year.
<fbond> abentley: In any case, I can pull one thread at a time by moving through threads on each end before pulling.
<emmajane> thanks, james_w
<rocky> bzr has no equiv of svn:externals right ?
<emmajane> (Lenz Grimmer, I think I had the last name wrong.)
<Jc2k> rocky: aiui.. it has by-value nested trees, but not by-reference trees in 1.6 (svn:externals are by-reference)
<Jc2k> *by-reference nested trees
<rocky> what does a "smart server" mean within the context of bzr? (in relation to just a "server")
<dudus> when should I use bzr init and when to use bzr init-repo to create a central repository?
<rocky> dudus: i just learned that "bzr init" doesn't create a central repository ... it merely turns the directory into a bzr-versionable dir ;)
<dudus> in the second exemple in this link it uses init to create the central one !?! http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#publishing-a-branch
<StyXman> james_w: sorry for dissapearing. bzr svn-import <path to repo>
<james_w> StyXman: and you were in /home/mdione/src/projects/psync/ when you ran that?
<james_w> StyXman: what directory are you running the "co" command in?
<emmajane> statik: Lenz says hello. :)
<StyXman> james_w: no, in /home/mdione/src/projects/psync/new/
<StyXman> err, in another dir, actually. so the question is, how should I do it?
<abentley> dudus: No, it uses init-repo to create a central repository.
<james_w> StyXman: have you moved anything around since running "bzr svn-import"?
<Jc2k> rocky: smart server implies not dumb, e.g. vanilla http is dumb
<StyXman> james_w: actually I copied the .bzr dir in trunk
<james_w> StyXman: ah, that's probably not a good idea
<StyXman> thing is, if I do a svn-import it creates the whole svn tree: trunk, branches/* and tags/*
<james_w> do you just want "trunk"?
<StyXman> in the parent of all those there's a .bsr
<StyXman> james_w: idealy I want all the history, but trunk is enough
<StyXman> s/bsr/.bzr/
<james_w> can you put the .bzr dir back where it was?
<StyXman> james_w: yah, I only copied it
<james_w> ah, can you delete what you copied then?
<StyXman> yeha, it's throw-away'able :-P
<StyXman> done
<james_w> now "cd trunk; bzr checkout ."
<StyXman> takes time :)
<StyXman> there, thanks
<StyXman> now, i have lots of .bzr dirs
<james_w> have you got what you want now?
<StyXman> psyc/.bzr, psync/trunk/.bzr, psync/tags/*/.bzr, etc
<james_w> yep, they are each branches
<james_w> except for psyc/.bzr which is the "shared repository" that holds the actual revision data
<StyXman> aha
<StyXman> ok, I'll have to re-read the user reference then... thanks james_w
<Jerky_san> hello
<Jerky_san> I have a question or 2
<Jerky_san> what permissions are required to the .bzr folder and its sub folders if you are going to do http?
<rocky> Jc2k: the reason i'm asking is because i was wondering about serving up a bzr repo from my python wsgi app (i'm a python programmer) in a R/W fashion ... does the standard wsgi app allow that?
<rocky> (i'm aware of the missing auth problem)
<Jc2k> rocky: not a dev, so dunno
<james_w> Jerky_san: if you are just serving the files out over http then any permissions that allow your web server to read the files is enough
<Jc2k> gour: ping
<Jerky_san> danke james
<Jerky_san> my other question is if i use htaccess to restrict who can see whats in the folder i seem to get an eror that says  ERROR: pycurl.error: (65, "necessary data rewind wasn't possible")
<Jerky_san> *error
<Jerky_san> i thought it had to do wtih permissions to folders/files so i did a test folder and 757 permissions to all files and folders..
<Jerky_san> bleh this error is so wierd ._.
<Jc2k> gour: bzr branch http://bzr-mirror.gnome.org/bzr/pandoc/trunk pandoc
<Jc2k> gour: ping me when you have it, i dont like having non gnome svn stuff on there
<Jc2k> gour: it really was just googlecode being flakey, i had to use bzr pull -r50, bzr pull -r100, bzr pull -r150 and eventually it got there
<jelmer> rocky, still there?
<rocky> jelmer: yes
<jelmer> rocky, what was the URL of your svn repo again?
<rocky> https://dev.serverzen.com/svn/cluemapper
<jelmer> and the specific branch on which the error occurred?
<rocky> jelmer: well, this was against a local bzr branch that branched off of cluemapper/trunk checkout
<rocky> err
<rocky> cluemapper/ClueMapper/trunk
<jelmer> thanks
<Jerky_san> welp i figured my error out.. apparently the file pycurl.pyd causes it if you attempt to connect through https
<nihilocrat> hello
<nihilocrat> I'm wondering if there's a way of intentionally ignoring any conflicts that come up in a particular file
<gour> Jc2k: got it. thanks a lot ;)
<james_w> nihilocrat: ignoring them how?
<james_w> committing the conflicted version? always using your current version? always using the version you merged?
<nihilocrat> always using the version that the parent branch has
<nihilocrat> so
<nihilocrat> file.OTHER
<Verterok> nihilocrat: 'bzr revert file', should do the trick
<lixomancem> Hello. I just installed 1.6 on windows and restarted my computer. When I right-click somewhere and choose "bzr init" a window pops up with the message "UnrecognizedCommandError: init". The same happens with the "bzr checkout" option, but not with the "bzr branch" option. What can I do?
<james_w> nihilocrat: there's no automatic way to do that, you can just move file.OTHER over the top of file in those cases though
<nihilocrat> k, I'll just write a shell script
<nihilocrat> thanks for the input though
<Spaz> hmm
<lixomancem> Hello. I just installed 1.6 on windows and restarted my computer. When I right-click somewhere and choose "bzr init" a window pops up with the message "UnrecognizedCommandError: init". The same happens with the "bzr checkout" option, but not with the "bzr branch" option. What can I do? I can run bzr init on the command line, but there are orhter commands that do not work then, like bzr add...
<lixomancem> ...for instance.
<Spaz> is there any plugin to bzr that can add RCS tags (or something similar) to files on commit?
<Spaz> it would be useful for me
<jelmer> Spaz, yeah, the keywords plugin should be able to do that
<Spaz> jelmer, hm
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test bzr-1.6.1rc1 |  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<jam> 1.6.1rc1 has been released, packages are building in the beta-ppa now
<vila> jam: you rock ! You deserve a good week-end at least :D
<jam> thanks vila
<jam> vila: did you get your patch submitted?
<vila> I'm preparing the submission for  -s aliases
<vila> oh, and just seen your approve for but '55 select/poll' bug, I will fire both
<vila> s/but//
<vila> yeah, no but ! :D
<jam> vila: well, no ifs ands or buts, but I guess there is an and in there ...
<jam> :)
<vila> :)
<abentley> jam: Where are we in the 1.7 release process?
<abentley> s/release process/development cycle
<jam> abentley: feature freeze is supposed to be today
<jam> rc1 next friday
<jam> final the next week
<jam> wait, I think I bumped it back a bit
<jam> 25th, 2nd, 8th
<jam> I'll probably end up going back to the original
<jam> so we don't end up with 1.6.1 and 1.7 on the same day
<abentley> jam: :-)
<jam> time based releases sneak up on you when you end up with 5 release candidates and a .1 release
<jam> at least poolie and spiv will be back next week to see all the carnage I've caused
<jam> abentley: is there anything you would like to get into 1.7
<abentley> jam: That push cleanup I sent in is the only pressing thing.
<jam> abentley: well, I at least gave it a once-over and it seemed fine
<jam> but I didn't poke at it enough to really give a review yet
<abentley> I've got about 6 threads left in my PreviewTree loom, but that can easily slip to 1.8
<jam> abentley: It would be *really* nice if you could review my merge patch
<jam> I really wanted that in 1.7
<jam> and it has sat around for about 2+ weeks
<abentley> jam: Okay, I will review it by next Wed.  Please harass me if I don't.
<jam> k
<jam> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48936560.6040106%40arbash-meinel.com%3E
<jam> Just in case you feel like you have some time
<jam> vila: don't forget that next week is going to be feature freeze, and you and Verterok offered to be OSX test guardians
<vila> yeah, I was waiting a bit for some feedback but I will submit as is and we'll continue
<jam> vila: feedback on what?
<jam> whether you are the padawan  or the master?
<vila> lol, no, this has been sorted out :)
<jam> I think with 1.7rc1 in slightly more than 1 week, you're running out of time to wait for feedback
<vila> To make the permission tests pass we implemented a _mac_mkdtemp to fix OSX strange idea to assign temp dirs group permissions to a group the user is not a member of...
<vila> That means one chown call at each creation, since bzr doesn't really need the abitility to set the group sticky bit I was wondering about making that a feature instead and skip the tests instead
<vila> well a single instead should be enouhg
<vila> enough
<vila> pfew
<Jerky_san> is there a way for when you do a push to set what permissions you want the files to have?
<Jerky_san> since when i push them the new files get permissions that can only be read by ftp but not http
<Peng_> jam: There's a typo in 1.6.1's NEWS, about the readv perf improvement: "we know always request full texts"
<Verterok> jam: thanks for the reminder (of the freeze)
<Verterok> vila: I've been strugling, with bzr-eclipse. I'll try to catch up with the os x test during this weekend
<fbond> Hi.
<fbond> How can I make lp: work over https instead of ssh?
<fbond> I keep getting permission denied but I have no intention of using ssh on this machine.
<ElianaTamerin> Can I set up bzr on shared host w/o SSH?
<fbond> ElianaTamerin: how do you upload files to your shared host?
<ElianaTamerin> ftp
<fbond> You can bzr push over FTP.
<ElianaTamerin> what does that involve?
<fbond> Others can get read-only access via HTTP.
<fbond> ElianaTamerin: Nothing complicated.  Works out of the box as well as SSH, etc.
<ElianaTamerin> hmm, not idea, it's a project with multiple devs
<ElianaTamerin> ideal*
<fbond> ElianaTamerin: I doubt you can spawn long-running process in a limited shared hosting environment, so everyone that wants write access to the repo needs write access to the machine.
<fbond> (If long-running process are okay, you can probably use the smart server.)
<fbond> ElianaTamerin: Can you give other devs FTP access, too?
<ElianaTamerin> yes, I can
<fbond> That'll be the way to go, I guess.
<ElianaTamerin> would they need to keep a local build of bzr to push from?
<fbond> ElianaTamerin: I'm not sure I understand your question.  The other devs would also be using bzr, right?
<ElianaTamerin> correct
<fbond> ElianaTamerin: So what do you mean by "a local build of bzr"?  I assume they have bzr installed on their local machines.
<ElianaTamerin> that was my question
<ElianaTamerin> if they had to have bzr installed
<fbond> Oh, yes, they would have to install bzr to use it.
<fbond> (Like every other VCS that I am aware of.)
<ElianaTamerin> and one last question, would the platform matter? if one used win, and another used mac, another *nix, would there be any issues?
<ElianaTamerin> on their local computers, that is
<fbond> bzr is designed to be cross-platform.
<ElianaTamerin> wonderful
<fbond> If it doesn't work well on any of those machines, it's a bug.
<fbond> Now, I don't use those platforms, so I can't personally say how good support currently is.
<fbond> But cross-platform support is an explicit goal of the project.
<ElianaTamerin> alright, I'll give it a go and see how it works
<fbond> ElianaTamerin: Great, good luck!
<jam> abentley: I'm getting an "unexpected success" trying to merge 1.6.1 into bzr.dev, something about the "test_sprout_upgrades_to_rich_root" which expects it to be an Incompatible repo
<jam> I think because the 1.6.1 *should* auto-upgrade now
<jam> Do you thnik that is correct?
<abentley> jam: yes.
<jam> ok, I'll remove the "expect_failure" then
<abentley> That test was how I discovered the format issues.
<jam> k
<jam> The error was a bit odd
<abentley> poolie should really have written one like it, and then we wouldn't be brown-bagged.
<jam> AssertionError: Unexpected success.  Should have failed: Rich root format should be sprout-compatible
<jam> Because it is unclear what the actual failure message is versus what is actually expected
<jam> anyway
<jam> i need to get going
<abentley> jam: not sure how to fix in the general case.  I have to go too.
<rocky> jelmer: any luck on my problem? :)
<jelmer> rocky, sorry, that's a bzr problem, not a bzr-svn one
<rocky> jelmer: oh yeah?
<rocky> does it have a issue #?
<jelmer> rocky: not sure, let me check
<jelmer> rocky, didn't you file a bug about bzr shelve giving NoSuchRevision?
<rocky> nope
<jelmer> rocky, still there?
<springdale> Hi, I would love to use a gui tool for diffs between revisions of files. Is there some way to use meld or how would I do it?
<springdale> I found this "--using=meld" somewhere but it does not seem to do anything.
#bzr 2008-08-30
<Jerky_san> is there a way for when you do a push to set what permissions you want the files to have?
<markh> if you have a bundlebuggy account, does it offer a simple way to find/filter all of your own requests?
<lifeless> yes
<lifeless> mine
<lifeless> and my pending
<markh> how do I get an account then? :)
<markh> mail aaron?
 * markh tries to get a few off his 'resubmit' queue...
<Peng_> markh: You rock for working on the "up -r" thing. :)
<Peng_> (That was you, right?)
<fullermd> Mmph.  Does anybody else see 'missing' over bzr+ssh being a lot slower with 1.6 than 1.5?
<fullermd> Heck, missing took longer than pull.
<jam> fullermd: "time bzr1.6 missing" 0.663s, "time bzr1.5 missing" 2.766s
<jam> Seems faster to me
<jam> it does use a different algorithm, so there are cases where it is slower
<fullermd> Is that against a 1.6 server?
<jam> fullermd: this is localhost stuff
<jam> and 3 extra revisions locally
<fullermd> Well, I'm talking about with matching servers.  1.6 client was REAL slow against a 1.5 server, since it stopped using some verb or other.
<jam> fullermd: for "bzr missing bzr+ssh://" I get 6.8s bzr1.6,  9.9 for bzr 1.5
<fullermd> This is across 100ms.  1.5 on both ends used to be <10s, for much larger than the 3 revs I just got in 20s with 1.6.
<jam> no verbs changed for missing, that I know of
<fullermd> Oh, there was something.  1.6 would churn for 30 seconds or so before it started showing anything, then list the revs at the same speed.  1.5 went right into the listing.
<jam> fullermd: are you sure about that, 1.5 spends a long time grabbing the full ancestries before it continues
<fullermd> Against a 1.6 server?
<jam> fullermd: against all
<jam> there is no smart missing functionality
<jam> it loads the whole graph
<jam> and then does set ancestry diffs
<jam> in 1.5
<jam> the only thing I could possibly see
<jam> is if loading the whole graph was fast
<jam> but that is not usually the case
<fullermd> Well, the other week, the server was running 1.5.  Missing ~20 revs, 1.5 listed them out in 15 or 20 seconds.  1.6 churned for upwards of 30 seconds before it started listing them in (in 15 or 20)
<fullermd> That was repeatable over multiple runs, back and forth.
<jam> well 1.6 *searches* the graph, 1.5 just loads it and does set diff
<jam> it is possible for the search to take longer
<jam> generally depends on the amount of extra ancestry you have
<jam> stuff "around" the search locations
<jam> So... in all the common cases I've tried, 1.6 is faster, but maybe every 50th try or so 1.5 is faster
<jam> same thing for "bzr status" showing pending merges
<fullermd> % time \bzr missing
<fullermd> 2.508u 0.760s 0:28.12 11.5%     212+3647k 0+0io 0pf+0w
<fullermd> (1.6 both ends)
<fullermd> % time env BZR_REMOTE_PATH=~/src/bzr-1.5/bzr ~/src/bzr-1.5/bzr missing
<fullermd> 1.799u 0.599s 0:11.23 21.1%     215+3123k 0+0io 0pf+0w
<fullermd> (1.5 both ends)
<fullermd> There are 2 missing revs.
<fullermd> In both casts, it takes about 4 seconds to display them after the "You are missing 2 revision(s):" line.
<fullermd> But with 1.6, it churns for ~23 seconds before showing that line, and 1.5 goes for ~7.
<fullermd> (multiple runs of both; everything on both sides will be warm cache)
<fullermd> ~100ms round trip.  Not bandwidth contrained; it peaks up to a top of ~50k/s, while I can pull over 300 between these systems.
<ElianaTamerin> first time using a RVS, I've created my BZR repo and project under my windows platform, do I need my project files in that dir prior to the bzr add?
<ElianaTamerin> nevermind, figured it out ;)
<markh> jam: I've got a bzr-setup-1.6.1rc1.exe - after I upload it I will followup your announcement - anything else you'd like to me to?
<jam> markh: that sounds good, thanks for putting it together on a weekend
<markh> np
<ElianaTamerin> i'm trying to setup an ftp push system, I've added my files and done a bzr add, what do I need to do before pushing to FTP
<ElianaTamerin> hello?
<Peng_> ElianaTamerin: "bzr commit"
<Peng_> ElianaTamerin: Have you read the tutorial?
<ElianaTamerin> commit stalls for me
<Peng_> ElianaTamerin: Um, are you adding tons of large files or something?
<ElianaTamerin> Peng_: largest file is 61kb
<Peng_> ElianaTamerin: What version of bzr?
<ElianaTamerin> 1.6
<ElianaTamerin> stable
<Peng_> ElianaTamerin: I don't know much about debugging bzr. Maybe you should pastebin exactly what commands you're running.
<ElianaTamerin> I did a cd to the directory I wanted, made a bzr init and created the repo, created the project and then dumped in my files. Then did a bzr add and tried a bzr commit, which froze the console
<ElianaTamerin> it did say it committed the files, and popped up the log
<ElianaTamerin> here's the log: http://devira.pastebin.com/d1acb1da8
<ElianaTamerin> and no prompt returns, the console merely sits after it's added the last file with a blank line afterwards
<Peng_> ElianaTamerin: You need to write a commit message, save and exit the text editor.
<ElianaTamerin> oh, lol!
<ElianaTamerin> I'm too slow tonight
<Peng_> I wonder how Googlebot found its way to "/loggerhead/a/branch/revision/unknown".
<Peng_> Hmm, it seems it's been trying that URL for a while now.
<cammoblammo> I'm trying to install bzr-git. As far as I can tell all I need to do is ./setup.py build then ./setup.py install as root. Before I risk hosing my system, is this the correct procedure?
<asabil> cammoblammo: isn't checking it out enough ?
<asabil> cammoblammo: cd ~/.bazaar/plugins && bzr branch lp:bzr-git git
<cammoblammo> Doesn't seem to be. I ran the setup script and it copied a few bits and pieces into /usr/lib somewhere. Now I'm trying to figure out exactly how to use it.
<asabil> that should be it
<cammoblammo> Ah, I'll look at that.
<lifeless> cammoblammo: bzr branch local-git-repo new-dir
<cammoblammo> lifeless: Cool! That was my next question...!
<asabil> bzr vis doesn't seem to work with git repos
<asabil> :/
<cammoblammo> So I git to clone a repo on my box then use bzr to operate on it?
<AfC> asabil: (that seems worthy of a bug report)
<lifeless> cammoblammo: its early days for bzr-git
<cammoblammo> lifeless: Yeah, I get that. I'm only looking to use it for local stuff for now. The bzr UI seems a little easier to use.
<AfC> Just a little.
<lifeless> :P
<lifeless> ended up chatting to a git user last night; one that uses the index
<lifeless> walked him through why its totally unnecessary etc - hes going to give bzr a go :P
<AfC> lifeless: (speaking of last night, it was delightful catching up with you for dinner. You'll be pleased to know that the Shiraz from "out back" didn't give me a hangover (or a heart attack, for that matter)).
<lifeless> excellent
<lifeless> I enjoyed the catch up as well
<lifeless> the wine was scary  :P
<AfC> Scott and I went to a right proper wine bar after and more than made up for it :)
<AfC> lifeless: incidentally, I really like your idea about one list with multiple topics. If you can possibly figure out the mailman foo for that it would be superb.
<lifeless> will try
<gustavonarea> Hi. By mistake I've added some files to the branch, and now I have bzr to ignore them *without* removing them. What should I do? Thanks in advance
<gustavonarea> OK, it's with "bzr revert [myfile]"
<nekohayo> I am a bit scared by the concept of merge conflicts
<nekohayo> what does manually resolving a conflict achieve?
<nekohayo> does that mean "I did magic. Bazaar, please ignore whatever happened here and only care about diffs in the next commits/merges" ?
<nekohayo> oh wow, I just discovered "bzr gconflicts"
<nekohayo> it starts a 3-way comparison in meld with .BASE on the left, .THIS in the middle and .OTHER on the right
<nekohayo> I am assuming that I must "fix" the one in the middle and save?
<sohail> hi, I just moved a repository on my server to a public/ subdirectory, how do I tell my clone locally to use the new one?
<luks> use for what?
<sohail> luks, for pull and push
<asabil> sohail: bzr pull -- remember newlocation
<luks> bzr pull <URL> --remeber
<luks> and the same for push
<sohail> ah, k
<sohail> thanks
<sohail> How to get rid of this warning: This transport does not update the working tree of: <url>
<sohail> the help doesn't tell me
<luks> I don't think you can't
<luks> *can
<sohail> oh that's annoying
<jelmer> there's a plugin that can take care of running update on the server side
<sohail> but I don't want any updates server side, do I?
<asabil> well, sohail, do you actually need a working tree on the server side ?
<sohail> I'm just using the server as a central point for the master repo
<asabil> sohail: if you don't need a tree on the server, you can do a bzr remove-tree URL
<asabil> that will make the warning disappear
<sohail> great
<sohail> ah crap
<sohail> I just removed my local tree
<asabil> :)
<luks> bzr checkout .
<sohail> I had mods that I had forgotten to commit
 * sohail cries
<sohail> oh theyre still there
<sohail> yay
<luks> hm, remove-tree doesn't check for a clean tree
<luks> ?
<asabil> it does iirc
<luks> ah, it just keeps the modified files there
<luks> maybe an error would be better
<sohail> bzr: ERROR: You cannot remove the working tree of a remote path
<luks> because if you do "checkout ." to such a branch, you get conflicts
<sohail> somehow I have bzr version 1.3.1
<luks> can you do it from the server?
<sohail> ya
<sohail> ok warning gone
<sohail> thanks
<hsn_> how to remove parent branch from related branches, i have there for some reason bogus branch
<uws> hsn_: use 'bzr pull --remember' with the right url
<hsn_> isnt pull branch different from parent branch?
<uws> hsn_: (or edit .bzr/branch/branch.conf)
<uws> hsn_: "pull" uses the parent location. "push" uses the "push" location.
<uws> update/bind/unbind/checkout has "bound" location
<uws> and "send" has a "submit" location
<uws> hsn_: see .bzr/branch/branch.conf  (usually you don't edit this since it's inside .bzr/)
<hsn_> is there simple way to look into bzr protocol? i.e. commands sent over socket?
<uws> hsn_: wireshark/tcpdump
<hsn_> i upgraded protocol to bzr+ssh and SVN is still much faster
<uws> that's my experience as well for some reason :(
<hsn_> well, but wireshark will not help much since it is encrypted
<uws> hsn_: you can use bzr:// with a branch published using "bzr serve" on localhost to test
<hsn_> local bzr speed is fine, but network speed is still too slow. I never used git over network so i cant compare
<funkyHat> I read an article (on a planet I think) about using bzr for web development, and a command that could push just a single revision to a server via ssh... but I've lost it now
<funkyHat> I've been poking around trying to figure out how to do it myself but not got anywhere, anyone know which command I should be using? Perhaps it's a plugin I need to add or something?
<jelmer> funkyHat, bzr upload
<funkyHat> thanks jelmer that's it :)
<funkyHat> :( the plugin seems to be broken though
<jelmer> funkyHat, works fine here
<jelmer> funkyHat, what's not working?
<funkyHat> jelmer: the problem was I was using bazaar from hardy, I've upgraded to the bazaar ppa version now and it's all good :)
<sohail> funkyHat, how do you do that?
<funkyHat> sohail: https://launchpad.net/~bzr/+archive
<sohail> funkyHat, thanks
<funkyHat> :)
<Odd_Bloke> luks: remove-tree not warning when you have uncommitted changes is bug 74101.
<ubottu> Launchpad bug 74101 in bzr "remove-tree should warn user if the WorkingTree has uncommitted changes" [Medium,Confirmed] https://launchpad.net/bugs/74101
 * ToyKeeper wonders when bzr 1.6 will land in debian/testing, or even unstable
<Peng_> Hun. I get a KeyError when pulling from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
<jelmer> Peng_, CAn you pastebin it?
<Peng_> Err, hold on
<Peng_> jelmer: From .bzr.log, http://paste.pocoo.org/show/VgqQj9CdOoFkDfZkvswz/
<Peng_> (I'm running latest bzr.dev as of 20 minutes ago.)
#bzr 2008-08-31
<jelmer> Strange
<jelmer> that's the latest revision I pushed
<Peng_> If I try to pull the trunk branch, I get a KeyError on another revision from today.
<Peng_> I can pull lp:bzr-svn.
<jelmer> branching here locally works fine
<Peng_> "bzr log -r -1 http://people.samba.org/bzr/jelmer/bzr-svn/0.4/" works fine.
<Peng_> I get the same KeyError on a copy of the branch on another computer.
<Peng_> FWIW, my branches are in pack-0.92-subtree, not rich-root-pack.
<jelmer> Peng_, please file a bug against bzr
<jelmer> no idea what's causing this
 * jelmer runs bzr check in his 0.4 directory
<Peng_> jelmer: OK, I'll do that
<Peng_> Check passes on my repo, aside from 22 inconsistent parents.
<jelmer> works fine here, no inconsistent parents either
<Peng_> I just reconciled. No more inconsistent parents, but it didn't help the KeyError.
<Peng_> jelmer: Did you run check on http://people.samba.org/bzr/jelmer/bzr-svn/ or your local copy?
<jelmer> Peng_, locally
<Peng_> jelmer: Can you try it remotely, just to be sure?
<jelmer> 980 inconsistent parents, but ok other than that
<jelmer> ok, reconciled
<jelmer> Peng_, can you try again?
<Peng_> Sure
<Peng_> Still failed
<Peng_> Mmm, the packing reconcile did made it much faster. :)
<Peng_> jelmer: bug 263137 filed
<ubottu> Launchpad bug 263137 in bzr "KeyError pulling bzr-svn's branches" [Undecided,New] https://launchpad.net/bugs/263137
<jelmer> Peng_: hmm, reconcile on the server crashes
<ToyKeeper> FWIW, I was able to 'bzr branch http://people.samba.org/bzr/jelmer/bzr-svn/' just a moment ago with bzr r1682, and then 'pull' inside the new branch.
<ToyKeeper> Er, r3668, I mean.  1682 was the revno for bzr-svn.  :)
<ToyKeeper> Geez, I pasted the wrong URL, too.  Add '0.4/' to that.
<Peng_> Hmm, branching into my shared repo failed, but branching into /tmp succeeded.
<Peng_> (Sorry for wasting some of your bandwidth, jelmer.)
<ToyKeeper> I get a KeyError if I use a pack-0.92-subtree shared repo.
<ToyKeeper> ... and it takes about 72s instead of 20s, most of which is spent with the cpu pegged.
<Peng_> Heheheh, using a really fast Internet connection is fun.
<Peng_> ToyKeeper: I can confirm it.
<Peng_> ToyKeeper: Mind if I update the bug?
<Peng_> I just tried to confirm it with a tiny test branch, and everything worked fine.
<ToyKeeper> Peng_: Yeah, sorry, I was away.  Since you haven't marked it as confirmed, I may as well.  :)
<cr3> I seem to have done a checkout rather than a branch, so when I commit it goes directly to the repository instead of making a local commit requiring a later push.
<cr3> how can I change my current directory so that I can do local commits and later push?
<cr3> can I just remove the bound* variables from my .bzr/branch/branch.conf file?
<cr3> nevermind, that seems to have worked
<Peng_> cr3: "bzr unbind"
<LaserJock> any bzr-svn people around?
<LaserJock> I keep getting bzr: ERROR: exceptions.NameError: global name 'revnum' is not defined
<markh> LaserJock: do you have the latest version?
<LaserJock> of the 0.4 branch yes
<LaserJock> I couldn't find any tarballs
<markh> what file and line number is the exception on?
<markh> revision 1670 of that branch was the recent release - its possible the trunk has an error
<markh> s/trunk/tip/
<LaserJock>   File "/home/mantha/.bazaar/plugins/svn/workingtree.py", line 595, in pull
<markh> looks like a typo in working tree
<markh> that line should say 'revnumber' it seems
<markh> personally I'd go back to r1670 though
<LaserJock> how do I do that?
<markh> hrmph - that seems to have the same problem though
<markh> I'm really not sure why that hasn't been seen before - you could try editing that file, or wait for Jelmer to pop up.
<LaserJock> hmm, I'm getting another error
<LaserJock> bzr: ERROR: bzrlib.plugins.svn.core.SubversionException: ("Unable to lock '/data/projects/avogadro/openbabel/cmake'", 155005)
<LaserJock> hmm, maybe I'm doing this wrong. some branches that I've been using bzr-svn on previously seem to work
<rocky> hm, i'm in a mode where several of us are committing changes to our branches on a frequent basis and we have an integration server that we need to update with the changes several times a day ... what should the workflow like that look like ?
<gour> rocky: have you seen http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id58
<rocky> gour: i've read through that guide a couple times now ;)
<gour> rocky: what do you think about that workflow with gatekeeper?
<rocky> gour: well, that's basicaly what i'm doing now... i guess i could try the automated gatekeeper approach
<gour> rocky: yeah. sounds good for your reqs. i, however, do not have experience with pqm
<rocky> neither do i
<rocky> and it's a relatively small project... seems like adding pqm is overkill
<gour> right. human gatekeeper is enough then
<gour> do you use LP?
<rocky> no
<gour> so, distributed workflow with human integrator sounds good for you
<rocky> yeah
<fta> too bad it's not possible to re-upload a deleted package with a different src tarball in ppa :(
<fta> as the tarball is gone from the pool, it should be possible..
<rocky> hrm... if i want to distribute a patch (but not via email) what's the most sensible way to get all info involved? i would have thought "bzr send" but it needs an email addr
<fta> oops; wrong channel, it was meant for #lp
<sven> hi! i got this crash when running bzr log -r <revid>: http://pastebin.com/d6ff1c6a1
<sven> is this a known problem, and do you need the tree in order to debug it?
<jonnydee> hi, can anyone help me out with a merge problem? I would like to merge with anther branch, but I want to decide myself how to resolve (automatically resolvable) conflicts. Bazaar tells me that it has merged all changes successfully, but I do not want to take everything which is in the other branch...
<luks> rocky: bzr send -o filename
<rocky> yeah just figured that out ... it's not obvious in the docs though that that option stops the email from occurring
<sven> jonnydee, if you mean that you don't want to take all changesets in the other branch, use 'bzr merge -r <latest revision you want to take from the other branch>
<rocky> these bundles produced by "bzr send" don't record the commit msgs tho right?
<luks> of course they do
<luks> they are like normal branches, you can merge/pull from them
<jonnydee> no, it's not dependent on the change sets. I would like to merge in only part of the changes of the last changset existing in the other branch
<rocky> luks: oh, is that contained within the "bundle" portion of the file?  the bottom part that is base64-encoded?
<luks> rocky: yes
<jonnydee> sven: I wish I could tell bazaar to let me merge in the changes using kdiff3 instead of leaving it to bazaar to merge in the changes automatically
<luks> the "patch" part is actually not used for anything important by bzr
<luks> all is in the bundle part
<sven> jonnydee, sorry, i don't know how to do that...
<jonnydee> sven: no problem, thanks anyway :)
<jonnydee> maybe anyone else has an answer?
<luks> jonnydee: http://erik.bagfors.nu/bzr-plugins/extmerge/
<luks> oh, actually I'm not sure if that does what you want
<luks> it seems to be only for resolving conflicts
<jonnydee> I've just installed this plugin. Unfortunately, it only allows to resolve conflicts that cannot be resolved automatically by bazaar
<jonnydee> luks: exactly
<jonnydee> actually, what would be needed is to switch off bazaar's automatic conflict resolving strategy and to mark all differences as conflicts
<tumbleweed> anyone familiar with loggerhead?
<luks> jonnydee: hm, telling it to mark everything as conflicts shouldn't be hard
<tumbleweed> I'm using an auto_publish_folder, and getting lots of "Exception: name 'url' is not defined"
<jonnydee> bazaar tries to be as intelligent as possible in resolving conflicts (which it does indeed very good) but it should also allow to be as dumb as possible
<Snaury> Hello, is there a separate channel for bzr-svn?
<jonnydee> luks: how can I do that?
<jelmer> Snaury, Hi
<jelmer> Snaury, nope, this channel is for bzr-svn as well
<luks> jonnydee: not from the command line, but using a plugin maybe. wait a minute
<Snaury> I wonder if anybody else has noticed a dramatic speed drop in bzr-svn 0.4.11: bzr 1.5 + bzr-svn 0.4.10 +django trunk = roughly 1 second per revision, bzr 1.6 + bzr-svn 0.4.11 + django trunk = roughly 10-20 seconds per revision. :(
<jonnydee> luks: ok :)
<jelmer> Snaury: 0.4.11 should actually be significantly faster
<jelmer> Snaury, any chance you can run with -Dtransport to see what sort of requests it's making?
<Snaury> jelmer: I know it should, but in fact it is actually dramatically slower
<Snaury> jelmer: where should I use -Dtransport? bzr update -Dtransport does not show anything. :-/ And I'm on Windows, btw.
<jelmer> Snaury, it will write to .bzr.log
<luks> jonnydee: nope, too complicated for me :)
<jonnydee> wow, you tried to write a plugin :) well, thanks a lot, anyway!!! Shall I maybe submit a bug regarding this issue?
<rocky> jelmer: i just checked out an svn trunk using bzr-svn, then i branched the co, then i tried pushing the branch back as a new branch in svn and it committed the changes i made to the svn trunk instead :(
<jelmer> rocky: Please file a bug
 * rocky wonders if he's just trying to use bzr in a very unusual way which is why he keeps having problems
<jelmer> preferably with some way to reproduce this easily
<jelmer> rocky, what version of bzr-svn are you running?
<rocky> jelmer: 0.4.11 final
<Snaury> jelmer: http://kitsu.ru/bzr-1.6-django.log
<Snaury> That's two revisions. :)
<jelmer> rocky, I can't reproduce it here, there must be more in play there
<jelmer> Snaury, thanks
<Snaury> jelmer: and here what it looks like on 1.5: http://kitsu.ru/bzr-1.5-django.log
<Snaury> jelmer: when I added
<Snaury> jelmer: when I added properties.PROP_IGNORE in fetch.py now log looks like this: http://kitsu.ru/bzr-1.6-django2.log
<jelmer> Snaury, Ah, I think I've seen this before
<jelmer> revprop-list is hanging
<jelmer> I don't remember if it was a server or client-side problem
<Snaury> same subversion, same tree, bzr 1.5 and bzr-svn 0.4.10 and everything is pretty fast. :?
<jelmer> yeah, but bzr-svn 0.4.10 didn't use revprop-list
<jelmer> fetching from django works fine for me (http://code.djangoproject.com/svn/django/trunk/)
<jelmer> one revision every couple of seconds
<Snaury> hmm? look at my bzr-1.5 log. :-/
<Snaury> it has svn revprop-list -r * lines, every one takes ~2 seconds.
<jelmer> it's probably doing other things in between those lines as well
<jelmer> This was a bug in the subversion libraries, but I don't recall the details :-(
<jelmer> Did you build bzr-svn 0.4.10 yourself?
<jelmer> Snaury, any chance you can try the latest revision from bzr-svn's 0.4 branch? Ive added more debug statements
<Snaury> jelmer, sure, just a little later, I made some more mutter calls myself...
<Snaury> jelmer: and it's definitely not revrop-list, I've added (done) mutter call in finally and it returns after just one second. it is hanging somewhere else.
<jelmer> Snaury, revprop-list itself wasn't hanging but was delaying the command that follows it
<Snaury> jelmer: it's lp:bzr-svn?
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<jonnydee> I submitted a bug regarding a "dumb conflict resolution strategy" that marks all differences as conflicts (in essence this means to switch off automatic conflict resolution): https://bugs.launchpad.net/bzr/+bug/263302
<ubottu> Launchpad bug 263302 in bzr "No way to switch off Bazaar's automatic conflict resolution" [Undecided,New]
<Snaury> jelmer: http://kitsu.ru/bzr-1.6-django3.log, as you can see it's not hanging. something is working, just very slowly.
<jelmer> Snaury, but where is it spending that time?
<Snaury> I have no clue. :-/
<Snaury> Is there any 'full-debug' mode, where it prints maximum info in the log?
<jelmer> Snaury: there's various -D options
<jelmer> -Dcache also prints a lot of things
<jelmer> you may want to try profiling
<jelmer> jonnydee, Can't you just use the .THIS and .OTHER files?
<jonnydee> jelmer: but the do not show up when bazaar resolves the conflicts successfully.
<jelmer> jonnydee, ahh
<Snaury> jelmer: I found that the expensive call that takes so much time is reporter.finish(). looks like while it working it calls lots of callback functions, though I can't figure which ones yet. :-/
<Snaury> jelmer: but it takes 10 seconds before it starts calling any callbacks. :-/ And it calls too many of the callbacks, http://kitsu.ru/bzr-1.6-django4.log
<jelmer> Snaury, what do you mean with too many?
<uws> jelmer, Snaury: I also experience extremely SLOW and also overly network intensive "bzr pull" from a svn repos
<uws> that's with Webkit SVN
<jelmer> uws, that's a new regression (with bzr-svn 0.4.11 )?
<uws> the traceback in the log file after "ctrl-c" also shows reporter.finish() almost at the bottom
<Snaury> Well, I'm not an expert, but what I read in svn include files implies that reporter should only call callbacks (i.e. report) changes to what was specified to it. Judging from the number of calls it looks like it reports the whole tree. :-/
<uws> jelmer: dunno when it got this slow. it's haever been fast, but I remember that it only took a few secs for each revision
<uws> right now it's running >1min and still at the first rev
<uws> [=                                                                                                  ] copying revision   1/195
<uws> last 2 lines of log file:
<uws> 176.514  lookup parents: 'svn-v3-trunk0:268f45cc-cd09-0410-ab3c-d52691b4dbfc:trunk:35809'
<uws> 176.514  revprop list: 35809
<Snaury> could it depend on the tree size?
<uws> This is with -Dtransport -Dcache btw
<jelmer> Snaury, it should only call for the changed files in the tree
<uws> tree is huge in the webkit case
<jelmer> uws, it's hard to judge without the full log
<Snaury> jelmer, then look at http://kitsu.ru/bzr-1.6-django4.log (very huge!). that revision changed only *one* file.
<uws> jelmer: http://pastebin.com/m15a35bde
<Snaury> jelmer: if it should only report changed files, then something is royally wrong somewhere. Maybe in the way reporter is initialized. :-/
<uws> jelmer: (has 2 logs, first is with Ctrl-c, the latter is the currently running bzr)
<jelmer> Snaury, uws: any chance you can try again with the last revision of 0.4 ?
<jelmer> (r1688)
<jelmer> that should give more information about what deltas it is trying to retrieve
<Snaury> jelmer: shows svn update -r8749:8750
<jelmer> hmm, that looks right
<jelmer> hmm, wait..
<jelmer> Snaury, what happens if you comment out line 589 to 592 ?
<jelmer> (in fetch.py)
<Snaury> bzr: ERROR: LICENSE is already versioned :)
<uws> jelmer: WAAAAAAY faster, e.g. 1 rev / 3 secs now
<Snaury> so much for "any directories or files not explicitly `set' are assumed to be at the baseline revision originally passed into do_update()"
<jelmer> Snaury, that only doesn't work on Windows for some reason
<jelmer> Snaury, A windows user contributed that fix, it's not necessary for *nix
<Snaury> jelmer, which fix?
<jelmer> Snaury, to explicitly call set_path
<jelmer> for more than just the root
<jelmer> uws, thanks for veryifying that, btw
<uws> jelmer: yw.
<rocky> is the release notes for bzr 1.6.1rc1 available any place? not on news.html yet it seems
<rocky> nvm, found it
<rocky> looking to migrate some svn repos to bzr ... anyone know if tailor supports bzr 1.6 or perhaps suggest an alternate preferable tool to tailor?
<jelmer> rocky: bzr svn-import ?
<rocky> heh
<rocky> didn't even realize such a thing existed
<jelmer> it's part of bzr-svn, just makes it easier to run for a full repository
<rocky> gotcha
<rocky> does it require a rich-root repo?
<jelmer> yeah, it'll still require a rich-root repo
<rocky> how come?
<jelmer> since it generates repositories that are compatible with bzr-svn
<jelmer> and it seems pointless to have two different code paths that have to be tested, given that rich root will be the default in bzr soon
<rocky> makes sense
<Snaury> jelmer: is it possible, for a given InventoryEntry, to find its associated svn revision?
<Snaury> jelmer: could it be that reporter is behaving like that because revision numbers bzr-svn reports to set_path are bigger than what is actually in the repository?
<jelmer> Snaury: That could cause it to do strange things
<jelmer> Snaury, but is that actually the case?
<Snaury> I don't know, that's what I want to try.
<jelmer> it should be easy to see if a revnum exists remotely by running "svn log -r<revnum> <url>"
<Snaury> no, I tried a different thing (passing repo.lookup_revision_id(entry.revision)[1] to reporter.set_path), but it didn't help either.
<Snaury> jelmer: I'm just out of ideas of what's going on here. :-/ I've been looking at svn_client in how it initializes reporter, and it's basically just that: set_path on every dir/file in the working tree..
<jelmer> Snaury, I wonder how this is different from bzr-svn 0.4.10 though
<jelmer> Snaury, did you build subversion yourself for bzr-svn 0.4.10 ?
<Snaury> jelmer: no, I just downloaded official 1.5.1
<Snaury> jelmer: it's also strange how 0.4.10 managed to work with a single set_path("", ...)... :-/
<jelmer> Snaury: same here
<jelmer> Snaury, is start_empty perhaps set to True?
<Snaury> no, I checked and it's False.
<jelmer> hmm
<jelmer> last resort I guess would be to see what's going on on the wire
<jelmer> Snaury, ah
<Snaury> jelmer: what is it?
<jelmer> Snaury, I thought I'd found something but it turns out to be the same behaviour anyway :-(
<Snaury> jelmer, I can't help the feeling there is something wrong in the extensions layer. it's very strange how bzr-svn 1.4.10 with pysvn 1.5.1 manages to succeed with a single .set_path for "", and after adding a bunch of mutters I see that it gets a very small delta.
<Snaury> There is something very wrong somewhere.
<jelmer> Snaury, Not sure why it would be wrong in the extensions layer then though
<Snaury> (and imho writing these extensions was a mistake)
<Snaury> jelmer: because with bzr-svn 1.4.11 it's as if we are updating from revision 0. :-/ Yet python code looks ok (c code, on the other hand, also looks ok, but maybe I wasn't digging deep enough)
<jelmer> Snaury, the C code layer is very thin and works fine here on Linux, for example
<jelmer> Snaury, The python code has changed significantly as well between 0.4.10 and 0.4.11
<Snaury> jelmer: I'm talking here about two things only: call to reporter.set_path and the methods that get called on the editor inside reporter.finish
<Snaury> same calls to set_path / finish give different calls on the editor.
<jelmer> Snaury, those callbacks are called by Subversion
<jelmer> Snaury, and are just wrapped by the bindings, there's no logic there
<Snaury> jelmer: I know. And that's why it's strange. Because same calls should lead to same callbacks. Yet with 1.4.11 we get add_file('LICENSE'), which shouldn't be there.
<jelmer> Snaury, does this problem occur against other repositories as well?
<jelmer> Snaury, I can't reproduce it, that makes it very hard for me to fix :-/
<Snaury> jelmer: I found an interesting bit. 0.4.10 was calling conn.reparent, 0.4.11 no longer does it. Why?
<jelmer> Snaury, because in 0.4.11 the connection is already at the right URL
<Snaury> jelmer: are you on Windows?
<jelmer> Snaury, no, on Linux
<Snaury> jelmer: I can reproduce it with any subversion tree, when there is a single reporter.set_path for "" only, then it give a whole tree instead of delta.
<Snaury> Yet that's how 0.4.10 was doing things, and it always worked.
<jelmer> Snaury, Somebody else reported that the multiple set_path calls were necessary before the bindings were introduced
<jelmer> Sorry, that was actually after it was introduced
<Snaury> jelmer: patched 0.4.10 to call reporter.set_path on all items in the inventory. Not only it still works, it also works fast.
<Snaury> jelmer: I guess I'll just have to keep using bzr 1.5 until I port bzr-svn back to pysvn. :(
<jelmer> Snaury, bzr-svn needs features that aren't provided by pysvn
<jelmer> Snaury, that's one of the reasons for going with the bindings
<Snaury> jelmer: what are those features?
<rexbron> does anyone have a link to an explaination on how to what are and how to use stacked branches?
<jelmer> Snaury, https with untrusted certificates, for example
<jelmer> access of svn working copies
<jelmer> Snaury, with a bit of luck somebody else will figure out what's going wrong on Windows
<Snaury> jelmer: or could it be something related to svn 1.5? what subversion version are you testing with?
<jelmer> I'm using 1.5.1
<Snaury> jelmer: unfortunately I couldn't compile bzr-svn against subversion 1.4.5, ld just keeps crashing for some reason. :-/
<jelmer> Snaury, can you perhaps add a printf in ra.c:124 to check that path and revision arrive correctly?
<Snaury> jelmer: gcc version?
<jelmer> Snaury, 4.3
<Snaury> same here... :-/
<jelmer> Snaury, 32 bit platform?
<Snaury> yes
<jelmer> Snaury, ah
<jelmer> Snaury, another idea
<jelmer> Snaury: in stdbool.h, can you change the typedef to "typedef char bool;" ?
<jelmer> enum will default to int, that may cause strange issues
<Snaury> God damn it. %)
<Snaury> I found out the same thing. :)
<Snaury> that bool start_empty turns out to be always true. :-/
<jelmer> does it help to make bool a char?
<Snaury> Yes indeed. That's the API problem. bool and "b" don't mix.
<Snaury> Perhaps it works on Linux because it was somehow initialized with zeroes?
<jelmer> stdbool.h from the system should be included on Linux, rather than the one in the local directory
<Snaury> Ouch. enum { false, true } is size 4. x_x
<jelmer> I've pushed a fix that changes it to char
<jelmer> please let me know if it's indeed the problem
<jelmer> and if changing it to char helps
<Snaury> Yeah, it finally works. ;)
<Snaury> (I also changed <stdbool.h> to "stdbool.h", because mingw has stdbool.h)
<Snaury> Ouch. But sizeof(bool) in mingw is 1, so how come it was including the one in current directory?! O.o
<jelmer> I think there is magic in setup.py to do that if you run it on Windows
<jelmer> Snaury, yep, it automatically adds "." to the current directory if os.name == "nt"
<jelmer> s/current directory/include directories/
<jelmer> thanks for tracking that bug down though, that was an odd one
<Snaury> Damn. I wonder if with Visual Studio there would be no problem?..
<jelmer> Snaury: It's there as well - the guy who did the patch that calls set_path() for every path in the inventory was working on Visual Studio
<jelmer> I think it's time for a 0.4.12 release :-)
<ToyKeeper> Yay for a bzr-svn release.  :)
<rocky> jelmer: don't suppose you could show me a list of the commands that you would use to setup a bzr repo that has project Foo with trunk, branches, and tags folders that look like how you would do it in svn? :)
<rocky> pastebin
<jelmer> rocky, You mean how I would import into bzr from a repository like that?
<rocky> no... no import
<rocky> say you're creating a bzr repo from scratch, and you just want to setup a new Foo project and work with it similarly to how you would in svn
<rocky> with separate trunk/branches folders
<Pilky> rocky: bzr init-repo Foo
<Pilky> cd Foo
<jelmer> bzr init-repo project; bzr init project/trunk
<Pilky> ah, that too... :P
<rocky> ;)
<Pilky> rocky: just so you know, you shouldn't really need a tags folder
<rocky> what if you're hosting multiple subprojects in that repo ...  bzr init-repo base; bzr init Foo; bzr init Foo/trunk; bzr init Bar; bzr init Bar/trunk   ?
<jelmer> rocky, no, just create a directory "Foo", no bzr init
<jelmer> bzr svn-import will automatically do this for you as well when you import :-)
<rocky> of course... but i'm talking about from scratch now ;)
<rocky> so why no bzr init Foo for the previous example?
<Pilky> jelmer: you wouldn't happen to know who's in charge of the OS X installer?
<rocky> i'm trying to understand the "whys" ;)
<Pilky> rocky: because you don't want Foo to be a branch
<ToyKeeper> rocky: As far as I know, there's not much to be gained by putting multiple projects in the same bzr repo.
<Pilky> it's merely a folder
<jelmer> rocky, bzr init is used for branches
<jelmer> rocky, there is no concept of a "project" in bzr
<jelmer> Pilky, verterok has something to do with it
<rocky> interesting
<Pilky> Verterok: ping
<rocky> jelmer: so if i were using trac-bzr to view what i did above as "base" and then just mkdir Foo and Bar ... they would show up in the trac browser?
<jelmer> rocky, yeah
<rocky> which reminds me, how is trac-bzr these days? :)
<jelmer> there are a couple of things that need to be updated for 1.6
<rocky> oh :(
<jelmer> other than that, it's a bit slow but works quite well
<Verterok> Pilky: pong
<jelmer> we're using it for BitlBee and ctrlproxy with 1.5 I believe
<Pilky> Verterok: do you make the OS X installer for bzr?
<rocky> wonder how it would scale ... i'm looking at offering bzr support for ClueMapper (cluemapper.org) so when creating new Trac projects it would automatically create matching bzr repos (right now it creates matching svn repos)
<ToyKeeper> rocky: You might want to read bzr-trunk/doc/en/user-guide/shared_repository_layouts.txt
<rocky> ToyKeeper: thanks for the pointer
<Verterok> Pilky: yes, only for 10.4
 * Verterok is working on the 1.6 DMG ATM
<Pilky> do you know who does it for 10.5?
<Verterok> Pilky: yes, phanatic build the 10.5 DMG
<Pilky> ah
<Verterok> Pilky: http://bazaar-vcs.org/MacOSXBundle :)
<Pilky> I'm just wondering because it seems to take a week or so for the Installers to come out for OS X :P
<Pilky> was wondering when the 1.6 installers would come out
<Verterok> Pilky: don't know about phanatic, but I've been quite busy... the past week. I'm trying to get it done for monday
<Verterok> Pilky: also for the moment, building the installer is almost completely manual :(
<Pilky> ah, not fun
<Verterok> Pilky: not at all :p
<rocky> ToyKeeper: that info is great at showing you the structure of the options, and shows you when to "bzr init-repo" the toplevel repo, but it doesn't describe when you want "mkdir Foo" VS "bzr init Foo"
<ToyKeeper> If Foo is a branch, then bzr init Foo.  If it's just a directory, then mkdir Foo.
<ToyKeeper> Like, I have a dir called 'merged' where I move old merged branches to.  'merged' isn't a branch, but the items inside it are.
<ToyKeeper> Generally, you probably won't need to 'bzr init Foo' much, because you'll be running 'bzr branch trunk Foo' instead.
<rocky> right
<rocky> that makes sense
<rocky> that of course does mean the management of branches (ie moving them around, etc) isn't versioned, but i dunno yet if that matters ;)
<ToyKeeper> The branch name is recorded for each commit, at least.  So, you can see that a branch started out as 'blah' then became 'fnorg' before it was eventually merged.
<Verterok> jelmer: do you know which branch of bzr-email should I use? (I'm packaging 1.6 for OS X 10.4)
<jelmer> Verterok, I would just use trunk
<Verterok> jelmer: ok, thanks :)
<jelmer> that's at least what I package for Debian
<Verterok> jelmer: trunk 'll be , thanks :)
 * Verterok wonders if it's time to make a 0.1 release
<Verterok> jelmer: bzr-svn 0.4.11 works with 1.6?
<jelmer> Verterok, yep
<Verterok> thanks
<Verterok> just asking, because I'm getting some errors with bzr.dev
<jelmer> with 0.4.11? That's right, bzr.dev broke cloning_metadir()
<Verterok> yep, exactly that
 * ToyKeeper looks forward to new bzr and bzr-svn packages in debian
<ToyKeeper> ... I have a few dozen svn repos on my scm server waiting to be converted, and it looks like it can happen soon.  :)
<dmoerner> what is the equivalent of git reset --hard HEAD? how can i reset the changes represented in bzr diff?
<jelmer> dmoerner, bzr revert
<dmoerner> thank you
<jelmer> ToyKeeper, they're already there
<ToyKeeper> jelmer: I just updated, and debian/unstable has bzr 1.5-1.1
<jelmer> ToyKeeper, ah, you need experimental
<jelmer> unstable is kept clear for things that will make it into lenny
<ToyKeeper> Oh yeah, debian always gets funky around release time.
<ToyKeeper> There it is.  I'm running mostly testing, and hadn't added experimental yet.
 * ToyKeeper <3 apt pinning
<jelmer> ToyKeeper, strange btw, for some reason I was under the impression you were an Ubuntu developer
<ToyKeeper> Nah, I started but got too distracted to follow through with it.
<ToyKeeper> Mundane 'real life' issues keep popping up, so I've had to limit myself to drive-by bugfixes and small projects.
<jelmer> ToyKeeper:  the various bits and pieces you've contributed to bzr and subprojects are very much appreciated
<ToyKeeper> Ooh, sweet.  bzr-svn picked up tags when I pulled today.
<jelmer> yeah, it does that now
<ToyKeeper> In any case, bzr is a better svn client than svn itself.  :)
<jml> hello
<james_w> hey jml
<james_w> happy monday
<jml> urgh
 * jml doesn't like Mondays.
<jml> actually, that's a lie.
<jml> I don't like *mornings*.
<james_w> jml: do you have any love for me yet?
<jml> james_w: no, sorry. stacking's taking all of my loving.
<james_w> that's ok, it surely needs some
<spiv> Good morning!
<jml> spiv: good morning!
<jml> spiv: welcome back.
<james_w> we just passed feature freeze, so it makes you look forward to the release.
<jml> james_w: yep :)
<james_w> hey spiv, welcome back.
<james_w> good holiday?
<jml> james_w: I saw mdz's blog post and thought "oh bother, that doesn't really leave much time?"
<jml> except with a mental '!', rather than a '?'.
<jml> because I type better in my head.
<james_w> jml: I got that, but luckily a few days before feature freeze
<spiv> jml: thanks!
<spiv> james_w: very good, yeah.  NZ seems to be composed almost entirely of scenery designed for postcards.
<jml> heh
<jml> it's true.
<james_w> :-)
<spiv> "Oh look!  *Another* alpine lake surrounded by snow-capped mountains!"
<lifeless> moin
<lifeless> wb spiv
<james_w> hi lifeless
<jml> g'day lifeless
<jelmer> Verterok, ping
<Verterok> jelmer: pong
<jelmer> Verterok, does the new mac os x installer include  bzr-svn?
<Verterok> jelmer: nope (yet)
<Verterok> I was trying to write a mail about this :)
<Verterok> jelmer: I can't build the package using setuptools :(
<jelmer> Verterok, oh, ok - what sort of error do you get?
<Verterok> jelmer: I get an empty package in dist/
<Verterok> jelmer: let me try a last thing before bother with this :)
<Verterok> jelmer: yay! it worked (just need to be root to run the setup.py :p )
<Verterok> jelmer: I can include bzr-svn in the final 1.6.1 (or the next rc)
<jelmer> Verterok, oh, ok - odd
<Verterok> jelmer: just one thing. I'm building it against Collabnet subversion-1.4.6
<jelmer> Verterok, that should work fine
<Verterok> jelmer: I'll build another package against 1.5. It's ok if I upload both installer to launchpad.net/bzr-svn?
<jelmer> Verterok, yeah, please do
<lifeless> poolie says hi, and his adsl isn't; he hopes it will be in time for the standing and upping
<markh> jelmer: did you happen to see a conversation here yesterday where someone reported a NameError in bzr-svn?
<jelmer> markh: yeah, I committed a fix for that
<markh> excellent :)
<jelmer> lifeless, is there a reason Repository.revision_tree(None) is used rather than Repository.revision_tree(NULL_REVISION) in several places?
<Verterok> jelmer: I'm going to package both versions of bzr-svn (for 1.4 and 1.5), same DMG or one DMG for each? (1.1MB each pkg)
<jelmer> Verterok: I'm not really familiar with DMG files
<jelmer> Verterok, is it possible to choose the installation of just one?
<Verterok> DMG is a fancy zip :p
<Verterok> jelmer: there is each pkg is an installer itself, the only issue is that only one can be installed
<Verterok> s/there is//
#bzr 2009-08-24
<blizzkid> no I'll just have to find out how to push it to lp
<blizzkid> s/no/now
<poolie> blizzkid: see http://help.launchpad.net/
<poolie> lifeless:  thanks for fixing the selftest tests, they annoy me every time i see them
<poolie> for some reason tests that just check a parameter is passed through a layer annoy me though
<blizzkid> hmmz.... why do my branches have /+junk in it?
<poolie> i guess partly they often require a big hammer (monkeypatching) to write but they don't test very strongly
<poolie> blizzkid: if they're not associated with a project they're called junk
<poolie> maybe you want to register a project?
<blizzkid> poolie: not exactly... let me explain: I made a change to a gwibber branch
<blizzkid> but I can't upload to that branch
<poolie> is it your branch?
<blizzkid> no
<poolie> so you want to fix a bug or something and give that back to them?
<blizzkid> right
<poolie> i see you're already in the gwibber team?
<poolie> what's the branch about? what name do you want to push it to?
<blizzkid> poolie: in short I'd like ~blizzkid/gwibber/cwibber instead of ~blizzkid/+junk/gwibber/cwibber
<poolie> ok and what happens if you try to push to the first of them?
<poolie> igc, what are we going to do about bug 415508?
<ubottu> Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,Triaged] https://launchpad.net/bugs/415508
<blizzkid> poolie: testing atm
<igc> poolie: I think we're going to deprecate the code path using path_content_summary()
<igc> poolie: iiuic, it's not broken in 2a, "just" 1.14
<lifeless> poolie: so, testing that a layer does whats meant to is never pointless IMO
<igc> poolie: so maybe it's high and not critical?
<lifeless> path_content_summary is broken in 2a as welel
<lifeless> *well*
<lifeless> if you e.g. do 'bzr commit --excludes' (or at the moment 'bzr commit foo')
<blizzkid> poolie: it worked
<poolie> yay
<poolie> lifeless: if you do that then what?
<poolie> (impatient)
<poolie> blizzkid: all good now?
<blizzkid> poolie: yeah, now let's hope they accept the merge proposal :)
<lifeless> poolie: then the corruption occurs because the non iter_changes commit code path is executed
<poolie> ok so if we set up content filtering, in 2a, then used commit --excludes there would be corruption
<poolie> of what type?
<poolie> btw our bug-handling doc says we don't use status Triaged, only Confirmed
<lifeless> poolie: of the sort in that bug
<lifeless> poolie: john's done all the digging
<lifeless> poolie: (why are you impatient, its a fine monday morning)
<poolie> it's a lovely day
<poolie> i just want to get a 2.0 out
<poolie> it's constructive impatience :)
<poolie> so i'm just asking because it looks like it's not actually corruption, just that we redundantly store a new text
<poolie> which would be bad, admittedly
<poolie> if we store all the texts on every commit it would be awful
<lifeless> it also means that log <FILE> does very much the wrong thing
<lifeless> and the merge graph, when merges are involved, goes haywire without converging
<poolie> ok
<lifeless> if we can get a small fix I'm incliined to say say we should backport it to the karmic version and get it out there.
<lifeless> its _bad_
<lifeless> its not eat your history and spit it out
<lifeless> but if you recall the bug we discovered it via, its a tremendous performance hit
<poolie> i do
<poolie> just trying to understand it
<poolie> i might start on this today
<poolie> and would you agree with ian's thing to "deprecate the code path using path_content_summary()"
<lifeless> that requires adding exclude support to iter_changes (via internals or decoration) and checking it creates consistent deltas.
<poolie> which sounds a bit large
<lifeless> I think changing the record_entry code path to stop using path_content_summary, and delete the path_content_summary method is fine.
<poolie> i thought that's what ian was suggesting
<lifeless> alternatively, have path_content_summary work when there are filters
<poolie> did you just set that bug to triaged, or is this launchpad being weird?
<lifeless> poolie: well, the code path that /uses it/ can't be deprecated without the exclude changes I mention above. But you can /change the code path to not use path_content_summary'.
<poolie> right, and deprecate path_content_summary
<poolie> at least weakly
<poolie> ok, i'll pull on that string
<lifeless> I'm against deprecating the method. If its irredeemably broken, delete it.
<poolie> i love the ajax bug stuff but it does seem to trip over itself a lot :/
<lifeless> if its not so broken, fix it.
<igc> +1 from me wrt deleting the method instead of deprecating it
<lifeless> deprecation is good for non-ideal things, or things we've improved. its a poor way to indicate 'bad things are happening'
<poolie> mm
<poolie> as i see it, it's a way to give plugin or similar authors a clue that 'no you're not going crazy, we changed this' and to possibly give users something that still works until the plugin is updated
<poolie> it's good at the first, only mediocre at the second because those users don't actually want to see the technical mesasges
<lifeless> sure; but this doesn't meet the contract it claims too
<lifeless> s/to/
<poolie> so wrt the first one, we could say it's better to raise an error if you still try to call it
<lifeless> sure. Or put it in NEWS.
<poolie> yeah, there is that
<poolie> igc, iirc you were going to check if any plugins care about it
<lifeless> poolie: I wasn't touching that bug
<poolie> ok
<lifeless> poolie: re confirmed/triaged; LP changed its meaning around when it added triaged. I think we should ignore confirmed and just use triaged everywhere that we've set an importance.
<poolie> something strange happened between the various status controls i think
<lifeless> because thats what lp's  workflow and reports want.
<poolie> like what?
<lifeless> like 'what bugs has a core dev not seen'
<poolie> what i mean is, where does lp make a distinction between them?
<lifeless> I don't recall offhand
<lifeless> I've encountered glitchy things
<poolie> mm, they may have
<poolie> this thing i just saw might have been such a glitch
<igc> poolie: quick grep over my plugins.popular directory (used to build the plugins guide) shows ...
<igc> poolie: svn/commit.py, git/commit.py, cvsps_import/importer.py
<lifeless> poolie: anyhow, unless you have a reason /not/ to use triaged, we should be using it.
<poolie> i think 'triaged' is kind of a stupid name that means the same as 'has an importance'
<poolie> but that's not a very strong reason :)
<lifeless> poolie: I agree. Thats a different discussion though.
<poolie> i just don't want more labels than there are logical states
<lifeless> [as in, its a discussion with #lauchpad-dev]
<poolie> yeah
<igc> make that cvsps_import/cvsps/importer.py
<poolie> i don't think we distinguish between two confirmed-type states, but the bugs are spread across them
<poolie> igc, well there are 77 uses just in the tree so that's enough to get on with
<poolie> so what would be a good overall test for this?
<igc> Triaged just means "I'll look at this and assigned an importance" to me
<poolie> at the blackbox level i could set up a tree with filtering, commit, and then see if the per-file graph changed
<lifeless> igc: *looked* ?
<poolie> or not quite blackbox
<lifeless> poolie: what particular thing do you want to test
<igc> lifeless: yes, sorry - Monday morning typo
<poolie> that this bug is fixed :-)
<poolie> i'm trying to work out what that means
<lifeless> poolie: I wouldn't write such a test; the bug is a lack of test coverage in filtering trees.
<lifeless> filtering trees in per_workingtree should be testing all the stock tests with filters, that would have caught this.
<poolie> caught it how?
<lifeless> the path_content_summary bug would have been exposed
<poolie> by exercising content_summary returns the summary of the canonical form?
<poolie> s/exercising/checking
<lifeless> so we know its not a repository bug, exercising repository code to show the bug is fixed is waste
<poolie> hm
<poolie> yes, though if we added canonical_content_summary and convenient_content_summary
<poolie> we ought to have something that tests that commit uses the right one
<poolie> well
<poolie> adding the test_content_filters test would be an easy place to start
<spiv> Good morning.
<lifeless> poolie: we have lots of tests of commit builder
<poolie> hi spiv
<lifeless> poolie: but roughly yes.
<poolie> ok so i might start by changing *content_something to an interface with a more explicit name
<lifeless> FWIW, I think john had a patch.
<lifeless> If I were working on this, I'd look at how to make sure that that stops using path_content_summary; then work towards that.
<lifeless> poolie: re triaged/confirmed, can we at least not twiddle them - its just noise. I have no objection to a change when something else is being altered on the bug, but arbitrarily altering that field doesn't seem beneficial.
<poolie> yes, i agree on both
<poolie> i thought you were twiddling them, that's why i asked
<poolie> but apparently it was lp
<poolie> or something
<lifeless> no, I'll set to triaged if its < than that when I am altering the bug; but I won't just change that field alone ;0
<poolie> less than that?
<lifeless> triaged. If its new or incomplete or confirmed, and I'm changing other status fields
<poolie> look, the doc says "don't use triaged"
<poolie> so please don't
<poolie> if you want to change the policy, because lp has changed or for other reasons, please do that first
<poolie> having them set randomly depending on who last touched it is not helpful
<spiv> igc, lifeless: if either of you feel like doing a review, there's https://code.edge.launchpad.net/~spiv/bzr/ids-only-necessary-texts/+merge/10444 :)
<GungaDin> http://pastebin.ca/1541055
<GungaDin> I just got this error from Bazaar.
<GungaDin> Could this be due to not having enough memory?
<spiv> GungaDin: yes.  (Or alternatively, due to Bazaar not being clever enough when dealing with large files)
<poolie> maybe we should give a special message for memoryerror?
<GungaDin> hmmmm...
<GungaDin> ok
<GungaDin> The problem shouldn't be large files... it's just a big repo
<GungaDin> none of the files inside is that big.
<spiv> poolie: not a bad idea.  At least for some of the known trouble spots like that ''.join...
<spiv> GungaDin: Hmm.  IIRC, that error usually occurs when handling a large file version.  Perhaps there used to be a very large file earlier in the history?
<GungaDin> could be...
<GungaDin> dunno really
<AfC> So, given that you dump traces in bzr.log, couldn't you just swallow any even remotely predictable exceptions and give a human readable single line error message instead?
<spiv> AfC: well, we mostly do that already :)
<AfC> [me is Java programmer, knows value of thread dumps at programming & debugging time, but I also know how much they freak out innocent users who were under the mistaken impression that they have a warranty with their software :)]
<poolie> yeah, we do exactly that
<AfC> spiv: ... it also just came up on the mailing list
<poolie> afc, the question is more precisely,
<poolie> should we add MemoryError to the class of errors that are treated as environmental not a bug
<AfC> poolie: ah
 * AfC understands
<AfC> So, does Python's VM expand to use all available memory until the kernel OOM killer gets it?
<spiv> Probably "bzr: ERROR: out of memory" is virtually always a better thing to do than a traceback, even if the MemoryError is (hypothetically) a bug in a dependency rather than bzrlib.
<AfC> For reasons that defy comprehension Java's VM has to be told manually to use [lots of] available memory. Quite the pain in the ass.
<poolie> afc, no, it's like java, it normally raises an exception
<AfC> especially with people innocently using recursive descent parsers, etc.
<AfC> poolie: right, but in Java's case if you don't manually tell it to use more than hard coded maximum 256 MB (or whatever stupid number it is) of heap, that's all it'll ask for before raising OutOfMemoryError
<spiv> Well, in the case of recursion, CPython has a limit on the amount of recursion it can handle because Python function calls use C stack frames too.
<spiv> But yes, CPython will happily ask the OS for as much memory as the program demands.
<AfC> spiv: (yeah, I realize I was conflating stack and heap there, but the two tend to go hand in hand when tree-building)
<thumper> general frustration
<thumper> packaged bzr and bzrtools don't work together :(
<poolie> thumper: what are you using from bzrtools?
<thumper> poolie: I tried both trunk and the one from the ppa
<poolie> i mean, why do you have bzrtools installed?
<poolie> just for background
<thumper> cbranch
<poolie> ok
<poolie> :/
<lifeless> so I was chatting with john yesterday
<poolie> aaron insists on having them locked in sync
<lifeless> he's going to package more
<thumper> :(
<poolie> even though in this case there were 0 changes to update to 1.18
<lifeless> to help with this
<thumper> icanhazcbranchtrunk?
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/417922
<ubottu> Launchpad bug 417922 in bzr "treat MemoryError as a special/environmental error" [Medium,Confirmed]
<lifeless> thumper: not for 2.0; something equivalent but hopefully integrated not bolted on, in 3.0
<poolie> yeah
 * thumper nods
<lifeless> and by integrated I don't mean 'in core', I mean 'in UI / workflow'
<thumper> using bzr.dev for bzr now
<poolie> regarding john's patch http://bazaar.launchpad.net/~jameinel/bzr/1.17-content-filtering-commit/revision/4530
<poolie> it looks like it's still trusting the content_summary sha1
<poolie> i don't know if that's safe
<poolie> but if we were going to take this patch, it does seem like we'd need a test of commit with content filtering
<lifeless> it depends what dirstate is doing
<lifeless> I suspect dirstte stores the canonical sha1
<lifeless> in which case the sha1 in a content summary is valid if its coming from a dirstate cache hit
<rbriggsatuiowa_> wt = Branch.open('/Users/rbriggs/bzr/test.bound')
<rbriggsatuiowa_> wt.update
<rbriggsatuiowa_> this is not actually updating the branch (it's a bound branch)
<rbriggsatuiowa_> what is the method that I actually want to use
<lifeless> wt.update()
<lifeless> but
<lifeless> Branch.open returns a branch, not a tree
<lifeless> you want
<lifeless> wt = WorkingTree.open(...)
<lifeless> wt.update()
<rbriggsatuiowa_> alright - I tried that too and it doesn't work either
<lifeless> what are you expecting to happen that is not happening?
<rbriggsatuiowa_> I am expecting it to have the same result as if I ran bzr up from the command line
<rbriggsatuiowa_> the branch that wt is bound to is at version 3 - but wt keeps staying at version 2
<lifeless> thats the api that cmd_update uses
<lifeless> cmd_update does more; you should look at it inside bzrlib.builtins
<rbriggsatuiowa_> cool - thanks
<rbriggsatuiowa_> btw - love this chatroom - it has always been helpful
<AfC> Ok, that's weird. That rbrigg fellow managed to have his nick show up in italics in my IRC client. Hm. injection vectors. Yeay.
 * igc lunch
<vila> hi all
<poolie> hi vila!
<lifeless> hi vila
<vila> lifeless: rev4638 on trunk is weird, the message and the "code" actually committed doesn't seem to match >-/
<vila> The message says : "Improve test performance of selftest tests." but the commit is about the "Triaged" definition...
<vila> lifeless: not a big deal, more a heads-up in case you missed something
<lifeless> oh frell
<lifeless> landed totally the wrog branch there
<vila> my worst nightmare.... :D
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10590
<lifeless> is the follow on to what I had meant to land
<poolie> igc, so as far as i can make out the content_summary is meant to be about the internal form
<poolie> i think we should see about a clearer distinction between those that are and those that aren't
<igc> poolie: right. It's only used in bzrlib (to my knowledge) for getting what to commit
<lifeless> it predates filters
<poolie> sure
<poolie> the question really is, what are interfaces that predate filtering meant to do
<lifeless> I agree with what you're saying.
<lifeless> interfaces predating are all about the canonical form, IMO
<poolie> cool :)
<poolie> then we all agree :)
<igc> lifeless: ir predates filters landing; content filtering development started before it existed by then I got sick
<igc> s/ir/it/
<igc> s/by/but/
<poolie> i mean even aside from this particular method there are going to be other things that are not filtering-aware
<igc> right, because there was no convenient form
<poolie> i was wondering before if perhaps we should have a separate tree object that represents the filtered form
<poolie> it may be complicated to make that work properly with eg treetransforms
<poolie> but it might be cleaner
<poolie> hm it might be hard to make it work well with dirstate too
<fullermd> Files can be different from the filtered form (and different from canonical), and still evaluate to the same canonical form...
<fullermd> So at best it would probably only save you work some of the time.
<igc> fullermd: right
<fullermd> (of course, that may be the vast majority, so still be a win.  But you'd always have to treat a miss as just a hint at any rate)
<poolie> i meant easier in terms of less bugs, not faster
<fullermd> I'd think the result would just be to hide them more often.
<fullermd> (I guess that's "less", but probably not in a way we really want  :)
<poolie> why?
<poolie> actually, are we even talking about the same thing? ie having a FilteredTree(filters, tree) class
<fullermd> Possibly not.  I never really know what I'm talking about.
<poolie> :}
<NEBAP|work> vila: ping
<vila> pong
<NEBAP|work> vila: good morning :)
<vila> NEBAP|work: You too :)
<NEBAP|work> vila: get the error reproduced?
<vila> So, I looked at our bug and couldn't find a way to reproduce the "obj/file2' is not conflicted, only "obj.moved/file2" is not conflicted
<NEBAP|work> hmmm
<NEBAP|work> weird
<vila> So I left it up to you to find the right sequence :)
<NEBAP|work> ^^
<vila> From there, but from there only can I try to fix the problem
<NEBAP|work> will play a bit with generated folder ;)
<NEBAP|work> and then give you the results
<vila> NEBAP|work: ok, thanks !
<vila> NEBAP|work: My best guess is that the sequence is so alien to me that I can't force myself to reproduce it,
<NEBAP|work> doesnÂ´t bazaar have a "log" where you can see the last xx commands?
<vila> .bzr.log in $HOME (bzr version will tell you where)
<vila> Good idea
<NEBAP|work> I hope that it wasnÂ´t my fault that caused the error..
<vila> I suspect some more non-bzr commands are involved though
<NEBAP|work> so, will that help if I take the log from chris computer?
<vila> NEBAP|work: Don't think about it as whose fault it was, in the end we want bzr to help you avoid such problems anyway
<NEBAP|work> kk
<vila> NEBAP|work: it will certainly help, if only by restricting what bzr commands we should include in the scenario
<vila> there can also be a '.bzr.log.old' there too
<NEBAP|work> k, I will look for those files on chris computer and then send them too, ok?
<vila> if you can find the commands that have been executed in the right time frame (hopefully you can identify that :)
<vila> that will help
<vila> NEBAP|work: try to filter them a bit first
<NEBAP|work> ok, if the commands are in the log file, IÂ´ll find them ;)
<NEBAP|work> ok
<lifeless> poolie: I landed the policy change by mistake. I'll back it out tomorrow.
<poolie> k
<vila> lifeless: grr, I already asked you (can't remember where): where the h is boto ?
<lifeless> vila: apt-get install python-boto
<vila> I'm sure I tried that :-(
<lifeless> may be only in karmic
<lifeless> in which case
<lifeless> add karmic to your sources
<lifeless> then apt-build install python-boto
<poolie> python2.5-boot
<poolie> boto
<vila> available in jaunty, may be it wasn't last time I checked...
<poolie> in jaunty
<vila> in universe
<vila> lifeless: but did you try my patch ? The only helper class I modify is *inside* fork_for_tests...
<lifeless> vila: is it? [no I hadn't;  I was doing a trawl through for unreviewed things...]
<NEBAP|work> vila: email is on the way, keep that one private please .. (should contain the hole session from friday)
<vila> NEBAP|work: sure
<vila> lifeless: I don't want to force your vote (non sense anyway) but I'd like to keep that submission simple, I *want* to limit the number of spawn process, but it requires a more extensive change (I know, I tried)
<lifeless> vila: It would make me happy if you test it with ec2test.
<vila> lifeless: devil :)
<lifeless> I'd like to know that all the hacking you do in this space fits with ec2test, because I think its a good model for a bunch of things like - having pqm validate on windows during commit.
<vila> lifeless: you know we agree on the aim, even if we disagree on the steps to get there :)
<lifeless> I'm not sure we disagree on anything ;)
<vila> Is that the same as: "I'm sure we agree on nothing" ? :-D
<lifeless> heheh
<vila> NEBAP|work: I received the file, but it looks like a lot of lines are badly truncated (as if you copied some file content in a mail...) can you resend the file itself as attachment ?
 * igc dinner
<NEBAP|work> vila: sure, give me a second
<Coke> Hello. I have a problem, the server admins have changed the SSH port so now my bzr branch is wrong when I try to commit files. How can I change this without losing the data I've modified?
<vila> NEBAP|work: the scope sounds good though as far as I can see, the last commit/push is the one that succeeded right ?
<NEBAP|work> vila: yes should be :)
<vila> Coke: mention the port explicitly in the url
<vila> Coke: uze 'bzr info' to check what bzr thinks your branches are, use --remember in the right command to update that
<Coke> vila: ah, remember
<vila> Coke: now you remember ? :-D
<Coke> no, I'm trying to remember
<Coke> sorry, to USE --remember
<Coke> unknown command "--remember"
<vila> Coke: --remember is a parameter accepted by commands like 'push', 'pull'
<Raim> Coke: more like: bzr push --remember
<Coke> ok. and after remember I have the new URL?
<Raim> and the URL as additional parameter of course
<Coke> ok.
<Coke> bzr: ERROR: no such option: --remember
<Raim> which bzr version do you use?
<Coke> I'm trying to do a ci
<vila> Coke: you use the command as usual (but mentioning a new URL) and you add --remember
<Coke> 1.17
<vila> Coke: what does 'bzr info' says ?
<Raim> bzr ci does not have --remember as it does not require a URL
<NEBAP|work> vila: on the way
<Coke> vila: about?
<Coke> Raim: so how do I solve this?
<vila> Coke: can you paste it somewhere ? Do you use a standalone branch or a heavyweight checkout ?
<Coke> it says "checkout of branch" in info
<vila> hmm
<Coke> all I want to do is change the URL used when doing ci and up
<Coke> it's stored somewhere in some magic file
<Coke> (which the README says explicitly not to touch manually)
<vila> Coke: cat .bzr/branch/branch.conf
<poolie> vila: have you ever seen this:
<poolie> mbp@grace% ./bzr --no-plugins selftest nested
<poolie> testing: /home/mbp/bzr/bzr.1.18/bzr
<poolie>    /home/mbp/bzr/bzr.1.18/bzrlib (1.18 python2.6.2)
<poolie> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<poolie> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<Coke> vila: should I change that manually?
<poolie>                                                      
<vila> poolie: yup, every day :)
<poolie> really? i don't think i ever havebefore
<vila> poolie: I traced it back to a test saying it was expected or something
<spiv> I see it sometimes.
<vila> I was about to summon you spiv :)
<Coke> vila: OH! that worked nicely even though I shouldn't meddle with .bzr
<spiv> It's something that only happens when .pyc files are generated, or something weird like that.
<vila> Coke: huh ? Just looking at the file ? Or do you mean you edited the file ?
<Coke> vila: I edited it.
<vila> Coke: ok, certainly the simplest there :)
<vila> There may be a way to do it from the command line, but not using heavy checkouts myself, I don't know it
<Coke> How come bzr up doesn't restore deleted files?
<Coke> I deleted a file in the local branch and then did bzr up to see if it would restore it, but no go
<vila> Coke: a versioned file ?
<vila> Coke: ho, you want 'bzr revert'
<vila> bzr update will respect your local changes as much as it can
<Coke> vila: ah
<Coke> thanks
<Coke> still getting used to the CVS -> bzr switch
<vila> Coke: You're welcome
<Coke> wow. bzr uploads could not possibly be any slower. :)
<poolie> :/
<Coke> it's doing < 1k/s
<poolie> over what protocol, and with what version?
<Coke> sftp
<Coke> 1.17
<poolie> to launchpad, or elsewhere?
<Coke> elsewhere
<Coke> for launchpad I use lp protocol
<Coke> Man, does launchpad have support for showing number of checkouts and/or downloads yet?
<poolie> no
<poolie> would be nice
<Coke> I've seen that as a requerst for ages now.
<Coke> What are the launchpad devs doing? Lunch from monday to friday?
<Coke> lunchpad
<Coke> Does bzr work inherently with other project sites?
<Coke> or, rather, can you guys recommend a project site, as bzr user?
<poolie> what do you mean?
<Coke> poolie: I'm looking for a place to host my free projects, launchpad is lacking too many features
<Coke> I want something like sourceforge, but something that has bzr repos support
<poolie> sourceforge supports bzr repos
<Coke> Ohh?
<poolie> i'm pretty sure
<poolie> what features do you think lp needs most?
<Coke> statistics on repos and files and a wiki
<Coke> it can even be a linked wiki, as long as it works with the lp login
<poolie> like download counts? to know if anyone cares?
<Coke> poolie: indeed
<vila> NEBAP|work: I'm pretty sure the problem is case related, can you check that ? (It also explains why I couldn't reproduce it since Linux is case sensitive)
<poolie> it has counts for download files
<vila> NEBAP|work: like 'bzr resolve "pda/<etc>"' raises 'is not conflicted' while 'bzr resolve "PDA/<etc>"' works, can you check that ?
<Coke> poolie: I haven't packaged my stuff yet, so number of checkouts/branches would be cool too
<Coke> poolie: the wiki (or anything that let's you put some screenshots up) would be great
<Coke> poolie: I do a lot of UI things lately and in the case of UI's a picture really says more than a thousand words
<vila> NEBAP|work: and thanks for the updated mail :)
<NEBAP|work> vila: IÂ´ve checked that while we had the problem, but IÂ´ll recheck, but windows is not case sensitive even using bazaar (used it for many projects)
<Coke> poolie: lp could even have a wiki with support for a bzr backend :)
<vila> NEBAP|work: right, if you can confirm, we have identified the bug :)
<poolie> 'cos there's a thread here
<poolie> https://lists.launchpad.net/launchpad-users/msg05247.html
<poolie> a wiki is very popular
<Coke> poolie: it would solve all project hosting problems I've encountered with minimum effort from lp
<Coke> like "can I post more screenshots?" -> do whatever you want in your project wiki
<poolie> one more wish?
<Coke> poolie: that's it.
<Coke> poolie: checkout stats and a wiki would make lp _complete_
<Coke> I'd be able to throw away my freshmeat and sf accounts
<poolie> heh
<poolie> well, there are still about 5000 bugs open :)
<poolie> but those two would help a lot
<poolie> i'm told that now there are file download counts doing it for branches may not be that hoard
<poolie> hard*
<Coke> poolie: bugs are another story. so far nothing that prevents me from using lp
<Coke> I think the biggest reason launchpad is moving slowly with development is the license. :)
<poolie> oh?
<Coke> poolie: sure. I'd help if the sources were readily available
<vila> NEBAP|work: The trick is that the message is "file does not exist" or "not conflicted" depending on whether or not the file exists, but on case insensitive file system, that's wrong and that's why I couldn't reproduce it
 * fullermd has to question just how many random contributions Sourceforge-the-software has ever gotten...
<poolie> then i have a treat for you
<vila> NEBAP|work: looking at the code, I'm 98% sure I found the problem, can you give that 2% missing ? :-D
<poolie> Coke: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/files
<NEBAP|work> vila: I will, just give me a second, can you tell me which commands I should test with the folder we created on friday?
<vila> 'bzr resolve "pda/<etc>"' sould fails, 'bzr resolve "PDA/<etc>"' should succeed,
<Coke> poolie: yes, that's not new though, is it? I still can't find any news on the license
<vila> replace <etc> with the path leading to the conflicted file that caused problems
<vila> NEBAP|work: be extra careful with the case, start with the wrong case
<Coke> "gnu affero" ?
<poolie> right
<poolie> http://www.gnu.org/licenses/agpl.html
<poolie> is that a problem?
<Coke> not sure.
<Coke> poolie: hm. I didn't know there was any linking donein lp at all
<Coke> poolie: well, this is great news anyway
<Coke> poolie: looks tidy for such a large project
<Coke> poolie: are you one of the lp regular devs?
<poolie> no
<poolie> i just kibbitz
<Coke> kibbitz?
<fullermd> n'bitz n'bitz.
<Coke> huh?
<fullermd> Random jingle injection.  Don't mind me   :p
<vila> fullermd: http://instantrimshot.com/
<vila> Coke: My dictionary tells me: v : make unwanted and intrusive comments [syn: kibitz]
<NEBAP|work> vila: sorry, had to do some work ^^, so how can I get back the conflicts?
<spiv> Ooh, this groupcompress batching fix for remote IO also improves build-tree time for Launchpad by ~5%.
<spiv> I was worried the complexity might have the opposite effect, apparently not :)
<Coke> vila: weird :)
<vila> NEBAP|work: 'bzr conflicts' ?
<vila> NEBAP|work: or restoring the backup you made friday
<NEBAP|work> vila: I use the backup from friday, but it seems to be the point before the conflicts
<lifeless> spiv: less IO is less IO
<vila> NEBAP|work: so you should merge again, was it -r29.1.1 ?
<NEBAP|work> vila: yes, should be the latest server version
<NEBAP|work> vila: bzr merge server -r 29.1.1    ?
<spiv> lifeless: right, that's what I was hoping.  But I know better than to merely hope that a change will improve performance :)
<vila> NEBAP|work: I think so
<NEBAP|work> :D
<spiv> lifeless: I can be hopeful and worried simultaneously ;)
<vila> spiv: Yeah, I often worry about my daughters being to hopeful :-D
<NEBAP|work> vila: ok, conflicts are there, also created the obj.moved folder and the xxxx.cache.BASE and xxxx.cache.OTHER files :D
<NEBAP|work> vila: now what should I do to check if itÂ´s the error you think?
<vila> NEBAP|work: 'bzr resolve "pda/<etc>"' sould fails, 'bzr resolve "PDA/<etc>"' should succeed,
<vila> NEBAP|work: be extra careful with the case, start with the wrong case
<NEBAP|work> k
<NEBAP|work> lower case (wrong) -> xxx.cache does not exist
<vila> ok, try with correct case for the directory but not final part of the path
<NEBAP|work> PDA/trunk/.../lower.cache (just file is wrong) -> xxx.cache does not exist
<NEBAP|work> XxxxXxxx.cache (everything ok) -> file does not exist
<vila> ....
<NEBAP|work> because of that I renamed the file using the os functions
<vila> NEBAP|work: usr bzr conflicts forst
<NEBAP|work> on friday
<vila> what ?
<NEBAP|work> on friday I get the same error (file doesnÂ´t exist)
<NEBAP|work> because it doesnÂ´t exist (there is just the xxx.BASE and xxx.CACHE left) I renamed on of them using normal os functions
<NEBAP|work> sorry
<NEBAP|work> (xxx.cache.BASE and xxx.cache.OTHER are left, no xxx.cache)
<NEBAP|work> so I used "rename xxx.cache.OTHER xxx.cache"
<NEBAP|work> to ensure that the file exists
<vila> ok, do that first then,
<vila> then retry 'bzr resolve lower',
<vila> hmm, but I think 'bzr mv xxx.OTHER xxx' is mandatory here...
<vila> ha, no, forget about that
<NEBAP|work> maybe you can see in the logs what IÂ´ve done (if you look on the files)
<NEBAP|work> k
<NEBAP|work> will rename it now
<vila> NEBAP|work: you did 'bzr mv' for the one that worked and then 'bzr resolve <right case path>'
<NEBAP|work> k and for the ohter bzr mv didnÂ´t work, right?
<NEBAP|work> k, renamed the file now
<vila> NEBAP|work: apparently yes
<NEBAP|work> lower case -> file doesnÂ´t exist
<vila> does the file exist ?
<NEBAP|work> yes
<NEBAP|work> file lower case -> file does not exist
<NEBAP|work> but I can see bzr converts in the wrong way
<vila> then you don't specify correctly or something because this message is issued after a os.path.exists(path)
<NEBAP|work> the file is: Folder/folder/Folder/FileName.ext   for example
<NEBAP|work> the bazaar error format is like this: Folder/folder/Folder/filename.ext  (he converts the folders correct, but doesnÂ´t for the filename)
<NEBAP|work> using all in the right case worked
<NEBAP|work> no errors
<NEBAP|work> jup worked for both files
<NEBAP|work> but no "there is no conflict"
<vila> NEBAP|work: so you don't reproduce the bug ?
<NEBAP|work> maybe that was because of the wrong conversion of the filename
<NEBAP|work> no
<vila> :-/
<NEBAP|work> but let me test something more
<NEBAP|work> give me a second
<NEBAP|work> wird
<NEBAP|work> weird
<NEBAP|work> no this time it also worked with the lower case
<NEBAP|work> but no way to reproduce the error ..
<NEBAP|work> sorry
<vila> NEBAP|work: ok, let's stop there then, I'm pretty sure there are bugs around case sensitiveness anyway, so I'll write some tests and see how to run them on some case insensitive file system
<vila> NEBAP|work: Thanks for your efforts
<NEBAP|work> thank you for the help ;)
<danny_> Does anyone have a suggestions on what editor to use for developing in python. 'cause I've got some trouble understanding the code without the (static) types.
<jml> dvheumen, for which OS?
<quicksilver> try komodo edit, perhaps
<quicksilver> it ives some kind of autocompletion which might help alittle
<dvheumen> quicksilver, I'll give it a try
<dvheumen> I was hunting for some bug, but without any type information, it's pretty hard to even discover what kind of a thing it is that you're looking at :P
<quicksilver> dvheumen: agreed. python is fail :P
<quicksilver> dvheumen: some people love it though :)
<dvheumen> I haven't decided yet :P I haven't done much in Python yet, but I'm kind of interested in learning. It seems like a very useful language.
<dvheumen> but it's kind of difficult to do something in an existing project, since I get (almost) no context information at all
<michaelforrest> is anybody working on a log plugin that does JSON output for bzr ?
<dvheumen> quicksilver, it looks nice, doesn't give information for my target though :P but it looks like a nice editor ... and think I'll keep it for a while :D
<beuno> james_w, hey
<beuno> did you manage to upload loggerhead to karmic?
<james_w> not yet
<james_w> I'm not sure which bzr-svn is compatible with bzr 1.18
<james_w> I have the updated loggerhead on my hard disk though
<beuno> ah, so you're upgrading a bunch of packages around bzr at the same time?
<james_w> yeah, 1.18 and the needed plugins
<beuno> awaesome
<beuno> and awesome
<james_w> it all falls apart when jelmer's not around :-)
<beuno> heh, I was just thinking the exact same thing
<Kamping_Kaiser> When resolving a conflict, am I /required/ to edit the .BASE .THIS and .OTHER [sic] files, or can I simply edit the file which conflicted?
<Kamping_Kaiser> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#resolving-a-conflict I'm working through this
<beuno> Kamping_Kaiser, edit the conflicting file, and "bzr resolve" will take care of those files
<beuno> (that's what I always do)
<Kamping_Kaiser> beuno: thanks. the user-guide makes it sound like thats not an option
<beuno> Kamping_Kaiser, care to email the lsit about it?
<beuno> woulb be interesting to fix it
<Kamping_Kaiser> beuno: does it support non-subscriber messages? if so, I'll fire off an email now
<beuno> Kamping_Kaiser, it does not, but you can subscribe, and configure it so you don't get email
<Kamping_Kaiser> hm.
<Kamping_Kaiser> clunky :/
<fullermd> Non-subscribers get moderated.  So it should get through eventually, though it may take a few days.
<emmajane> beuno, good morning. :)
<emmajane> Please let me konw if there's anything you need from me for the designer.
<emmajane> (this is your daily harassment message ;) )
<beuno> emmajane, gooood morning
<beuno> I do not, I'm waiting for him to arrive to jump in and do the changes
<emmajane> beuno, ok :)
<cjnodell> I was wondering if there was a "best" way to delete a branch/working tree with bzr?
<james_w> "bzr remove-tree" for the latter
<james_w> nothing special for the former
<james_w> doing the remove-tree first will help you check there aren't uncommitted changes, "bzr missing" can help you work out if there are revisions there you forgot to push/merge whatever
<cjnodell> so, if I wanted to make a one-time change to a project using bzr, I could create a new branch, make the changes commiting as needed, push or merge the changes with the original branch, run "bzr remove-tree" then delete the folder like any other. Does that sound right?
<james_w> yeah
<james_w> the remove-tree isn't required, but can help avoid "oops" moments
<cjnodell> cool. thanks. Everything was making sense, but i found little info on removing old branches/working trees. I figured that it would be best to create a new branch for each task (bug fix/feature add) and then merge the new branch back, but I ended up with a bunch of old branches that I didnt need/use.
<igc> night
<lifeless> moin
<jam> lifeless: you're up early
<jam> or raiding really late :)
<lifeless> up early
<lifeless> gale force winds, or I miss my guess
<jam> If you are around, I'd like to chat a bit about bug #402645
<lifeless> also have a virus, went to bed early...
<ubottu> Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645
<lifeless> and the result is I get up 7 hours later like clockwork
<lifeless> voice or IRC?
<jam> IRC is fine for now
<jam> So in debugging it, it seems that we are, indeed, fetching in 'groupcompress' order for stuff like inventories and file texts
<jam> rather than 'unordered'
<jam> conceptually it seemed nice
<jam> but we *don't* auto repack on the fly
<jam> so all we are getting is fragmentation, without the associated recombination in the new 'optimal' ordering
<jam> (so it might be ordered better on disk now, but it is fragmented...)
<jam> It probably doesn't help that we just changed the topo_sort algorithm ... :)
<lifeless> so its ordered but not grouped
<lifeless> is the new topo sort stable?
<jam> the new topo sort is not particularly stable
<lifeless> if its not, we should fix that asap
<jam> it orders based on children
<jam> and children is populated by walking a dict
<lifeless> it will mess up pack on packed repos and things like that
<lifeless> It seems to me that we _really_ need it to be stable
<jam> so I could try to figure out when to repack on-the-fly, or we could just request unordered
<jam> and the groupcompress sort during pack
<lifeless> so
<jam> lifeless: I can certainly write a groupcompress sorter that would be more stable
<jam> btw, lifeless, I hope you're feeling better
<lifeless> jam: doc says its a virus
<lifeless> push liquids
<lifeless> sleep when tired. The usual.
<lifeless> if not better in a week blood test.
<jam> lifeless: yeah, I had a 24-hour ish thing last week
<Fagan> Hi im getting an error when I try to branch.
<Fagan> Permission denied (publickey).
<Fagan> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<Fagan> Should I just make a new pub key?
<jam> Fagan: did you do launchpad login without actually telling launchpad about your ssh key ?
<lifeless> are you on windows?
<Fagan> It worked about a month ago but I tried it there a minute ago and it didnt
<jam> lifeless: as an aside, if we do a new gc ordering without packing on the fly... then we will opportunistically fragment everything until everyone has upgrade their versions and repacked their repositories with the new sort order
<jam> Fagan: you could try checking your launchpad ssh key list and see if the keys you expect are still present
<Fagan> Yep
<lifeless> Fagan: if you're on windows, make sure that you can connect outside of bzr
<lifeless> we use plink which just errors hard if its a new host
<Fagan> Im on ubuntu
<jam> lifeless: Wasn't there a special "~me" user for launchpad links?
<lifeless> +me?
<lifeless> jam: so a few thoughts: we want the end result to be well ordered& grouped repos. We want initial pulls to end up that way too.
<jam> lifeless: launchpad.net/~me   /~+me    /+me  all no love... :(
<lifeless> jam: we don't particularly want to do massive computation on the server, OTOH full pulls should already be in near-ideal gc order anyway - and besides, if we offload it all to the client, then when the client pushes to the server the server will do all the work.
<lifeless>  /people/+me
<lifeless> so for an ideal solution with high server scaling we need:
<lifeless> client-does-the-work-on-push
<jam> lifeless: well, I was hoping for "launchpad.net/+me/+sshkeys" to help out Fagan, but that doesn't seem to work
<lifeless> client-does-the-work-on-pull
<lifeless> jam: /people/+me/+sshkeys
<jam> ah, but people/+me/+sshkeys does
<jam> lifeless: you could have a hint that gets passed down when the source is RemoteRepository...
<lifeless> its worse than that its dead jim
<lifeless> site to site fetch [corner case] can go remote->remote
<lifeless> with the 'client' in the middle
<jam> as an aside, changing the ordering to 'unordered', I no longer get any "creating new compressed block on-the-fly" messages, as expected.
<lifeless> so
<lifeless> lets look at what that does
<lifeless> we have a repo which is partially packed
<lifeless> N packs.
<lifeless> but we write a repo which has the same groups but 1 pack.
<jam> yep
<Fagan> Ah I just made a new ssh key and it worked
<lifeless> I'm really inclined to say 'pull in gc-optimal order and do a 'decent' job of combining groups'.
<lifeless> because otherwise the repack heuristic will never kick in on the recipient
<jam> lifeless: right, the question is all about the 'decent' issue
<jam> and I'm wondering if the fix *today* is to just switch back to unordered
<jam> while we work out a reasonable heuristic
<lifeless> but this may have really bad behaviour if for instance it ends up recompressing everything.
<lifeless> and because its newest-first thats actually a plausible side effect
<jam> lifeless: right, say you get the 'off-by-one' issue because there is a single new text
<jam> so you try to fit 100 nodes in each group, but they all get shifted by 1
<lifeless> we should expect most repos to be mostly packed most of the time
<jam> lifeless: aside from the current fragmentation issue, which causes them to be at best partially packed part of the time :)
<lifeless> indeed. Bugs.
<lifeless> perhaps
<lifeless> gc-optimal is meant to be 'what a gc repo wants'
<lifeless> One thing we could do is allow that to not fragment
<jam> so here is an idea
<lifeless> I'm concerned about asking for unordered because unordered can be _really_ unordered.
<jam> what if we fetch in groupcompress order
<Fagan> thanks guys bye
<jam> and leave a compression group 'open'
<lifeless> ciao Fagan
<jam> such that if we want to split an existing group into a new one
<jam> we put it in the 'pending' group
<jam> so we leave groups alone as much as possible
<lifeless> re; off-by-one. I think in that case we should just make the first group a little bigger and not touch others.
<jam> but if we are doing the work of splitting, then we flag it as something that should be recombined
<SamB> jam: could something like that avoid repacking repeatedly during a single fetch as well?
<lifeless> SamB: no, thats a different condition entirely.
<jam> SamB: repacking repeatedly only happens on cross-format-fetches
<SamB> true
<SamB> I guess
<SamB> but the idea of a "pending" group sounds sorta like what I was thinking could be used to avoid too much of that ...
<lifeless> SamB: no, it wouldn't help there.
<jam> lifeless: sure, I'm just saying that a heuristic that is too simple could cause an off-by-one problem
<lifeless> jam: yes, I'm acking that.
<lifeless> jam: but also saying that we should ahve a goal, that adding texts to a group at fetch time, *at worst* merges them with the first group, and doesn't touch any deeper group.
<lifeless> I think your pending group concept is a description about how we might implement that
<jam> lifeless: so the main problem that I see is that repacking the groups is considered to be a "get_record_stream" process, while combining them would be an "insert_stream" process...
<SamB> oh, also ... it seems like there is a certain size beyond which repacking is a BAD idea ...
<jam> either that or the get_record_stream side would buffer...
<lifeless> jam: andrew has a need for a streaming gc interface
<lifeless> let me describe this briefly
<lifeless> he has a lot of inventory deltass
<lifeless> they will compress very well against each other
<lifeless> we want to put them on the network as a series of gc groups
<lifeless> so he wants to be able to do:
<lifeless> def get_fulltext_stream(): make deltas and yield FullTextContentFactory(delta_text)
<lifeless> network.insert_stream(gc_compress(get_fulltext_stream()))
<jam> lifeless: the bzrlib.groupcompress.GroupCompressor class can do all that he needs, other than knowing when to start a new group
<jam> so it would be pretty easy to have a moderately trivial logic in a helper function to do that
<lifeless> yes, and in fact he may have already; it was a weekish ago that I did the design review with him
<lifeless> it just seemed related to your point ;)
<lifeless> so, get_record_stream repacking would be inefficient for tree building
<lifeless> we'd want to only do it when serializing to the network
<lifeless> insert_record_stream is a better conceptual fit. Can we reasonably confidently hook it in there
<jam> lifeless: so insert_record_stream would need to be holding the pending group anyway
<jam> the question is how to figure out that the block coming across the wire is unoptimal
<jam> We could start with groups that have a single entry
<jam> I don't know whether that is enough, but it would certainly be a start
<lifeless> thats likely
<lifeless> uhm
<lifeless> lets start by getting a trace
<lifeless> what does irs see when fetching from a fragmented 2a repo
<Noldorin> hey lifeless
<lifeless> hi Noldorin
<lifeless> jam: that will give us data to fit an algorithm too
<Noldorin> got another reply from my admin today
<Noldorin> heh
<lifeless> jam: as well as test data for verifying we've fixed it.
<Noldorin> basically i finally got them to try it, but they are adamant there is nothing to be done
<lifeless> they agree that the behaviour happens?
<Noldorin> waiting for the upgrade to IIS 7/win 2008 is the solution i think :)
<Noldorin> if i'm lucky, that will fixc it
<jam> Noldorin: this is the "ie6 ftp server" doesn't like to actually respond to delete requests?
<lifeless> jam: yes
<Noldorin> but it's possibly just the fact that it's on a shared server
<Noldorin> and the OS is really slow to process filesystem operations
<Noldorin> jam: it does, only very slowly.
<lifeless> Noldorin: do they agree that it happens?
<jam> having RENAME and DELETE return before the action has completed is a bit silly anyway
<jam> lifeless, vila-afk: In doing this testing, I'm seeing a lot of: "25 bytes left on the HTTP socket" in .bzr.log
<jam> any idea what would be causing that?
<lifeless> jam: thats odd
<lifeless> I'd change the trace to print the first 50 bytes of whatever is left as well
<lifeless> that will answer it quickly
<jam> It is in bzrlib.transport.http._urllib2_wrappers.Response.finish()
<jam> anyway, I'll poke at it a bit
<Noldorin> lifeless: well, they kind of agree.
<vila> jam: still haven't found the time to look into it, but it's just a warning, it means we the http response contained more data than we can consume, which may or not indicate a more serious problem
<Noldorin> not directly though
<lifeless> Noldorin: they can't reproduce it?
<Noldorin> took a very frank email to even get them to (what seems) like try it
<lifeless> Noldorin: or they can?
<vila> jam: if you poke, poke at the higher levels
<Noldorin> erm
<Noldorin> let me paste you the email
<Noldorin> maybe you can make heads and tails of it :P
<Noldorin> lifeless: http://pastebin.ca/1541941
<lifeless> ok, they acknowledge that it happens.
<lifeless> RFC 959 section 4.2
<jam> vila: so interestingly, it is always 25 bytes
<jam> and seems to be a content boundary:
<jam> '\r\n--471e8a95308203bb4--\r\n'
<lifeless> their server must send a 1xx status, not 2xx if it hasn't completed the operation.
<lifeless> Its a defect. Its not RFC conformant.
<jam> lifeless: of course, we might not be paying attention to 1xx...
<lifeless> jam: http://launchpadlibrarian.net/30593974/trace.txt
<lifeless> wireshark FTW
<vila> lifeless: you're replying to jam ?
<lifeless> vila: to Noldorin
<jam> lifeless: yep, I see your point
<lifeless> vila: bug 412244
<ubottu> Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows IIS6 FTP server which keeps files after delete" [Medium,Confirmed] https://launchpad.net/bugs/412244
<lifeless> vila: it will make you laugh, it will make you cry.
<vila> lifeless: ha right, I read that a couple of minutes ago, the server that is able to tell us about deleted files right ?
<jam> IIS6 FTP basically says "ok, that is deleted" but then you can go back and read the file at the deleted location.
<jam> more importantly renaming the directory
<lifeless> it also says 'ok thats renamed' and you can read from the old path
<jam> leaves the file in places so a future rename to fails
<jam> mv lock broken; mv new-lock lock # fails
<lifeless> Noldorin: so, they acknowledge that it happens and then say to use filezilla; and that their linux platform is better. (They are right, it is :P).
<vila> lifeless: your comments sounded so much like what I wanted to answer jam :)
<vila> jam: so, about the boudaries, wireshark FTW :)
<vila> boundaries
<lifeless> Noldorin: its clearly in violation of the RFC. They can open a ticket with Microsoft.
 * lifeless is sorely tempted to blog about this
<lifeless> oooh look, sunshine
<lifeless> not a lot, but better than full dark
<lifeless> SamB: so the reason cross format fetching has to repack is that the data is in the reverse order needed.
<lifeless> SamB: 2a compresses new->old
<lifeless> data conversion is old->new
<Noldorin> lifeless: yeah, i agree. i somehow suspect they would just tell me to open the ticket however, no?
<lifeless> [theres more complexity under the hood too, but thats the basic driver]
<jam> vila: anyway, it seems that we have a trailing content boundary that is getting 'silently discarded'
<jam> vila: not worth that to me :)
<jam> just a curiosity at this point
<lifeless> Noldorin: you don't have the windows CAL or server licence.
<vila> jam: same here :D
<lifeless> Noldorin: so you can't open the ticket.
<lifeless> I've dealt with MS support before. They are good - you pay money [quite a bit :P] and then work through the problem.
<Noldorin> lifeless: heh, good point.
<lifeless> this /may/ be your ISP's deployment. Or it may be an MS bug.
<jam> lifeless: what about your patch to repack the last pack file that was created. That only triggers on cross-format fetches?
<lifeless> you have no visibility into the infrastructure.
<SamB> lifeless: oh.
<lifeless> jam: yes, only cross format, and only the new  pack(s) written in that fetch.
<SamB> lifeless: but does it have to repack everything into a gigantic pack?
<lifeless> SamB: when we do data conversion we only repack the data that has been converted. We leave existing data alone.
<jam> lifeless: right. Just thinking that repacking the new pack would also be a way to handle the 'fetch from a non-optimal source'
<jam> but I think it is probably far too much data :)
<lifeless> SamB: so we don't actually create a gigantic pack (unless it is the initial fetch).
<lifeless> SamB: and on the initial fetch a single large pack is the best possible size and performance to have - its desirable.
<SamB> lifeless: how many weeks has this been the case for?
<lifeless> I'd have to check NEWS :P
<lifeless> jam: Yeah, it cross my mind too while we've been chatting. The problem I think is that its too global; we don't need to be global for this problem so lets not.
<lifeless> jam: dunno if you saw, but spiv has a 5% faster tree build by grouping IO
<lifeless> on lp trees
<jam> lifeless: I had not seen anything to that effect yet. Sounds good
<SamB> where does one get a bzr-gtk that doesn't freak out about bzr >=1.18~ ?
<lifeless> 19:54 < spiv> Ooh, this groupcompress batching fix for remote IO also improves build-tree time for Launchpad by ~5%.
<lifeless> 19:54 < spiv> I was worried the complexity might have the opposite effect, apparently not :)
<Noldorin> lifeless: ah, thanks for updating the bug report :)
<Noldorin> i'll link that in my next email to the admin
<lifeless> Noldorin: the hidden subtext I get from the admin is that they don't think they can fix the windows service.
<Noldorin> lifeless: i got the same impression
<lifeless> They are wrong though - its only software.
<Noldorin> they see a deep and most likely difficult problem, and they don't want to get involved
<Noldorin> mm
<SamB> what do you mean by "fix the windows service"?
<jam> vila: did you change something recently with "bzr selftest -s bt" ?
<jam> Because:
<lifeless> jam: I'm not convinced that switching to unordered is wise
<jam>  wbzr selftest -s bzrlib.tests.test_group runs 38 tests
<jam> wbzr selftest -s bt.test_group
<jam> runs 09
<jam> sorry
<jam> runs 0
<jam> lifeless: I think it is the best option *today*
<jam> as sorting only introduces fragmentation
<jam> I'm working on something better
<vila> jam: wow, no, try adding --list
<jam> but I expect it to take a while
<jam> vila: no test
<jam> no tests from --list
<jam> note that if I add a syntax error
<lifeless> jam: ah, I see it.
<jam> I can see that the file is getting loaded
<lifeless> jam: I'll fix. una momento
<jam> lifeless: something to do with your recent test speedups?
<kiko> hey
<vila> jam: I guess so
<kiko> lifeless, jam: any news on 1.18?
<jam> kiko: released waiting for installers to be built
<SamB> skipping the running of the tests is NOT a valid method of speeding up the tests ;-P
<jam> I build the win32 ones
<jam> Not sure about Mac status, etc.
<kiko> jam, awesome -- are packages in PPA or are we waiting to upload?
<jam> kiko: I believe johnf does the ppa packages now
<jam> and I don't see them yet
<lifeless> jam: test-start-with branch pushing now
<lifeless> johnf does them, and hes packaging more plugins now
<kiko> okay cool
<lifeless> he needs to wait for all the versioned locked plugins to have releases done before he can push any binaries
<lifeless> or else apt throws a tizzy and things go south
<lifeless> thats bzrtools, bzr-svn and bzr-gtk
<jam> and probably qbzr :)
<jam> though someone else packages those
<lifeless> jam: its pushd
<jam> lifeless: where?
<lifeless> test-start-with
<jam> lifeless: also, the *old* topo sort was not deterministic either, I thought
<lifeless> lp:~lifeless/bzr/test-start-with that is
<jam> since its starting point was determined to be "dict.popitem()"
<lifeless> jam: well, feel free to reword :)
<kiko> lifeless, ah, awesome to know. thanks!
<lifeless> we need a repeatable sort for gc-compress or we'll get pack churn
<jam> lifeless: yeah, I'm working on that now
<lifeless> kiko: so to make the PPA more usable we're doing the following on releases now:
<lifeless>  - make a source tarball
<lifeless>  - tell plugin folk
<lifeless>  - wait
<lifeless>  - make binaries once plugins are released
<lifeless>  - announce to the world
<kiko> I think we can solve this by allowing a configurable expiration time -- is that correct still cprov?
<lifeless> folk running nightlies will still suffer, but thats less solvable by process, and more by faster-plugin-updates
<lifeless> possibly nightlies should disable version locks ;)
<lifeless> kiko: ECHANNEL.
<cprov> kiko: supersede-date, maybe ? (when binaries are excluded from the repo indexes)
<lifeless> oh, hmm.
<kiko> cprov, yeah, that's what I'm htinking too
<lifeless> the apt thing is twofold though
<lifeless> there is the fact that old binaries go, and we've filed a bug on that ages back :)
<lifeless> but the bigger problem is the version-lock that various plugins have
<lifeless> which makes it an all-or-nothing upgrade step
<cprov> what's the problem with having a bzr meta-package (as ubuntu does for linux) ?
<cprov> someone suggested it in the past, but I honestly don't remember the arguments against it.
<lifeless> cprov: I don't quite see how that helps.
<lifeless> (ignoring transition issues and the fact that installing bzr shouldn't depend: on recommends-and-suggests)
<vila> SamB: Just pushed one on trunk (bxt-gtk)
<SamB> vila: wonder how long until it shows up in one of my apt sources ...
<cprov> lifeless: uhm, bzr doesn't really have a slow-moving ABI on which plugins depend on ...
<vila> SamB: far longer as a release is needed for that :-/
<SamB> 'kay ...
<vila> SamB: I'll see what I can do tomorrow
<cprov> lifeless: you are right, meta-packages doesn't make sense in this scenario, the relation bzr <=> plugins is 1:1, right ?
<lifeless> cprov: can you unpack that a bit; I think I know what you mean but I'm not sure I do.
<cprov> lifeless: version would be part of the source/binary name of bzr and its plugins.
<SamB> vila: http://arcanux.org/lambdacats_3.html#entry9
<lifeless> bug 400009 just rolled past my screen :)
<ubottu> Launchpad bug 400009 in ubunet "I had a problem with... finding a tutorial for ubuntu one, particularly, understanding sharing with others." [Undecided,Fix released] https://launchpad.net/bugs/400009
<lifeless> we've come a long way since 1
<lifeless> cprov: so, some plugins work with any bzr version.
<lifeless> cprov: others are API locked
<vila> SamB: ROTFL
<lifeless> and others are weakly API locked in that they work with e.g. 1.14 or newer only.
<cprov> lifeless: right, when the old bzr version vanish plugins with version lock breaks bzr upgrades. Is this what really happens ?
<cprov> lifeless: while the desirable would be apt avoiding the upgrade until the suitable plugins show up ?
<SamB> vila: Simon is the name of both of the lead developers of GHC (the Glasgow Haskell Compiler), but I suppose that's hardly important to the joke ;-)
<jam> lifeless: please submit your patch :)
<lifeless> jam: I did
<vila> Ha ! GHC, acronym of the day, was wondering what it was a couple of hours ago, thanks :) (I ended up with Gnu Haskell Compiler, close enough :)
<jam> lifeless: I meant to PQM, but perhaps you did that as well
<lifeless> jam: launchpad processes mail via cron, which is slow compared to listening on a socket
<lifeless> jam: oh, pqm - will do once my current one lands
<jam> lifeless: I saw your submission, and I approved it :)
<lifeless> jam: in lsprof
<jam> ?
<SamB> vila: where did you encounter it then?
<lifeless> _g_threadmap is only global so that the thread_profile can use it, right?
<vila> SamB: while toying with an OS that insist about recompiling anything and everything everytime you breath :)
<jam> lifeless: I assume it is to pass state between 'profile()' and _thread_profile
<SamB> vila: what, Gentoo^10?
<jam> lifeless: so... yes
<vila> SamB: :)
<lifeless> jam: same conclusion I came to.
<lifeless> *boom bye bye baby*
<ohmy> Hello
<g0nzal0> hi
<g0nzal0> this seems to be happening to me: https://bugs.launchpad.net/bzr-svn/+bug/413113
<ubottu> Launchpad bug 413113 in bzr-svn "SubversionException: ('Svndiff contains a too-large window', 185001)" [Undecided,New]
<g0nzal0> is there a workaround?
<ohmy> hapy with bzr abd apedt to command line, i'm using bzr since months a go and i have to work with some windows developers and hince the ethernel question : it"s a very cool tool but what about user interface
<g0nzal0> ohmy, http://bazaar-vcs.org/BzrPlugins#GUI%20(Graphical%20User%20Interfaces%20for%20Bazaar)
<ohmy> i would like to know (i have tried most of the tools provided in bzr web pages) if there are real (even comercial) gui frontend with full feature set, i mean, most of the persons i'm working with have a nice experience with bitkeeper (excellent gui) cm synergy and some already habituated with svn
<thumper> is format "2a" going to become "2" before 2.0?
<thumper> to me "2a" is 2-alpha, which it was at the time
<thumper> but probably not the best name for a default format :)
<lifeless> thumper: I feel the same way.
<lifeless> thumper: I lost debating this with poolie
<thumper> poolie disagreed?
<abentley> thumper, lifeless: I agree with you.
<ohmy> as i have said, for me command line is all what any serious developer/integrator need to use to work properly, but i didnt succeed to find anything similar to kdesvn for example, some tools only show only branches / diff ..
<jam> thumper: we can't change the disk string without causing everyone to upgrade
<jam> potentially we could change the command line string, though
<jam> personally 'a' was just the first letter, and not representing 'alpha'
<lifeless> thumper: poolie chose 2a
<thumper> jam: but there is common perception that a means alpha, so 2a will be thought of as 2-alpha
<thumper> no matter what _we_ think
<lifeless> our docs say we should have done 1.16
<lifeless> which would confuse people in a different way
<lifeless> 'what is 1.16 and why does 2.0 use it'
<jam> lifeless: how 'stable' do you think the sort order needs to be ?
<jam> We can have it "stable such that 2 people with the same graph get the same result"
<jam> or "stable such that people with similar graphs" get the same "subsets"
<jam> the problem is that not even 'merge_sort' is stable when you add extra keys which may become the new tips
<lifeless> jam: lets think about the impact. in small branches, well who cares.
<lifeless> in large branches, a order-change will cause group recompression in the middle of an existing large pack
<lifeless> so we'll care mode
<lifeless> *more*
<jam> lifeless: so this is mostly about whether 'bzr pack' considers a pack to already be optimal?
<jam> consider that if we fetched in gc-optimal ordering, but didn't recombine groups
<lifeless> right
<jam> the ordering could match exactly, but the contents would be poorly packed
<lifeless> so we're fixing the recombine
<lifeless> I think its ok if similar graphs get the same long runs internall
<lifeless> the key thing you're saying is 'if you don't start at the edge, the sort can be different'
<lifeless> but I thought that gc-optimal already required that we start at the edge ?
<jam> lifeless: so we are sorting an arbitrary graph with multiple heads
<jam> and compare that with another graph
<jam> that adds 1 node
<jam> which is a new head
<lifeless> so, the partial ordering of heads.
<lifeless> has to be partial by definition, I think.
<lifeless> but it would be good to say that three heads
<lifeless> A B C
<lifeless> always come out A B C
<jam> http://paste.ubuntu.com/258946/
<lifeless> wouldn't it?
<jam> lifeless: sure, but you can have children of them which then become D E F, or alternatively F E D
<jam> slightly illustrated in the paste
<lifeless> so D is a child of A?
<lifeless> 'newer than A'
<jam> D is a child of A
<jam> my text has a bogosity
<jam> but yes, time goes down
<mathbr> Hi, has anyone ever encountered this one: http://pastebin.com/m23f28c83
<mathbr> Only invoking "diff" and "status"â¦
<lifeless> then we want DA CB
<lifeless> or CB DA
<lifeless> don't we? for idea compression...
<jam> http://paste.ubuntu.com/258947/
<lifeless> mathbr: hmmm
<lifeless> mathbr: run 'bzr check' please
<jam> lifeless: isn't that the "os.listdir()" returns a filename for which "os.lstat()" claims it doesn't exist?
<jam> (using the POSIX functions directly, of course)
<jam> so readdir(), and lstat, IIRC
<jam> lifeless: I believe you are right about DA CB or CB DA
<mathbr> lifeless: This one now: http://pastebin.com/m3515a14e
<jam> my specific point was that whether D or C comes first is fairly independent of which of A and B came first last time
<mathbr> I indeed removed a directory by hand after bzr told me it couldnât because there were files left in a directory
<mathbr> s/a/that
<jam> lifeless: so the test I was writing was something like this:
<jam> http://paste.ubuntu.com/258949/
<lifeless> jam: yes thats true. we'd have to define a sort on the roots of the graph
<jam> The current implementation is 'depth first'
<jam> which is the first => E D F B C A
<jam> we could do 'layer by layer'
<jam> and get something like the second
<jam> which seems to have the advantage that "B C D A" is preserved after adding nodes
<jam> though I'm pretty sure with arbitrary changes I can break that
<lifeless> gits approach of graph depth makes a great deal of sense to me; the problem is changing heads in that definition.
<lifeless> so you're right to say 'what is this really about'
<jam> the idea of 'depth first' stability, though, seems to lead to better clustering (i think)
<jam> http://paste.ubuntu.com/258954/
<lifeless> perhaps this is a better way to phrase the problem/challenge:
<lifeless>  - gc-optimal is not a fixed order on nodes; its a fixed _goal_ of data compression
<jam> even if it isn't "as stable" it is more likely to bring parents and children closer to each other
<lifeless>  - gc optimal reading from existing groups should be permitted to preserve the groups, as long as it shoves good-to-have-together groups together.
<lifeless> - the overall goal is to make incremental operations like push/pull/autopack behave well; unneeded recompression and fragmentation is what we're seeing at the moment
<lifeless> garyvdm: hi gary. Yes, its 8am here :P
<jam> you know... we could use gdfo, and sort it by (gdfo, revision_id)... I would think that would handle the stability fairly well, at the expense of not being the best compression order.
<garyvdm> Hi lifeless.
<garyvdm> Hi jam
<jam> hi garyvdm
<mathbr> I did a clean checkout now since I donât really have the time to investigate this bug. The backtraces are up for one month. Bye
<itistoday> is there a way to easily have conflicts automatically resolved?
<itistoday> i.e. say that I just want to get rid of the changes I have in my working dir, and keep the ones from the result of updating the tree
<lifeless> bzr revert
<itistoday> lifeless: thanks!
<jam> lifeless: so my first goal is to make it stable wrt dict ordering
<jam> as that is the major limitation of the algorithm today
<jam> since python dict ordering can depend on the order the dict was populated
<jam> (from collisions, etc)
<poolie> hi jam, thumper, lifeless
<jam> hi poolie
<jam> ready for a call today?
<poolie> yes that'd be good
<poolie> regarding 2a, a is a sequence letter, not 'alpha'
<poolie> i realize people may read it the other way
<poolie> but
<poolie> i'm not going to change it now
<poolie> we had a thread about this and nobody seemed to have a better idea that met the requirements
<poolie> the main one being that it be 2-something and not look like a release number
<jam> poolie: we could just call it '--2' on the command line and worry about incrementing when we actually release the next repo format
<poolie> we could say just '2' means the latest format 2 or something
<jam> poolie: do you want to just skype me directly?
<poolie> heh, jinx
<poolie> i can't see you online...
<jam> I might have accidentally stopped it.
<jam> looks like
<jam> try now
<jam> "Contact can only receive IMs" ?
<lifeless> poolie: are you still on the phone?
<lifeless> for bug 393677 I think we should just error cleanly. 'you need to upgrade'.
<ubottu> Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed] https://launchpad.net/bugs/393677
<lifeless> having the branch someone pushes be something they cannot bzr pull from would just be _weird_
<lifeless> or alternatively, not error, and just push a complete branch.
<lifeless> fooding, back soon
<poolie> lifeless: i am
<poolie> that sounds reasonable
<poolie> jam: still here?
#bzr 2009-08-25
<poolie> lifeless: did you revert the bug policy change?
<lifeless> yes
<lifeless> about 5am or so
<lifeless> its now blocked on you, aaron's approve vote notwithstanding
<poolie> i can't go for "use either one randomly"
<poolie> i could be convinced to use it as Ubuntu does, meaning that random users can't "really" confirm it
<poolie> but that feels more heaviweight than necessary
<poolie> especially if you think about bugs flipping incomplete/confirmed
<poolie> "somebody does it" or even "lots of people do it" is not very convincing
<poolie> lots of people use 8-space tabs but i don't want random bzrlib files being done with 8-space tabs
<poolie> mm
<lifeless> poolie: so, I don't think I was asking for random; only to not have to memorise different rules when the difference doesn't gain us anything.
<lifeless> if you can point to something we gain by being consistent, I'll jump on board and be as consistent as a consistent thing
<poolie> the rule being "don't use triaged"?
<lifeless> a rule we haven't been honouring for some time, based on bug database evidence
<poolie> sheesh
<igc> morning
<lifeless> if it hasn't been causing harm, I think we should relax the rule
<igc> hi poolie, lifeless, jam
<lifeless> hi igc
<poolie> also, according to bug database evidence, we have lots of bugs, therefore we should keep having them?
<poolie> be serious
<poolie> hi igc
<lifeless> sheese yourself, totally useless analogy - not the same thing at all.
 * lifeless goes back to fixing bug 393677
<ubottu> Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed] https://launchpad.net/bugs/393677
<jam> poolie: sorry we got cut off. my cell phone died and I had to pick up my son anyway. If you want to chat more, maybe we can do so after a couple hours
<poolie> np
<poolie> jam, ping me here if you like
<garyvdm> Hi igc.
<igc> hi garyvdm!
<garyvdm> I've been working on a blue print for a text conflict resolving tool.
<garyvdm> It's not finished yet, but there lots done so far.
<garyvdm> http://bazaar-vcs.org/qbzr/Blueprint/diffmerge
<poolie> ooh
<garyvdm> Just wanted to bring you attention to it. I would like to discusses it in detail post 2.0
<garyvdm> And with vila
<garyvdm> Hi poolie
<garyvdm> igc: The bits I still need to spec out is the intergration with annotate and log.
<poolie> automatically helping you find the context for the merge would be excelletn
<fullermd> igc: Hey, quick fast-import Q...   does it rely on essentially holding the stream in memory?
<lifeless> fullermd: no
<lifeless> little bits of
<lifeless> memory issues?
<igc> fullermd: no
<garyvdm> Good night all.
<fullermd> So, if I've got this ~3.5 gig SVN repo, it probably won't want to suck up memory on that order to import?
<lifeless> fullermd: heh
<lifeless> no
<lifeless> ports?
<igc> fullermd: that's a baby :-)
<fullermd> No, ports is still in CVS.  src is in SVN.
<fullermd> I still don't have the guts to tackle ports   :p
<lifeless> \o/
<igc> fullermd: the emacs fastimport dump is 7.5GB gzipped
<lifeless> fullermd: does it have modules at all?
<fullermd> It _is_ a module  ;)
<igc> fullermd: the main thing to watch is that svn-fast-export.py falls over on huge repositories (like OOo) with "too many open files"
<igc> fullermd: that's a bug somewhere is the python-subversion bindings I think
<fullermd> Funny, I was thinking that the other week when I glanced at what was needed for it...
<igc> fullermd: but it often works (and there's a svn-fast-export.c that doesn't have the issue if it does)
<fullermd> "Subversion python bindings?  You mean the ones that jelmer gave up on using 'cuz they were too buggy?"
<igc> fullermd: there's at least 3 binding to my knowledge, so probably but not sure
<igc> bindings
<lifeless> python-subversion
<lifeless> subvertpy
<lifeless> and pysubversion
<lifeless> IIRC
<fullermd> So much simpler with CVS, where everybody gets to just implement their own RCS file parser...
<jkakar> abentley: I've been using your pipeline plugin since yesterday and I love it.  Thanks a lot! :)
<poolie> igc, i thought you wrote some developer docs about content filtering but i don't see them in the tree
<poolie> did they get lost, or was it perhaps just a mail thread that i was thinking of?
<lifeless> abentley: poolie has asked that I land the iter changes branch and we tweak from there - even if that is to then put the UI back the way it is now.
<lifeless> abentley: just giving you a heads up
<abentley> jkakar: Cool!
<jkakar> abentley: I have a pipeline with 8 branches and am happily making progress jumping between them.
<abentley> lifeless, poolie: I don't want to get it the way of fixing bugs.  But it feels like fixing the bug has gotten married to UI changes whose value is not clear-cut, and could easily have been done separately.
<abentley> jkakar: Wow, that might be the deepest bzr pipeline ever.  :-)
<jkakar> abentley: Heh. :)
<jkakar> abentley: I'm refactoring a bunch of existing code that has a nice hierarchy of objects already implemented.
<jkakar> abentley: I'm using a pipe for each level, making the changes I want, and slowly working my way through it.  Having pipes is actually helping me focus and figure out clean ways to make the changes I want to make.
<abentley> jkakar: I find it helps that way too.  Sometimes I'll work on something as a pipeline, even when I wind up submitting only the last pipe.
<jkakar> abentley: Yeah, I could see doing that too.
<igc> poolie: I'll look - one moment
<poolie> lifeless: nice mail re bugs; thanks
<igc> poolie: there's no separate design doc to my knowledge. There's pieces that may help though ...
<igc> (1) http://bazaar-vcs.org/LineEndings/Roadmap
<igc> (2) bzrlib/filters/__init.__.py docstring
<lifeless> poolie: anytime
<lifeless> poolie: all it takes is a good 1/2 hour chat :P
<igc> (3) bzrlib/dirstate/SHA1Provider class docstrings
<igc> (4) I'm sure there's useful tidbits in various email threads as well fwiw (not that they count as doc)
<poolie> igc, thanks
<poolie> i might provide a bit of an overview or fusion of them
<spiv> Hmm, the -s option to selftest seems to be broken.
<lifeless> spiv: fixed
<spiv> Or the aliases, anyway..'
<spiv> lifeless: in bzr.dev?
<lifeless> i my branch, which a local typo stopped landing this morning
<lifeless> its on its way again now
<spiv> Ah, good.  Thanks.
<lifeless> just use a long alias for now
<lifeless> spiv: https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10633
<lifeless> while U wait
<spiv> Yeah, I'm using the full python name for now.
<lifeless> spiv: so two things
<lifeless> 1) ICanHazReview
<lifeless> I waved that branch in front of poolie, but I suspect you'll have more immediate interest in it, given you're working on perf
<lifeless> 2) self.make_branch_and_tree - It seems that this creates disk branches always, or something. I'm confused about it. I'd like to make a playdate to beat up on it, late this week or early next week.
<lifeless> spiv: ^
<poolie> lifeless: this is an interesting case for wanting some kind of ad-hoc dependency injection to tests
<spiv> I haven't looked at make_branch_and_tree recently, but it usually does confuse and vex me when I do.
<lifeless> poolie: your branch
<poolie> ie i'd like to say, "run everything with crlf conversion turned on" and see what fails
<lifeless> ?
<poolie> this meaning content filtering
<lifeless> poolie: I agree. broadly 'parameterise everything in this dimension'
<poolie> obviously that would require the tests be written in a way to work with that
<poolie> so you could not just do it now very easily
<lifeless> yes, words out of my mouth.
<spiv> lifeless: looking at your branch now
<lifeless> danke
<poolie> igc, what i have so far is http://pastebin.ubuntu.com/259053/
<poolie> do you see anything wrong?
<igc> polie: I'll take a look
<lifeless> spiv: ping
<lifeless> spiv: when adding remoting of exceptions, do you test them?
<lifeless> or just make-it-work and depend on tests that build on that ?
<spiv> lifeless: I try to test them
<spiv> I don't think there's perfect coverage
<spiv> I'm just looking up the relevant tests.
<lifeless> I'm adding IncompatibleRepositories
<spiv> There's test_remote.TestErrorTranslationSuccess for the client-side
<igc> poolie: that's excellent - thanks
<lifeless> q
<poolie> thanks
<igc> poolie: I particularly like the clarification re content-only, not tree munging
<poolie> mm
<poolie> it would be interesting to do that later
<igc> poolie: I'm *not* volunteering for that one fwiw :-)
<poolie> :)
<spiv> And there's some per-request error serialisation tests in test_smart.
<igc> poolie: I'm planning to fix the current content filtering bugs real soon now and then never touch it again :-)
<poolie> ok
<poolie> let's talk, later
<poolie> maybe after this bug i'll understand it better
<poolie> this doc is yak-shaving for bug 415508
<ubottu> Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508
<spiv> I don't think I have direct tests for the generic server-side serialisation of various exceptions (bzrlib.smart.requests._translate_error), although I do have tests that translation will occur (even when during streamed bodies etc).
<spiv> Those cases are probably covered indirectly, though.
<igc> poolie: understood. the one I need to finish fixing is bug 385879
<ubottu> Launchpad bug 385879 in bzr "EOL filter only applied to files when first checked out" [High,In progress] https://launchpad.net/bugs/385879
 * igc lunch
<lifeless> spiv: so
<lifeless> spiv: rich objects
<lifeless> do we flatten to strings and keep them that way
<lifeless> or do we try to reconstruct [in these exceptions]
<lifeless> Command 'pqm-submmit' not found, perhaps you meant 'pqm-submit'? [y/n]: y
<lifeless> :)
<lifeless> poolie: I'm halt()ing for work. Hopefully I'll sleep more tonight
<spiv> lifeless: we try to reconstruct some things
<spiv> lifeless: e.g. if we already have a Branch or Repository locally, we may as well use that.
<spiv> lifeless: I don't think there's a firm policy yet.
<lifeless> spiv: I'm dealing with Repository here, and won't have at either of them. In fact, one won't exist cause it will be deleted :P
<spiv> At the moment it's really been driven by what the individual exceptions require/expect.
<lifeless> spiv: I'm inclined to coerce this one down to strings and stay there
<spiv> I'm starting to think I should be more inclined to adjust the exception classes than adjust the error deserialisation to suit them, although I don't have any specific cases in mind.
<spiv> That's ok with me, although I suggest making it explicit in the exception class that it has strings rather than repo instances.
<spiv> Or at least, that it can have.
<lifeless> sure
<lifeless> tomorrow :)
<spiv> Enjoy your afternoon :)
<lifeless> you'll probably get to enjoy this sort of schedule soon :P
<lifeless> waking @ 4 that is
<spiv> Heh.
<spiv> If upstairs keeps deciding that hammering things at 1am is a great idea, I won't even have to wait ;)
<lifeless> ><
<poolie> ok switching machines
* poolie changed the topic of #bzr to: Bazaar version control system | 1.18 final released soon | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<poolie> igc: mini-review wanted on http://bazaar.launchpad.net/~mbp/bzr/doc/revision/4636
<poolie> just a few more additions beyond what i showed you before
<poolie> moved to https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/10638
<poolie> igc, it seems like what we need for bug 415508 is for commit to say to the wt: give me the hash of the canonical form of this file iff you know it without reading the whole file
<ubottu> Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508
<igc> back
<igc> poolie: I'll take a look now
<poolie> igc: sadly the dirstate.py code seems to assume the stat size is the same as the size column
<poolie> so we can't rely on the value cached there to be the size of the canonical form
<igc> poolie: where does it still do that?
<poolie> add()
<poolie> and py_update_entry
 * igc looks
<poolie> and the pyrex update_entry
<poolie> igc: what do you think?
<poolie> that code might not be active on an important path i suppose
<lifeless> iter_changes
<igc> poolie: starting with your doc patch ...
<igc> I'm not sure the comment about the UI is right
<lifeless> it would be worth a smoke test to make sure iter_changes with size changing filters returns the right size
<igc> e.g. diff ought to show ...
<igc> how the canonical form changes
<poolie> ok, does it?
<igc> that's painfully for external diff tools but the right thing IMO
<poolie> i'm trying to document what does happen more than what should happen
<igc> poolie: yes, I think diff does
<igc> also export dumps the canonical format ...
<igc> though it has an option to apply filters to the output
<igc> poolie: so I'll approve your doc patch with those tweaks
<poolie> so, maybe i shouldn't generalize, and just say that different commands might have different defaults?
<poolie> or do they all default to the canonical form?
<poolie> also i'll have to update it about dirstate, assuming that's correct that it's not always storing the canonical size
<igc> poolie: all canonical to my knowledge
<igc> wrt dirstate, I *thought* we had py_update_entry covered and the pyrex implementation
<igc> add() I can't recall changing, though the docstring is explicit about the fingerprint applying to the conical form
<poolie> right, but they are using st_size
<poolie> i haven't actually proved it's wrong but they do seem to be accessing something they should not
<lifeless> test_intertree tests both implementations for iter_changes
<poolie> lifeless/igc: teddybear re testing this:
<poolie> this being the actual originally reported bug, that multiple commits here store multiple copies even when the canonical form hasn't changed
<poolie> i think we are lacking smoke tests here
<poolie> or integration tests for all of content filtering
<poolie> but probably it also needs a more localized test for the specific change to record_entry_contents
<poolie> and we could do that in isolation by just feeding it pre-canned content summaries, along with a fake tree
<poolie> and then we'd observe what file graph it eventually writes out
<lifeless> so
<lifeless> the bug was in tree - it exposed data inconsistent with its model
<lifeless> but we're changing record_entry to stop using that exposed data, because exposing the right data is too big a change [or something]
<lifeless> so, if the new API doesn't have flaky data I don't think we need any new record_changes tests
<poolie> actually it's too expensive
<lifeless> the altered existing ones are _very_ comprehensive.
<lifeless> poolie: re expensive - we have a size field, we could write the canonical size there when we determine the canonical hash.
<poolie> so
<poolie> we could
<lifeless> and on stat cache misses we'd read the file and figure out the right canonical hash - thats not so bad
<poolie> we'd have to either detect existing dirstates that have it wrong, or bump the version, or tolerate it sometimes being wrong til people's dirstate gets rewritten
<poolie> the last of those might be ok
<lifeless> thats all true. I'm not meaning to judge the solution.
<lifeless> just teddybearing where we need to test.
<poolie> i'd kind of like to do it, but not as part of this change
<lifeless> we are changing record_entry; but we're changing it in a way consistent with its tests.
<igc> bbiab
<poolie> maybe, depending what ian says, i'll file a bug for that
<poolie> cheerio
<lifeless> we're also changing tree, with the new api. We should test *there* on both filtered and unfiltered
<poolie> lifeless: anyhow, it's expensive and not very useful
<poolie> mm, i have a test for it
<poolie> not very useful because knowing the size doesn't help commit very much
<lifeless> do we need glue to test that record_entry does the right thing when given data that we've seperately tested is canonical?
<poolie> if it's the same it still needs to check the hash, and if it's different it needs to read the whole thing
<poolie> i guess i'm feeling the need for an overall integration test
<poolie> or smoke test
<poolie> there don't seem to be any/many for commit with content filtering
<lifeless> mmm, I think we don't :- if anything we'd want a test that the interface used by record_entry is actually the tree one, but in fact record_entry takes the result generated by the commit code
<poolie> maybe i'll put this up and see what happens
<lifeless> so a test to close the loop would be  test that a) commit calls tree.NEWAPI and then calls record_entry(...NEWAPIRESULT)
<lifeless> neither of which need to hit disk or exercise the whole stack. And with that test changes to commit to not use NEWAPI will show up, and we know (because the repository tests do this) that record_changes is compatible with the NEWAPI signature
<lifeless> YMMV, Just my thoughts, etc.
<poolie> mm
<poolie> i agree with testing bits in isolation
<poolie> i guess i just feel like it can miss the big picture
<poolie> anyhow https://code.edge.launchpad.net/~mbp/bzr/415508-content-filtering/+merge/10640
<igc> back
<vila> hi all
<poolie> hello vila
<vila> hmm, someone broke the tests on leopard....
<poolie> igc, feel free to say "nothing" but what do you think about smoke tests for content filtering?
<vila> ha ha ! no paramiko on that slave, some test didn't check its dependencies :)
<igc> poolie: I feel we need them
<poolie> it's the kind of thing that would be nice to write in a (whisper it) doctest-like mode
<poolie> narrative mode
<igc> poolie: but I agree with lifeless about making sure we're testing the low level interaction for this particular bug
<poolie> mm
<poolie> it's not either or
<vila> poolie: hehe, no problem wrote both kind of tests :)
<poolie> it would be slow and clumsy to test everything that way
<igc> poolie: I'm a fan of high level tests because it's end-to-end that ultimately matters
<igc> poolie: but good quality comes from checking each layer is doing it's bit correctly as well
<vila> igc: it's not either or, but high level tests tends to leave *bug* holes in the coverage
<igc> vila: right
<vila> s/bug/big/ funny typo :)
<igc> vila: and low-level ones alone leave integration holes so either-or is not the answer!
<al-maisan> Hello there, can someone please explain how I can set a tag for a particular revision. I did "bzr help tag" but did not quite get ot.
<al-maisan> *it
<igc> to tag the current revision ...
<vila> igc: I find the integration holes easier to deal with... :)
<igc> bzr tag xxx
<igc> to tags an explicit revision ...
<igc> bzr tag -rN yyy
<igc> al-maisan: ^^^
<al-maisan> igc: thanks, will try that.
<poolie> well i guess it was a silly question
<poolie> i was actually wanting to ask "why don't we have them" and have the answer not be "cos ian got sick and the rest of us dropped the ball"
<poolie> :-}
<poolie> vila, so what's up next for you?
<vila> poolie: today: fix the leopard regression and try to package a new bzr-gtk :-/
<vila> The later is required as the last release version don't work with 1.18....
<vila> and I'll try to create the PPAs that time
<lifeless> so, I think we have many more high level tests that we need at the moment. Thats not a reason not to write ones we need. But I feel an urge to be parsimonious about adding them.
<vila> lifeless: agreed, and many of them should be turned into lower level ones too
<poolie> i think it's unbalanced
<poolie> like here we have a major feature and there's not really any integration tests
<poolie> i think in some older tests there are probably too many high level tests
<poolie> and the ones we do have are probably too slow to run and too hard to debug
<bialix> hi igc
<igc> hi bialix: no explorer work so far today - hopefully tonight after dinner
<bialix> ok
<bialix> you answer my question :-)
<bialix> vila: bonjour?
<igc> bialix: still replying to emails in my queue and tying up other stuff :-(
<bialix> igc: don't worry
<bialix> igc: I'm just want to know about installer
<vila> hello bialix !
<bialix> igc: btw, quick answer on your q in bzr-windows about msi: I think the answer is NO
<bialix> vila: hello!
<igc> well my plan is to package 0.7 tonight and hope someone picks up the ball and gets it into karmic
<bialix> vila: I'd like to beg you again about merging my patch (now patch for paramiko default)
<vila> bialix: was on my list :-(
<bialix> vila: https://code.launchpad.net/~bialix/bzr/win32-paramiko-default/+merge/10563
<bialix> vila: I'm sorry?
<bialix> igc: I can't help with karmic. Gary could, but it's hard to catch him
<bialix> from irclogs he was here this night
<poolie> hello bialix
<bialix> hello poolie
<bialix> how's 2.0beta going?
<fullermd> FWIW, I'll pretty much always write high-level tests, 'cuz it's very easy to say what I want like that, compared to faking my way through the API...
<vila> fullermd: And you do right !
<vila> I mean, it's a very good way to start, others can then rewrite your tests into lower levels ones
<vila> I often start by writing a *shell* script to reproduce a bug (based on a skeleton I derived from one of your bug reports, just because it was using 'bzr' as a parameter to help test against various versions (among other tricks)
<vila> once I Isolate the problem enough I can write more precise tests.
<vila> There has been discussions (I hope it wasn't in a code review :-/) about defining some kind of easy to use language to allow people to write tests more easily, so the idea in the air :)
<vila> is in the air even (does it make sense in english ?)
<fullermd> Actually, IIRC, I started doing that after I got all riled up about some bug that turned out to be fallout from one of my aliases...
<fullermd> So having a var I could stick --no-aliases in was a "Don't be a dumbass in public" mechanism   ;)
<bialix> I remember this idea was first developed by James Blackwell (?)
<vila> bialix: sent to pqm
<bialix> vila: thanks! and 2.0 branch too?
<vila> bialix: against trunk though
<bialix> poolie said in ML 2.0 branch is separate now
<vila> indeed
<vila> you need explicit approval to land there I think
<vila> or the RM will cherry-pick it ?
 * fullermd dreads 2.0 betas...
<fullermd> Once they start coming out I have to make packaging decisions   :(
<bialix> poolie: waht about merging paramiko-default patch to 2.0?
<bialix> poolie: what about merging paramiko-default patch to 2.0?
<vila> fullermd: yeah, yeah, people keep being afraid, but the truth is, we generally fail in unexpected places anyway but rarely in parts people were afraid about :-D
<vila> fullermd: and if you could send me a short mail pointing to the better instructions to install the most important xBSD distro to test against, I could add it to the test farm one of these days...
<vila> fullermd: It doesn't have to be detailed as long as it's: download the iso here, boot, click, click, done :)
<lifeless> bialix: nominate it for 2.0 in launchpad
<lifeless> or target it
<bialix> nominate patch?
<bialix> or nominate bug?
<vila> bialix: and ensures that it can be merged cleanly into the 2.0 branch (that will help)
<vila> bialix: bug
<bialix> vila: it will be merged cleanly yes
<fullermd> vila: *blink*  Non sequitor?  Or did I forget a conversation?
<vila> bialix: so that it will either: 1) be merged in 2.0 2) be re-targeted
<bialix> vila: unless you guys doing extra NEWS items and they are always conflicts
<vila> forget about NEWS conflicts, there is no way the RM can avoid handling them :)
<bialix> vila, lifeless: I have no control over targetting bugs, so...
<vila> fullermd: Clearly non sequitur, but I wanted to ask for a long time, now, was as good as any other time :)
<bialix> bug https://bugs.launchpad.net/bzr/+bug/414743 nominated
<vila> bialix: are you kidding ?
<ubottu> Launchpad bug 414743 in bzr "paramiko should be default client for Windows" [High,Fix committed]
<bialix> vila: about what?
<vila> about nominating bugs, just select the milestone, *that's* nominating :)
<vila> wow, you're not part of bzr devs team on launchpad... :-/
<bialix> vila: I'm not part of bzr team @ lp. so I can't
<bialix> yes
<vila> bialix: nice picture though :D
<bialix> thanks
<bialix> also is 2 years old
<vila> oh, and I was wrong, nominating is a precise meaning, you seem to have done it anyway
 * bialix now is older and not so nice :-P
<fullermd> Ooh, that's a good excuse.  I'm gonna use that.
<vila> fullermd: always happy to help (tm)
<fullermd> I meant bialix's  :)
<bialix> sorry?
<fullermd> I'll try throwing something a sketch together for you.  I only really know Free, though; it's been 10 years or so since I touched Net/Open.
<fullermd> "older and not so nice"
<vila> fullermd: whatever you know the best
<bialix> Free is FreeBSD?
<fullermd> Some of the test failures, like the '..' one, are so weird I can't believe it actually works anywhere, so that's an easily portable fix.
<fullermd> The one with the disappearing revs, I have NFC though.  I don't even have a guess as to the culprit, so I dunno how portable the failure would even be.
 * fullermd nods at bialix.
<vila> fullermd: you have *fixes* for test failures on FreeBSD ????
<fullermd> No, but the '..' would be pretty trivial.
<bialix> fullermd: sorry, it seems I don't follow your last jokes
 * bialix trying to steal .desktop file from bzr-gtk
<fullermd> bialix: Don't worry, it wasn't a very good one.
<bialix> fullermd: ok, because I like your jokes
<bialix> anybody knows something] about .desktop files?
<bialix> anybody knows something about .desktop files?
<fullermd> Heck, I use ctwm; I don't even know anything about desktops  :]
 * bialix even don't know what is ctwm and fear to ask
<fullermd> The only proper way to run a GUI, naturally.
<vila> bialix: pre-historic window manager, a bit younger than twm
<fullermd> Pre-historic?!  Bah.  Kids these days...
<bialix> lol
<fullermd> I'll have you know that its latest commit was in June of this year.
<vila> fullermd: sorry, I'm a bit grumpy because I played with gentto and went as far as twm running... :-D
<vila> yeah gentto, that's it
<fullermd> I hear gentto comes with a good hhtp server.
<vila> LOL
<AfC> bialix: the .desktop spec is fairly clear; what are you having trouble with?
<bialix> AfC: Icon
<bialix> I've hacked something based on olive-gtk.desktop and pushed to trunk
<AfC> bialix: Should be just
<bialix> anybody able to test?
<AfC> Icon=/fully/qualified/path/to/file.png
<bialix> AfC: hmm, because bzr-explorer it's a plugin then I dont think I know what will be /fully/qualified/path
<AfC> I'd show you a working example, but judging by the discourteousness rudeness above, I think we'll skip that.
 * bialix wonder...
<bialix> AfC: I don't quite understand what do you mean
<AfC> bialix: that was a Gentoo user expressing that he doesn't quite appreciate other people rubbishing the hard work of people who contribute to community distros.
<bialix> AfC: I'm Windows user/developer
<bialix> AfC: and I'm native Russian
<bialix> so if you think I say something wrong -- I'll live with that
<AfC> bialix: it wasn't you. It was the others.
<vila> AfC: ohhh, so sorry, that was a joke about me having lost the habit of installing linux the hard way,
 * bialix feels out of sync
<AfC> bialix: but in this case, the working example I was going to show you was in a Gentoo package [to my knowledge it's not packaged in Debian or Ubuntu or Fedora]
<bialix> I think I'd better skip all this stuff
<AfC> bialix: but as the others here would just make fun of me if I attempted to show it, I think we'll just move on.
<vila> Contrast my requirement to fullermd for an install: 'download iso, boot, click , click' and the way Gentoo is installed... different needs, different means, not a critic of the Gentoo community...
<AfC> bialix: I do remember that http://standards.freedesktop.org/desktop-entry-spec/latest/apa.html was not much help, but http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html does give the rules
<AfC> bialix: I believe the FHS path for .desktop files is /usr/share/applications
<AfC> bialix: I have lots of .desktop files there.
<AfC> bialix: if you're running Microsoft Windows (only) then that won't be of much help to you
<bialix> AfC: so IIUC it should be done when packaging
<AfC> bialix: yeah, that gets tricky
<bialix> AfC: not only
<bialix> AfC: but bzr development I do only there
<AfC> bialix: it's one of those things that the program knows the data for, but that needs to get deployed by make install && packaging
<bialix> AfC: Ok, thanks
<AfC> bialix: so what I can show you is a Perl script (a ./configure) that writes out a .desktop file at configure time.
<bialix> I understand now
<AfC> bialix: see the very end of http://research.operationaldynamics.com/bzr/slashtime/mainline/configure
<bialix> I think it will be toooo much for me
<AfC> bialix: `make install` moves that to $(DESTDIR)$(PREFIX)/share/applications
<AfC> s/that/the .desktop file that outputs/
<bialix> I see
<AfC> bialix: sorry I don't have a cleaner example; most projects do m4 macros or similar template substitution. I did it with Perl
<bialix> np
<bialix> I'm already understand I'm unable to propely do this stuff
 * bialix avoids do the things he can't test
<AfC> bialix: and, for what it's worth, that IS an in-production application, so it is a real example
<AfC> bialix: even if it's a very tiny program
<bialix> tiny?
<AfC> bialix: the package is just a small program that tells you the time[zone] in various places: http://blogs.operationaldynamics.com/andrew/software/slashtime/slashtime-the-graphical-version.html
<bialix> I understand
<AfC> "tiny" :)
<bialix> :-)
<AfC> but "complete" in the sense that it installs properly, has translations, has a .desktop file, etc
<AfC> The cafe I am sitting in is closing. See ya
 * bialix waves
 * igc dinner
<poolie> hello again bialix
<bialix> hello again poolie
<bialix> poolie: I've tried to ask about including paramiko-default patch to 2.0
<poolie> hey
<bialix> vila said you should judge
<poolie> i just sent another post in the metronome thread
<poolie> well, as you know, i think it's a good idea in general
<poolie> if we're going to do it we should do it before 2.0beta
<bialix> so we going to?
<poolie> what's the worst that could happen?
<poolie> :)
<bialix> people continu asking why push to lp does not work on windows?
<bialix> *continue
<poolie> i guess if there are people who have complicated putty setups eg to set up proxies they might stop working
<bialix> as I said BZR_SSH=plink force it
<bialix> and this mentioned in NEWS in Compatibility break section
<bialix> I'm aware about 3 cases when plink does not work with lp
<poolie> mm
<bialix> it seems it depends on actual plink/putty version
<poolie> also, it would kind of avoid unnecessary variation
<poolie> like if you have bzr working ok, and then for some other reason you install putty, it'll start doing something different
<bialix> it?
<poolie> it meaning this change
<bialix> yes
<vila> meh, where are the 1.18 and 2.0 branches on bazaar-vcs.org ? Or does the pqm direclty use the lp branches now ?
<poolie> so being a bit more selfcontained is worthwhile
<poolie> yes, direct to lp i think
<poolie> ok, let's do it!
<vila> poolie: so I send bialix patch to pqm against lp:bzr/2.0 ?
<poolie> yes please
<bialix> thanks gentlemen
<poolie> just for future reference, i don't think this kind of fix would be appropriate to merge into the branch after the stable release
<poolie> thanks for the patch bialix
<bialix> it was easy
<vila> wow, oh yes, lp:bzr/2.0 resolves to ~bzr-qm/bzr/2.0 .... cute :)
<poolie> ok so i should probably go...
<vila> poolie: need some help ?
<vila> poolie: GO !
<poolie> ok, cheerio
<vila> bialix: your started your branch from bzr.dev after 2.0 got created...
<bialix> (and melody from crazy frog fly away...)
<bialix> vila: ashes on my head!
<poolie> https://edge.launchpad.net/bzr/+milestone/2.0 :)
<bialix> vila: if you have rebase plugin installed, then cherrypicking will be easy
<vila> bialix: no
<vila> bialix: I mean, I don't have it installed
<bialix> you want me to cherrypick it?
<vila> yes please
<bialix> k
<bialix> lp:bzr/2.0 yes?
<vila> bialix: yup
<bialix> vila: your no applicable to both cases
<vila> ? cherrry-pick is not easy ?
<bialix> no, it's easy if you know how to run rebase :-P
<bialix> jelmer should be proud of his weird design of -r argument for rebase command!
<bialix> vila: rebased, and no conflicts encountered!
<vila> pushed somewhere ?
<bialix> vila: quick check: latest revision in 2.0 branch is luks patch?
<bialix> vila: pushing now
<vila> revno 4634 luks patch for branch --switch
<bialix> vila: bzr+ssh://bazaar.launchpad.net/~bialix/bzr/win32-paramiko-default-2.0/
<bialix> pushed
<vila> bialix: sent to pqm
<bialix> thx
<vila> I should certainly try to merge 2.0 to trunk sooner rather than later to catch the conflicts asap
<vila> bialix: remind me to do that if I forget :D
<bialix> tomorrow?
<bialix> or after 2.0 is out?
<vila> bialix: once it's landed in the 2.0 branch
<bialix> hmmmmm
<bialix> tomorrow then ;-)
<vila> ok
<vila> bialix: still there ?
<bialix> yip
<bialix> vila: what's up?
<vila> ha, tortoisebzr now includes a wtcache.py file that uses the 'with' feature
<vila> is 2.6 a strong requirement on windows now ?
<vila> it makes the dev/dev installer build fails
<bialix> wtcache? I think it's recent work from Naoki INADA
<vila> yup
<bialix> vila: no, it's wrong
<bialix> he's asking about testing his new work
<bialix> wait a sec
<vila> this has landed on lp:tortoisebzr .... that's more than testing :)
<bialix> vila: https://lists.launchpad.net/tortoisebzr-developers/msg00041.html
<bialix> vila: lp:tbzr is open for everyone and Naoki the one who trying to maintain it
<bialix> you should not be so grumpy
<bialix> write him a mail, ok?
<bialix> (preferrable using ML, but it's up to you)
<vila> not grumpy ! (Damn, am I grumpy today ? Afc first now bialix, soon fullermd ? ) :-) :-/
<vila> bialix: just a heads-up, that's what the test farm is for :-D
<bialix> vila: err! no! no! you're wonderfuil today
<bialix> bad word chosen by me
<bialix> sory
<bialix> sorry
<vila> if you can pass the info to INADA, that would be nice !
<vila> bialix: is he here ?
<bialix> ok, so I'll answer him to tbzr ML. is ti what you want?
<bialix> he?
<vila> yes please, he asked for feedback, that's feedback :)
<vila> INADA, is he here on IRC ?
<bialix> his nick at lp: songofcandy
<bialix> or something like that
<bialix> I'm not sure he's chatting here
<bialix> Japan timezone IIUC
<bialix> vila: do you have precise traceback or error message?
<vila> just a sec
<vila> http://babune.ladeuil.net:26862/builders/installer-dev-plugin-dev/builds/35/steps/compile/logs/stdio
<vila> look at the end
<bialix> (cough)
<bialix> is it URL stable?
<vila> bialix: pretty stable yes
<bialix> vila: error said it's not error but warning
<vila> bialix: and it's read-only now
<vila>  SyntaxError: invalid syntax (wtcache.py, line 202)
<vila> first the warning then an error, at least, that's how I read it
<vila> bialix: the fix should a mere s/with/try+finally/ but without a way to test...
<bialix> vila: http://pastebin.com/m75032c50 ok?
<fullermd> vila: Hmmwhat?  I have to be grumpy now?  But I just got coffee...
<vila> bialix: perfect
<vila> fullermd: you don't have too, you have to say *I* am :)
<vila> fullermd: you don't have too, you just have to say *I* am :)
<fullermd> Oh.  Well, that's why I had to get coffee, see.  'cuz you're so grumpy.  And stuff.
<bialix> lol
<vila> hehe, and people think that because I work from home I can't have a good laugh....
<bialix> lol
<AfC> I don't work from home. But I have a _really_ short commute from my home to my office.
<fullermd> Heck, that's WHY you work from home.  If you stare at a computer screen for hours, then bust out laughing in an office, people eventually put you in a straitjacket.
<bialix> vila: thanks for head up, mail sent, waiting for songofacandy response
<fullermd> I mean, so I hear.  Not that I would ever be in a situation where I'd have such an experience.  No siree Bob.  That would be crazy.
<vila> fullermd: indeed
<bialix> fullermd: I do this all the time
<bialix> in the office
<AfC> fullermd: what's wrong with wearing a straitjacket in the office?
<fullermd> AfC: It depends on who puts you in it   :p
<AfC> fullermd: and what colour it is. White is so passÃ©
<fullermd> Yah,  Tie-dye is much more festive.
<mrevell> Szilvester -- around?
<mwhudson> mrevell: i think he's phanatic when he's here
<mrevell> hey mwhudson, expanding your nick soon? Thanks, yeah, looks like he's not around.
<mwhudson> mrevell: not sure about that, people give intellectronica enough grief for a long nick :)
 * mwhudson zzz
<mrevell> :)
<bialix> vila: ping
<bialix> vila: check mail, Naoki said he's fixed this issue, how hard is to test with your army of slaves?
<quicksilver> it's the cost of the whips which really gets you down.
 * bialix seems to lost his sense of humor today. too little coffee in the blood maybe
<vila> bialix: test launched, I'll keep you informed
<bialix> cool
<danigm> Hello, is there a hook to send mails at post-commit? like in subversion? I saw that exists bzr-email plugin but I want tu put in my server and not in every client
<bialix> danigm: https://launchpad.net/bzr-hookless-email
<danigm> bialix: ok, thanks
<vila> bialix: test ok ! congrats to Naoki :)
<vila> bialix: I was a bit long as I had to manually update the branch... I don't understand why, but that doesn't really matter for now
<vila> test farm all green again :)
<bialix> vila: how about publishing that installer as "nightly" build for testing?
<vila> bialix: I have no idea of its quality *today*... but that's indeed the mid-term plan
<bialix> well, Naoki asked for testing his changes
<bialix> but it's almost impossible to do without any installer
<bialix> even broken one
<vila> AIUI jam uses the same script to build the official installers (using dev/release instead of dev/dev)
<vila> abentley: BB down ?
<vila> abentley: BB down ?
<vila> abentley: not sure you got my first message
<abentley> vila: restarted.
<vila> abentley: thanks
<jam> vila: I use release/release to build the official installers "make installer-all PYTHON=..."
<vila> jam: yeah, right thanks for the heads-up :)
<vila> jam: good morning :)
<vila> jam: already get your first coffee ? :D
<jam> vila: yep
<bialix> vila/jam: so what about "nightly" builds for windows installer/tbz
<bialix> tbzr?
<vila> bialix, jam: I see two parts: 1) deciding whether the dev/dev installer is correctly built (jam ?), 2) Finding the right process to upload the installers to ... lp ?
<vila> jam: for some context: the builds have been green for some days except this morning due to an update in tbzr, I raised the problem, bialix caught it, Naoki fixed it
<vila> jam: a concrete example of the usefulness of the build farm :)
<vila> jam: but now, bialix want more ! :-D
<bialix> ... nad garyvdm would like to test it but asked for installer
<bialix> *and
<bialix> *rats
 * bialix don't want more
<bialix> I've just threw idea
<jam> so i think vila points out that we have daily builds
 * vila rats forgot the BIG RED FLASHING JOKE :)
<jam> we just need to figure out where to put them
<bialix> lp is not the good place
<jam> lp seems like it would be an ok place
<jam> given that the nightly-ppa is there
<vila> I love the agreement :)
<vila> bialix: why not a good place ?
<jam> It isn't perfect, though
<jam> as from what I can tell, downloads are release specific
<jam> I suppose we could create a "windows-nightly" release target?
<bialix> maybe to distinguish nightly it should be named something appropriate?
<jam> I also don't know how we would prune out old downloads like they do with old ppa items
<vila> err, aren't the nightly names already contain the trunk revno ?
<bialix> vila: because it should be separate from official stables?
 * pygi almost convinced libburnia folks (e.g. myself and some others) to move to bzr :p
<vila> bialix: ho, that's what the PPA are for, but may be the nightly PPA doesn't have the right kind of download space
<vila> pygi: If you can't convince yourself.... :-D
<bialix> PPA != download installers area?
<bialix> pygi afraids of qbzr and garyvdm?
<pygi> bialix, nah, one of the devs started with VCS back in the time we started with the project
<pygi> and he doesn't understand all the benefits of bzr just yet (he uses it in a bad way)
<pygi> (we use svn for most components atm, only use bzr for one)
<bialix> VCS or VSS?
<bialix> pygi: I'm bad in jokes today
<pygi> I know
<pygi> :P
<bialix> :-P
<pygi> vila, isn't that always the hardest? :)
<vila> hmm, right, ~bzr-nightly-ppa is a team, not a project, it can have a PPA but not an upload area, AIUI
<vila> pygi: depends.... ;)
<pygi> vila, on cheese?
<vila> pygi: hardest cheese ?
<pygi> vila, no..I asked what does it depends on xD
<vila> :)
<jam> vila: I have a question for you. Did you see any of the conversation robert and I had about the 'sort_gc_optimal' stuff?
<vila> on IRC ?
<jam> yeah
<jam> last night
<jam> I can rehash the high points if you want
<vila> I prefer :-) I was rather sleepy when I read that
<vila> (yes, I was lurking :)
<jam> so... topo_sort is non deterministic
<jam> as it depends on sort order from dicts
<jam> right now when we pack a repo
<jam> we do "sort_gc_optimal"
<jam> which is basically
<jam> reversed(topo_sort())
<jam> so it is also non-deterministic
<jam> We also have a concept that fetching between 2a repos should be "groupcompress" ordered.
<jam> With the idea that streaming one to another can opportunistically repack a little bit
<jam> The fundamental problem is that we 're-use' blocks when streaming from another repo
<jam> so if you have a poorly packed repo
<jam> and you stream it into another
<jam> you end up with a poorly packed repo, that has only 1 pack file
<jam> and thus autopack will never 'clean up' the new repo
<jam> so we would *like* to have a way to opportunistically repack on the fly
<jam> without having that degrade into repacking everything all the time
<jam> one possibility
<jam> if sort_gc_optimal was more stable
<jam> was that you could compare the stream with the 'optimal' ordering
<jam> and if it was close enough, re-use the incoming stream
<jam> if it was different enough
<jam> repack
<vila> ha yes, my first reaction was: 1) make topo_sort deterministic, 2) switch to merge_sort order,
<jam> because it is currently non-deterministic
<jam> that doesn't really work
<jam> so the problem is 'what is deterministic' :)
<vila> hehe, hence 2)
<jam> given a graph, you want to get identical results between repos
<jam> which is a starting point
<jam> the issue is that given 2 *similar but not identical* graphs, you want them to somehow be similar
<poolie> hello jam, vila
<jam> hi poolie
<poolie> we overlap again
<jam> poolie: yep. You're up way too late again :)
<vila> how identical ? fully identical or identical enough ? :-}
<jam> well the point is that if they are fully identical then you should get exact results
<jam> that is mostly a given
<jam> but often you will have 2 repos with slightly different revs
<jam> and you want the sorting between them to be "stable" in a similar sense
<vila> right, so merge_sort works where topo_sort fails
<jam> sort of
<jam> but merge_sort isn't all that stable either
<vila> it isn't stable with ghosts only, and I'd argue that filing ghosts is a f. good occasion to recompress
<jam> vila: let me give an example, just a sec
<jam> http://paste.ubuntu.com/259307/
<jam> so if you consider that one side has graph F and the other G
<poolie> jam, the only fixcommitted bug from spiv i see is https://bugs.edge.launchpad.net/bzr/+bug/402657
<ubottu> Launchpad bug 402657 in bzr "2a fetch over dumb transport reads one group at a time" [Critical,Fix committed]
<poolie> which does have a branch attached but maybe not an mp
<poolie> actually it does have https://code.edge.launchpad.net/~spiv/bzr/gc-batching/+merge/10643
<jam> it does
<jam> I just didn't see it in my inbox for some reason
<jam> I'll certainly review it
<jam> argh... hopefully this is a MAD issue
<jam> his MP has: ``bzr push`` locally on windows will no longer give a locking error with
<jam> maybe he merged Robert's branch before it landed...
<poolie> mm
<poolie> probably out of sync
<poolie> you could diff it again yourself
<jam> yeah
<spiv> jam: yeah, that would be a MAD issue I think :(
<jam> just painful how many times we run into code review problems
<jam> though I suppose we can now switch to having "bzr.dev" hosted on LP
<jam> since we've had success doing that for the release branches
<vila> jam: hmm, merge sort should be: A B|C D|E F or A B|C D|E G (same level nodes can be forced to respect an arbitrary but stable order (think revid alphanumerical))
<spiv> Launchpad could pay attention to the base_revision_id of merge directives and if it's not present in the target rescan before generating a diff.
<jam> vila: I'm not sure that you understand merge-sort
<spiv> Well, mirror then scan.
<jam> it is "topological, with revisions appearing just before the rev that merged them"
<spiv> (Although in this case I created the merge proposal via the web, so that wouldn't have helped...)
<jam> spiv: supposedly it does something different if you send an MD attachment, rather than say "propose this branch"
<vila> jam: I can see that, and I think it's a weakness as you just demonstrate :)
<spiv> Anyway, it *is* late, and I'm off to sleep :)
<jam> at least I've seen comments from Aaron that it re-uses the exact patch you sent
<jam> spiv: sleep well
<jam> vila: so while investigating, I also realized that the 'most stable' sort order may not be the best "compression" order.
<jam> but I figured it would be good to talk about possibilities
<jam> for example
<vila> if you want stability you need leveling,
<jam> sorted((gdfo, revision_id) for gdfo, revision_id in revisions)
<jam> however
<jam> for *best compression* order
<jam> it is probably *not* good to group by gdfo
<jam> as they *specifically* don't have ancestry in common
<hsn> anybody knows if sf.net hosted trac supports bzr plugin?
<jam> or they couldn't have the same gdfo
<vila> correct
<jam> certainly we would need to actually do real-world values to be sure
<vila> I was about to say that merge_sort flatten the rev space but we want different ways to flatten
<jam> but my gut says that gdfo would be more stable
<poolie> hsn: i don't know, but given they support bzr it seems like a reasonable thing they should do
<jam> but would be worse compression
<jam> versus depth-first sort of sorting
<vila> my guts agree with yours :)
<jam> so right now I have an updated "gc_sort" which is topo_sort, but at each of the steps it sorts the parent_keys/child_keys
<vila> i.e. A BD CE F ?
<jam> though perhaps it is enough to just go via parent_keys
<jam> since that is a stable ordering
<jam> F D B E C A
<jam> is the current order, I believe
<vila> right, exactly what I said :-) (Believe it or not :)
<jam> and the other would be
<jam> G D B E C A
<vila> and what if G has D as second parent ?
<fullermd> G files a paternity suit, obviously.  It plays out on national TV.  Big scandal.
 * vila puts his tie-dye suit back
<jam> vila: D *is* G's second parent
<jam> the point is that it was sorted(parent_keys)
<jam> D < E
<vila> ok, that was unclear,
<jam> so there is an open question of whether that is important
<jam> if you don't have it
<jam> then you get
<vila> the question was: is it independent of the parent order
<jam> F E C D B A
<jam> G D B E C A
<jam> well, depending on whether you walk right->left parent or left->right parent
<jam> but walking left->right the 'right' gets put on the stack last, and thus gets popped off first
<jam> probably we would want to walk left-parents first
<jam> hmm....
<jam> I wonder if walking left parents first is more important than lexicographical order
<vila> walking when ?
<vila> oh, missed that line
<vila> no, I don't get it, what walk, what stack ?
<vila> when you create the group from the full texts ? You walk the graph ?
<jam> vila: we sort the graph to figure out how we want to group the texts
<jam> topo_sort uses a stack of nodes left to walk
<jam> go to a node
<jam> if parents are ready
<jam> push them on to the stack
<jam> pop from the stack to go to the next node
<jam> there are other ways
<jam> like everything in 'pending' is ready to be evaluated
<jam> evaluate all pending nodes before evaluating their parents
<jam> a bit more of a 'breadth-first' method
<vila> oh, you're coding gc_sort ?
<jam> similarly for the (gdfo, revision_id) sorted version
<jam> vila: well, updating it. Given that we already have one based on topo_sort :)
<jam> I don't really want to make topo_sort perfectly stable, because it gets to be *fast*
<vila> ok, I missed that part of the context :)
<vila> I think having a dedicated gc_sort is the way to go
<jam> I agree :)
<jam> I'm just trying to define the problem space well enough to decide on all the options for sorting an arbitrary graph :)
<jam> for example, I *could* do merge_sort(sorted(tips))
<jam> and define merge-sort when there is more than one tip
<jam> given that the algorithm is only defined for 1 tip
<jam> of course, you can always have "special_tip => [tip1, tip2, tip3]" and filter special_tip back out at the end
<cristi_an> hi,what is the diff between bzr checkout and bzr clone or branch
<cristi_an> ?
<vila> exactly and force or not an order on the tips
<jam> cristi_an: in a bzr checkout when you do "bzr commit" it commits the change to the source branch, and then locally
<jam> versus only committing locally, and you have to 'bzr push' the data back to the source
<cristi_an> jam: and otherwise localluy
<cristi_an> interesting and so diff from cvs and svn
<jam> note that one of the main benefits is when you want to collaborate on a shared branch
<jam> since it helps to keep the 2 parties in sync
<jam> if one commits, the other has to update before they can commit
<jam> often, it is desirable to work on your own local branches only to get things done before they are integrated
<cristi_an> yep but the merge is done ok
<cristi_an> alter ?
<cristi_an> later
<jam> however managing the *integration* branch is very well done via checkouts
<cristi_an> jam: last sentece i did not fully understood
<cristi_an> :(
<jam> You have a project
<jam> it will almost always have an integration branch of some sort
<jam> (trunk, head, development focus, etc.)
<cristi_an> trunk...yes
<cristi_an> as in svn
<jam> you do work on branches
<cristi_an> that is more familiar to me
<jam> but eventually that work is integrated into another branch
<jam> (trunk)
<cristi_an> correct ar some point
<jam> if multiple people are committing to an integration branch
<jam> a good way to collaborate
<jam> is via 'bzr checkout'
<jam> rather than having a local copy
<cristi_an> that is ...a pian in the ass
<jam> which may be out of date
<jam> a bzr checkout requires you to be up-to-date before you can commit
<cristi_an> that is more like svn cvs style
<cristi_an> with checkout
<jam> cristi_an: so you can still develop your feature in a branch. But then "cd trunk-checkout; bzr merge ../my-feature/branch; bzr commit -m "merging my feature""
<jam> checkouts in bzr are a way to bridge the gap between:
<jam> I'm developing independently (distrbuted)
<jam> I'm collaborating  (centralized)
<jam> Anything you can do with checkouts you can do with regular branches and a bit of care
<jam> checkouts just help with the 'bit of care' part
<cristi_an> i see
<jam> vila: right
<jam> the main problem with "force an order on the tips"
<jam> is that any arbitrary new tip can upset the ordering
<jam> if you sorted(tips)
<jam> then if you have G F, and someone commits an "A"
<jam> suddenly your whole graph gets rebalanced based on A
<jam> since that is now the new sort tip
<jam> of course, sorting somehow is better than not sorting at all
<jam> vila: and this is now a bit circular. But it is the bits I'm trying to understand as I come up with the graph => order of texts in groups algorithm
<vila> right, it should only occur at the "tip[s]" of the graph so, only for the last inserted revisions
<jam> vila: well, most algorithms are dependent on the starting point
<jam> merge_sort and topo_sort both obviously being effectde
<jam> effected
<jam> affected... actually
<jam> (i think, I'm really bad about that one)
<vila> one question then, we're talking about file graphs here right ? How many revisions can you put into a group ?
<jam> vila: as many as will fit
<jam> yes it is a bit loose
<jam> the current rule is:
<jam> fit up to 2MB worth of mixed-file-id data, or 4MB of single file-id data
<vila> but inside a single pack right, until the next autopack that is
<jam> or 2x the size of the largest content, if it is >4MB
<vila> ?
<jam> vila: well, we don't split groups between packs (yet, if ever)
<cristi_an> jam i reviewd out discussion
<cristi_an> jam: thx much more clear now
<vila> My point is that inside a pack you don't insert so your graph is immutable
<jam> cristi_an: happy to help
<jam> vila: sure, but when you transmit those to another repo...
<jam> or during pack
<jam> etc
<jam> My "big picture" work is opportunistically repacking groups
<jam> during transmission
<jam> and the "little picture" is that we need a stable way of listing content, so that the opportunistic repacker doesn't flip-flop all the time
<vila> but even in that context you know the full graph you care about no ?
<jam> thinking that things should be group A B C then C B A then BCA then...
<cristi_an> how can i update a branch ?
<cristi_an> since a checkout is bzr update
<jam> cristi_an: a regular branch is usually "bzr pull" a checkout is usually "bzr update"
<cristi_an> same as for checkout ?
<vila> could you really receive disconnected parts of a graph, starting a group and then receive connecting parts while still using the same group ?
<cristi_an> i mean for a project that was get usign checkout ?
<jam> vila: well, if you consider a streaming interface, yes
<vila> ha !
<jam> you would get C => [A B], A => [], B => [A]
<cristi_an> jam
<cristi_an> thx
<jam> however, that isn't particularly of concern
<jam> well maybe some
<jam> get_record_stream() determines the order to send data
<vila> jam: I would tend to punt during the transfer waiting for the next autopack to get it right, is that acceptable ?
<jam> but insert_record_stream() is responsible for putting that data into the target repo, and possibly rebuilding groups
<jam> vila: we have determined that it is not
<vila> if the sending order can acted upon then... surely that's better
<jam> specifically
<jam> if my source repo has 1 large pack, and 200 loose packs
<jam> and I fetch from that
<jam> the data stream will create 1 large pack
<jam> with lots of loose data inside
<jam> and then my target repository
<jam> will have a single large pack
<jam> that will never get repacked
<jam> Too big to fail.... :)
<vila> don't do it then :)
<vila> create several smaller packs
<jam> vila: how do we know what to put where?
<jam> what heuristic do we use that we are ready to start a new pack
<jam> at the moment, what I'm thinking
<vila> size
<jam> is to have insert_record_stream() keep a "pending group" open
<jam> and if it gets a record that it thinks needs repacking
<jam> to put it into the pending group
<jam> with the algorithm there being
<jam> a Group with 1 entry
<jam> (at the moment)
<jam> and then fetch requests things in 'groupcompress' order
<jam> so if things are out-of-order they will get repacked on the fly
<jam> as we will split up the old group if it doesn't yield data in the correct order automatically
<jam> I'm not sure if you understand that from just what I've written. But it makes sense in my head...
<vila> trying to rephrase: you have a way to detect that you're creating a bad group and trigger its reconstruction afterwards ?
<jam> vila: mmm...
<jam> the source is already split up into groups
<jam> if we request "unordered" we get the groups as they exist
<jam> if we make a request for "topological" or "groupcompress" ordered
<jam> then the source will send groups that match the requested ordering
<jam> but will create new groups if it needs to
<jam> or truncate existing groups, etc.
<jam> at the moment
<jam> we have bug #402645
<ubottu> Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645
<jam> which is that we make a groupcompress request
<vila> so why not use unordered ? It seems to guarantee that the groups are not that bad and can be made better at the next repack
<jam> which causes the source to create small group fragments
<jam> vila: see above as for "at next repack"
<jam> after initial fetch
<jam> "next repack" never happens
<vila> but if the groups are correct that's not a problem
<jam> well, for the data transmitted with the initial fetch, it will never be repacked via autopack
<jam> vila: but they aren't in a real world repo
<jam> which has some amount of "perfect" groups
<jam> and then a whole lot of new "not yet autopacked" groups
<jam> and probably some "autopacked, but not with all the new stuff yet"
<jam> given that our "optimal packing" is newest first
<jam> we can never be truly optimal in a live repo
<jam> since there will always be a bit more new stuff
<vila> hmmm
<jam> so the other bug is bug #402652
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [High,Triaged] https://launchpad.net/bugs/402652
<jam> the twin to #402645
<vila> I'm back to the idea that we should create several packs
<jam> namely, if we are going to fragment, then we should recombine
<jam> vila: that is a possibility
<jam> but how do we know what/when/where to do that?
<jam> remember that individual packs are meant to be fairly self-contained
<jam> though I guess not fully self contained
<jam> given that a pack with rev 10 won't have the text files for rev 9
<jam> well, from rev 9 that are still present in rev10
<vila> where is the easiest: only locally do you have the right info to do a good job, the knowledge  can't be shared
<vila> when: repack, repack, repack
<jam> vila: so I already have a patch for review for bug #402645
<ubottu> Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645
<jam> which would be nice to get reviewed
<vila> that could not be simpler that handled at repack time
<jam> I think lifeless was so-so on it, but I don't think he was blocking
<vila> that left what... and that one is not easy :D
<jam> vila: so... the problem with 'repack' time, is that for very large projects repacking everything takes a while
<jam> it would be nice to have a lighter repack
<jam> which is what we have autopack for today
<jam> but that assumes that a single pack file is already as optimally packed as it could be
<jam> one option
<vila> yeah, I mean autopack, sorry, the point where you decided to group the last 10 packs
<jam> is that we get the pack code to produce deterministic output
<jam> such that we compare what a pack actually contains
<jam> with what the optimizer would create
<vila> wait !
<jam> and if they differ, redo the work
<vila> you just pointed out the flaw !
<vila> we assume that a single pack file is already optimally packed
<vila> that's wrong and we know when
<vila> so how about repacking that one when we know it's wrong ? Is it already too late ?
<vila> repacking with a special sense here: don't try to combine with others, focus on that one
<vila> or not...
<jam> vila: how do we know when?
<vila> didn't you say you can identify that a group badly compressed ?
<jam> (its a serious question, how do we detect that a pack is sub-optimal without fully repacking)
<jam> vila: I'm saying maybe we can
<jam> potentially by checking the sort order
<jam> though that requires....
<jam> a deterministic sort order
<jam> which ... is where I started this discussion :)
<vila> gc_sort is deterministic, we agreeD on that :)
<jam> it is not
<jam> it potentially is
<vila> it should
<jam> so here is the next issue with determinism, and why it would be good to be stable when changing graph
<jam> consider
<jam> A B C D E F G
<vila> and locally you can even realize that you're receiving a group that will be better compressed here but the other side couldn't know
<jam> which are currently in groups of:
<jam> [G F E] [D C B A]
<jam> it would be good that when adding H
<jam> we don't end up with
<jam> [H G F] [E D C] [B A]
<jam> If instead we could get
<jam> [H G F E] [D C B A]
<jam> that would mean that our 'lite-repack' doesn't have to touch everything
<jam> just a group here and there that we push some extra data into
<jam> vila: you can, but if you aren't going to look beyond the current pack file, you actually have *less* data...
<vila> one question: is it legal to create groups in new packs from bits of groups in old packs ?
<jam> it is legal to have multiple copies of a text in different packs
<jam> Is that sufficient for your question?
<vila> right
<jam> of course, having 2 copies of a text in your repository is, by definition, sub optimal :)
<vila> so we can create a new pack with only well compressed groups and wait for the autopack to clean the dust
<vila> of force the cleaning
<jam> vila: so I think you are saying that Repository.start_write_group() should be creating 2 pack files
<jam> one with 'seems to be good' data
<jam> and one with 'seems to need repacking' data
<jam> though again, if you are only creating 2 packs...
<jam> autopack doesn't kick in for a while
<vila> but you force it with a focus on the need repacking one
<vila> what worries me is that we may still transfer too much data...
<jam> vila: well, there are other problems. Like the fact that 'optimally' you would probably want to mix some of the data in the 'needs repacking' pack with the data in the 'fully packed' pack
<vila> nahhh, what is the risk that a group contains irrelevant data for a given fetch ? Isn't it capped by your 2M limit anyway ? Or can that trigger multiple times for a single fetch
<jam> Consider a group of a single file content
<jam> which has 100 revs of that content, and you get a single 'ungrouped' text of the same file
<jam> vila: so the server side code knows that you are requesting XX bytes out of the 2M group, and can opportunistically split up a group
<jam> which is currently causing our fragmentation issues :)
<vila> Is it a bug that it split too much or is needed for some reason ?
<jam> the bug is that our current fetch says:
<jam> give me the first 2 texts from group A, and the first 2 texts from group B, then the middle 3 texts from A, then middle 3 from B, then the last 2 from A, and last 2 from B
<jam> which causes a nice 7 entry group A and 7-entry B to be split up
<jam> into 6 groups 2, 2, 3, 3, 2, 2
<jam> the *good* is that we don't send the full 14 texts multiple times
<jam> the bad is we end up fragmenting without recombining afterwards
<jam> The original idea we had for smart fetch was bug #402652
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [High,Triaged] https://launchpad.net/bugs/402652
<jam> we could create optimal groups on the fly
<jam> (whether that ends up being done in the server or the client...)
<vila> I vote for the client... half-heartedly :-/
<jam> vila: in theory client scales better, because you have 1 server and N clients
<vila> It's the fetch for the smart server or also for dumb ones ?
<jam> that said, because of 'push vs pull vs copy ' who the client is ...
<jam> (it can be the source or target, or neither as an intermediary)
<jam> vila: so it is basically the same fetch, it just depends on the layering
<jam> "smart fetch" is
<jam> dumb_fetch => SmartObject => bytes on the wire => RemoteRepository => local repo
<jam> versus
<jam> dumb_fetch => local_repo :)
<jam> So for plain 'http' requests, we have to read the whole group
<jam> and then locally we split it up into smaller bits
<jam> we have a local cache of groups
<jam> so we are unlikely to fetch the same big group twice
<jam> though it is possible that we do so if we are really bad about our fetch ordering
<vila> 1) we shouldn't "fragmenting without recombining" or at least we should give hints about it so that the other side knows there is work to do,
<vila> 2) if the "smart" is to send multiple groups to reduce the amount of data transmitted and we fail to achieve that, that's not smart :-/
<jam> vila: I'm pretty sure (2) is working
<jam> with the caveat that it is introducing (1) :)
<vila> so if we are happy with 2, the only problem is to not consider the received pack as optimally compressed no ?
<vila> What if you just look at that pack file, counting groups/file and deciding if it's worth keeping or not ?
<vila> Kind of an autopack after fetch focused on the just received pack ?
<vila> You can even spawn it in the background :-)
 * kfogel is away: lunch + an errand
<oubiwann> lifeless: hey man, I fixed that branch and re-submitted the review
<jam> oubiwann: just so you know, lifeless is usually sleeping for another 4hrs or so
<oubiwann> jam: yeah, that's what I figured...
<oubiwann> jam: I msg'ed him in the off chance that he checks his irc highlights ;-)
<jam> it does
<vila> pfffffffff
<vila> jam: ping
<jam> vila: ?
<vila> jam: I just upload new packages for bzr-gtk in bzr-beta-ppa
<vila> When should I do the same for bzr-ppa at the latest  for 1.18 ?
<vila> well, doesn't reallt matter I suspect
<jam> I think you should copy them from the beta ppa
<vila> well, now that the script is written... :-)
<garyvdm> Hi vila, jam
<vila> hi garyvdm , too bad, I'm about to leave :-)
<garyvdm> np - just saying hi.
<garyvdm> Hi bialix
<bialix> Hi garyvdm!
<vila> I've seen your blueprint for the conflict manager, nice job, I'll try to comment if I find the time before you code it :-D
<bialix> garyvdm: have some quick questions
<bialix> may I?
<garyvdm> sure
<bialix> garyvdm: you can answer in short form
<garyvdm> vila: There lots more that I still have in my head.
<vila> james_w: builddeb rocks, just wanted to let you know :)
<vila> james_w: bzr-builddeb I meant !
<james_w> thanks :-)
<bialix> garyvdm: 1) your fix for qdiff and painting is great. is it possible to do similar thing for annotate? today annotate is slow on scrolling...
<bialix> james_w: hi, great idea around bzr-build
<vila> garyvdm: as all of us :) The tricky thing is to get them out :)
<bialix> james_w: at first I've thought you steal my scmproj cookies :-)
<garyvdm> bialix: annotate is slow to scroll because it's only loading revision on screen, like qlog.
<bialix> james_w: sorry: bzr-builder of course
<bialix> garyvdm: and so?
<garyvdm> bialix: I plan to make both qlog and qannotate be a bit more aggressive with revision loading.
<garyvdm> bialix: Its the same bit of code.
<bialix> garyvdm: that's great, especially if you put this agression inth thread ;-)
<garyvdm> :-o
<bialix> ok, ok
<bialix> oh, ok
<james_w> bialix: yeah, it is quite similar to scmproj :-)
<bialix> james_w: but it's much more than that in one area and much less than that in other
<bialix> ;-)
<bialix> but I like the idea
<james_w> heh
<bialix> maybe I can persuade guys like jam to use it for working with windows installer configuration
<bialix> garyvdm: 2nd q: oh, you already answer it about agressive loading
<bialix> garyvdm: maybe I'll put some my thoughts about threads/subprocesses and multipass work as text document? (not wiki :-P) and we can work on it toghether?
<bialix> garyvdm: 3rd) can we put throbber as status bar?
<bialix> something like in firefox
<bialix> (and other browsers)
<garyvdm> bialix: If you want to look at the qlog/qannotate revisions loading, the code is in lib/revtreeview.py
<garyvdm> bialix: You can put the throbber anywhere, so it is a question of design.
<bialix> mostly I'm not very like as it appears and disappears
<garyvdm> The throbber will look funny just bellow the buttons.
<garyvdm> Or where you thinking above the buttons?
<bialix> well, if it will be status bar, then we have to use progress bar instead of spinning wheel
<bialix> no, I mean status bar, like in firefox
<bialix> wannan screenshot?
<garyvdm> Don't worry. I know what you mean
<bialix> ok
<bialix> garyvdm: igc is not asked you about packaging bzr-explorer?
<garyvdm> bialix: maybe just have a throbber that sits in the top right, with no text like firefox...
<garyvdm> No
<bialix> top right? under title bar icon/buttons?
<garyvdm> bialix: My knowledge about debian packaging in limited to "How to update qbzr's packages."
<garyvdm> bialix: I'll have a shot on the weekend.
<bialix> new firefox (at least on windows) lacks this spinning wheel at top right, but I remember it
<bialix> "How to update qbzr's packages." -- that's cool anyway
<garyvdm> I did not even notice that the top right throbber had gone...
<bialix> garyvdm: I've just asked. igc want bzr-explorer 0.7 into karmic
<bialix> (I'm about of packaging 0.7 release now)
<garyvdm> bialix: 0.7 - I just read on the ml about 0.8?
<bialix> bzr-explorer 0.7 is not released yet
<bialix> tonight wil be
<garyvdm> Oh - worry - miss read
<garyvdm> *sorry
<bialix> np
<bialix> garyvdm: also I want to redesign qbzr.conf. completelly
<jam> a
<bialix> I'm thinking about this many months
<bialix> jam: ?
<jam> sorry, wrong window
<garyvdm> bialix: I would recommend that you try find someone else to do the packaging, cause I will be very slow. Maybe luks?
<bialix> garyvdm: don;t worry about packaging, I'm sure Ian will find the way
<bialix> I was unsure is he asking you or not
<garyvdm> bialix: To be honest, I'm not to familiar with the .conf code. You know it much better.
<bialix> garyvdm: about qbzr.conf: I want to put data in more sections and subsections. instead of keep everything in [DEFAULT]. If you have any thoughts on this topic we can discuss it. otherwise I'm planning to work on it soon
<bialix> ah, ok
<bialix> I'm still unsure ow to organize things like geometry settings, color settings
<bialix> s/ow/how/
<garyvdm> Yes - It would be nice if the the window sizes were separate from every thing else.
<bialix> and I want some universal MRU handling (latest 10 pull locations used, push, commit messages etc)
<bialix> garyvdm: precisely.
<bialix> it was my first intent
 * bialix often mulling some ideas several weeks/months because there is always bugs to fix rather than redesign deep internal code
<bialix> garyvdm: also I want to redesign most of qsubprocess windows: to always show working branch/tree location.
<garyvdm> Yes
<garyvdm> Like qcommit
<bialix> I found it's very easy to lost identity while working with multiple branches in bzr-explorer
<bialix> yep, but maybe a bit shorter
<bialix> garyvdm: and perhaps latest. today I've asked about qrevert to revision
<bialix> I'm not filed a bug report yet
<bialix> trying to understand where to put this control
<garyvdm> bialix: I have the same thing. I've been thinking about this for about this for about a year now: http://bazaar-vcs.org/qbzr/Blueprint/diffmerge
<garyvdm> Note that blueprint is not finished...
<bialix> we have several dialogs where we expecting user can specify revision
<garyvdm> Lots still in my head.
<bialix> garyvdm: I like your screenshots
<bialix> very much
<bialix> very impressive
<bialix> it seems meld's way is too complicated (from screenshots)
<bialix> so, garyvdm, what we can do about revision selector? ;-)
<garyvdm> Screenshots made with balsamiq
<garyvdm> bialix: Yes I need to finish that.
<bialix> I remember you stumbled upon some bugs/issues with qt
<garyvdm> igc wants me to make it do all different types of revision selectors.
<bialix> I'm still thinking about reusing qlog widget
<garyvdm> Yhea - had problems putting qlog inside a qcombobox
<bialix> is it possible to run separate dialog with qlog-like graph and allow user to click/dbl-click on revision and we pick it?
<garyvdm> That would be easy
<bialix> for selecting range -- just draw the mouse with button pressed and all
<bialix> or something like that
<bialix> something easy
<garyvdm> bialix: I'm busy trying to use jam's new graph code to make qlog faster.
<garyvdm> It's promising.
<bialix> garyvdm: I'd like to fix https://bugs.launchpad.net/qbzr/+bug/417895
<ubottu> Launchpad bug 417895 in qbzr "qannotate error when clicking on line which origin is dotted revno" [Critical,Confirmed]
<bialix> if you will have a time to comment on it, I'll try to find the root of problem
<jam> garyvdm: btw, feedback is welcome if you find "it would be nicer if..."
<bialix> he, faster :-(
<bialix> heh
<bialix> today qlog on bzr.dev opens for me ~10 seconds
<garyvdm> jam: sure, I've allready got a draft mail :-)
<garyvdm> bialix: I want that to be 1sec...
<bialix> I will be happy if it start painting latest revno from the start and then loading the tail later
<jam> hmm... cold cache it is 18s here, 12s before the window shows
<jam> hot, 5s
<bialix> (and working in thread because it's completely ignore repaint while doing loading)
<garyvdm> Speed is important for using it for a revision selector
<bialix> I think we have to load only mainline first
<garyvdm> It takes about 45 sec for OOo
<garyvdm> yes
<bialix> because for revision selector this is what you need 90% of the time
<jam> well, for OOo, *everything* is mainline...
<bialix> oh, I recall
<bialix> garyvdm: qlog on multiple branches
<bialix> garyvdm: can we dont show dotted revnos for non-trunk branches?
 * garyvdm hides under the desk.
<bialix> no, it's easy question
<garyvdm> or the right revno...
<bialix> right mainline revno would be confusing
<bialix> but dotted revno is unusable
<bialix> I can't merge using this revno
<garyvdm> Easy to not show the wrong revno
<bialix> I'll be happy just to see no revno at all
 * bialix has too much questions/ideas so not everything is filed as bugs
<garyvdm> :-)
<bialix> garyvdm: it was last question. I promise!
<garyvdm> jam: for OOo, I think we have to look at loading just part of the mainline...
<garyvdm> Sure
 * bialix packaging 0.7 now
<bialix> oh
<bialix> and after rebase qlog refresh crashed...
<jam> garyvdm: so... qlog could just load enough of the mainline to fill the first screen
 * bialix hides
<jam> and read those revisions so that it could put up summary messages
<jam> and then spawn something that would load the rest of the data
<garyvdm> Jam: yes
<jam> you can number mainline revs, etc
<jam> without needing the full graph
<garyvdm> bialix: please log a bug.
<jam> arguably, we could have something inbetween 'get_parent_map()' and 'get_known_graph_ancestry()', I'm just not sure exactly how to flesh that out
<jam> so I didn't bother yet
<jam> (give me as much parent information as you can cheaply determine from these tips)
<jam> note also that if something like OOo switches, they will likely have a better conversion that actually makes use of their metadata in cvs to do merges
<jam> I'm not positive of that
<jam> but they have 3rd party tools to do a lot of merging, etc. for them
<jam> built on top of cvs
<jam> so there is some merge info there if people chose to extract it
<garyvdm> I need to get a copy of a OOo branch...
<jam> ping igc, he uploaded it somewhere
<jam> let me check
<bialix> does mysql branch is also very heavy and have much merge info?
<jam> bialix: mysql is *very* bushy
<garyvdm> bialix: Yes - I do have copy of that.
<jam> something like 65k ancestry revs, versus... 3k mainline?
<bialix> bushy? hmmm
 * bialix wonder what fullermd would say about this
<garyvdm> jam: Aprox how many mb is OOo branch. I have limited bandwidth.
<bialix> gigs?
<jam> yeah
<jam> checking
<jam> 1.3GB in tar.bz2 form
<jam> 945MB in .bzr/
 * bialix wonder when people start using torrents to get such big repos
<jam> bialix: there already is gittorrent, IIRC
<bialix> cool
<jam> garyvdm: 3.0GB of .bzr/ + working tree
<bialix> wow
<jam> garyvdm: http://people.canonical.com/~ianc/benchmarks/repos/bzr/
<jam> that has, emacs, OOo, python, mozilla, etc.
<bialix> interesting how big lp sources?
<garyvdm> Cool
<bialix> comparing to those
<jam> bialix: about 100-200MB, IIRC
<jam> (note that numbers quoted are for --2a formats... LP was 1.2GB in --pack-0.92)
<jam> MySQL is 600MB in --pack-0.92, around 225MB in --2a, IIRC
<bialix> jam: because bzr is also used packs as repo format it's possible to build bzrtorrent, hm?
<garyvdm> jam: I think I'm going to ask igc to post me a flash drive with some repos on. It will be cheaper that way :-(
 * pgega is away: I'm busy
<jam> bialix: well, I think it is based on git's sha1 content stuff. But certainly we *could* do a torrent-like protocol. I thought someone brought it up on the mailing list a while back
<jam> garyvdm: where do you live?
<garyvdm> South Africa
<bialix> jam: yeah sha-1 hashes should helps them
<garyvdm> Someone worked out that if you wanted to download more than 5gib in south africa, it's quicker to fly to hong kong, download it there, and fly back...
<jam> we have sha1 hashes, but things are addressed in that sense
<jam> garyvdm: well, there is the old 'lorry full of backup tapes' question
<bialix> btw jam, how's hard to implement commit --amend? is it possible to avoid uncommit/commit dance to simply fix commit message?
<jam> at what point is a truck full of backup tapes higher bandwidth than OC-3 ?
 * pgega is back (gone 00:03:15)
<jam> bialix: The hardest pressure would be to get it past review
<jam> I don't see the specific benefit over uncommit/commit myself.
<jam> given that as I understand it
<jam> commit --ammend == uncommit + commit
<bialix> use case: you have changes in your tree when you realize you need amend
<jam> as in, it takes the current content on disk
<jam> and recommits it
<jam> bialix: git commit --amend (I believe) will include those changes
<jam> perhaps not if you haven't 'added' them?
<bialix> hm
<jam> not really sure
<jam> but as I understood
<jam> it was a way to resolve conflicts in the merge
<jam> which means it has to include content changes as well as metadata changes
<bialix> I was under impression it just create new commit object for old tree/blobs
<bialix> it == git
<emmajane> beuno-afk, ping when you've got a minute.
<jam> bialix: The discussion I read about it was talking about what to do when an autocommit after-merge got something wrong
<jam> and the recommendation was to use commit --amend
<jam> hence... it has to change content somehow
<garyvdm> bialix: bushy mysql branch: http://imagebin.ca/view/3GLAnke.html . I just expanded the twisties on the screen. It gets much wider that that...
<bialix> I don't use git at all, only read the docs sometimes
<jam> garyvdm: so... mysql also has the policy of letting anyone overwrite the mainline
<jam> so "bzr merge trunk; bzr commit -m "merge trunk into my branch"; bzr push trunk" is acceptable to them
<jam> which means their history is much harder to understand
<garyvdm> jam: Yes. I chatted to vila about that at uds. They need a "land" command
<jam> garyvdm: there are a lot of possibilities. They need to allow one first :)
<jam> for example, setting 'append-revisions-only' would force the issue
<jam> but they didn't want to impact the developers
<garyvdm> I think I would find "land" command usefull too.
<jam> garyvdm: what about 'bzr merge --swap-parents' ?
<bialix> jam: one day after 2.0 I'll asking you a lot about file-specific commit messages. I want them in qbzr
 * garyvdm goes to look
<jam> garyvdm: doesn't exist yet
<jam> just ~ the same idea as land
<garyvdm> :-)
<garyvdm> Yes
<garyvdm> land == merge --swap-parents
<bialix> and we'll need commit --revision-properties-from-file FILE
<bialix> merge-to
<luks> I still think it's a bad idea
<garyvdm> Hi luks,
<luks> hey
<garyvdm> Important for mysql people to use qbzr
<bialix> lukc: which one?
<luks> bialix: per-file commit messages as they are implemented in bzr-gtk
<bialix> heh
<bialix> they became stadard de-facto now
<bialix> and only jam knows all secrets of them!
<bialix> (joke)
<luks> it just hides information if there is no official support in bzrlib
<bialix> luks: this is the latest feature bzr-gtk has and we don't
<garyvdm> bialix: we can start with showing per file commit messages in qlog, and qannotate (In the revision html view)
<bialix> vila said me it's officially supported
<bialix> or something like that
<luks> bialix: yet bzr doesn't support them, loggerhead doesn't support them, etc.
<garyvdm> I'm sure. I think mysql pays for bzr support.
<bialix> garyvdm: yes, but we need commit support too
<bialix> garyvdm: yes, although and not to us
<garyvdm> :-)
<bialix> so we can ignore these properties
<bialix> it's just mater of competition with bzr-gtk
<luks> I find it weird to update tools just to fit some weird workflow
<luks> I can completely understand why it was done in bzr-gtk
<garyvdm> Bialix: I think that mysql guys would love for qlog to show pfcm (per file commit messages) because bzr viz is unusable on the mysql branch.
<bialix> because it's core gui tools
<jam> garyvdm: As I Understand they have a custom "glog" which uses gtk widgets and does effectively qlog
<bialix> bzr-gtk ^
<luks> heh
<garyvdm> heh!~
 * bialix does not see difference
<garyvdm> just mainline, or expandable?
<garyvdm> jam^
<jam> garyvdm: expandable
<jam> bialix: 'bzr vis' doesn't have twisties
<jam> so you get *all* revisions *all* the time
<bialix> ah
<bialix> so it quickly become unusable on big histories
<jam> yep
<garyvdm> I wonder why that is not in bzr-gtk.
<jam> garyvdm: I really don't know
<jam> other than some concerns about "not developing a VCS" to get in trouble with their existing bk license
<garyvdm> any idea where I can find the code?
<garyvdm> I c
<jam> whether that has finally run out or not, I don't know
<jam> guilheimb is the best mysql contact I know of
<jam> he just sent an email to the list if you want to get his address
<garyvdm> vila might know too
<garyvdm> jam: I was thinking about storing gdfo, and I'm not sure why ghosts are a problem, because you can calculate the gdfo on commit, and then when you pull, you copy the gdfo from the branch you are pulling from?
<jam> garyvdm: fetch can bring in a node which was a ghost locally without you realizing it
<jam> garyvdm: http://paste.ubuntu.com/259422/
<jam> time goes down
<jam> merging D into B will bring in the ghost
<garyvdm> ok
<jam> causing B to have a new gdfo
<garyvdm> bla
<garyvdm> jam: but the gdfo for b and d are know, and the gdfo for the new revision is the max(gdfo of parents)
<garyvdm> max(gdfo of parents) +1
<jam> garyvdm: the gdfo for b *changes* when the ghost is filled in
<jam> we need to detect that
<jam> and propagate that change
<jam> garyvdm: for example: http://paste.ubuntu.com/259426/
<jam> merging D into Z
 * vila remembers when jam explained him the first time and send some love to garyvdm :-)
<jam> (so in those graphs, the first one has 'ghost' as a ghost, but the second has the actual revision.)
<jam> if you merge D into Z
<jam> it has to renumber, B, X, Y, Z
<jam> In the first graph, we think the gdfo(B) == 2 (origin => A => B)
<jam> however, after filling in the ghost it is 3
<jam> origin => A => C => ghost => B
<jam> sorry. it is 4
<garyvdm> Are the ghost in that dag the same rev?
<jam> garyvdm: right. In the first it is a real ghost, in the second it is a known revision
<jam> (the whole point is that 'filling in ghosts' is a problem for caching gdfo)
<jam> and unless you track a list of ghosts, it isn't cheap to determine what ghosts may have been filled in by fetch
<jam> if any
<garyvdm> Ok lest say the ghost is rev g
<jam> sure
<garyvdm> Who ever committed b would have had to have g in their repo
<garyvdm> So the correct gdfo of g was know the b was commited
<jam> garyvdm: yes. but bzr-svn has had a great knack for introducing a ghost in other people's repos
<jam> and ...
<jam> wouldn't store the gdfo property
<garyvdm> So bzr-svn whould need to check for introducing a ghost on fetch, but normal bzr would not.
<jam> garyvdm: it all depends on how ghosts can be created and when they can be filled
<jam> converting from Arch is another way that ghosts were generated
<jam> etc
<garyvdm> jam: ok I see.
<jam> And fetching bzr-svn => bzr branch can create a pure bzr branch that has a ghost
<jam> and then fetching that bzr branch to another bzr branch can propagate that ghost
<jam> and then fetching into that from the original bzr branch will fill in the ghost
<jam> I can draw a diagram if you prefer
<jam> basically, though, allowing a bzr revision to be stored in a non bzr location
<garyvdm> DW. I understand.
<jam> and then pulled out
<jam> *could* introduce all kinds of craziness
<garyvdm> Jam: and checking for ghosts on fetch would involve loading the whole graph.
<jam> garyvdm: unless we start keeping a list somewhere of things that are ghosts. Yes
<garyvdm> yes
<jam> also, if you are loading the whole graph, you may as well number it from scratch
<jam> since the numbering is ... low ms
<jam> versus the loading
<jam> I think gdfo on OOo is something like 700ms versus 10+s to load the whole graph
<garyvdm> So is the plan to track the ghosts?
<garyvdm> Hi amanica!
<jam> garyvdm: well, if we want to cache gdfo, I think we have to track ghosts
<jam> we don't do either yet
<jam> vila-dinner is the one looking at that side of it
<jam> :)
<amanica> Hi garyvdm! :)
<garyvdm> jam: My ideas for KnownGraph, and question about find_ancestry are very brief, So I'll ask you here.
<garyvdm> For KnownGraph, It would be nice if I could acquire via a public api the parents, and children for a revision.
<garyvdm> Qlog uses that, I would be nice if there was just one copy.
<jam> easy enough to add
<jam> would you want it to be multi-way returning a dict?
<jam> or just a single node?
<garyvdm> Jam: just single node
<jam> KG.get_parents(key)
<jam> or KG.get_parent_map(keys)
<jam> would you rather get the node directly, and have a way to walk node child and parents?
<jam> or do you prefer to have KG as the pure api?
<jam> (at the moment, the internals are slightly different between the KGN for python and pyrex)
<garyvdm> KG.get_parents(key), KG.get_children(key) would be cool
<garyvdm> I'll do a patch for that.
<garyvdm> Ok 2nd question: This is how I'm using find_ancestry: http://paste.ubuntu.com/259445/
<garyvdm> Keys are in the format (revid,)
<garyvdm> Is there a quick way to get just revid?
<garyvdm> jam ^
<jam> key[-1] ?
<jam> Also, I'm fairly sure that your else: clause will fail
<jam> because CombinedGraphIndex doesn't implement _find_ancestors() only find_ancestry()
<jam> oh, and revisions._index is not a CombinedGraphIndex
<jam> but a _GCGraphIndex or a _KnitGraphIndex
 * garyvdm tests.
<garyvdm> jam: I don't understand what ref_list_num is for. Is it ok for me to just pass 0, like you do in groupcompress.get_known_graph_ancestry?
<jam> garyvdm: Indexes store a list of referenced revisions, which is repository specific
<jam> it turns out that all current repos have the regular 'parents' as the first entry
<jam> (KnitPack also stores the compression parent as the second entry, Groupcompress doesn't have a second entry)
<jam> but it is why the index code doesn't claim to know the right value
<jam> and gets it passed in from higher levels
<garyvdm> I see, so I should just pass 0 then.
<jam> garyvdm: you honestly shouldn't really be accessing that low of a level from qbzr
<jam> as it could technically be different in a different repo
<jam> for now, yes, you could just pass 0
<garyvdm> Ok - Then I need higher level way to get the whole ancestory from multiple repos.
<lifeless> garyvdm: repository.get_graph()
<garyvdm> lifeless: hi
<jam> lifeless: well, he'd like to get it in a KnownGraph form. :)
<lifeless> hi :)
<garyvdm> Lifeless: I'm trying to take advantage of the better performance of find_ancestry
<jam> garyvdm: you could do: g = repository.get_graph(other_repo); pm = dict((r, p) for r, p in g.iter_ancestry([tips]) if p is not None); kg = KnownGraph(pm)
<jam> but that doesn't give you the benefit of faster ancestry search
<jam> search/loading
<lifeless> garyvdm: then you need to work on exposing it cleanly higher up
<garyvdm> lifeless: Yes
<lifeless> otherwise you'll just end up repeating all of te logic to handle stacking etc
<garyvdm> jam: Any reason why not Graph.iter_ancestry could use find_ancestry?
<chrispitzer> I want to branch a working copy off of my repo without keeping it connected to the repo.  What's the command for this...?
<jam> garyvdm: layering issues?
<lifeless> chrispitzer: bzr branch
<chrispitzer> yea, but then bzr push will go back to the parrent... won't it?
<jam> it would certainly be the expected use case
<chrispitzer> I don't want that
<lifeless> then don't push ?
<jam> but iter_ancestry is a bit silly to cast up into a generator when the lower level is creating dicts
<garyvdm> jam: I c
<lifeless> chrispitzer: if you create a separate branch, you can push anywhere you like
<jam> garyvdm: also, I'm pretty sure get_known_graph_ancestry() doesn't handle stacking yet...
<jam> as you have to explicitly support stacking everywhere, you never (anymore) get it for free
<garyvdm> chrispitzer: You can remember a new push location with bzr push new_push --remember
<jam> especially when you don't even get fallbacks over RemoteRepository anymore...
<jam> garyvdm: and... nobody noticed that it was broken because again, stacking requires explicit testing, since it can't just be a permutation on existing formats...
<garyvdm> jam: So in that case, I shall stick to using repo.get_graph().iter_ancestry( ) for now
 * jam really dislikes the overall impact of stacking, as it breaks things over and over and over again
<jam> garyvdm: yeah probably
<chrispitzer> thanks
<bialix> jam: does stacking even worse os locks?
<bialix> I don't believe
<bialix> :-)
<jam> bialix: stacking has caused more direct bugs in bzr than just about any other feature
<bialix> direct bugs easier to fix?
<jam> it requires a whole lot of code to know whether the thing it is looking at is stacked or not
<jam> especially given that RemoteRepository is no longer abstracting away the fact of stacking
<bialix> oh
<jam> so the client now needs to know about stacking, and do operations 2x, etc.
<jam> bialix: not to mention all the recent stuff about "filling in parent inventories", etc.
<jam> which broke fetch, commit, merging a bundle, autopack, pack, upgrade, ...
<bialix> I'm happy to not know about all this nightmares
<bialix> but it scary
<bialix> jam: btw, did you saw james_w's new bzr-builder plugin?
<garyvdm> jam: for KnownGraph.get_parents(key), should it check if the key is in the graph and return None if it is not, or just let a KeyError get raise?
<jam> garyvdm: I would probably raise an exception
<jam> I think the common uses
<jam> mean that you should only be using keys that it has told you about
<jam> so it is easier to write code that doesn't have to check if None
<jam> the bigger question is what to return for ghosts?
<garyvdm> ok
<garyvdm> []?
<jam> Since they have a node with parents of None
<garyvdm> jam: [] would be the nicest for qbzr use. However, returning None may be usefull for other
<garyvdm> users of the api
<garyvdm> to know if a Node is a gost
<jam> garyvdm: well, kg.merge_sort() now directly filters out ghosts nodes from the return value
<jam> so you can pass in ghosts without having to filter
<garyvdm> Ok, in that case, I'll just return None.
<garyvdm> jam: Sorry to bother you so much. I've added a test that I expect to pass for the py version, and fail for the pyx version. But I don't get any failers.
<garyvdm> How can I check that it is testing the pyx version.
<jam> garyvdm: how are you creating the KnownGraph instance?
<jam> self.create_known_graph() ?
<jam> you can also just print kg
<jam> and it should be obvious whether it is python or pyre
<jam> pyrex
<garyvdm> self.make_known_graph
<garyvdm> ok
<garyvdm> bla - I was running bzr selftest, not ./bzr selftest
<jam> :)
<lifeless> jam: shelf on windows nearly fixed.
<lifeless> jam: is there a bug for it?
<jam> lifeless: bug #305006
<ubottu> Launchpad bug 305006 in bzr "shelve fails on win32 with "Could not acquire lock"" [Medium,In progress] https://launchpad.net/bugs/305006
<jam> I believe
<garyvdm> jam: Thanks alot for all the help.
<garyvdm> Night all
<lifeless> jam: hai five!
<jam> ? got shelve to work?
<jam> lifeless: grats
<lifeless> yup
<lifeless> 96 passing tests
<lifeless> and a bit of test stipple cleaned up
<lifeless> jam: branch is up, review request mailed.
<lifeless> jam: only 5 thisFails calls in tree now.
<lifeless> abentley: you might like to review it too, as I think you use shelf in pipelines implementation.
<lifeless> abentley: are you around? I have a merge_inner question
<abentley> lifeless: on the phone
<lifeless> gimme a ping when you have a minute then.
<lifeless> oubiwann: thanks
<lifeless> oubiwann: shall look again
<oubiwann> lifeless: sweet -- thanks!
<lifeless> jam: thanks
<bialix> does bzrlib has helper function to deteremine is given location (or pair tree/branch) is actually light checkout?
<lifeless> <when he returns> bialix: I don't think so. tree.bzrdir.root_transport.base != tree.branch.bzrdir.root_transport_base though.
<abentley> lifeless: ping
<lifeless> abentley: hi. so there is a single test left that does locking operations that won't work on windows
<lifeless> bzrlib.tests.per_workingtree.test_workingtree, test_merge_revert in that
<lifeless> in that, the merge_inner call fails
<lifeless> it fails because Merger replaces the base tree with a new revision tree
<lifeless> but 'base' is a modified tree, so I'm not sure that its safe for Merger to do that.
<lifeless> I'm hoping to get a better understanding from you of this part of the code base
<abentley> lifeless: Where does this happen?
<lifeless> in set_base_revision I think. I paged it out since I pinged you, and I'm running low on blood sugar now, I was about to eat when you pinged.
<lifeless> Can you bear with me while I do that ? be about 10 minutes
<abentley> lifeless: I'm looking....
<lifeless> if you want to see the error, remove the thisFailsS... line at the top of that test.
<lifeless> back soon
<abentley> lifeless: It looks like jam wanted to update Merger.base_rev_id, so he called set_base_revision, which has side effects that I can't imagine he wanted.
#bzr 2009-08-26
<lifeless> I've added (and its landing now) an earlier cache of revision trees, but that doesn't help here because its not a revision tree
<lifeless> and as the tree is modified it seems to me it will be doing the wrong thing - this could be exacerbating up-thread/down-thread/update conflicts as well, if I understand it correctly.
<abentley> lifeless: I don't understand jam's change, but it looks wrong in two ways.
<lifeless> ok; I'll file a bug about this, as its not 'just a locking issue' then.
<abentley> lifeless: You shouldn't call set_base_revision if you don't want to set the base tree, and you shouldn't set base_rev_id for the revision-id of a WorkingTree.
<abentley> lifeless: For working trees, Merger does know about a basis revision, e.g. Merger.this_basis and Merger.other_basis.  There's no corresponding variable for base trees, but that's what he would want to set.
<abentley> lifeless: The smallest change that would get this working would be to set Merger.base_rev_id directly instead of calling set_base_revision.
<abentley> lifeless: Confirmed, that passes.
<lifeless> abentley: thank you. It could have fall out elsewhere though?
<abentley> lifeless: It's conceivable.  Most likely in a test case where we had coded it to expect the wrong behaviour.
<lifeless> ok. I was doing this locking stuff as a warmup, so I'll put this bug in for now, and come back to it later.
<lifeless> do you have a diff of that change you just made?
<abentley> lifeless: http://pastebin.ubuntu.com/259556/
<lifeless> thanks
<lifeless> win 83
<lifeless> sorry about bug noise on 305006
<lifeless> trying to get lp to do what I need ><
<lifeless> igc: when you get here
<lifeless> igc: my faster commit was broken; it should have been faster; fixed and landing now
<lifeless> igc: so you may want to retest it speed wise :)
<igc> morning
<igc> lifeless: shall do
<josh_k> anyone want to point me in the right direction for using bzr to merge two heretofore unrelated files?
<josh_k> hm
<josh_k> now that i say that out loud, I don't see how it would reasonably be possible
<josh_k> hand-merge, here we come...
<lifeless> igc: its landing at the moment
<igc> lifeless: excellent. well done!
<lifeless> http://pqm.bazaar-vcs.org/
<igc> lifeless: as soon as I wake up this morning, I'll give it a spin :-)
<lifeless> kk
<lifeless> it wasn't using specified_files in iter_changes
<lifeless> which is why 'partial commit' was only as fast as full commit
<igc> poolie: my focus today will be on reviewing critical/high patches and ...
<igc> poolie: announcing explorer 0.7 + fastimport 0.9
<igc> hopefully james_w or someone can get those uploaded to karmic in time
<poolie> igc, that sounds good
<poolie> mine is to merge the 2.0b1 branches and get that out
<lifeless> igc: its landed
<igc> lifeless: sweet
<igc> lifeless: so IIUIC, shelve/unshelve now work correctly on Windows?
<lifeless> igc: yes
<igc> lifeless: landed?
<lifeless> or rather
<lifeless> unit tests say they do
<lifeless> yes, landed.
<igc> lifeless: wow, you rock!
<lifeless> also pushing locally
<lifeless> there are now no tests that should fail due to locking interactions on windows that represent things users can do
<lifeless> there are a few that we use to test race conditions
<igc> lifeless: you may want to email the bzr-windows list calling for testing on this
<lifeless> I've a branch up for review that guards those tests on windows more aggressively
<lifeless> igc: I'm not on the windows list - could you send such a mail?
<igc> lifeless: sure
<igc> lifeless: that's mega cool because I'll now get some interest in someone writing qsheve/qunshelve
<lifeless> we can of course still collide between separate processes
<lifeless> but same process stuff should be rock solid
<igc> lifeless: as long as they weren't working on Windows, there was limited interest
<igc> lifeless: pulling the 2.0 branch doesn't show your commit changes, nor the shelve-related changes
<igc> lifeless: are they only in trunk or is lp mirroring to blame?
<lifeless> only trunk
<lifeless> landing a big batch to 2.0 later
<igc> ok
<poolie> ok time for brunch, or whatever it is :)
<AfC> poolie: it's not a weekend, so I think yes, you need to have brunch before noon. Weekends you're ok until 13:30 :)
<lifeless> igc: my testing shows - 1.3 seconds for commit w/out iter_changes, 0.25s for commit w/iter_changes 0.36s to commit the full tree
<lifeless> igc: (alll with a single file changed)
<igc> lifeless: which project?
<lifeless> samba in 2a
<lifeless> the first two times are 'commit  README', the last one is 'commit'
<lifeless> spiv: ping
<lifeless> IncompatibleRepositories: CHKInventoryRepository('chroot-97810960:///stack-on/.bzr/repository/')
<lifeless> is not compatible with
<lifeless> KnitPackRepository('chroot-97810960:///to/.bzr/repository/')
<lifeless> different rich-root support
<lifeless> thats what I'm generating at the moment
<lifeless> spiv: this isn't ideal, but AFAICT its roughly what we do elsewhere
<lifeless> and its at least in the category of 'class of thing we already have to fix'.
<lifeless> spiv: seem ok to run with this?
<spiv> lifeless: ugh
<spiv> What's the benefit we'd trade this against?
<lifeless> well at the moment its an UnknownSmartServerError
<lifeless> the client hasn't ever opened 'stack-on', so it can't translate it without going to the network.
<lifeless> and 'to' doesn't exist because the server is aborting a 'create foo for me' operation.
<lifeless> so in terms of benefits; it will error about 600ms faster
<lifeless> possibly my unit tests are not representative of what launchpad itself will do
<spiv> I'm not really fussed about making that error faster :)
<spiv> I think we need to fix the server to return relpaths fairly soon.
<lifeless> spiv: note that I'm going to be catching this in cmd_push *anyway*
<lifeless> this is 'bzr push a 1.9 branch somewhere with a stacking policy that points at a 2a branch'
<lifeless> a precondition on that is that I can catch the error; so my motivation here isn't 'make this error nice', its 'make it typed rather than 'unknown''
<spiv> IncompatibleRepositories can occur on other operations, although I agree that's the most common.
<lifeless> they can, and at the moment - well see above - unknown smart server error.
<spiv> What does the error serialisation look like?  I'm wondering if it will be reasonably easy to replace the useless in-proc URLs with relpaths later without disrupting old clients.
<lifeless> I argue that what I've done so far is an unqualified improvement, even if its not an ideal end-state.
<lifeless> ('Incompa..', str(err.source), str(err.target), str(err.detail))
<spiv> Yeah, I agree it sounds like an improvement.
<lifeless> but as the client doesn't process at all it would be easy to change later
<spiv> The crummy URLs are essentially the same issue as in the lock contention message, I guess.
<lifeless> yes
<spiv> I'm satisfied that this is an improvement.  I'm a little worried it'll be an impediment to doing something better later.
<lifeless> there are two cases
<lifeless> either we need more fields, or we need to change the serialised value of fields
<lifeless> the client doesn't care about how many fields
<lifeless> so we can add some (including adding different representations of existing fields)
<spiv> Ok, if you leave that wiggle room in the client that sounds ok.
<lifeless> and the client doesn't parse the fields, so we can change fields if we want- knowing that the client will just show the strings it receives
<spiv> i.e. effectively reserving some fields for future use.
<lifeless> its no worse than
<lifeless> Using default stacking branch /~bzr/bzr/trunk at lp-45211856:///~lifeless/bzr
<lifeless> I feel you're very concerned about a special case of a pervasive problem.
<lifeless> which is a bit odd.
<spiv> Oh, it is pervasive.
<spiv> That doesn't mean we should spread it even further without thought :)
<spiv> Actually, that particular message is extra crummy.
<spiv> It's actually emitted on stderr by the server process!
<lifeless> the incompatible one?
<spiv> Oh, actually, not that one.
<lifeless> merge review request sent.
<spiv> I'm thinking of the 'Source format doesn't support stacking' one.
<lifeless> as we've discussed, I figure you've just volunteered to review ;)
<lifeless> spiv:
<lifeless> https://code.launchpad.net/~lifeless/bzr/bug-393677/+merge/10710
<lifeless> spm: whats the url configured in pqm's bzr config for 2.0 ?
<lifeless> spm: ping
<lifeless> poolie: whats the url for submitting to 2.0?
<igc> lifeless: I'll kick off that benchmark now while I grab some lunch
 * igc food
<lifeless> igc: its going to be awesome
<spm> lifeless: similar to the 1.17 & 18: bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> spm: thanks
<lifeless> we need to doc this better. /me adds a yak to the list
<poolie> spiv, hi, shall we catch up?
<poolie> lifeless: do you think https://code.edge.launchpad.net/~ian-clatworthy/bzr/faster-dirstate-saving/+merge/7537 is good to merge now? igc says you read a previous version
<lifeless> poolie: the last one I read looked like it could cause confusion about the internal state; jam's comments were along those lines and I agreed.
<lifeless> I don't know if its been improved since then; and while its a functional improvement it is a risky area of code.
<poolie> so it needs to be reworked?
<poolie> jml: regarding the test suite
<poolie> i don't think running it twice from pqm is, um
<poolie> likely to be actioned very fast
<poolie> so, i'd rather rely on buildbot, which is apparently now working ok
<lifeless> poolie: do you mean 'lifeless: regarding the test suite' ?
<jml> well, it is being run twice from PQM right now
<poolie> no :-P
<poolie> jml: now that we have a buildbot and are getting results from it i propose to just remove the second run from make check
<poolie> and get vila to do that on a slave somewhere
<jml> poolie, that sounds fine
<lifeless> poolie: I have been watching carefully since we last discussed this
<lifeless> poolie: I haven't landed any utf8-related patches to see if it helps or not :P
<poolie> i loked through all my recent pqm mails and didn't see any failures in ascii tests
<poolie> but that may be unrepresentative because people tend to work in different areas
<lifeless> poolie: right, but what fraction were ... exactly
<poolie> anyhow i'm not going to do it now
<lifeless> anyhow, I've voiced my opinion - to keep it - before. I don't think the gain is worth the pain if something slips through.
<poolie> or not today
<lifeless> but I won't try to stop the change, if I can't convince you, the arguments aren't convincing
<poolie> so, i respect your opinion, and i'm open to changing it back, but i think we should try changing it
<poolie> i'm sure we get more breakage across platforms or distro versions
<poolie> so we need buildbot to work well for that coverage
<poolie> so i'd be ok relying on it for that too
<poolie> s//for lang=c too
<lifeless> I get that. OTOH we've known about windows breakage for ages. It got fixed when it became possible for us to test it locally and quickly.
<lifeless> [locking specifically]
<lifeless> My experience with fix-later environments is that they are consistently lower quality than fix-before ones.
<lifeless> But as you say, open to trying the change and measuring.
<poolie> so eventually it might be nice to test them all synchronously but in parallel
<lifeless> poolie: what url did you give pqm to land bialix's patch?
<lifeless> on 2.0
<poolie> i didn't
<lifeless> spm: whats the public address configured in the pqm conf?
<poolie> i think vila sent it
 * lifeless hunts yaks
<spm> lifeless: http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> spm: thanks
 * lifeless submitifies
<poolie> how about https://code.edge.launchpad.net/~jameinel/bzr/2.0b1-402645-fragmentation/+merge/10621
<lifeless> spm: can you just paste me the stanza please..
<lifeless> econfused
<lifeless> poolie: jam and I don't agree about the short term fix
<spm> lifeless: https://pastebin.canonical.com/21499/
<lifeless> I'm worried about unordered being pathological because of whats out there already; he's worried about preventing existing branches getting worse
<lifeless> its not a strong difference
<lifeless> but as we rather have to fix this properly (IMO) for 2.0 to be released, I don't feel a strong urge to land a bandaid: users of 1.16/1.17/1.18 are already plentiful
<lifeless> spm: can you check if there is a pqm job in process on there? (not via the web UI... I suspect I may have tickled a bug)
<lifeless> poolie: bug 418998 is probably the symlink dereferencing bug
<ubottu> Launchpad bug 418998 in bzr-svn "bzr crashes when adding .vim/* from my home directory" [Undecided,New] https://launchpad.net/bugs/418998
<lifeless> poolie: rather than bzr-svn
<lifeless> the 'didn't add files' aspect will be the 'silently ignores subtrees' bug in bzr core
<spm> lifeless: technicall yes a job is running; but isn't a bzr one - if you ken what I'm not saying :-)
<lifeless> I do
<lifeless> can you check the log for requests from me
<spm> aye
<poolie> oh ok
<lifeless> spm: actually.
<lifeless> spm: cron spam!
<spm> ha
<lifeless> bzrlib.errors.ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<lifeless> Permission denied (publickey).
<spm> (*^%)@*(#&$^)@#*(^%()*!&@%$_@#$&*())@*(#&$^@(*&^!!!!!!!!!!!!!!!!!!
<lifeless> spm: please be fixing that file, that file you love so well.
<lifeless> poolie: I replied asking if it was a symlink, that will tell us
<poolie> spiv, tell me things?
<spm> lifeless: pls to try try again
<lifeless> bombs aaway
<spiv> poolie: heading out to lunch in a sec.  I've been responding to jam's review of my groupcompress batching branch.
<lifeless> arjenAU: hi
<lifeless> arjenAU: when are you in sydney?
<poolie> spiv, so how is it overall?
<lifeless> spm: no go?!
 * lifeless tries with http <-> http
<arjenAU> lifeless: 7-9 Sep (7pm on the 6th)
<lifeless> arjenAU: I'm going to try to swing past the mechanics school
<arjenAU> lifeless: hmm?
<lifeless> aren't you giving a talk?
<lifeless> at SMUG?
<spiv> poolie: he saw some possible holes in the batching/caching interaction.  I think I've fixed that up, although it's perhaps a little bit more complex now.  It's looking good; I'll submit it for re-review by jam just in case, but I expect it'll get a thumbs up.
<lifeless> poolie: http://pqm.bazaar-vcs.org/ will hopefully land all the cumulative fixes from bzr.dev. If it fails, they are pushed to lp:~lifeless/bzr/2.0 so that people can tweak.
<lifeless> I don't expect failures - but theres > 10 patches in the set so it may find something to bail on
<lifeless> arjenAU: http://www.pythian.com/news/3728/sydney-mysql-user-group-meetup-9-in-depth-mysql-with-arjen-lentz specifically ;)
<arjenAU> lifeless: oh right! sure
<lifeless> but if you want to get together and chat bzr/lp stuff before/after/some-other-timeslot that would be cool too
<jam> lifeless: so the code as it stands now only makes things worse and never better. Why wouldn't switching to 'unordered' be a reasonable short term fix?
<lifeless> jam: I'm concerned that it will also make things worse, just differently, as it will apply to all fetches too. And its a chance for more bug reports while we're doing the longer term fix.
<spm> lifeless: well I guess one positive - that file is back. So I suspect we know where it's coming from...
<lifeless> spm: wheres that then ...
<jam> lifeless: so.. if the source has been packed (ever) then at least we preserve that
<lifeless> my using lp: as the source for the merge, I'd suspect
<lifeless> jam: I'm mainly coming from paranois :)
<jam> it doesn't effect Packer
<lifeless> I need food
<lifeless> back shortly- jam, land if if you're quite sure we won't have fallout while we develop the longer fix.
<spm> lifeless: that was my guess, yes.
<lifeless> spm: so, what happened when we tried an empty file?
<jam> lifeless: given that we've been fetching pack => pack 'unordered' for a while....
<spm> lifeless: kaboom
<lifeless> actually, I don't want to know. I want to debug it with you tomorrow and file copious bugs
<spm> heh
<lifeless> we can't reliably switch to lp until thats fixed.
<spm> right
<lifeless> arjenAU: but if you want to get together and chat bzr/lp stuff before/after/some-other-timeslot that would be cool too
<lifeless> poolie: EOD(); suspend();
<poolie> ok
<poolie> i'm going to get as many of these things merged as we can then do a beta
<poolie> unless something comes up
<arjenAU> lifeless: we'd be done at 5pm, barack st in city.
<lifeless> sounds good
<lifeless> I'll tee it up with you next week
<lifeless> poolie: http://pqm.bazaar-vcs.org/ is good so far
<lifeless> jml: after work today can you do me a small favour. subunit progress review-or-rubber-stamp
<jml> lifeless, sure thing
<thumper> abentley: pipeline ping
<poolie> spiv, back?
<spiv> poolie: yeah
<poolie> i guess rather than nagging i want to know
<poolie> when i should do 2.0b
<poolie> so can you tell me either when you have nothing more to do with it, or alternatively
<poolie> if there's anything i should be doing, or if it's pear-shaped
<lifeless> poolie: if 2.0b means 'we think we're done', in a few days
<lifeless> poolie: if it means 'get a snapshot of where we are at' - well anytime really.
<lifeless> my backport of the last weeks progress looks like it will land
<lifeless> in 30-40 minutes
<poolie> it means we think there's no more critical bugs
<lifeless> ok, well I don't think we're going to be there today
<spiv> So I'm currently working on the fix for bug 402657, by doing the last tweaks from jam's review.  I'm going to ask him to re-review it, though, because he's touched this more than I have and I'd like to be cautious with this.
<ubottu> Launchpad bug 402657 in bzr "2a fetch over dumb transport reads one group at a time" [Critical,Fix committed] https://launchpad.net/bugs/402657
<spiv> Which means I expect it to land tomorrow morning.
<jam> well, if you submit it right now
<jam> I might get to it :)
<poolie> that would be much better
<spiv> Hmm, I'll see how quickly I can take care of the last little bits :)
<poolie> thanks
<lifeless> poolie:  '(mbp) fix IndexError printing CannotBindAddress'
<lifeless> thats in my branch thats landing
<lifeless> might want to ask spm to cancel your merge
<poolie> hm
<poolie> why is it in your branch?
<lifeless> because I did what I said I would do earlier
<lifeless> which is to cherrypick all the 2.0 candidates from trunk
<poolie> ah, ok
<poolie> i understood you meant you'd do one merge with all of your changes
<poolie> so spm would you please cancel my pending pqm job?
<lifeless> have a look at http://pqm.bazaar-vcs.org/ at my commit message :P
<spm> poolie: cancelled
<poolie> oh thanks
<jam> spiv: I'm going to bed now. So better to do a good job then a fast one.
<jam> I'll try to review first thing when I wake up
<lifeless> sleep well jam
<jam> night all
<jam> thx lifeless
<lifeless> spm: please tell me you didn't cancel the running job
<lifeless> spm: (and mean it!)
<spiv> jam: g'night
<spiv> d'oh, missed him.
<spm> lifeless: I didn't cancel the running job. ??
<spiv> Just pushing it up now, anyway.
<lifeless> whew
<spm> lifeless: rm patch.1251263587 ==> star-merge http://bazaar.launchpad.net/~mbp/bzr/prepare-2.0 http://bazaar.launchpad.net/~bzr-pqm/bzr/2.0
<lifeless> ah found it
<lifeless> poolie: its all landed
<poolie> spiv, so what now?
<spiv> poolie: Well, the review reply with a fairly small incremental diff (+68, -45) has been sent and I think addresses jam's concerns.
<poolie> so..
<spiv> Gar, wireless dropout.
<spiv> (on wired for the moment)
<lifeless> poolie: btw, record_entry_contents has exhaustive permutation tests.
<poolie> do they pick up the case where it shouldn't record a new text?
<lifeless> yes
<lifeless> they pin it down very very precisely.
<lifeless> they assumed that the interface they were building on returned accurate data.
<lifeless> grep for unchanged in bzrlib/tests/per_repository/test_commit_builder.py
<vila> ow, almost crossed jam...
<vila> hi all :)
<igc> hi vila!
<lifeless> poolie: Its my contention that only explicit tests for the problem would have exposed it - be they integration tests or unit tests of the interface.
<lifeless> poolie: I don't think it is a lack of tests on the record_entry_contents interface though; given accurate data it will behave well and is tested to do that.
<lifeless> given bogus data I think its extremely likely to misbehave - but thats why we have tests for the behaviour of tree :)
<poolie> https://bugs.edge.launchpad.net/bzr/+bug/418931 spiv
<ubottu> Launchpad bug 418931 in bzr "AssertionError: _remember_remote_is_before((1, 18)) called, but _remember_remote_is_before((1, 15)) was called previously" [High,Confirmed]
<lifeless> poolie: I guess I'm trying to say that you're very unlikely to be able to create a test that when given valid data the api does the wrong thing
<lifeless> poolie: because I spent a bunch of time trying to make the interface tests as defensive as possible
<igc> poolie: reviewing that cf patch now and have some questions ...
<poolie> ok
<igc> poolie: in repository.py, why the new exception wrt nested tree
<igc> ?
<poolie> more context?
<igc> did that fall out of tests?
<igc> lines 98-100
<igc> see https://code.edge.launchpad.net/~mbp/bzr/415508-content-filtering/+merge/10640
<poolie> it came out of testing it
<poolie> it should never be hit, but trapping it here gives a more meaningful message
<igc> ok
<igc> poolie: also the docstring in workingtree4.py ...
<igc> code doesn't seem to match?
<igc> well match precisely
<poolie> that it holds the hash and size?
<poolie> i thought it did :/
<lifeless> igc: how did the perf test go?
<lifeless> did it rock?
<lifeless> igc: also, all the stuff for windows users is in the 2.0 branch now.
<igc> lifeless: the one over lunch sucked because the lp mirror wasn't up to date :-(
<igc> lifeless: I kicked off another test 30 minutes ago
<lifeless> igc: ah, shame. eta?
<igc> lifeless: *this* time with your code :-)
<poolie> lifeless: so, possibly with the test_commit_builder tests, i just want to add a new one asserting that it copes ok if the size and hash are null
<poolie> none*
<poolie> and if the size is none but the hash is known
<poolie> and maybe for both those cases, with the case that the file actually either has or hasn't changed
<lifeless> poolie: So unknown I'd expect to be covered (I'd have to check though). But unknown size was not conceived of in the original interface definition.
<lifeless> poolie: so I definitely adding tests to cover the change to the interface is appropriate.
<igc> lifeless: full test is still running but the number you want just popped on my screen 10 seconds ago ...
<lifeless> s/adding/think &
<igc> 1.2 seconds
<igc> down from 73+ seconds
<lifeless> igc: and full commit is?
<igc> 1.96 seconds
<lifeless> booyah!
<igc> :-)
<poolie> i guess it returns an indication of whether something was recorded
<lifeless> igc: that 0.7 seconds is 'status on the rest of the tree'
<igc> right
<lifeless> poolie: yes, we also check that the inventory gets the right last-modified value for that entry.
<lifeless> poolie: remembering that this is an awkward interface we are deleting, so don't go overboard :)
<lifeless> poolie: 'rm the interface' is not-all-that-far-away.
<lifeless> igc: If you recally, I was expressing concern that that overhead would be substantial vis-a-vis layering on iter_changes rather than changing iter_changes.
<poolie> so i've sent that thing for merge
<lifeless> igc: you can see why now, I hope.
<poolie> there's a bug open about adding more tests but i'm not very motivated to do it now
<lifeless> I think thats fine; I'd be inclined to close the bug wontfix
<lifeless> diminishing returns
<poolie> if i'm going to do more here it would be primarily
<poolie> adding integration tests
<poolie> or trying to refactor it into a clearer layer that does filtering
<poolie> igc, tell me about bug 374735?
<ubottu> Launchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [High,In progress] https://launchpad.net/bugs/374735
<igc> poolie: one sec
<igc> poolie: so the issue is ...
<igc> could the Upgrade Guide recommend a less complex upgrade recipe for branches stacked on LP?
<igc> poolie: iiuic, thumper thinks no
<poolie> so, um
<igc> poolie: I'm happy to document whatever we agree on
<poolie> i suppose what i want to know now is, what's the implications for the 2.0 release? should i be doing something to unblock it, or should we considering that it might block 2.0?
<igc> poolie: maybe we need a conference call with thumper, lifeless, you and I to resolve it
<igc> poolie: I think the current recipe and doc is acceptable
<igc> poolie: I agree it *could* be better one day but I don't think it's a blocker
<igc> poolie: my personal opinion is that making shared repository upgrades easier is more important
<igc> by upgrading branches in that repo implicitly
<igc> my patch for patch got some love last Friday but hasn't moved since
<poolie> right
<igc> s/for patch/for that/
<poolie> so that's only weakly connected to the issue of upgrading stacked branches?
<poolie> like technically unconnected, just in the same area?
<igc> my patch is currently unconnected from stacked btranches
<igc> an earlier cut tried doing them in a certain order but ...
<igc> I backed that out because it didn't apply ...
<igc> stacked branches aren't supported in a shared repo at all
<poolie> i'm thinking about narrowing down the 2.0-targeted bugs to just things that we must or nearly must fix
<poolie> just for easier thinking
<igc> right
<jml> the best kind of thinking!
<igc> I think the Upgrade Guide is fine for 2.0
<igc> after all, it actually works
<igc> I wish the Data MIgration Guide (fastimport) had reached that lofty state
<lifeless> poolie: jml: spiv: I wonder if making scenario application do a shallow copy would be safe. It looks like it might be substantially faster.
<lifeless> we'd probably want to change some static parameters to factories.
<poolie> shallow copy of what?
<igc> poolie: btw, just approved that content filtering patch
<poolie> thanks
<poolie> i already sent it :)
<spiv> lifeless: of the test case, vs. a deep copy?
<lifeless> yes
<igc> poolie: ok, so approving it makes me feel better, if not adding any value otherwise :-)
<spiv> lifeless: I imagine it would be faster... I wonder if perhaps there should be an option for deep vs. shallow?
<lifeless> apply_scenarios is ~ 100% of the time of 'test_test_suite'
<spiv> I don't have a very strong opinion on the safety of it.  I think using copy/deepcopy is a bit of a rough approximation for the semantic that we want.
<lifeless> test.clone() would be better.
<spiv> Right.
<poolie> well, add a .copy() method and then it can be modified
 * lifeless adds another yak.
<poolie> exactyl
 * jml is agreeing so far
<jml> shallow will work, I think.
<spiv> Well, there's __deepcopy__ already ;)
<poolie> did you ever have yak butter tea? i once did in montreal.
<poolie> kiwis might like it :)
 * lifeless makes it shallow
<lifeless> 50% faster
<lifeless> and another second off loading the regular test suite.
<lifeless> 3.3 seconds being reported by selftest selftest now.
<lifeless> almost down to tdd speeds again
<poolie> nice :)
<poolie> want to do my selftest --debug-failure feature request too? :)
<lifeless> poolie: yes, but I won't
<lifeless> I want to drive this thread to the ground
<lifeless> and I haven't yet figured out how to fork() myself
<lifeless> _check_safety_net
<lifeless> this is kindof slow.
<poolie> hm, i don't know what to do now
<lifeless> I have been wondering if thats what you were doing:) [figuring out what to do]
<lifeless> poolie: if you don't have anything specifically for 2.0, you could pick one of [brain food, manage someone, something useful even if not 2.0 specific]
<poolie> i need to merge 415508 to 2.0 and then i guess look at john's bug 402645 fix
<ubottu> Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645
<poolie> and then do a beta release
<vila> lifeless: _check_safety_net *intent* is to ensure we don't fallback to a shared repo, it's more problematic when one set TMPDIR under his $HOME than the default under /tmp,
<vila> that being said, the *implementation* can be changed as you see fit
<lifeless> vila: yes, but opening a working tree 20K times is a lot of work.
<lifeless> vila: I'd rather make sure we error when someone reads from that dir
<lifeless> vila: by using the branch open hook. For instance.
<vila> lifeless: yup, that will work too, we discussed it with poolie long ago, but I never found the time to fix iit
<vila> maybe just chmod'ing may be enough (but may not work on windows)
<vila> *but* I'm a bit scared by a too tricky impl. that some tests may defeat
<lifeless> vila: so, a few thoughts
<lifeless> a test could go above it anyway.
<vila> anyway, a good test for that is to create a standalone branch and then do TMP_DIR='.' :-)
<lifeless> so we can't be perfect.
<lifeless> As we can't be perfect, we get to choose just where we put the line.
<lifeless> I suspect that a python callback * 20K will be much cheaper than open_wt + get_last_revision * 20K
<lifeless> the only tests that could bypass that are those that actually run bzr externally.
<vila> a few thoughts too: I'm pretty sure some tests already escapes the current jail (some cxxxpolicy tests actually use the local branch settings)
<lifeless> so roughly:
<lifeless>  - make a subclass (e.g. ExternalBase :P) be the only test class with run_bzr_subprocess()
<lifeless> give that subclass the current safety net check
<vila> External must die
<vila> ExternalBse must die
<lifeless> actually, I think it should live, for this and only this.
<vila> It's the one in blackbox right ?
<vila> be aware that it isn't used by all blackbox tests then
<lifeless> and remove the current safety net creation and check in the base class with the replacement of a bzrdir/branch open hook to catch library attempts to use that area.
<lifeless> vila: when i delete the method from the base class, they will show up pretty fast.
<vila> oh, by running selftest -s bb you mean ?
<lifeless> broadly, yes
<vila> also, some tests escape the safety net by accessing only the config files if I remember correctly
<lifeless> yes, thats why we change HOME
<lifeless> I plan to add hooks to file() and open() to catch them
<vila> I'm pretty sure some tests still access the local branch if TMPDIR is set
<poolie> lifeless: that still makes me a bit unhappy
<poolie> i'd really rather you use a readonly directory
<lifeless> poolie: I want to get away from disk IO completely for tests that think they are only testing functions.
<poolie> i agree too
<vila> I'm sorry I don't have more precise info there, it's all from experiments I made long ago and could never finish, the point is, we have some minor isolation problems that I saw long ago with the TMPDIR trick,
<lifeless> poolie: I don't see making a directory, readonly or otherwise, as being compatible with that goal :(
<lifeless> vila: I hope that I'll flush these out eventually.
<vila> *but* they never show up again with --parallel=fork, so may be some have been already addressed
<poolie> why?
<vila> and the long term plan is to catch them by running them one by one when I'm able to work on coverage again
<lifeless> poolie: because it requires mkdir(), either per-test, or a global variable and per-test-run
<lifeless> the former is expensive, and the latter is also aesthetically displeasing
<vila> lifeless: indeed, that's why I try to inherit from TestCase as much as I can :)
<vila> poolie: run selftest -v -s xxx (limited to 20 tests or so) and you quickly get the feeling
<poolie> which feeling?
<vila> that's TestCase tests are faster than TestCaseInTempDir
<poolie> but doesn't even the base class get a tmpdir?
<poolie> hm, ok
<poolie> i guess it may stop us reading anything
<poolie> i kind of suspect it will break things but it's worth a try
<vila> poolie: no, that starts with  TestCaseWithMemoryTransport
<poolie> did any of you have an opinion about john's groupcompress fragmentation patch https://code.edge.launchpad.net/~jameinel/bzr/2.0b1-402645-fragmentation/+merge/10621
<vila> poolie: we had a long discussion with jam yesterday regarding gc fragmentation, did you talk to him since then ?
<vila> or did you read the logs ?
<poolie> i did see it but i haven't read them exhaustively
<poolie> so i'd rather if you could summarize?
<vila> hmm
<poolie>  /should i stay or should i go now?/
<vila> 1) gc groups can't be fetched as a whole, we need to split them
<poolie> or more specifically is it a good idea to merge
<vila> I think it's good to merge in the short term
<vila> wow, you wanted a really short summary :)
<poolie> yeah
<vila> ... but the commit messages of the mp summarizes perfectly the situation: best we can to do in the short term, but there are far better alternatives for the long term
<vila> the discussion was about these alternatives
<vila> grr, damn lp:mad, this jam's mp is really a one-liner !
<vila> poolie: ow, you approved it, ok
<poolie> 'ow'?
<vila> poolie: no need for me to review it then, but no worries :)
<lifeless> sorry about the formating
<lifeless> {'TimeStandard': 0.001, 'TimeWithMemory': 11.399999999999878, 'TimeWithTransport': 13.820999999999875, 'TimeBzr': 2.1129999999999911, 'TimeWithDir': 14.200999999999917}
<vila> s/9//
<lifeless> thats 1000 tests, time summed
<lifeless> Standard is unittest.TestCase
<poolie> so close, so far away
<lifeless> you can see that tests.TestCase is about 2000 times slower than unittest.TestCase, and ~1/5 to 1/7th the speed of the richer test cases
<vila> lifeless: s/Time/bzrlib.test.Test/ ?
<vila> ok
<lifeless> yes, TimeWithMemory = a noop TestCaseWithMemoryTransport test
<vila> fully match my mental model
<vila> but what is TimeBzr ?
<lifeless> http://paste.ubuntu.com/259705/
<lifeless> +class TimeBzr(tests.TestCase):
<lifeless> +
<lifeless> +    def test_time(self):
<lifeless> +        pass
<vila> oh, ok
<lifeless> bzr's 'regular' TestCase
<vila> haa, costs a bit, well, cleanEnv I presume
<lifeless> mkdir()
<lifeless> and rmdir()
<lifeless> I'm pretty sure TestCase does the chdir and set HOME
<vila> lifeless: for tests.TestCase ?
<lifeless> yes
<vila> I don't think so, since home is under the TEST_ROOT shared by WithMemory
<vila> startLog instead
<vila> which seems wrong as many tests won't need it
<vila> I mean, it shouldn't be there or fail if we try to log anythinh
<vila> I mean, it shouldn't be there or fail if we try to log anything
<vila> that whole test/log interactions needs an overhaul anyway :-D
<vila> see the XXX in _get_log()
<vila> :-D
<vila> http://instantrimshot.com/
<vila> one more regression caught early by the test farm
<vila> FAIL: bzrlib.tests.blackbox.test_filesystem_cicp.TestMisc.test_status
<poolie> nice one
<vila> AssertionError: not equal:
<vila> a = 'added:\n  CamelCaseParent/\n  CamelCaseParent/CamelCase\n  lowercaseparent/\n  lowercaseparent/lowercase\n'
<vila> b = 'added:\n  CamelCaseParent/CamelCase\n  lowercaseparent/lowercase\n'
<poolie> i'm kind of tired and i want to stop, but i want to make 2.0b1 today
<vila> lifeless: I bet it's related to one of your latest changes but you can't run on case insensitive fs ?
<poolie> vila, do you think you could make a source tarball when pqm finishes grinding?
<poolie> oh also i was going to mention bug 409717
<ubottu> Launchpad bug 409717 in bzr "ExternalBase class is redundant" [Low,Confirmed] https://launchpad.net/bugs/409717
<vila> poolie: certainly
<poolie> and maybe ping james_w when you do?
<vila> poolie: it seems like lifeless will disagree/is working on 409717
<poolie> lifeless: bug 403360 is the report that the tests didn't clean up
<ubottu> Launchpad bug 403360 in bzr "tests don't clean up until they're all done" [Medium,Confirmed] https://launchpad.net/bugs/403360
<poolie> i haven't looked into it
<poolie> i haven't done anything about 409717
<vila> poolie: i.e. make a tarball from the 2.0 branch, upload it to lp and tell james_w about it ?
<vila> poolie: and let you do the announce email
<poolie> i wouldn't say we should certainly remove ExternalBase, but there is some misalignment
<poolie> vila, well, follow the process in the 'releasing' doc
<poolie> including bumping the version number etc
<poolie> and then send mail to bazaar@
<poolie> it doesn't take that long but it does block on waiting for pqm to finish these two branches
<poolie> assuming they all pass
<poolie> vila re ExternalBase, I think that just being able to run external commands doesn't need to be in a subclass
<poolie> saying "I need a temp directory" possibly does
<vila> I agree that cleanup is strongly needed
<lifeless> vila: I don't have a case insensitive machine handy; would a loopback vfat fs on linux work to test that ?
<garyvdm> Hi vila, lifeless
<vila> lifeless: in principle, but I'm pretty sure we use sys.platform to infer case sensisititotovity (sp? :)
<poolie> lifeless: wine would probably work :)
<lifeless> poolie: good point
<lifeless> vila: I'll see about playing around tomorrow in brain time to look at that
<garyvdm> vila: is it possible to download builds that your buildbot creates?
<lifeless> vila: unless you can track it down:)
<vila> lifeless: and I wasn't throwing stones, rather I wanted you to say,: "Oh yes, definetly, st output doesn't includes some parents anymore" :-D
<vila> lifeless: I'm tracking right away once Xchat stop ringing that is...
<poolie> ok
<poolie> that's enough for me then
<vila> garyvdm: not yet, but that's planned, I have a web page opened describing the necessary plumbing in buildbot, I need to solve some minors naming issues and more importantly get some freee time to do that
<poolie> good night
<lifeless> vila: oh no; uhm, not sure.
<lifeless> vila: I thought you meant it was a testing cleanup
<garyvdm> vila: ok - thanks
<vila> lifeless: ok, no worries, I'll investigate
<lifeless> if you want to binary search, start with the iter_changes patch
<vila> My point was: the buildbot test farm caught a *single* test failing ! Now, *that's* defect localisation :-D
<vila> garyvdm: to explain a bit more: you can't download from a slave, but a slave can upload to the master and from there we may fond a way to allow you to download
<poolie> vila, the two branches, in case they fail
<poolie> are
<poolie> http://bazaar.launchpad.net/~spiv/bzr/gc-batching-2.0
<poolie>  http://bazaar.launchpad.net/~mbp/bzr/prepare-2.0
<vila> poolie: ok
 * igc dinner
<vila> lifeless: ok, the test output was actual/expected instead of expected/actual so the question now is: "Did you make a change that will make status displays *also* the parents when adding  children ?"
<vila> lifeless: again, no worries if you can't answer, just a general feeling
<lifeless> yes
<lifeless> if the parent is changed
<Spabby> hi folks, my local tree appears to be borked, whenever I try and do anything  I get the error "bzr: ERROR: exceptions.AssertionError: name u'signapps_central_user.sqlite.THIS'  already in parent"
<vila> lifeless: oh right, 4649 NEWS entry is pretty clear :) In that specific case, the operation is a first 'bzr add' so I presume creating the parent counts as modifying it :)
<james_w> poolie, vila: I would also need to know compatible versions of plugins
<james_w> I feel like I should just upload 1.18 today rather than running around like a headless chicken trying to beat the deadline for 2.0beta
<vila> well, I think we use betas to *know* which plugins are compatible :)
<james_w> true :-)
<james_w> I won't make many friends if I upload something that breaks other things on the final day before FF
<vila> Firefox ? :-D
<vila> james_w: well, I'm not aware of any API changes at least, so I don't expect a lot of plugin breaks either
<james_w> uploading is not the way to find out though
<vila> and if *you* don't upload, nobody (or nearly) can find right ?
<lifeless> vila: it does
<vila> lifeless: context ? 8-}
<lifeless> 18:57 < vila> lifeless: oh right, 4649 NEWS entry is pretty clear :) In that specific case, the operation is a first 'bzr add' so I presume creating the parent counts as modifying it :)
<vila> ha :)
<vila> lifeless: test running
<vila> lifeless: so that's a canonical example of the benefits of the test farm: nobody can run all tests in all configs (I know we can improve things, but yet, the principle remains), the test farm caught a failure (splendid one, single failure), the NEWS entry for the offending revision gives an explanation related to the failure
 * vila takes picture, put on wall
<lifeless> vila: I think build farms are wonderful
<vila> lifeless: kudos to you for that by the way :)
<vila> lifeless: Oh I know I'm preaching the choir, I just wanted to share the pleasure :)
<lifeless> :)
<fullermd> Crazy people, those bzr folks.  They get excited when tests _fail_.
<vila> ouch, traceback while ttryinh to pull the 2.0 branch :-/
<vila> what's the flag to disable apport ?
<vila> hmm, weird, 'bzr pull' failed in a bound branch but 'unbind, pull, push, bind' worked :-/
<lifeless> vila: read only transport?
<lifeless> vila: iz bug with url normalisation
<vila> no, toomanyconcurrentrequests, the branch is pretty new (yesterday) so url norm is ruled out I think
<james_w> vila: ideally someone (possibly me) would *try* the plugins and make a best effort to check what was compatible, but that's what I mean by running around on the last day
<james_w> now, lots of us run bzr.dev + plugins, which is a good start
<vila> hmm, interesting, I have another one with almost the same setup, the difference being one has bazaar-cvs.org as parent while the other has lp:bzr/2.0 as parent,
<vila> so it may be that :parent and :bound being on the same server triggers the bug, no time to check yet though
<vila> james_w: ha ok, yes, I have a patch pending review that will allow me to include whatever set of plugins we decide in the test farm....
<james_w> nice
<vila> so far, it's running with --no-plugins (ashes on my head but the one who never sinned throw me the first stone :-)
<james_w> I'll get 1.18 in first, and if there is a beta tarball today then we can see if there is time to squeeze it in as well
 * lifeless hands vila a stone to throw at himself
<vila> lifeless: nice try :)
<bialix> lifeless: still here?
<lifeless> yes
<bialix> do you think it's possible (for me) to cherrypick your shelve fix back to 1.18?
<lifeless> yes
<bialix> I'll try
<lifeless> and the one for push ../newbranch
<lifeless> both are easy
 * bialix not ready for --2a as default
<bialix> ok, I'll try to cherrypick both
<bialix> (dreaming: will be nice to have them as 1.18.1)
<lifeless> bialix: go for it
<lifeless> I totally support you doing that :)
<bialix> 1.18.1?
<lifeless> yes
<bialix> ok
<bialix> I'll publish it shortly
<lifeless> if you ahve them in a branch of your own etc and it works
<lifeless> we can easily merge it to the 1.18 branch on launchpad - you should ahve access to do that yourself via pqm
<bialix> yes, this is my plan
<lifeless> worst case its a windows only release; but I think its important for windows users to have these fixes.
<bialix> yes
<lifeless> which is why I did them now that the problem was accessible to me :)
<bialix> you're using vila's farm or use windows machine?
<bialix> sorry
<bialix> lifeless: are you using kerguelen/vila buildbots or working on fixing this on native windows machine?
<vila> bialix: I think the devil is using wine :)
<bialix> lifeless: I should cherrypick from bzr.dev revno.4635 and 4650 only?
 * bialix hopes so
<bialix> 4635 applied cleanly
<bialix> 4650 has conflict (in NEWS -- surprise,eh?)
 * bialix found bug in replay :-/
<bialix> apparently I was wrong. There is a lot of conflicts while cherrypicking 4635
<bialix> lifeless: I'm unable to cherrypick 4635. Is it possible part of this fixed was already merged to 1.18 branch?
<bialix> part of this fixes
<bialix> the same for 4650
<bialix> it seems my bzr is totally broken
<bialix> some plugin... with --no-plugins I've got sane results
<spiv> poolie, vila: pqm tells me gc-batching-2.0 landed on 2.0 ok :)
<vila> spiv: yup, marked fixed released too :)
<bialix> oh, there is several non-trivial conflicts in tests, so I'm not sure how to cherrypick this cleanly
<lifeless> bialix: I don't know if 1.18 had the thisFailsStrict.. stuff
<lifeless> bialix: if it *doesn't* you can probably discard most of the test changes
<lifeless> bialix: or mail me/the list the conflict and I'll help you out tomorrow
<lifeless> bialix: vila: Neither; jam landed a patch to allow emulation of windows locks in the test suite.
<vila> wow, I didn't see that 8-/
<lifeless> which meants that a) I knew precisely which tests were failing, and b) I could use my standard productive environment to debug and fix
<vila> or may be I did but didn't realize the implications ...
<lifeless> so I was able to slide it in.
<lifeless> in brain-food time
<vila> brain-food ? Means short time here I presume but what is the general sense ?
<lifeless> well, food is something you need and consume
<lifeless> and for the brain
<lifeless> just bits and pieces, like first thing in the morning to warm up and get into the zone
<vila> I see, strangely nothing like that exists in french
<lifeless> its not a standard english idiom
<lifeless> its a robertism
<vila> :)
<beuno> james_w, hi
<james_w> hi beuno
<beuno> did you maange to work out all the bzr-gtk problems?
<james_w> bzr-gtk problems?
<vila> beuno: bzr-gtk problems ?
<beuno> james_w, weren't you having problems with bzr-gtk to upload all the latest bzr stuff to karmic?
 * beuno is secretly interested in loggerhead
<james_w> beuno: bzr-svn
<james_w> I thought you might be
<james_w> I'm working on it right now
<james_w> I used bzr-svn 0.6.4
 * vila relaxes :)
<beuno> right, that other jelmer thing  :)
<james_w> there was a report of it working, and any changes in trunk post that release didn't look to be compatibility fixes
<beuno> james_w, so we're good for feature freeze?
<james_w> should be
<beuno> awesome
<james_w> if people stop asking me things :-p
<vila> james_w: What do you want me to stop asking you today ?
<beuno> :)
<james_w> beuno: was the loggerhead release done from a release branch or trunk?
<vila> james_w: by the way, 2.0 tarball available
<james_w> vila: great, thanks, I'll add it to the back of the queue
<vila> james_w: sure, it's not as if I asked anything right ?
<vila> :-D
<james_w> heh
<vila> courtesy url https://edge.launchpad.net/bzr/2.0/2.0rc1
<beuno> james_w, I pushed a release branch
<beuno> and tagged trunk
<beuno> https://code.edge.launchpad.net/~loggerhead-team/loggerhead/1.17
<james_w> nice
<lifeless> james_w: we still have patches we consider critical for 2.0
<lifeless> just FYI
<james_w> sure
<james_w> but I was asked to get a beta in to karmic
<lifeless> yup yup
<bialix> vila: ping
<lifeless> just wearing my cautious hat; I doubt bzr-* that are version locked will play nice, for instanc.e
<lifeless> james_w: but while we're speaking of packaging, bzr-loom has some fixes in trunk not packaged yet, I think.
<vila> lifeless: I thought about that too, but generally they check the API and we didn't change that
<bialix> vila: if/when I cherrypick lifeless patches back to 1.18, may I ask you to run tests on win32 buildbot for me?
<james_w> "fixes" -> "talk to me next week"
<james_w> or even tomorrow
<lifeless> james_w: sure; its packaged as snapshots I think, FWIW
<vila> bialix: no, I suspended tests on kerguelen because 1) they didn't finish so we still don't know how many failures we have, 2) they run under cygwin which isn't our main target, 3) they were a nuisance for jam to build the windows installer
<vila> bialix: that being said, I still plan to install a local windows for my own needs and run the tests there until we migrate from kerguelen
<bialix> may I know more details about 1, 2 and 3?
<bialix> 2 is fixable I guess?
<vila> 1) blows up on CantCreateThread
<vila> 2) Needs a local setup to understand the issues
<bialix> 3) does jam build installers every night?
<vila> 2) is an related to buildbot
<bialix> buildbot won't work on native windows?
<vila> We *still* build the installers, we just don't run the tests :-/
<bialix> lifeless: I'm planning to cherrypick your patches without tests changes where I see conflicts
<vila> it works but the way the *service* is installed doesn't fit...
<bialix> :-/ :-/ :-\
<bialix> no means no
<vila> bialix: ?
<bialix> [15:14]	<vila>	bialix: no, I suspended tests on kerguelen...
<bialix> no means no
<vila> haa, yes :)
<bialix> I can live without tests
<vila> well, I didn't like doing that, but 1) kerguelen has limited memory and the tests were eating more than half of it, 2) 9 hours everyday to confirm that we still don't know how many tests fail was a bit too high a price :-/
<bialix> yep
<bialix> 9 hours is a bit too much
<alex-weej> hi
<alex-weej> i really like the way i can use "git checkout feature-x" to change my working directory to a new branch and continue testing my web app
<alex-weej> is there any way i can do the same with bzr?
<alex-weej> or will i have to manage some symlinks with my own scripts?
<bialix> no, you only need shared repo + lightweight checkot in bzr and then bzr switch between branches
<bialix> I guess there even was mini-tutorial on such setup
<alex-weej> there was nothing on the git user guide
<luks> I guess they don't mention much about bzr there :)
<alex-weej> btw is a shared repo one that is created by "bzr init-repo"?
<alex-weej> luks: i meant http://bazaar-vcs.org/BzrForGITUsers
<alex-weej> :P
<bialix> alex-weej: his page out of date (last changed 2007/09/28)
<alex-weej> aw
<luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#switching-a-lightweight-checkout
<alex-weej> thank you
<alex-weej> luks: so is this a good workflow in your opinion? i don't mind changing my workflow with bzr if there are better ways
<luks> I use it for every larger project in bzr
<luks> sometimes I have more than one working tree
<luks> but almost never as many as branches
<Ddorda> when i try to pull a project i get an error message. what could be the reason? http://ddorda.pastebin.com/d7d9fbc38
<luks> that your SSH key doesn't match the key on launchpad
<james_w> beuno: loggerhead uploaded
<beuno> james_w, THANK YOU
<james_w> no, thank you
<Ddorda> luks: how can i fix that?
<bialix> Ddorda: go to your personal page on LP and click on edit pen around your SSH keys; add your curent public  key there
<luks> another possibility is that your username is wrong
<luks> so try bzr launchpad-login first
<vila> poolie: I think I'm done with releasing 2.0rc1, please check :-)
<luks> wow, 2.0rc1 already and 1.8 is not even released?
<bialix> 1.18 was secret release
<bialix> https://launchpad.net/bzr/+download
<luks> heh
<vila> luks, bialix : They share the same RM :)
<bialix> they?
<luks> so you are now at 0 days release cycle?
<vila> 1.18 and 2.0
<luks> that's super-fast development
<vila> luks: 1.18 is about to be released, 2.0 is only at the rc stage
<bialix> vila: but announce for 1.18rc1 was never made
<vila> we need a 2.0beta into karmic
<vila> 1.18rc1 was announced, I just copied the mail to announce 2.0rc1...
<vila> 1.18 is yet to be announced
<bialix> 1.18rc1 -- I never seen announce
<luks> ah, couldn't you get 2.0 it in without this "cheating"?
<vila> that's because we've changed the process a bit so that installers can be ready when the announce is official
<vila> luks: that's not cheating, that the way it was planned
<vila> karmic is not released either see ?
<luks> vila: it just feels weird
<vila> luks: do you use Ubuntu ?
<luks> yes
<vila> which version ?
<luks> 8.04
<bialix> luks: new evil plan is to release once at 6 months, so 1.17 was release in June, so 1.18 will be around new year :-D
<luks> that's cool
<vila> luks: yet, many people are running 9.04 and some are already running 9.10...
<james_w> bzr-gtk uploaded
<vila> james_w: yes by me, yesterday
<james_w> no, by me today, to karmic
<james_w> :-)
<vila> james_w: yes by me, yesterday including karmic, sync ?
<luks> vila: I know, but seing two releases in the same day is pretty rare
<james_w> I think that's all in order to get us a consistent stack for 1.18
<vila> james_w: forget me, I was talking about ppas
<james_w> ah
<vila> james_w: hence my 'builddeb rocks' yesterday,
<james_w> ah, cool :-)
<vila> james_w: if you find I made a mistake, please, please, report, I added jaunty and karmic, stop producing for gutsy and feisty, without any real discussions, so any feedback will be warmly welcomed (no urgency though, you have enough to do :)
<james_w> I think that's a good plan
<james_w> they are EOL anyway
<james_w> not worth the effort
<vila> james_w: I'm unclear about deleting the remaining packages for edg, feisty and gutsy in https://edge.launchpad.net/~bzr/+archive/ppa
<vila> I can't imagine who will need them, but ignorance happens everyday :)
<james_w> vila: there's little cost to having them there, but then there is little benefit, so I don't really have an opinion
<vila> james_w: ok, I lightly prefer having a clean plate so nobody wonders why that's the only package for these distros...
<james_w> yeah
 * vila enjoys the silence brought by DOWNgrading its graphic card to a fan-less one ...
<vila> Now, only --parallel=fork starts the fans :-D
 * pygi sets some fire near vila's house...
<vila> pygi: hehe, I still have the laptop.... which just became the noisiest around here when the fan speed is above 4000rpm...
<pygi> vila, ^_^
<emmajane> beuno, ping?
<beuno> emmajane, good morning
<emmajane> beuno, morning! :)
<emmajane> PM?
<jam> vila: morning
<jam> I just submitted: https://bugs.edge.launchpad.net/launchpad-code/+bug/419252
<ubottu> Launchpad bug 419252 in launchpad-code "merge proposal threads have different headers" [Undecided,New]
<jam> I was wondering if you could confirm the email headers I'm seeing.
<vila> morning jam !
<vila> I replied via the web
<vila> but my threading is perfect :)
<jam> do you see different mail headers?
<jam> subject lines
<vila> jam: wow, rectification: *my* threading is broken too of course, see comment on bug
<jam> ah, so it is probably reply-to-comment versus add a review sort of thing?
<jam> vila: thanks for helping track it down
<jam> I've seen it before, and it is quite annoying
<vila> it's higly misleading indeed, I have no idea where the subject is coming from for *my* mail !
<vila> jam: Oh, I see we make the same jokes in addition to making the same reviews :)
<jam> vila: so why did we go with rc1 rather than b1 ?
<vila> jam: :my mistake ?
<vila> jam: I followed releasing.txt and missed a part ? Missed a reference ?
<vila> cycle.txt mentions 2.0rc1, rats, I used 2.0rc1 released instead of available :-/
<vila> well, still haven't been a true RM haven't I ? :)
<vila> but I think that 2.0beta1 will be *released* later anyway so I wasn't wrong on the naming, or was I ?
<vila> jam: ^
<jam> vila: it would be 2.0beta1-rc1 in that case
<jam> but we are switching to the 'new' layout, I thought
<jam> where we don't do rc's for beta releases
<vila> then I goofed :-/
<jam> vila: question about mainline parent ghosts and merge_sort
<jam> if you have ghost => A => B
<jam> should A be revno 1 ?
<jam> (that is the best I could come up with...)
<vila> strictly speaking you know it *can't* be one since there is a ghost...
<vila> so it should be 2
<vila> jam: I'm unclear about deleting the remaining bzr-gtk packages for edgy, feisty and gutsy in https://edge.launchpad.net/~bzr/+archive/ppa
<vila> what do you think ?
<jam> vila: I wouldn't delete packages
<vila> jam: ok, sold, I didn't but was unsure, james_w agree with you, 3/0, they stay, my only problem is that it's a bit unclean as we don't have corresponding bzr packages to go with
<jam> vila: then obviously someone else doesn't agree with not deleting packages
<jam> :)
<vila> err, no we all agree to keep the packages
<vila> or are you just joking ? :)
<jam> well, I'm guessing that poolie deleted the old packages
<jam> so he obviously would disagree (at least a little)
<jam> so.. I wouldn't delete them *yet*
<jam> but we should think about it
<vila> ha !
<vila> ok, get it :)
<vila> Now that you mention it, I seem to recall poolie talking about deleting them, so we'll see if he read the highlights in the IRC logs :)
<jam> vila: what is the branch in lp?
<vila> lp:bzr/2.0 ?
<jam> k
 * jam wonders how we'll do it with on-going beta branches, etc.
<jam> and the final stable branches
<vila> I'd say betas will come out one at a time from lp:bzr/2.1 and lp:bzr/3.0
<jam> vila: that isn't how we do it today... but perhaps
<jam> I kind of like having a separate branch per official release
<vila> we don't have a lp:bzr/1.18rc1 AFAIK
<jam> but I guess we aren't planning on doing point releases from any of the betas
<jam> vila: rc != beta
<vila> jam: look at cycle.txt may be ? It sounds that a single branch is enough for each serie
<vila> I'm talking about the scheme in the Schedule section
<hno> A little question related to the 2.0rc1 release. Will there be a bzrtools release matching this shortly, or do the 1.18.0 bzrtools release work with 2.0rc1 as well?
<hno> and related to this, is bzr 1.18 released or not? It's uploaded in launchpad, but bazaar-vcs webpages and this channel topic seems to say it's not released..
<jam> hno: we have a new policy of not making the official announcement until all plugins/installers/etc have been built
<hno> jam: that's regarding 1.18 right?
<jam> hno: yeah. I'm pretty sure it is 'all released' but last night not all the packages had been made
<hno> jam: So it should be fine if I go ahead and get it packaged for Fedora I guess.
<jam> vila: also, you seem to have sent the announcement to 'bzr-announce' which I thought we were waiting for packages to do
<jam> hno: the tarball is the 'official' release, yes
<jam> Consider it "gone gold" versus "at the publishers"
<vila> releasing.txt :
<vila>    For release candidates, this is sent to the ``bazaar-announce`` and
<vila>    ``bazaar`` lists.  For final releases, it should also be cc'd to
<vila>    ``info-gnu@gnu.org``, ``python-announce-list@python.org``,
<vila>    ``bug-directory@gnu.org``.  In both cases, it is good to set
<vila>    ``Reply-To: bazaar@lists.canonical.com``, so that people who reply to
<vila>    the announcement don't spam other lists.
<jam> hno: and bzrtools 1.18 will explicitly not work with 2.0. abentley has code in bzrtools that checks the version string and refuses to run if they don't match
<jam> vila: 1) this wasn't supposed to be an rc
<vila> rats, forgot the reply-ti :-(
<jam> 2) I think we are changing that policy
<jam> at the minimum, though, we aren't sending "announce" until we have packages
<igc> vila: new docs built, packaged and uploaded for 1.18 and 2.0rc1
<igc> vila: the current bot is called igc til we get an RT request done :-(
<vila> igc: bot ?
<igc> well 'cron job'
<vila> haaaa
<hno> jam: So the 2.0rc1 isn't an rc?
<igc> anyhow, time fro bed
<igc> night all
<vila> sleep well igc, I'm almost EODing myself
<jam> hno: so.... in *my* opinion, rc1 means we expect 0 changes before turning this code into -final
<jam> and I don't think the current release is at that point
<vila> when jam had finished listing all my mistakes in that 2.0rc1 release :)
<jam> Maybe Martin decided otherwise overnight and told that to vila without telling me
<vila> jam: nope, martin told me: I'm tired but I want that relase to be out today, can you help
<jam> vila: so... I can't package the windows installer until the plugins have updated to 2.0-X, which means we should 'announce' the full release until after everything has been brought up to date
<jam> so we should make an bazaar@ posting that the code is frozen and available
<vila> yes, we should release 1.18 first
<jam> and get people to catch up, build installers, etc.
<vila> I understand we needed 2.0 to enter karmic asap
<vila> so let's forget about 2.0 until the *official* RM for both 1.18 and 2.0 clears my mistakes :)
<hno> The window for Fedora-12 is also relatively short (weeks).
<vila> hno: we're talking days or hours here, the RM is in AU TZ
 * vila chuckles AU RM TZ, how about obscuring via acronyms...
<hno> wasnÂ¨t obscure to me.
<vila> hno: I was thinking about an outsider trying to catch up the thread... poor guy :-/
<jam> vila: and he is in EST (AEST) which doesn't help
<jam> EST == New York time, *and* Australian Eastern (sydney) time.
<fullermd> It's not a REAL timezone unless it has a 15 minute offset...
<jam> fullermd: I'm pretty sure AU has one of those, too
<jam> AIUI, they have 9 different timezones in the summer, and 5 in the winter
<vila> jam: who is in EST ?
<fullermd> Yah.  AU and somewhere in SE Asia I think.
<jam> vila: The official abbreviation for the time zone in Sydney is "EST"
<hno> SE is here... donÂ¨t think we have an Asia region in SE.
<jam> though for sanity purposes, Martin calls it AEST
<jam> I think it might be Eastern Standard versus Eastern Seaboard or something silly like that.
<jam> vila: Google just claims Sydney == UTC+10: http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=lY0&q=time+zone+sydney&aq=f&oq=&aqi=g7
<jam> however:
<jam> http://www.timeanddate.com/worldclock/city.html?n=240 says "EST"
<jam> vs
<jam> http://www.timeanddate.com/library/abbreviations/timezones/na/est.html
<jam> which also says EST and is New York (ish)
<Tak> imo the only reasonable abbreviation for timezones is UTC+-N
<hno> Tak: +/-NNNN in such case...
<jam> Tak: given that there are 15min offset timezones...
<Tak> I meant to indicate N as a number, rather than as a character ;-)
<vila> UTC+4h15
<jam> vila: UTC+4.25
<vila> jam: tsk tsk, too easy
<hno> jam: UTC+0425 usually...
<jam> hno: 0415 actually
<jam> it is base 60 not 100
<hno> right.
<hno> whoever came up with base 60 for time... most of us have 10 fingers..
<jam> vila: UTC+4.4h ?
<jam> 2*3*4*5 = 60
<jam> it is the smallest number that is evenly divisible by 2,3,4,5,6
<lfaraone> Hey, a git import in launchpad failed with this traceback: http://launchpadlibrarian.net/30852208/rainbow-olpc-mstone-trunk-log.txt
<lfaraone> Is this a bzr bug?
<jam> I personally prefer base 12, but its never caught on
<jam> lfaraone: most likely a bug in bzr-git, but I don't really know for sure
<lfaraone> jam: mkay.
<vila> I recently read a funny explanation for base 60: you count 12 via 3 points on each finger (can find the english word for french phalange) and then 5 fingers on the other hand
<hno> bzr 1.18 will hit Fedora-11 testing tomorrow I hope.. still building.
<jam> vila: interesting.
<vila> of course bases 12 and 60 are far more useful than 10 because you can divide by 2/3/4/5/6 (well not 5 for 12 but you get the idea)
<jam> I've usually counted to 10 on one hand
<jam> using the thumb as a pointer for >5
<jam> which makes it pretty easy to count to 100 on two hands
<jam> I've never really successfully counted in binary to get to 1024
<jam> fingers just don't bend that way easily :)
<jam> vila: yeah, it is a shame we weren't born with 12 fingers :)
<jam> It actually was the one thing that is somewhat nice about the US inches to feet.
<jam> It is very easy to cut 1 foot into 3rds
<jam> Which I've done far more often than cutting into 5ths
<jam> 1/2 and 1/5ths is all metric is really good at, without getting repeating decimals :)
<vila> there were other articles about the romans counting up to hundreds of thousands with various finger gestures
<vila> and some others about base 20 being popular using fingers and toes...
<jam> vila: I can count in the hundreds of thousands. just not with 1 digit precision :)
<vila> jam: they had a way to express such numbers with all digits in several gestures, but they didn't use positional numeration (sp?) so they had special gestures for higher numbers
<vila> what surprised me was that I thought they couldn't go higher than M, were in fact, even in the written form, they could
<vila> oh, and another funny one was about the chinese having special ideograms for bank accounts to fight counterfeiting (sp ?)
<jam> vila: https://code.edge.launchpad.net/~jameinel/bzr/2.0rc2-419241-merge-sort/+merge/10755 if you get a chance
<vila> not today, I'm crashing :-)
<jam> vila: hmm.. I wonder about finger positions for roman numerals
<jam> vila: critical segfault in the  2.0 release
<jam> 'bzr log lp:~jameinel/bzr/2.0b1-stable-groupcompress-order -n0 -r -20..-1' segfaults
<vila> you ran 'make' ?
<jam> vila: I wrote the code
<jam> I know the segfault
<jam> fixed in attached
<jam> though there is still a critical regression, at least it doesn't segfault
<vila> jam: couldn't you be more daggy than 2.0 ?
<hno> Ok. I won't package 2.0rc1 today
<jam> vila: for what purpose? The code is only in 2.0 or trunk
<jam> wasn't in 1.18
<vila> ok, wasn't sure
<vila> jam: the only worrying line is the deleted parents = self._original_graph[node_name]
<vila> jam: reviewing online I miss the context
<jam> vila: parents is passed into the function
<jam> it was a bit bogus to re-read it from the dict
<vila> ok
<jam> I've been meaning to clean that up for a while
<vila> approved then
<jam> argh...
<jam> robert's fix for "bzr selftest -s bt" isn't in 2.0
<vila> I'm sure we can backport that one :)
<jam> I just sent in the MP so that we don't forget about it
<vila> james_w: I love that feature :)
<vila> err, sorry james_w that was for jam :-/
<vila> stupid xchat
<vila> jam: hehe, not all things went wrong finally, my message to @announce is waiting approval :)
<vila> jam: was waiting, cancelled now :)
 * vila really EODing
<jam> vila: ok. I'll have another patch for the rest of the regression, but that can be handled by Martin et al
<mthaddon> anyone able to tell me how do to figure out how many packs and indices a branch has (per https://bugs.edge.launchpad.net/launchpad-code/+bug/416990/comments/3)?
<ubottu> Launchpad bug 416990 in bzr "Memory usage of codehosting processes is excessive" [High,Confirmed]
<mthaddon> nm
<cellofellow> I was just wondering if there was a way to put the bzr revision number into the code, in a comment particularly.
<jam> mthaddon: ll .bzr/repository/{packs,indices}
<jam> should be even able to do that over http
<mthaddon> thx jam
<jam> mthaddon: I suppose the most accurate is to check .bzr/repository/pack-names in case some packs aren't referenced
<jam> but that depends on the branch format
<jam> (older formats is just 'cat', newer ones 'bzr dump-btree --raw .../.bzr/repository/pack-names')
<jam> well repo format i guess :)
<beuno> igc, spelling mistakes have not been fixed because I'm using up the designers time to do design changes
<beuno> emmajane can pick it up after we finish with the graphical part of it, and tweak
<emmajane> beuno, I just got back in from lunch and am reading backwards in time. :)
<emmajane> igc, yeah. No worries about the spelling mistakes. That's easily fixed.
<emmajane> beuno, I think the shuffling that is being suggested would be remedied if the banner had more breathing room and there was a more obvious "in" for each of the top four sections.
<emmajane> beuno, In my response I think I'd recommended that the list of links be reduced to a single button or graphical entry point to those four topics?
<beuno> abentley, a single button for all the links?
 * emmajane blinks.
<emmajane> that was for me?
<abentley> beuno: I throw my blind support behind the Canadian.
<emmajane> LOL
<beuno> argh
<beuno> :)
<emmajane> abentley, thanks :)
<beuno> damn
<beuno> emmajane, yes
<beuno> tab FAIL
<emmajane> abentley, I owe you beer :)
<abentley> emmajane: Sure, we can hang out with William next time you're in the T dot.
<emmajane> abentley, that'd be most excellent!
<beuno> mwhudson, btw, while you where away, I did an emergency release of Loggerhead
<beuno> to get it into karmic
<emmajane> beuno, yeah, a single button that leads to essentially a second "home" page for each of those topics.
<beuno> emmajane, wireframe?
<emmajane> beuno, there's *so*much* right now on the front that it doesn't direct the eye to click *somewhere*
<beuno> it's the fastest way to communicate  :)
<emmajane> ah
<emmajane> ok.
<beuno> emmajane, remember when I said taht it was too much information?
 * beuno is a sucker for "I told you so"'s
<beuno> :)
<emmajane> beuno, but I said the list of links could be dropped to a single icon into a page BEFORE you started with the designer.
<emmajane> beuno, then I said it as feedback.
<beuno> ah
<beuno> ok
<beuno> I take it back then
<emmajane> beuno, you're just ignoring me so taht you can be right. ;)
<emmajane> Can I save stuff on the web version of http://www.balsamiq.com/?
<beuno> my brain tends to do that
<emmajane> hehehe
<beuno> emmajane, I don't know. But if you can export the bmml file, I have a full version
 * emmajane gives it a try.
<emmajane> beuno, http://pastebin.ubuntu.com/259976/ see if that works?
<emmajane> it's just "above the fold"
 * beuno tries
<emmajane> (if I'd had more time the boxes would ahve been the same size)
<emmajane> I was just trying to mash out something to see though :)
<emmajane> beuno, not sure if that worked?
<jjack86> are there any known issues with using the bzr server across linux / windows?  I'm having a heck of a time getting going -- I can "bzr checkout bzr://yadda-yadda" just fine from linux to linux, but my windows machines seem to just hang with the same command
<emmajane> jjack86, any chance the windows machine has a port closed or some other weird windows-specific restriction?
<beuno> emmajane, it did
<beuno> thanks
<beuno> I'll get another revision with this cahnge
<jjack86> i turned off my firewall to no avail, don't know where else to look (windows 7)
<emmajane> beuno, do you want me to follow up to igc's email as well?
<beuno> emmajane, please
<emmajane> beuno, will do right now.
<emmajane> jjack86, hrm. I'm not entirely sure. I haven't used Windows in a while.
<LarstiQ> jjack86: does networking to the server work at all?
<jjack86> I can ssh with putty to the bzr server just fine
<jjack86> and bzr checkout doesn't work from a windows xp machine either, fwiw
<Tak> bzr co WorksForMe on windows (bzr 1.17)
<emmajane> jjack86, you said it just hangs?
<Tak> this is with lp, sftp, bzr+ssh, and bzr-svn
<emmajane> jjack86, is there anything on the server side that shows an incoming request?
<LarstiQ> jjack86: does the bzr.log provide any helpful info?
<jjack86> yeah, it hangs, and when I break off the connection, the server throws some 'error connection closed' messages -- can you tell me where the log file is located by any chance?
<LarstiQ> jjack86: bzr --version should mention that
<jjack86> ty
<LarstiQ> jjack86: both server and client have a log, but I meant the windows client in this case (doesn't hurt to look at the other one too)
<emmajane> beuno, sent! hopefully that makes more sense... :)
<awilcox> Hello.  I was wondering if anyone has ever successfully versioned /etc in a Bazaar repo.  I have tried but I'm still relatively new to Bazaar and I haven't been successful.  I've also googled around and found nothing.  I would appreciate pointers?
<emmajane> awilcox, do you know about etckeeper?
<emmajane> awilcox, It does exactly that. :)
<emmajane> awilcox, http://joey.kitenet.net/code/etckeeper/
<awilcox> emmajane: I have read about etckeeper but I would like to keep *all* my servers' (I have about 15) /etc's in one central repository.  (In fact I have made an (approved) repo called "servconf" on the central code server.)  It didn't look like etckeeper did that; it seemed to make /etc a repo itself.
<emmajane> once you have one server using etckeeper you've got a bazaar branch that you can share with other machines...
<awilcox> I'm also using FreeBSD while this looks very linux-specific.
<Tak> one place I worked had all the /etc on an nfs mount
<emmajane> awilcox, Bazaar is "just" python. anything that can run python can run Bazaar.
<awilcox> emmajane: I meant etckeeper.
<emmajane> awilcox, it will version any folder you tell it to.
<awilcox> My code repo is on FreeBSD :)  I also do my development on OS X and Windows in addition to FBSD
<emmajane> awilcox, it'll even do /user/home if htat's what you want
<lifeless> moin
<mwhudson> beuno: i saw that, thanks a lot!
<mtaylor> lifeless: you wake up entirely too early in the morning
<lifeless> I do I do I do I do...
<lifeless> jam: you'll have to explan to me why you say commit doesn't have tests about the file graph
<jam> lifeless: it obviously didn't have a test under the particular circumstances...
<lifeless> jam: it did the right thing given the data the api gave it
<jam> lifeless: record_iter_changes behaved reasonable wrt path_content_summary
<jam> commit was still wrong
<lifeless> record_iter_changes doesn't use path_content_summary
<jam> record_entry_contents
<jam> sorry
<jam> lifeless: so can you point me to the test that asserts only X texts have been added?
<lifeless> I must be missing something here
<jam> I'm happy to verify
<lifeless> per_repository.test_commit_builder - grep for 'unchanged'
<lifeless> those tests assert that the inventory entry gets the original last-modifying revision id
<lifeless> in non merged, merge-collapsing etc corner cases
<lifeless> they build on the assumption that the tree api isn't damaged
<lifeless> I'm not sure that passing in a damaged path_content_summary tuple could be expected to do anything other than record_entry_contents did
<jam> lifeless: so... perhaps I'm wrong, but _commit_check_unchanged looks to be doing a no-op commit and asserting that nothing has changed
<jam> it doesn't seem to be an edge case
<lifeless> test_last_modified_revision_after_converged_merge_dir_unchanged
<lifeless> etc
<jam> rev1 = tree.commit(); rev2 = mini_commit(), rev1.inventory[file_id] = rev2.inventory.file_id
<lifeless> test_last_modified_revision_after_converged_merge_file_unchanged
<lifeless> yes, no op commit is one of the corner cases
<lifeless> remember that record_entry_contents hits every entry, so its entirely possible to have it spuriously record the entire tree
<lifeless> if not tested
<Wurblzap> Hey there... I don't seem to get Bazaar's --fixed functionality to work. I added a bugtracker_xyz_url line to branch.conf, but I keep getting my commits with "--fixed=xyz:123" refused because of "Unrecognized bug". Do you have a pointer for me?
<jam> lifeless: I'm trying to figure out if this line is a bug:
<jam>         def _check_graph(in_tree, changed_in_tree):
<jam>             rev3 = mini_commit(in_tree, name, 'new_' + name, False,
<jam>                 delta_against_basis=changed_in_tree)
<jam>             tree3, = self._get_revtrees(in_tree, [rev2])
<jam> shouldn't that be tree3 = ...[rev3] +
<jam> ?
<lifeless> let me look
<jam> also, the way you do "expected_graph" isn't quite right
<lifeless> Wurblzap: hi, uhm.
<jam> you pass it the tip you want it to expect
<jam> and then make sure that things are correct
<jam> however, if you were to add (file_id, rev3) to the graph
<jam> we wouldn't know
<jam> because it wouldn't be an ancestor of (file_id, rev2)
<lifeless> Wurblzap: try putting it in bazaar.conf
 * Wurblzap tries
<lifeless> Wurblzap: it may be a bug in how we find the config
<jam> (I'm not saying that the code would have been able to catch the issue. I *am* saying that it doesn't seem to actually be asserting that we didn't create a new node.)
<lifeless> Wurblzap: did you put in the {id} bit?
<Wurblzap> Yup
<Wurblzap> Don't start bug hunting just yet, I'm using 1.11rc1
<lifeless> oh ok.
<jam> Wurblzap: I assume you got this from "bzr help bugs" ?
<Wurblzap> No, from doc/en/user-reference/bzr_man.html
<jam> Wurblzap: k. I think that is taken from the other anyway
<lifeless> jam: so, these tests got quite archaic, its entirely possible there are bugs. They have caught bad graph output from commit many times for me though.
<lifeless> jam: re: adding file_id, rev3 - we don't care if thats added do we? as long as its not referenced by the entry it won't get copied...
<jam> lifeless: seems like a good way to introduce bugs
<jam> like the one where we reference a text that isn't referenced by the original inventory
<Wurblzap> Yeah, lifeless, it works if it's in bazaar.conf
<lifeless> jam: how do you mean?
<jam> lifeless: having a text key in the repository that is pointed to by the index doesn't seem like a good thing
<lifeless> Wurblzap: you might like to try bzr 1.18, and if that doesn't work in branch.conf file a bug.
<jam> it doesn't seem critical if it isn't referenced
<jam> but it may not be referenced in X, but *is* referenced by Y
<jam> and we just didn't think to check both
<Wurblzap> All right. Thanks, lifeless.
<jam> (say in the dirstate cache, but not in the committed revision inventory)
<jam> so I sort of do care that it isn't written to the repo
<jam> as then I'm more sure that it won't be referenced anywhere without that location blowing up
<lifeless> jam: so, I think that if we care if its written we have other bugs - design ones even
<lifeless> All we should care about is the reference that is made by the commit code - other people only get references from commit
<jam> lifeless: I would care if every commit generated a new text for every file in my tree that was just never referenced
<lifeless> jam: If the disk store that that environment had was a git layout, you wouldn't care
<lifeless> because those references would be to the hashed unchanging versions
<jam> lifeless: if it wrote new blobs I would
<jam> and it still bloats the index severely
<jam> which is the whole problem that caused Frits to even really notice
<jam> 700k entries in an index for 20k changes isn't a good thing
<lifeless> I may be unclear on something
<lifeless> were his inventory entries bogus?
<mthaddon> jam: can you talk me through the process of debugging the command run against one of these lp-serve processes that you describe in the bug?
<jam> lifeless: I'm saying that bloating the indexes is bad, regardless of whether it is referenced from the inventory
<jam> mthaddon: I'm honestly not sure how to do the debugging in your environment, but I can gi
<jam> give some ideas
<beuno> emmajane, the tabs on your mockup, don't need to be tabs, do they?
<lifeless> mthaddon: you don't want to do this on a live server
<emmajane> beuno, nope
<lifeless> mthaddon: it will freeze the process while you do it and may cause disconnects
<jam> lifeless: consider that we changed 'pack' to always copy all references from the index
<mthaddon> lifeless: ah, okay
<emmajane> beuno, I was just looking for the shape that meant what I said.
<jam> which means that these don't go away
<beuno> emmajane, cool. Just handed over the changes, crossing my fingers
<mthaddon> lifeless: in that case, I think I'll leave it to one of the lp-bzr devs
<emmajane> beuno, thanks :)
<lifeless> mthaddon: we should simply be using these questions as things to get codehosting logging. (And I filed bugs in this space some time back)
<mthaddon> lifeless: since they now know which branch it is, should be able to reproduce
<beuno> emmajane, and we'll probably want to take it to the public list from now on
<emmajane> beuno, that's fine.
<lifeless> what I'd like to know is what format its being pulled into
<lifeless> doing data-conversion on the fly is a likely candidate for that footprint IMO
<lifeless> jam: well, pack with no revspec always copied all indexed items.
<jam> why am i seeing 3 calls to get_tags_bytes() .....
<jam> lifeless: sure.
<lifeless> jam: fetch() however was never meant to copy all index items.
<jam> which means... it would be carried around
<lifeless> jam: and IMO its a pretty bad bug that it does because it means private data can be exposed
<mthaddon> lifeless: how would you know what format it's being pulled into?
<jam> so... to say "I don't care" is false
<jam> I don't care a lot about a small amount of extra
<jam> I care a lot about a *lot* of extra
<lifeless> jam: were his inventory entries bogus?
<jam> lifeless: bogus in what sense?
<jam> rev1.inventory[file_id] == rev2.inventory[file_id] except for last-modified-revision
<jam> so the inventory referenced a text key which was added to the repo
<lifeless> jam: the tree3=...[rev2] thing isn't a bug, but its horribly unclear
<lifeless> jam: ok, so the inventory entry was wrong
<jam> lifeless: why do you commit rev3, but never look at it?
<lifeless> what line are you looking at
<jam> lifeless: 1065
<jam> rev3 = mini_commit(...)
<lifeless> k
<jam> and rev3 is never mentioned again
<jam> lifeless: in your hpss streamlining work, did you notice that get_tags_bytes is being called repeatedly and getting the same result each time?
<lifeless> yes
<jam> in poking around at mthaddon's stuff, I just noticed that
<lifeless> branch lock being dropped to zero
<lifeless> discards the cache
<lifeless> got pulled over to the 2a crunch though before fixin
<jam> sure
<jam> as long as it isn't something new I'm finding
<lifeless> can be the client too
<jam> lifeless: bzr.dev + bzr.dev for my testing
<lifeless> ok
<garyvdm> Hi all
<lifeless> so, I'm struggling to explain rev2 there
 * garyvdm is looking for bialix
<lifeless> I'll poke at this
<jam> garyvdm: I don't think bialix is usually on at this time... but you might get lucky
<lifeless> jam: its a bug;
<lifeless> jam: but only on that line; the rest of _check_graph is correct
<jam> interestingly, during the fetch, memory consumption is pretty steady until 375s into the fetch, when it starts growing, and it grows until the fetch completes at 560s. (from 75MB to 178MB.)
<lifeless> as we're testing it didn't add an entry
<jam> lifeless: right, so  I think you are trying to test that tree3.inventory[file_id].revision == rev2
<jam> and that the graph ancestry of rev2 is correct.
<jam> though I almost think you are trying to test that the graph ancestry should also not have a rev3 in it
<jam> but can't test that easily, because you can't use it if it isn't there...
<jam> I do wonder if assertFileGraph should be using iter_ancestry()...
<jam> lifeless: anyway, back to the original question. I didn't realize that there was at least some level of this testing. Which is good to be wrong about. :)
<jam> though they are pretty hard to read and understand tests...
<lifeless> yes
<lifeless> this was written when we had a merge convergence bug many years ago
<lifeless> I was 'dammit I'm going to stomp this out'
<jam> lifeless: the flip-flopping issues, etc?
<lifeless> yes
<lifeless> "failure to converge"
<lifeless> [think Mao]
<lifeless> jam: so, back to the commit issue
<lifeless> I agree that adding huge numbers of unreferenced objects is undesirable; however thats not what happened here.
<lifeless> we added huge numbers of referenced objects
<jam> lifeless: right
<lifeless> I don't think we should pin down at the *interface level* whether unreferenced objects are used or not.
<jam> you said "do I care if unreferenced data gets writteN"
<jam> I care if *lots* of unreferenced data gets written
<lifeless> I'm totally open to writing non-interface tests about unreferenced data being written.
<lifeless> But I don't believe its part of the contract
<jam> lifeless: it would seem to be part of the contract for all currently-implemented formats...
<lifeless> jam: which contract
<lifeless> I'm talking about the interface, which bzr-svn also implements
<jam> lifeless: all currently implemented repository formats don't add unreferenced text nodes to the index
<lifeless> I don't think its appropriate to test *at the interface level* that that is the case
<jam> lifeless: and bzr-svn doesn't pass per-repository tests anyway
<jam> lifeless: And I would bet that we wouldn't want to write a new format that *does* do that
<lifeless> I should have the freedom to drop in an implementation that does things radically differently and passes
<jam> so it seems a bit weak to say it isn't an valid interface contract
<jam> lifeless: I think a reasonable part of the contract is that I won't grow grossly out of the order of actual content that you are versioning
<lifeless> jam: I'm not saying we shouldn't have [some] tests, I'm saying I don't think its part of 'the inventory entries generated by commit are X, Y and Z and have valid references' contract.
<jam> it is sort of a hard-to-pin down statement
<lifeless> add to that that its proving a negative
<jam> sure
<jam> which is part of the problem
<lifeless> A misbehaving implementation could add newrevid-RANDOM nodes to the index
<jam> we have a lot of aspects that we don't test...
<lifeless> and not reference them
<jam> lifeless: you could check that the index only has 3 nodes
<lifeless> they could make a new index
<jam> lifeless: so we have some holes when it comes to our testing wrt negatives...
<jam> like not fetching 5MB when you should only fetch 10k
<lifeless> jam: if we wanted to write a test that all our built in repositories don't write (fileid,NEWREVID) for these cases, I'd be fine with that.
<jam> I realize that the particular circumstances with content filters is fairly specific, and hard to predict ahead of time
<lifeless> jam: btw 1.9 to 1.9 fetching, does it use the generic codepath now?
<jam> lifeless: I don't believe so
<jam> that would have been spiv's change, though
<jam> not mine
<lifeless> jam: my assertion about content filters is that it was testing coverage with the tree interface that lacked
<jam> hmm....
<lifeless> jam: if we'd insisted on a parameterised version of per_workingtree for content filters - which would be a time consuming change - we would have caught this easily.
<jam> lifeless: after the transfer has completed, the process still has 230/299MB of in-use ram.
<lifeless> and realised we need to make 'size able to be None'
<lifeless> and then gone to the test_commit_builder tests and tested that combination
<jam> lifeless: sure, though stacked branches suffered a lot of similar issues
<lifeless> yup
<jam> in that we don't have a 'per' on them
<lifeless> hindsight in both cases
<lifeless> I'm trying to formulate something I can be stubborn about with the next orthogonal-but-not-really feature
<lifeless> to help us prevent this sort of surprise
<jam> lifeless: where do you think would be good to make "Repository.get_stream" a little less opaque
<jam> right now if I use -Dhpss
<jam> I get about 4 lines
<jam> 0.428  hpss call w/body: 'Repository.get_stream'
<jam> 15.000     result:   ('ok',)
<jam> 554.473  creating branch
<jam> make a request
<jam> it returns in 15s
<jam> and 500s later I'm ready to create the branch
<lifeless> -Dhpssdetail
<jam> rather opaque
<thumper> abentley: ping
<jam> lifeless: doesn't add much. Or are you saying that if I add debug statements I should use that category?
<lifeless> jam: hmm, it should be reporting all the items
<jam> lifeless: there are other bits
<jam> my point is that get_stream( ) is 500 / 510s
<jam> and it only merits about 3 lines
<lifeless> hpss_detail should be printing
<lifeless>               %d byte part read', len(bytes_part))
<jam> just that it is streaming something for the bulk of the time
<jam> ugh
<jam> network glitch
<lifeless> hpss_detail should be printing
<lifeless>               %d byte part read', len(bytes_part))
<jam> sure I do see that
<lifeless> I'd also consider -Dfetch
<lifeless> if you want details on the bits inside the stream
<lifeless> [you may need to patch stuff up for that one]
<jam>  grep -rnI "fetch.*debug" bzrlib/
<jam> returns nothing
<jam> so I'm pretty sure -Dfetch isn't going to help (yet) :)
<lifeless> it used to :P
<lifeless> -Dstream too
<lifeless> that should be s/stream/fetch IMO
<jam> of course, I'm more interested in the server than client side...
<jam> lifeless: something seems wrong with -Dstream
<jam> 15.046  inserting substream: revisions
<jam> 15.048  inserting substream: revisions
<jam> 15.049  inserting substream: revisions
<jam> 15.049  inserting substream: revisions
<jam> 15.049  inserting substream: revisions
<jam> 15.050  inserting substream: revisions
<jam> 15.050  inserting substream: revisions
<jam> 15.050  inserting substream: revisions
<jam> 15.051  inserting substream: revisions
<jam> 15.051  inserting substream: revisions
<jam> 15.052  inserting substream: revisions
<jam> 15.052  inserting substream: revisions
<jam> 15.052  inserting substream: revisions
<jam> 15.053  inserting substream: revisions
<lifeless> I think that shows the point :P
<jam> 15.053  inserting substream: revisions
<jam> 15.053  inserting substream: revisions
<awilcox> someone hit paste...
<jam> sorry about the spam
<lifeless> its getting lots of little substreams
<lifeless> probably the batch size of knit reads
<abentley> thumper: pong
<jam> lifeless: http://paste.ubuntu.com/260064/ would lead me to believe that every record is being treated as a separate stream
<thumper> abentley: I wanted to talk to you about pipelines again
<thumper> abentley: I'm in a similar situation to last time
<abentley> thumper: It's not a good time right now.  Making supper.
<thumper> abentley: ok, will talk later
<lifeless> jam: thats possible
<beuno> jam, lifeless, while branching LP locally into a shared repo, I'm getting the CPU thrashed, as well as ~500mb of CPU usage
<beuno> 70.735  creating new compressed block on-the-fly in 0.000s 2645 bytes => 428 bytes
<beuno> that's the last output, something like 2 minutes ago
<lifeless> beuno: do you have the C extensions
<beuno> lifeless, I'm using people.canonical.com
<beuno> so I'm guessing yes?
<lifeless> please not to be guessing
<beuno> ok, how do I verify?
<lifeless> which bzr [check its a system one]
<beuno> yes
<beuno> /usr/bin/bzr
<lifeless> python -c 'import bzrlib._groupcompress_pyx'
<beuno> returns nothing
<lifeless> then you do
<beuno> ok, it's still not giving me output, and using up a lot of CPU and RAM
<jam> lifeless, spiv: So it does, indeed, seem that every knit-ft-gz is getting sent as a separate 'substream'....
<beuno> it's currently running if you want to ssh in and fiddle  :)
<beuno> this is bzr 1.17, and 2a format
<jam> beuno: it is also possible that it is just taking a lot of time to create a working tree, and that it has nothing to do with the last log message
<jam> I don't see why it would be 500MB, though
<beuno> I've been having problems at the office with 2a as well, mainly for a bug repo (1.6gb), making the PC unsable when trying to push, and resulting in a traceback (haven't filed a bug yet)
<beuno> deepjoy,
<beuno> jam, [#########\          ] Fetching revisions:Get stream source
<beuno> it's stuck like that
<beuno> aha
<beuno> 649.908  creating new compressed block on-the-fly in 0.000s 4063168 bytes => 36 bytes
<poolie> hello beuno, jam, lifeless, abentley
<beuno> hiya poolie
<lifeless> jam: thats undesirable but shouldn't cause memory or serious perf issues
<beuno> jam, https://pastebin.canonical.com/21528/
<jam> hi lifeless
<jam> beuno: it is always stuck like that
<jam> no progress with the new stream code
<lifeless> jam: ITYM hi poolie :P we've been chatting for hours?
<lifeless> hi poolie
<poolie> easy mistake to make :)
<jam> lifeless: apparently the tab key hits at weird times
<jam> beuno: that branch isn't sharing a repository
<jam> it is fetching between 2
<jam> 'file:///home/beuno/db-devel/.bzr/repository/' to 'file:///home/beuno/launchpad/.bzr/repository/'
<jam> beuno: what made you think it was inside a shared repo?
<beuno> jam, correct, it's being branched *into* a new shared repo
<beuno> https://pastebin.canonical.com/21529/
<beuno> it's taking a VERY long time to do so, and a lot of CPU
<jam> beuno: k. So you just finished transferring revisions, as near as I can tell. Which is the new "lots and lots of fragmentation" issue
<jam> that said, 650s to get to that point is pretty crazy
<lifeless> beuno: we know the cause :P. We're working on it - jam has landed some mitigation stuff and spiv has landed more mitigation, but we still need to fix up 'does not compress on combining packs/streaming'
<beuno> perfect
<jam> lifeless: I don't think we know why it took 650s before it started copying "inventory" texts
<jam> that is 650s spent copying Revision texts
<poolie> jam, so i wonder what happened, did vila make a beta tarball?
 * poolie opens mail
<jam> poolie: he made an rc1 tarball
<poolie> rc!
<poolie> really
<jam> ... which I think was a mistake
<poolie> i think so too
<jam> he called it 2.0rc1
<jam> we chatted about it a bit
<jam> he also sent it to bzr-announce, though it got cancelled while it was pending
<jam> etc
<jam> so the release process docs seem to need a bit more polish
<jam> since he felt he read them and was following what they said
<jam> but he seemed to do a lot that doesn't fit what we were looking for
<beuno> jam, it's all on rookery, if it's of any use to you. logs, repos, all of it
<lifeless> beuno: what url did you pull from?
<beuno> lifeless, originally, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/
<jam> lifeless: he pulled from launchpad originally, but the current fetch is a local to local one
<beuno> correct
<lifeless> jam: my top candidate for the 650 seconds is the 'walking the full graph for fetching into a local repo is slow' bug
<lifeless> but direct graph access would tend to argue against that
<jam> lifeless: well, it still isn't super fast to query for missing revisions when the target repo already exists
<jam> so it could be the problem
<lifeless> beuno: new repo?
<jam> bzr init-repo --2a .; bzr branch ../other
<lifeless> jam: an empty repo is _very_ fast to query :>
<beuno> lifeless, yes, completely
<jam> lifeless: but not as fast as when you create one from scratch and it does 0 queries
<lifeless> jam: thats true, but it won't be hitting disk
<jam> your code to use AncesterOf rather than _search_missing_revisions
<lifeless> something like 6 function calls per graph depth
<lifeless> spivs, but yes. it is better
<jam> beuno: can you run 'bzr --version' again real quick?
<jam> hmm... that doesn't put it in .bzr.log
<jam> lifeless: it is using python2.4 if that matters...
<jam> 0.029  looking for plugins in /usr/lib/python2.4/site-packages/bzrlib/plugins
<beuno> sure
<lifeless> I wouldn't expect that dramatic a change
<beuno> Bazaar (bzr) 1.17
<beuno>   Python interpreter: /usr/bin/python 2.4.3
<poolie> emmajane: thanks for keeping the website moving, i'm replying now
<jam> lifeless: so yeah, as near as I can tell it is using the compiled extensions, so that isn't strictly a reason
<beuno> FWIW, branching /devel from HTTP into the new shared repo, blazing fast
<beuno> but that initial operation was murder
<jam> 1068s according to the log
<jam> 18min
<beuno> right, to branch locally
<beuno> and the CPU was angry at me in the meantime
<jam> beuno: on the plus side you saved 1421 => 1068 = 6 minutes versus branching from remote...
<beuno> :)
<jam> beuno: any particular reason why you felt you *needed* to do this?
<lifeless> jml: you should subscribe yourself to 'https://code.edge.launchpad.net/~jml/testtools/trunk'
<lifeless> beuno: I hear that launchpad.net can host branches
<jam> anyway.... EOD for me.
<beuno> jam, yes. I got db-devel and wanted devel as well
<beuno> to run a script against that branch
<jam> beuno: but why two repos
<jam> anyway
<lifeless> jml: and/or fix the bug that reviewers are not treated as implicitly subscribed. Its really the most frustrating thing.
<jam> I'm off to pick up my son
<beuno> jam, there shouldn't be a shared repo on the first one
<jam> beuno: there still is *a* repository
<beuno> jam, I realized that I wanted a shared repo *after* I had branched intially
<lifeless> bzr bind lp:launchpad/db-devel
<lifeless> bzr switch devel
<lifeless> bzr switch db-devel
<lifeless> no repo, should be fast, thanks :)
<beuno> yes, that's another way of doing it
<beuno> this week is "don't learn new tricks week"
<jam> lifeless, spiv: so as near as I can tell, bzrlib.smart.repository._stream_to_byte_stream does indeed intend to create a separate substream for each record
<jam> which doesn't seem to match all the gyrations that _byte_stream_to_stream does to try and get multiple records per substream
<jam> for substream_type, substream in stream:
<jam>   for record in substream:
<jam>   pack_writer.bytes_record(serialised, [(substream_type,)])
<lifeless> so,
<lifeless> knit-* should all down to serialised = ...get_bytes_as()
<lifeless> and for the additional records, that returns None or '' (I don't remember which)
<lifeless> so we'll yield one substrea, for the entire group of IO that knit did back to disk
<lifeless> the revisions vf is a bit special, because it only uses full texts
<jam> lifeless: I see exactly the same for inventories and texts
<lifeless> jam: what precisely are you seeing
<jam> 3.323  accepting bytes: 'B341\ntexts\n\nknit-del...'
<jam> 3.323  substream_type texts, record_bytes: 'knit-delta-gz\nTREE_R'...
<jam> 3.323  inserting substream: texts
<jam> 3.323                294 byte part read
<jam> over and over again
<jam> anyway, 1 substream per record is... abusive but not specifically harmful
<jam> I suppose it makes it easier for me to debug exactly when memory goes wacko
<jam>  /away
<lifeless> expected for revisions
<lifeless> not for others
<lifeless> (revs and sigs)
<lifeless> jam: knit-delta-closure and knit-delta-closure-ref
<lifeless> jam: in the server you should see lots of the first, and many more of the second
<lifeless> knit-delta-closure-ref's are not serialised
<lifeless> and it should be using LazyKnitContentFactory
<lifeless> poolie: lunch?
<lifeless> jam: I'm sorry the selftest bug hit 2.0, I thought I'd cherrypicked around it
<lifeless> jam: or rather, I'm pretty certain I had
<poolie> jeez you are getting up early
<poolie> igc, did we get an os x mailing list? i can't remember
<poolie> jam, lifeless, i'm going to merge 2.0 back to trunk
<poolie> if we want to back out jam's changes, let's explicitly back them out
<poolie> though i'd be inclined to leave them the same as 2.0 until we fix the bug if any properly
#bzr 2009-08-27
<lifeless> poolie: would you like to have lunch?
<lifeless> poolie: today I mean
<poolie> mm
<poolie> i would
<poolie> i have to finish circa 5
<poolie> rather than 1 :-O
<lifeless> this sounds compatible so far
<poolie> the bad 1 o'clock that is
<lifeless> I'll be finishing ~ 2 I imagine
<lifeless> wish I knew why i'm waking so early
<lifeless> but it sure is peaceful to be hacking - no trucks or traffic
<lifeless> anyhow, if you'd like to have lunch, so would I. So we should
<poolie> sure
<poolie> pick a place
<poolie> meeting here would let me work more
<poolie> meeting somewhere at the end of a motorcycle would add joy to my life :)
<lifeless> poolie: you're not seriously asking me to choose between you working or having joy?
<lifeless> poolie: thats rather faustian :)
<lifeless> uhm, I could go pie. Or vietnamese. or $other
<poolie> one of us needs to choose :)
<lifeless> lets say pie
<poolie> i am enjoying my work
<poolie> ok, here?
<igc> poolie: yes, bzr-mac
<poolie> wfm
<igc> morning all
<poolie> great
<lifeless> done
<lifeless> 12ish?
<poolie> igc, i was thinking about platform-specific bugs
<lifeless> or is that too early for your stomach
<poolie> i suspect non-core people aren't subscribed to bug mail, or don't read it
<poolie> in fact core people probably don't read all of it
<poolie> should we maybe explicitly forward or subscribe platform teams to relevant bugs?
<poolie> lifeless: wfm, i woke about 6.30
<igc> poolie: maybe. I'm not sure if there would be any backlash against that or not. We could ask if anyone objects?
<poolie> ok
<igc> poolie: there's certainly value in asking the teams to test platform specific fixes
<poolie> i've had some success in the past pointing them out on the main list marked with eg win32
<poolie> i guess the question is whether they're platform test teams or platform dev teams
<igc> poolie, jml: can users/teams subscribe to bugs with certain tags?
<jml> igc, I don't believe so. It's quite possibly a filed bug too
<lifeless> vila: still here?
<poolie> igc, i was wondering the same thing
<poolie> it's probably better to just subscribe the team
<poolie> i think it's probably not appropriate to subscribe the whole team to all relevant bugs
<poolie> (maybe they want it)
<poolie> but we could make ~bzr-win32-bug-team
<lifeless> poolie: do you want developers or qa-on-fixes
<poolie> developers
<lifeless> poolie: if its qa on fixes I'd suggest ~bzr-qa-PLATFORM
<poolie> primarily
<poolie> i think some of these bugs are shallew
<poolie> btw did you have any luck with wine in the case we mentioned yesterday?
<lifeless> poolie: no, it was on my todo to experiment today, but late last night bialix said it works
<poolie> how sad :)
<lifeless> its terrible fixing bugs and stuff
<lifeless> bialix is going to try and get a 1.18.1 prepared with the windows fixes
<lifeless> Whats really a shame is that all of them were very shallow.
<lifeless> does buildbot actually run ascii tests specifically at the moment?
<poolie> i don't know
<poolie> i don't think so
<poolie> but it sounds like vincent will add it soon
<poolie> lifeless: oh, actually unfortunately i can't do lunch today, i have to do something for s
<lifeless> ok
<lifeless> no wakas
<poolie> monday could be good, let's talk then?
<lifeless> friday or tuesday would be better for me
<poolie> k
<igc> poolie: can you clarify vila's email last night ...
<poolie> mm, which one?
<poolie> about the rc? just done
<igc> poolie: the one that said rc1 vs beta1
<igc> and lrelease date early next week
<poolie> ah, i didn't see that about the release date
<igc> poolie: so to confirm, rc2 next week
<igc> poolie: and 2.0 the week after
<igc> if 2.0 is next Monday, that impacts what I'll do today!
<lifeless> poolie: would tomorrow work foryou?
<poolie> igc: yes
<poolie> was i insufficiently clear about what i wanted to happen or was vincent just a bit random here?
<poolie> probably both
<lifeless> poolie: I think unclear; I know I've been unclear
<lifeless> *I've been unsure*
<lifeless> I was asking you yesterday whether this should be done before we're finished with the critical bugs or not, and you said not-before, but this seems to have happened before they are fixed : I don't really know where we stand.
<igc> poolie: I thought it was clear-ish but it's a change in process and we'll still finding our feet wrt monthly vs otherwise
<igc> poolie: 1.18 is yet to be announced for example IIUIC
<poolie> true
<poolie> what's "this"?
<poolie> 2.0b1? at that time all of the 2.0 critical bugs were closed, i believe
<lifeless> doing a 2.0 b1
<lifeless> poolie: jam is working on the fragmentation issue, I'm working on the pushing of 1.9 stacking against 2a issue
<lifeless> 415508 and 402645 were still open
<poolie> bug 415508
<ubottu> Launchpad bug 415508 in bzr "Content filtering breaks commit w/ merge parents" [Critical,In progress] https://launchpad.net/bugs/415508
<poolie> !
<poolie> it shouldn't be
<lifeless> poolie: also when you said critical I heard 'targeted to 2.0' not 'critical'
<lifeless> which is a hearing defect
<poolie> we have non-2.0 bugs marked critical
<poolie> um
<lifeless> poolie: I'd like to either untarget, or bump to critical, all the non-critical, non-fixed, bugs targeted to 2.0
<lifeless> I think it will make sure you and I are on the same page
<poolie> i'd like to either degrade or target all the critical bugs
<poolie> so the non-critical bugs targeted to 2.0 are meant to be things we'd like to fix, or would consider merging
<poolie> this might be an unhelpful distinction compared to just looking at the high/critical lists generally
<poolie> so, um
<poolie> i think both those changes are good
<poolie> but let's do them one-by-one not wholesale
<poolie> and then if we find a case that seems to invalidate the approach we'll reconsider it
<lifeless> I strongly desire that targeted means 'will delay release'
<poolie> mm, me too
<lifeless> not having them critical seems to make them mean something different to you
<poolie> i found that yesterday required more thinking than was optimal
<poolie> or more thinking of a kind of overhead category
<lifeless> ok bug 416732
<ubottu> Launchpad bug 416732 in bzr "check reports "Missing inventory {('TREE_ROOT'..." for trivial non-rich-root branch" [High,Confirmed] https://launchpad.net/bugs/416732
<lifeless> targeted to 2.0. SHould block it IMO
<AfC> lifeless: that's what "blocker" means in GNOME. Actually, "blocker" (if confirmed as such) means Â«holy shit, stop everything, and there will be a release about 30 minutes after we figure out the problemÂ»
<poolie> bug 402645 you mentioned before
<ubottu> Launchpad bug 402645 in bzr "fetch for --2a formats seems to be fragmenting" [Critical,In progress] https://launchpad.net/bugs/402645
<lifeless> poolie: lets do this over the phone; it will be quicker
<poolie> mm
<poolie> let me finish something here first
<poolie> then i'll call
<lifeless> ok
<AfC> lifeless: so yeah, I guess that's what "critical" means there too
<AfC> it's all very informal
<poolie> so the key question is
<poolie> should there be a category of 'wannabe blocker' or 'kinda blocker'
<lifeless> AfC: there are two dimensions here; one is 'before this release', the other is 'what should a dev look at next'
<poolie> it seems to cause mental pain for the RM and may have no benefit
<lifeless> poolie: I don't think there should be; it should be a blocker, and if someone disagrees they stop it being a blocker.
<lifeless> make the decision and make it easy to change if wrong.
<mneptok> lifeless: the answer to the second question is always "my manboobs"
<lifeless> mneptok: no, never. I'm sorry, but goram-no.
<AfC> lifeless: well, the later is task prioritization, and I've never found bug trackers are good for that. Anyway, topic for beer.
<mneptok> lifeless: so much for the adventurous and brave spirit of New Zealanders.
<lifeless> mneptok: ba!
<poolie> lol
<poolie> lifeless: your phone seems engaged, call me when you're fere
<poolie> free*
<poolie> as in beer
<lifeless> poolie: doing
<lifeless> poolie: your phone rang out
 * lifeless tries again
<emmajane> poolie, ping?
<emmajane> beer?
<emmajane> I like beer.
<emmajane> mneptok, stay classy :)
 * emmajane reads backwards in time.
<emmajane> poolie, reply sent. :) I'll be back in a bit for a little bit.
<jam> lifeless: you only get knit-delta-closure etc if you pass "include_delta_closure=True" which doesn't happen for normal fetches, only when someone wants fulltexts.
<jam> so you end up getting every little bit of content as a separate 'substream' in a normal fetch
<jam> 2a would be different
<jam> though I think it would be 1 group per substream
<jam> which still isn't great
<jam> and means that the target repository won't really have a chance to do batching
<jam> since it won't get all the groups in a single 'insert_record_stream'
<jam> you would have to batch between the streams...
<spiv> jam: it's still the same write group, though.
<jam> spiv: sure... still sort of violates what I thought substreams were abouet
<AfC> jam: wish you were here. Then I could buy you a coffee.
<spiv> Well, it's explicitly allowed for there to be multiple substreams of the same kind.
<spiv> It would be more elegant to turn the stream from the request into a continuous object stream, but Python doesn't make that easy to do.  Well, we could add more threads...
<jam> spiv: sure. but 1 record at a time is not really a bunch of *streams*, but more, a bunch of records... :)
<jam> also, Repositories know about write groups
<jam> VF's know about record streams
<jam> so you would have to figure out how to have the VF know about the current Repo's write_group
<jam> which is a small inversion
<jam> or have Repo.commit_write_group() tell the VF.flush_your_buffer()
<spiv> Well, for 1.9 pack repos I don't think there was any practical difference between insert_record_stream([2 records]) and 2 insert_record_stream([1 record]) ?
<jam> (and dump_your_buffer for abort)
<spiv> Because it's the write group that allocates the pack file.
<jam> spiv: present day there isn't for 2a
<jam> I would *like* to regroup on-the-fly
<jam> given the discussion about fragmentation and recombination
<jam> I can't regroup if everything I see is a single record-at-a-time
<spiv> Ah, I see.  I was trying to figure out why you cared :)
<AfC> bzr 1.18 is out or will be immenently right? (ie, it's ok for me to "advise" people that they really ought to be using bzr >= 1.18 on a website & in release notes for something I'm cutting today or so?)
<jam> AfC: 1.18 is out, the announcement hasn't hit pending the building of all packages for all platforms
<jam> the code is cut, though
<AfC> k
<AfC> close enough
<poolie>  2009/8/27 Mary Gardiner <mary@puzzling.org>:
<poolie> > Why say "can we upgrade this to critical" when you mean "can we fix this?"
<poolie> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â -- Martin Pool, twitter.com
<poolie> great sig :)
<jml> heh
<spiv> Heh.
<fullermd> Wait.  We're supposed to FIX them?
<lifeless> poolie: I've just mailed the list with I think the pith of our chat
<lifeless> spiv: jam: it would be quite easy to daisy chain all the substreams of the same kind together in the insert_stream method
<poolie> >  "Do not assign bugs to other people unless you are confident they will work on them." sounds like some people can avoid getting bugs assigned to them altogether :)
<poolie> but no one on this team :)
<lifeless> poolie: if you assign a bug to me, its == 'hey robert, please fix this for me'
<lifeless> and I'm very unlikely to unassign it immediately.
 * igc lunch
<poolie> mm
<poolie> i'll reply in mail
<lifeless> I've seen fairly regularly in other areas, assign-to-someone being used by users to get their bug looked at
<lifeless> I think that was before the permissions on the assigned field were straightened out
<poolie> what is 'staying stay' supposed to mean?
<lifeless> blah, typo
<lifeless> just switching folders.
<lifeless> poolie: staying stale
<lifeless> poolie: as data:  https://bugs.edge.launchpad.net/~mbp/+assignedbugs :)
<mwhudson> would bzr reconfigure --append-revisions-only be a useful feature?
<lifeless> mwhudson: yes!
<fullermd> Only I'm not sure I'm sanguine with it in reconfig.
<mwhudson> lifeless: is there an easy way to set it at the moment?
<lifeless> mwhudson: vim
<lifeless> fullermd: got a better place?
<fullermd> Unfortunately, no.  We should have a place for a lot of things like that.
<fullermd> And reconfigure is a great command for it.
<fullermd> But it's currently fairly purely "reshuffle the arrangement of bzrdir components", and I don't like mixing that with "set branch config options".
<fullermd> mwhudson: init has a flag for it, so check the cmd_init code.
<lifeless> fullermd: and repository options
<lifeless> mwhudson: api wise its easy
<poolie> lifeless: i know
<lifeless> branch.get_config().set_user_option()
<poolie> they're some of my favorite bugs
<fullermd> Yah, I know.  I put that one there, remember  :p
<poolie> it may be too large of a queue but they're also things that i want to do in my slack time, if any
<lifeless> poolie: o/~ these are a few of my favourite things
<fullermd> Still a bit uncomfortable with it being there, though.
<poolie> it may be there's some better place to store that
<lifeless> poolie: Would you be happy having an mbp tag on the tracker?
<poolie> mm
<poolie> maybe
<poolie> tags are still harder to use
<poolie> there is this 'bug list' feature that's meant to do exactly what i want here
<poolie> no idea when that will be done though
<lifeless> I get concerned when I do something with someone else assigned to it.
<lifeless> to the point that I don't do those things.
<lifeless> or do them less often
<poolie> ok
<poolie> that's definitely a problem
<poolie> some of this stuff is like working in python
<poolie> nice, but you have to work with what you've got
<lifeless> s/.*, //
<poolie> ie encoding all the bugs as tuples :-/
<lifeless> :P
<lifeless> I like that we can file bugs on launchpad in launchpad.
<lifeless> thumper: will pyconz be briliant or just ok?
<thumper> lifeless: I have no idea
<thumper> lifeless: I expect it to be at least ok
<lifeless> very close to uds
<lifeless> I'm trying to decide if I should come to pyconnz and give a lightning talk on fixing unittest
<lifeless> amongst other things
<poolie> lifeless: i think you have a good point about assignment actually
<poolie> i've just had enough metadevelopment for today
<lifeless> poolie: thats fine, I have too
<lifeless> I was expecting a 3 minute call :P
<poolie> :-)
<poolie> spiv, igc, either of you want to catch up?
<poolie> now would be good for me
<spiv> poolie: sure, I'll call
<lifeless> poolie: I've EOD'd
<RobOakes> Hi, I just started using bzr (and I've absolutely loved it, especially the bzr-svn module), but had a couple of new user questions.  Is this a good place to ask them?
<RobOakes> I created a test branch from an SVN repository and then posted it to my server.  From there, I made a "working" branch that I could experiment with.  However, whenever I post anything to the working branch, it also posts to the main branch on the server via SFTP.  Is that normal?  And if so, is there any way to disable it?
<fullermd> RobOakes: How did you make the working branch?
<RobOakes> The first branch I created by using bzr push from within the SVN working copy.  It took four days, but eventually it created a bzr branch of the code.
<RobOakes> The "working" branch was created from that initial export using bzr branch /path/to/original
<fullermd> What does 'info' tell you in the working branch?
<mtaylor> lifeless: ooh, when's pyconnz?
<thumper> mtaylor: you mean kiwipycon?~
<RobOakes> It says "checkout of branch sftp://path/to/branch"
<RobOakes> Related branches push branch: sftp://path/to/branch
<thumper> mtaylor: http://nz.pycon.org
 * mtaylor is always looking for excuses to go places...
<thumper> mtaylor: where are you based?
<fullermd> RobOakes: Right.  So you didn't make a branch, you made a checkout (either by running 'checkout' instead of branch, or later using 'bind' or one of its relatives).
<mtaylor> thumper: seattle
 * mtaylor now notices that CFP is open for US pycon
<thumper> mtaylor: we'd love to have you :)
<RobOakes> Okay.  Is there any way to unbind it?
<fullermd> RobOakes: You want to turn it into a separate branch if that's what you want, with e.g. 'unbind'.
<thumper> mtaylor: it is just a weekend though
<thumper> mtaylor: we're only just starting out
<RobOakes> Very, very nice.  I just tried a test commit and it looks like everything is working.  Now, when I want to update the remote branches, I use bzr push, right?
<mtaylor> thumper: I'd love to come! you know, I'm sort of low on flying miles this year...
<thumper> mtaylor: need to keep that gold membership?
<fullermd> RobOakes: Right.
<mtaylor> thumper: yes!
<mtaylor> thumper: if I lose it, they'll stop upgrading me places, and that would make me sad :(
<thumper> mtaylor: you could talk to me in person about code reviews
<mtaylor> thumper: oooh. now there's a business reason to come
<RobOakes> Got time for a second question?  Because of reasons too complicated to go into, I do most of my development work on a linux virtual machine.  However, the actual files are stored on the physical hard drive and accessed through an interface.
<RobOakes> For reasons I don't understand bzr seems to think that the file permissions change, quite frequently.  This leads to very big (and pointless commits).  Is there a way to tell bzr to ignore changes in the file permissions?
<fullermd> The only permission bzr watches is the +x.  That really shouldn't be changing around unless you're flipping it...
<lifeless> mtaylor: mid nov
<fullermd> (I mean, depending on just what the 'interface' is, it may not mean much, but it shouldn't be _changing_)
<RobOakes> I'm not, but the way vmware handles it's remote directories is weird.  Sometimes, they mount as 777 and sometimes they mount with other permissions.
<RobOakes> I still haven't quite figured out the overall method to the madness.
<fullermd> That's...    pretty insane.
<fullermd> Anyway, making bzr ignore it would really be hackaroundish.  Wouldn't be my choice of how to handle it.
<fullermd> But given that, no, AFAIK there's no existing config option to say "ignore +x totally plz".
<RobOakes> Agreed.  My plan has been to watch the permissions and only commit when they are 777, this prevents the nasty problem.
<fullermd> Maybe you could thunk something in with a plugin, but that's way outta my league.
<RobOakes> I may think about doing that.  My first desire would be for VMware to tell me why the permissions in the vmfs module are all crazy.
<fullermd> Vague memory tells me there is (or was) a plugin to try and allow some +x handling on win32; that might be a place to start.
<RobOakes> I'll take a look at that.  I'll look through the devel mailing list and see if I can find anything about it.
<spiv> Maybe write a plugin or shell alias that checks that a) a file that should not be +x is indeed not, and b) a file that should be, is.  Then abort/warn before commit as appropriate?
<fullermd> Oh, good, somebody competent is here.  I'll leave you with spiv    8-}
<RobOakes> That would help solve the problem, and wouldn't be too complicated.
<RobOakes> Anyway ... thanks for the help.  That clears up most of the miscellaneous questions I had.
<spiv> That would catch any sort of weird "all mounted files get +x"/"all mounted files lose +x" condition.
<spiv> And hopefully you can fix the root problem :)
 * spiv grabs a late lunch.
<RobOakes> Agreed.  What's funny is that I don't seem to have the same issue with my svn working copies.  (But I also haven't spent much time testing it.  I figure it's a weird VMware thing.)
<vila> hi all
<vila> lifeless, poolie : the test are run with and without locale for quite a few days/weeks
<vila> poolie: argh, sorry about the rc/beta misunderstanding :-(
 * vila checks mail
<lifeless> vila: thanks
<poolie> it's ok
<poolie> vila, what was the source of the confusion?
<vila> hmm, I think I fired qlog to search for examples of updates for version_info and could only found rc examples of course
<vila> you certainly mentioned 'beta' but it didn't print hard enough in my brain to override at that point :-/
<vila> add to that some stress due to bugs encountered while setting up my 2.0 branch and apport masking me the real cause, etc, => small mistake, big consequences :-/
<poolie> ok
<poolie> i thought that might have been it
<poolie> the examples in the docs are a bit of a two-edged sword
<poolie> without them it would be vague but it's easy to mentally or literally copy & paste them
<vila> while discussing with jam, I still wasn't sure about my mistake as 'cycle.txt' doesn't mention 2.0beta1 but mention 2.0rc1
<vila> so it's still unclear whether 2.0 is different because it starts the new cycle
<poolie> jam, you rejected your merge sort bug?
<vila> poolie: re-reading releasing.txt, memory comes back also: the document is clear about final releases, less so about candidates and says nothing about betas, I'll outline everything I found by mail
<poolie> s/bug/mp
<vila> poolie: I saw it too, but I think he wanted to work on a second part instead and I'm pretty sure he send a submission to pqm
<lifeless> poolie:
<lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/tests/test_selftest.py", line 2645, in test_run_bzr_user_error_caught
<lifeless>     'bzr: ERROR: Not a branch: ".*nonexistantpath/".\n')
<lifeless> AssertionError: pattern "bzr: ERROR: Not a branch: ".*nonexistantpath/".
<lifeless> " not found in
<lifeless> """\
<lifeless> bzr: ERROR: Attempt to escape test isolation: 'file:///nonexistantpath/' []
<lifeless> """
<jml> :(
<igc> bbl - some errands to run
<lifeless> jml: this is good
<lifeless> jml: its a step towards not making 4 directories on every test
<jml> lifeless, I was reacting to a costly mistake that bzr let me make
<jml> make lots and lots of tedious changes, shelve them, merge in latest trunk, forget to commit, unshelve them, realize they're all mixed together, revert, sigh
<lifeless> jml: oh :(
<lifeless> jml: did you lose the changes?
<lifeless> jml: perhaps you can uncommit, or maybe we kept a backup for you?
<jml> backups would end with '~', right?
<jml> ... and the modified files aren't open in my editor.
<lifeless> mmm, they would have it in the name
<lifeless> is there a backup of the shelf in .bzr/checkout/**
<lifeless> jml: we should have kept backups for sure, grep for **/*~*
<lifeless> em, find . | grep .. or $something like that
<jml> no backup in .bzr/checkout
<jml> the backups look like they are of the wrong changes
<jml> I want what was in the shelf
<lifeless> please file a bug about this; we may tease it into several bugs
<lifeless> however, the backups are numbered
<lifeless> are you looking at the right ones
<jml> there's only ~1~
<jml> no others.
<lifeless> ok, two bugs
<lifeless> revert is meant to back things up
<lifeless> unless you've set no backups
<vila> poolie: ouch, only 2.0rc1 appears on https://edge.launchpad.net/bzr in the download part, that's not true for https://launchpad.net/bzr though
<poolie> i like the pedantry of the tooltip on RDF
<poolie> vila, you're saying it should show the last stable release too
<poolie> sounds like an lp bug
<vila> yes
<poolie> oh, sigh
<poolie> will you file it or should i?
<vila> well, had I made a beta I think the problem would have been the same... please do, I'm already filing  another:-/
<poolie> oh, which one?
<poolie> i'm going to finish soon btw
<poolie> for a change
<vila> TooManyConcurrentRequests when pulling from lp in a lp bound branch
<vila> lifeless: bug #309309 was the one I was referring too yesterday in my review
<ubottu> Launchpad bug 309309 in bzr "selftest can't be run in a bound branch" [Undecided,New] https://launchpad.net/bugs/309309
<AfC> Launchpad is pathetic. Again. "The URI scheme "bzr" is not allowed.  Only URIs with the following schemes may be used: bzr+ssh, ftp, http, https, sftp" when trying to give it a bzr:// branch.
<poolie> someone just filed a bug on that
<poolie> it may be a recent regression
<AfC> I mean, shit, even Ohloh manages to get that right.
<AfC> poolie: (no, I don't think so. I recall trying to register the proper branch URI for my mainline about a year ago and it didn't work. Back then it _also_ crashed my browser when I tried to file a bug about it, which was exceptional. But now it just errors)
<poolie> well, sorry
<lifeless> AfC: I think you're being a little harsh; that code tries to be very paranoid (and thats arguably a mistake), but pathetic is a little strong.
<AfC> poolie: {shrug} I'm not about to hold their behaviour against you.
<AfC> poolie: but this is yet another feather in the cap of why I think it so important to encourage people to realize they don't need to use Lauchpad to work with Bazaar.
<spiv> Yeah, I think that's always been the case.  I think there was/is some reluctance to open up unnecessary ports.
<AfC> lifeless: perhaps, perhaps not. Given that I've registered an external branch as a project's mainline I don't really see it as necessary that Launchpad advertises "to get this do `bzr branch lp:myproject`. It's like? Huh? That's a mirror, and a 5 hour out of date mirror at that. How about Launchpad advertise `bzr branch bzr://...` like I asked it to.
<AfC> lifeless: things like that, again and again
<spiv> So my recollection is that refusing bzr:// is not because LP doesn't understand that prefix, but because it knows it can't work.
<AfC> lifeless: me registering a release series at a certain well known foreign location and then Launchpad claiming it's where the releases are hosted? That's not cool either.
<lifeless> AfC: for some folk its great, because they don't want lots of people pulling directly. Maybe there should be a toggle.
<AfC> spiv: that's interesting. Bizarre to my eyes, but certainly informative. Of course, if bzr:// doesn't work maybe someone should take it out of bzr and I'd stop using it.
<lifeless> AfC: it works, its just firewalled @ canonical.
<spiv> bzr:// works just fine, in general.
<lifeless> AfC: is there a bug on this?
<AfC> lifeless: classic
<spiv> Operationally, the way Launchpad is currently deployed, Launchpad cannot access that port on arbitrary hosts.
<AfC> [and you said I was being harsh?]
<spiv> It's probably worth revisiting that decision.  At the time there were very few TCP-only bzr branches out there, so it wasn't a big deal.
<spiv> And, co-incidentally, someone did file a bug about it recently as mentioned above, so probably someone will be revisiting that decision soon.
<AfC> lifeless: I can try and file one if you like. Launchpad's javascript doesn't seem to be crashing Epiphany anymore.
<spiv> Oh hey, another Epiphany user.
<AfC> :)
<AfC> spiv: of course. GNOME integration, baby
<poolie> vila: i don't think you put the changelog in the2.0rc1 release on lp?
<poolie> vila: i filed bug 419735
<ubottu> Launchpad bug 419735 in launchpad-registry "downloads page harshly truncates series descriptions" [Undecided,New] https://launchpad.net/bugs/419735
<vila> good
<poolie> (not so important)
<poolie> and more importantly bug 419733
<ubottu> Launchpad bug 419733 in launchpad-registry "new Downloads portlet should show latest stable release as well as latest" [Undecided,New] https://launchpad.net/bugs/419733
<poolie> and reopened bug 275677
<ubottu> Launchpad bug 275677 in launchpad-registry "downloads should be grouped by release, not series" [Low,New] https://launchpad.net/bugs/275677
<poolie> vila, also we should probably change the process not to upload source zips
<poolie> i misunderstood the request when i added that
<lifeless> vila: checking the safety net appears to be 1-2 ms
<lifeless> (*20K = most of a minute)
<poolie> people actually wanted zips of windows binaries
<vila> changelog... oooh, I just understood how it works, but that's not mentioned in releasing.txt and I think at the time I filed  http://bazaar-vcs.org/Download I was already worried because the bugs didn't appear
<poolie> lots of bugs appear :)
<poolie> which ones did you miss?
<vila> I mean they weren't targeted at the milestone
<poolie> mm
<lifeless> poolie: I'm wondering if your fix to show every test is the right way to fix the test progress bar
<vila> also creating the milestone was a key time in my mistale
<poolie> rather than what?
<lifeless> poolie: simply because if tests are very fast the progress bar starts to dominate :)
<poolie> srsly?
<poolie> nice
<lifeless> I'm closing in on that
<lifeless> Ran 203 tests in 2.975s
 * jml is reminded of Ubuntu boot discussions
<poolie> presumably because of the time to paint it, not to calculate the text
<poolie> what's the delta if you run with =none
<lifeless> =none ?
<lifeless> how would I spell that
<vila> BZR_PROGRESS_BAR=none ?
<poolie> yes
<lifeless> ./bzr --no-plugins selftest selftest
<lifeless> ok
<lifeless> Ran 203 tests in 2.881s
<lifeless> about 0.5ms per I guess
<lifeless> so not huge yet
 * lifeless ignores for now
<lifeless> mmm, but 5% of test time
<lifeless> when it gets up a bit higher I'll worry
<poolie> 3% according to my calculator
<vila> lifeless: why not ./bzr selftest -s bt.test_selftest -s bb.test_selftest ?
<poolie> but it seems like these are atypically fast tests?
<lifeless> vila: I have a lot of plugins I don't want loaded for this; and its fast enough without -s that I've never learnt to use it.
<poolie> i reckon the overall overage is still above 50ms
<bialix> does anybody knows why merge shows many files as modified in its output, but status after merge shows there is changed only file or two?
<lifeless> poolie: they weren't when I started
<lifeless> bialix: you're merging in things that have patches you already have
<lifeless> bialix: so the change ends up being nothing
<bialix> I don't understand
<bialix> why merge shows me incorrect info
<poolie> there's a bug that merge should only show files as modified if they actually changed
<bialix> ?
<poolie> because they 'might have changed'
<lifeless> bialix: because it shows the files that had changed on branch A
<poolie> but the changes didn't add up to anything
<lifeless> bialix: but in your branch, B, they already have the same textual changes
<bialix> lifeless: about your fixes for win32 and locks
<bialix> if I merge with --weave I don't have conflicts
<bialix> but resulting diff after merge is scarely short
<lifeless> bialix: for example; if you and I both change "print foo" to "print bar" in different branches, if I merge from you I will get your change, but end up with no difference in the file.
<bialix> lifeless: I think this is a bug in merge
<lifeless> as poolie says there is a bug open.
<bialix> ok
<bialix> lifeless: back to your 2 revisions with lock fixes: do you want to review them?
<bialix> after I cherrypick them with weave?
<lifeless> I'm not entirely sure that this is wrong though, I mean, it would be odd to merge what you thought were different branches and see no output.
<lifeless> bialix: if you'd like me too, I'm very happy to.
<bialix> lifeless: for me odd thing is that after merge status shows there is nothing changed, while merge shows there is a lot changes
<bialix> it makes me nervous
<luks> you can always diff against both parents and see if the diffs look the same
<lifeless> bialix: I think it should say that this has happened
<lifeless> bialix: being totally quiet would be wrong; looking like a normal change and st showing nothing all looks wrong.
<lifeless> /all/also/
<bialix> luks: I can, but only if I know that bzr lies me
<bialix> lifeless: revno 4635 NEWS has completelly unrelated entry:
<bialix> * Fix a test failure on karmic by making a locale test more robust.
<luks> lifeless: well, if merge doesn't change anything in those files, does it need to list them?
<bialix>   (Vincent Ladeuil, #413514)
<lifeless> luks: see above
<bialix> lifeless: it's not related to your patch. may I  omit it while cherrypicking?
<lifeless> luks: its merging a patch from someone, you'd expect the change
<lifeless> bialix: sure
 * bialix start hates the fact that bialix adding bzr.ico to bzr.exe, grrr
<luks> perhaps merge could output some diffstats
<luks> so after each file you see how much of it is changed
<lifeless> luks: that would be one way
<lifeless> M foo.py +0 -0
<luks> yeah
<lifeless> M bar.py +123 -456
 * fullermd goes back to dreaming of having that in log...
<lifeless> fullermd: jfdi
<lifeless> fullermd: log -p on 2a:)
<luks> is it usably fast?
<lifeless> fullermd: hey, how did you go with your src tree?
<lifeless> luks: oh yeah
<fullermd> Oh, yeah, I'll just go design up a new repo format   :p
<lifeless> fullermd: shouldn't need to now
<lifeless> it should be able to keep ahead of you
<fullermd> lifeless: Oh, I didn't.  It's on my "hey, this is probably good enough to try sometime" list.   Soon's work quiets down a little.  15, 20 years maybe.
<fullermd> Oh, I think it desperately calls for being cached at commit-time.  log bzr.dev takes 1.6 seconds (with a somewhat chilly cache).  log -p hasn't finished yet...
<lifeless> fullermd: in 2a format!
<bialix> jam: merge -cN --weave ROCKS!
<fullermd> Well, I don't have a sizable 2a branch around.  But still.  I'll bet it's more than a factor or 2 or 3.
<bialix> jam: you ** genius
<fullermd> (which is my WAG for "pretty expensive")
<lifeless> fullermd: so; I know someone that does log -v -p ~ in cron
<lifeless> of a big arse branch
<lifeless> data >> WAGs
<fullermd> Sure, but who's got a hundred thousand revs of ~?
<lifeless> fullermd: I mean approximately in cron
<lifeless> not homedir
 * lifeless watches screens of tests fail
<lifeless> well, I expected that
<fullermd> "Crap, we just blew up half the moon."  "Well, I expected that."
<bialix> lifeless: cherrypicked branch bzr+ssh://bazaar.launchpad.net/~bialix/bzr/bzr-1.18-oslocks-win32/
<bialix> should I send merge proposal to the list?
<lifeless> bialix: please
<lifeless> or just propose it in lp
<bialix> poolie knows beforehand that I will ask you him about 1.18.1 and ran away
<bialix> ghaa
<bialix> poolie: 1.18.1?
<bialix> hi garyvdm
<vila> poolie: https://code.edge.launchpad.net/~vila/bzr/releasing-clarified/+merge/10792
<bialix> lifeless: oops, I've just realized I had to use --author when commit your fixes. I can rework if you wish
<lifeless> bialix: its fine
<lifeless> bialix: NEWS has my name anyhow
<bialix> sorry
<lifeless> its fine
<vila> lifeless: https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10775 leads to 14 failures for a full test run (I was checking --parallel=fork was still working but it's unrelated)
<lifeless> vila: thanks, could you attach --subunit output from that to the merge thread?
<vila> lifeless: yup, trying to do that right now but the output looks far too verbose >-/
<lifeless> vila: bzr selftest --subunit | subunit-filter --no-skip > failed.log
<vila> subunit-filter ?
<vila> got it
<vila> hmm, known failures and unavailable features are back <SHUDDER>
<vila> lifeless: re-running without fork, will be longer
<lifeless> vila: thats because you only fixed it in bzr :)
<lifeless> vila: ignore them
<lifeless> vila: they'll get filtered out on my end
<vila> lifeless: the file is still 2M want that by mail ?
<lifeless> vila: sure
<lifeless> bzip2 it
<vila> lifeless: sent
<lifeless> you'll probably like my mail to the list ;)
<lifeless> jml: are you on xmpp
<jml> lifeless, I think so.
<lifeless> as?
<lifeless> jml: [gchat counts]
<jml> lifeless, I like your recent bzr ML post
<lifeless> thank you
<jml> lifeless, have you seen http://dev.launchpad.net/FasterTests
<lifeless> no
<lifeless> or rather maybe
<CaMason> I want to fork one of my projects and develop elements of it seperate to the trunk. I will want to periodically merge changes from the trunk into this fork, but not overwite specific files. Is this possible?
<jml> lifeless, it should probably cross-pollinate with your post
<lifeless> jml: actually, yes I have
<lifeless> I've even edited it.
<jml> page history doesn't say so, but maybe that's pre-open sourcing
<jml> probably was.
<lifeless> look for my name
<jml> ahh yes
<jml> anyway, I'm off for the evening
<jml> g'night.
<lifeless> ciao
<lifeless> LarstiQ: know where jelmer is?
<vila> wow karmic booting in16s...
<lifeless> vila: have you tried --lsprof-tests?
<lifeless> vila: piiing
<vila> lifeless: poong, was biking and lunching :)
<vila> lifeless: not tried yet, but it's been a while since I wrote a test that took longer than 50ms :P
<CaMason> if I've got two branches, one of which is a fork, how do I merge specific changes into the fork?
<CaMason> i.e. I don't want to alter some of the files in the fork
<vila> bzr merge trunk
<CaMason> wont that give me a load of conflict messages?
<CaMason> or even merge in some changes I don't want?
<vila> The only way to know is to try
<vila> Start with a clean working tree (no changes nor pending merges), 'bzr st' should reports nothing
<lifeless> vila: 50ms is pretty slow ;)
<vila> lifeless: higher value, many are 0ms :D
<vila> lifeless: highest value, many are 0ms :D
<lifeless> vila: --parallel gives wrong per test timings, btw
<vila> lifeless: I know, I don't rely on these, I use '-v' without --parallel when the set is small enough
<vila> in fact I mostly use parallel for the whole suite
<vila> mostly
<vila> but no always :)
<lifeless> yea. its on my to-fix
<vila> I still use -s more than --parallel
<lifeless> subunit's parallel support has landed
<lifeless> sorry, progress nesting
<lifeless> anyhow, those tests all pass for me
<lifeless> with revno: 4659
<lifeless> message:
<lifeless>   Detangle test listing: its more part of the ui layer not the execute-this-test-layer.
<vila> eerk, same revno here
<vila> revision-id: robertc@robertcollins.net-20090826233048-4yerdwqhvi2dqzi9 right ?
<lifeless> yes
<vila> with extensions built ?
<lifeless> hmm will check
<vila> hmm, mine weren't up to date
<vila> dirstae_helpers
<vila> tricked by reviewing repeatedly in the same branch may be...
<vila> lol, unrelated but funny failure: test_crash.TestApportReporting.test_apport_report_contents AssertionError: pattern "(?m)^CommandLine:.*selftest" not found in CommandLine: ['./bzr', 'tss', '--no-plugins']
<vila> tss is an alias for selftest --parallel=fork) :
<vila> so, sorry for the false alarm, the above is only failure I get once *I* recompiled my extensions
<lifeless> so, +1 to land?
<vila> re-reading now
<lifeless> also file a bug on that failure
<lifeless> tag selftest please
<vila> k
<vila> I don't follow the stopTestRun merged in python.. Is that in 2.7 ?
<lifeless> yes
<vila> I thought done() has been defined in subunit and testttools too... will they be updated too ?
<lifeless> testtools is
<lifeless> subunit I need to check but I think is already
<vila> hmm, indeed testtools commit message explain it all
<vila> is the stop_early/stop_on_failure transitional or really needed ?
<lifeless> subunit does need an update
<lifeless> vila: it's contractually correct I think
<vila> so both are valid and need to be replicated ? stop_on_failure having higher priority ? Sounds a bit brittle
<lifeless> erm
<lifeless> I'll need to look closer, we may hav duplication
<lifeless> I only shuffled around in this patch
<lifeless> so whatever we had before, we have now
<lifeless> I thought you meant stop_early -> self.stop()
<vila> no :)
<vila> You give us a far cleaner TestRunner,
<vila> whatever is left appears bigger now
<vila> so a loop on result_decorators to propagate a boolean looks highly suspicious
<vila> the injection of BZRTransformingResult is uglier too now :)
<vila> and I still don't like that self.verbosity handling here
<vila> I think that sum up my review, will put that online under approve cause it's better, how about fixing those later
<vila> lifeless: reviewed
<lifeless> thanks
<vila> reagrding 2.7, xfail becomes standard but not UnavailableFeature ?
<lifeless> yes
<vila> k
<sender> hello, can anyone confirm that it is not a problem to just "rm <dir> -Rf" in a shared repository (the shared concept makes me feel this is not the right way to go, maybe leaving information behind in the shared .bzr or, worse, removing data necessary for other repo's under shared), thanks.
<vila> sender: if <dir> is a branch all that will be lost is the working tree, the changes not committed there and the easy reference to the branch tip
<vila> sender: doing 'bzr log -l 1 --show-ids' before the rm should give you all the needed bits to recreate the branch if needed
<sender> vila: thanks. that means that the removed branch will always remain in the shared repo?
<vila> the point of the shared repo is to share revisions between branches so the revisions will stay there yes
<sender> ok. so, I need the hash @ revision-id or parent to recreate it?
<sender> is there a way to fetch those, even after hard-removing a branch under a shared repo?
<vila> the revid yes
<vila> yes
<vila> bzr branch -r revid:<revid> trunk resurrected
<sender> hmm where does
<sender> sorry, where does trunk points to?
<sender> I've removed the branch, i've got the revid of that branch, now i am in the shared dir, and the command above gives me 'trunk' is no branch
<vila> hmm, generally I use a shared repo for each project I'm working on, so I always have a branch which is the trunk
<sender> and would trunk be the branch that was removed?
<vila> err, you have a shared repo without any more branch ?
<sender> can I pick just any other branch?
<vila> yes
<vila> we're cheating here anyway by using the branch as a entry point to the repo
<vila> the revid doesn't have to be part of the branch history
<sender> ah, nice it works :) yes exactly, it would make more sense to address the shared repo (as far as i can see)
<vila> sender: well, we are searching in the garbage can here, so it's not often used either
<vila> another way, a bit clearer may be is to do:
<vila> bzr branch trunk resurrected ; cd resurrected ; bzr pull -r revid:<revid> --overwrite .
<vila> mmm, not sure it's clearer, I guess it depends who you ask :)
<sender> interesting. now this is fastforwarding/scrolling back the resurected branch to a certain rev, right?
<sender> I guess this would never work with the regular revid, b/c those can diverge between branches, right?
<vila> You mean the revno ?
<sender> yes
<fullermd> You could just as well use "bzr init ; pull -rX .".
<luks> would that work?
<fullermd> Yah, I've done it a few times.
<vila> fullermd: preceding that with mkdir resurrected of course :)
<vila> and a cd
<luks> interesting, as far as I know, the revno is calculated based on the last_revision_info file
<fullermd> Well, init would make the 'resurrected' for you   :p
<fullermd> Well, obviously specifying the revid rather than the revno.  But you'd have to do that anyway, unless you had a branch with that rev in its history.
<luks> ah
<luks> I assumed that was a response to sender's last question
<vila> and in the future you may not have to specify 'revid:' once we get some DWIMery there :)
<fullermd> Someday, if somebody reviews the patch, it'll even DWIM the revid without having to qualify it   :p
<vila> fullermd: hehe, I said it first :)
<luks> what's blocking the patch, btw?
<fullermd> That means you volunteer to review it, right?   :p
<fullermd> Nothing.  People looking at it.
<vila> when 2.0 is out, I already told you that there will be many discussions around and including that subject :-D
<vila> fullermd: no sequitur, what is the latest bzr version available for FreeBSD and what is the command to install it ?
<sender> ok one more question: is there a way to find all the removed branches (head revids I guess) in a shared repo (or look into the garbage can - as vila said it)?
<fullermd> Oh, I got 1.18 in ports...   last week I guess.  I usually get 'em submitted within a day of the release, and it takes a few days to get committed.
<fullermd> So something like (cd /usr/ports/devel/bazaar-ng ; make all install clean)
<vila> bzr heads --dead
<vila> you need the heads plugin
<vila> and to clean the garbage from the shared repo, you do 'bzr gc'
<fullermd> It's in bzrtools.
<vila> err, wait, no, we still haven't that one :)
<vila> right bzrtools (what was I thinking... wasn't it in another plugin like, years ago ?)
<fullermd> Yah, it got Assimilated a while ago though.
<sender> that would be sth like git compact?
 * fullermd dreams of the day when he has a bzr command to check, reconcile, pack, and gc, all at once...
<vila> fullermd: you shouldn't need them :)
<vila> fullermd: seems to install 1.13 and failing because 1.13 is already installed
<fullermd> 1.13??
<sender> i've got two branches in my shared, but bzr heads gives only 1 tip of branch, is this b/c these branches are not diverged?
<sender> Both HEADs have a different revno and different parent and revision-ids.
<fullermd> Oh, I guess you probably have an old ports tree from a release.
<vila> fullermd: 7.2
<vila> sender: one is in the ancestry of the other ?
<fullermd> sender: 'heads --dead' only lists heads that DON'T already have a branch pointing at them.
<fullermd> vila: 'k, so you'll need an updated one.  Clean out the old (e.g., rm -rf /usr/ports/*), and pull down and extract a new with portsnap (e.g., portsnap fetch extract)
<fullermd> Then you can get manually rid of the old bzr (pkg_delete /var/db/pkg/baz<TAB>) and install the new, or install portupgrade and use that to catch everything up.
<sender> vila: true. thanks all!
<vila> sender: so the most recent one is reported, the other one is not a HEAD because it has children
<sender> makes sense
<sender> so, if i understood correctly, right now there is no way to clean dead heads out of a repo?
<vila> fullermd: ok, so from there, it's basically 1) grumble, too old, 2) cd /usr/ports/<magical>/<package> 3) make all install clean (gee don't try -j there >-)
<vila> sender: There is: create a new shared repo, copy all the branches you care about from one to the other
<vila> not pretty, but works
<fullermd> vila: 1.5) pkg_delete to get rid of the old version, yah.
<sender> it will do, thanks
<fullermd> vila: And it -j's internally already where vetted   :]
<fullermd> vila: If you install portupgrade, you can also (after the tree update) just fire a 'portupgrade -a' to upgrade everything with upgrades available.
<fullermd> vila: That initial portsnap fetch/extract takes a while, but later updates (`portsnap fetch update`) are reasonably quick.
 * fullermd really should sit down and write up a portupgrade replacement someday   :|
<vila> fullermd: and what about upgrading the base system ? Not needed ? (*I* don't really care it's for the test farm so your advice will be god speak)
<vila> oh, Ill make that 2.5 instead 1.5 if you don't mind :)
<fullermd> Not needed right now, I'd say.  7.2's only a few months old.  I don't usually upgrade base but a few times a year, at most (sometimes much less)
<vila> k
<vila> in rome...
<fullermd> My server's still running a pre-7.2 RELENG_7.
<fullermd> FreeBSD 7.1-STABLE #0: Tue Feb 17 18:07:44 CST 2009
<fullermd> I guess it's probably due for an update...
<vila> fullermd: so to compare to Ubuntu, ports ~= main - base system +  universe + multiverse ?
<fullermd> (of course, _I_ update base as the first thing I do after installing a system, before I even install any ports.  But I'm nuts  :P)
<vila> fullermd: I tried that and got a nice brick yesterday night :)
<vila> virtual brick mind you, but yet, that wasn't my day :D
<fullermd> Mmm.  I don't know Ubuntu well enough to judge comparisons like that.
<fullermd> Base is...  well, base.  Kernel, basic complement of utils needed to run the system (newfs, mount, ps, ls, kill, sh, ssh, that sorta thing), and everything else is in ports.
<vila> fullermd: sounds correct
<fullermd> Don't need X or a web server or any of those weird fringe languages like python to get the system running, frex, so they're all off in ports   :)
<vila> that's not that clear when installing, but I think I get it
<fullermd> I should try clarifying those bits in my rant from $YEARS ago.
<fullermd> 'course, that's just a subset of "I should update my whole dang website"   :|
<vila> haaa 1.18 ! Thanks fullermd that was well spent minutes
<fullermd> vila: An offhand shortcut is "ls /{s,}bin /usr/{s,}bin"; that's base.
<fullermd> Anything ports does (with occasional exceptions for special cases) is under /usr/local/
<vila> and /usr/local in ports !!! That\s why I couldn't make bash my shell !!!
<vila> s/in/is/
<fullermd> bash?  You mean there are people who don't use tcsh?   :p
<vila> pff, I get out of these wars 15 years ago and settle to a shell I can use both interactive and batch :D
<fullermd> emacs?   :p
<vila> then I learned perl, then python :D
<lifeless> vila: an os isn't a shell
<vila> fullermd, lifeless: the shell is where I see most of an os from emacs :-D
<lifeless> vila: http://paste.ubuntu.com/260346/ - sneak preview for you of my next selftest patch.
<lifeless> vila: this one causes some fallout, so its not finishd yet.
<vila> ho ho, now you're getting angry :D
<vila> is that permit dir and below ?
<lifeless> yes
<lifeless> I'll think about better names
<vila> permit tree
<lifeless> doesn't take a working tree
<lifeless> possibly just permit_in_url
<vila> ok
<vila> that will not catch the access via os.xx calls, do you catch lots of pirates already ?
<lifeless> with this patch, the time for the selftest only modules drops from ~3.4 seconds to ~2.9 seconds
<lifeless> os.xx is in the pipeline
<vila> oohh, you remove test_safety_net !! wow :D
<lifeless> this catches bzrdir.open(), as it documents
<lifeless> yes, test_safety_net triggers this code :)
<lifeless> so it fails at commit, not @ arbitrary later time
<lifeless> [minor lie there; TestCaseWithMemoryTransport cd's to TEST_ROOT, and TEST_ROOT *is* permitted
<lifeless> but it was failing until I realised I needed to permit TEST_ROOT, at least transitionally
<lifeless> TEST_ROOT is only permitted for TCWMT, not for TCWT
<vila> TEST_ROOT is above self.test_dir right ?
<lifeless> yes
<lifeless> in TCWT, TEST_ROOT/NAME is permitted
<lifeless> in TCWMT,  TEST_ROOT is permitted
<lifeless> this isn't global, so its far safer
<vila> hmm, that's bad, at least it shouldn't after setUp
<lifeless> "at least transitionally"
<vila> sorry, just reading the pastebin, I lack context
<lifeless> I said that in IRC ;)
<lifeless> 23:48 < lifeless> but it was failing until I realised I needed to permit TEST_ROOT, at least transitionally
<vila> but transitionally is vague :)
<vila> I read it, just couldn't put a precise meaning on  it :)
<lifeless> vila: the actual bug is that TCWMT makes any dir on disk at all
<lifeless> have to work towards it
<lifeless> have to fix bzrlib.config
<vila> I was about to mention config files
<lifeless> yah
<lifeless> so, my approach is
<vila> I never clearly understand why it needed that
<lifeless>  - add preventative jails replacing detection jails
<lifeless>  - ix fallout
<lifeless> (wow?!)
<vila> ix ?
<lifeless>  - fix f allout
<lifeless>  - remove detection jails, things go faster
<lifeless> anyhow, midnight, and I bet I wake @ 5 again.
<lifeless> so I'd better go sleep. gnight.
<vila> how about pushing down home/work dirs to TestCaseInTempDIr
<vila> good night :)
<lifeless> yes, for sure
<vila> and the log file too :)
<vila> even if some tests needs to inherit from TCITD now instead of TCWMT
<lifeless> meh, just delete that
<vila> oh, and puting the def setUp just after the def __init__ just at the beginning of the class will get you a beer or two next time we meet :-D
<lifeless> hmm?
<vila> TCWMT.setUp is lost in the middle of the class
<lifeless> oh
<lifeless> is it in alpha order?
<vila> I bang my head against the desktop each time I missed __init__ or setUp because of that
<lifeless> here's a naughty tests
<lifeless> ======================================================================
<lifeless> FAIL: bzrlib.tests.blackbox.test_split.TestSplit.test_split
<vila> it was in alpha order, once, years ago ?
<lifeless> ----------------------------------------------------------------------
<lifeless> RemoteException: RemoteException: Traceback (most recent call last):
<lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/tests/blackbox/test_split.py", line 34, in test_split
<lifeless>     self.run_bzr_error(('.* is not versioned',), 'split q')
<lifeless> AssertionError: pattern ".* is not versioned" not found in
<lifeless> """\
<lifeless> bzr: ERROR: Attempt to escape test isolation: 'file:///tmp/testbzr-byGS2o.tmp/' ['/tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_split.TestSplit.test_split/', 'file:///tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_split.TestSplit.test_split/']
<vila> excellent, you need permit_url('q') ?
<lifeless> split a/q
<lifeless> its running the command outside of a tree altogether
<lifeless> which is walking up
<vila> hmm, isn't 'a/q' less clear ?
<lifeless> working_dir=a is the other way
<vila> on the error hand, that's clearly a test that could be done at a lower level right ?
<lifeless> quite likely
<lifeless> not a broad focus yet
<vila> cathc NotVersioned instead
<lifeless> I'm focusing on environmental stuff at the moment
<lifeless> make TestCase* as cheap as possible.
<vila> sure, not in your focu.. exactly
<lifeless> this is going to be a fun one:
<lifeless> ERROR: bzrlib.tests.blackbox.test_ancestry.TestAncestry.test_ancestry
<lifeless> RemoteException: RemoteException: Traceback (most recent call last):
<lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/tests/blackbox/test_ancestry.py", line 58, in test_ancestry
<lifeless>     self._build_branches()
<lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/bzrdir.py", line 1172, in sprout
<lifeless>     force_new_repo, stacked_branch_url, require_stacking=stacked)
<lifeless> BzrError: Attempt to escape test isolation: 'file:///tmp/testbzr-byGS2o.tmp/' ['/tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_ancestry.TestAncestry.test_ancestry/', 'file:///tmp/testbzr-byGS2o.tmp/bzrlib.tests.blackbox.test_ancestry.TestAncestry.test_ancestry/']
<lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/bzrdir.py", line 474, in determine_repository_policy
<lifeless>     policy = self._find_containing(repository_policy)
<lifeless>   File "/home/robertc/source/baz/pending/working/bzrlib/bzrdir.py", line 659, in _find_containing
<lifeless> its walking to the root to find a stacking policy
<vila> repo policy, I told you about these ones !
<lifeless> yah
<vila> triggered with TMPDIR too
<vila> scary a t first, but then I realized it wasn't harmful
<lifeless> so my hook based net catches them
<lifeless> :)
<vila> excellent
<lifeless> but need a pervasive answer to stopping them
<vila> may be we need dedicated branches for that kind of patches so that the effort can be spread
<lifeless> we may need that
<lifeless> OTOH it may be a simple annotation like '@needs_sprout
<lifeless> and that would permit_dir TEST_ROOT for now
<lifeless> I'd  like to land things that let you and others that are interested chime in in trunk
<lifeless> rather than accrue large branches outside
<vila> so it may landed somewhere even or *because* it leads to too many failures to be addressed in a single sumbission, right annotations may work too
<lifeless> I suspect determine_repo_policy is 90% of these
<lifeless> or more
<lifeless> if they were running against memory:/// it would be easy
<vila> from memory, maybe, many pirates there, but some more, I should retry the experiment, I think I had a script for that
<lifeless> 3K
<lifeless> here, I'll send you the fail.log
<vila> 3000 failures ?
<lifeless> :!subunit-filter --no-skip < failed.log | subunit-stats
<lifeless> There are 266 lines with trailing white space in 84 files.
<lifeless> There are 1961 lines longer than 79 characters in 313 files.
<lifeless> Total tests:    3212
<lifeless> Passed tests:      0
<lifeless> Failed tests:   3212
<lifeless> Skipped tests:     0
<lifeless> Tags:
<vila> ouch
 * lifeless waves gnight
 * vila waves back
<fullermd> vila: BTW, I have this perl script I threw together to munch up the selftest failures and throw out the summary I posted to the list.
<fullermd> You may find use for it, considering how many of those BSD failures seem likely to be the same root issue, whatever it may be.
<vila> fullermd: sure
<vila> the mail you're refferring to is around june 22 ?
<fullermd> Sounds right.
<vila> actually you may be interested in subunit which provided the same kind of filtering...
<fullermd> On its way.
<vila> cool
<fullermd> No cracks about code quality.  I was young, and I needed the money  :p
<vila> fullermd: oh, come on, that's perl, write once, use intensively, forget about it :D
<vila> python is far harder to use for throw-away code :-D
<vila> hu ho did I see gmake installed, wow, of course the famous BSD make ! :D
<fullermd> Well, everybody's gotta use their own local variant.  'till I get my replacement finished, of course, and everybody flocks to it.
<vila> well, I'm convinced that the problem is not with tools themselves but rather the way the are use (and in make's case abuse), I was.... impressed by the way autconf render the compile commands totally unreadable a couple of years ago...
<fullermd> Well, it had to do that.  Otherwise it couldn't add 3 minutes up front to the build time.
<samkramer> good morning
<vila> mornibg samkramer, jam
<jam> morning vila
<vila> fullermd: wow, pertty clean perl, at least relative to my standard, use strict, even use warnings ! use Data::Dumper , the perl  army knive :) Apart from the 8wide tabs, nice code :-D
<fullermd> Hey, just 'cuz a language CAN be dirty doesn't mean _you_ have to be in it.
<fullermd> (your tab size is your own problem though; mine at 4-char  :p)
<vila> fullermd: oooh, literal tabs ! yeah mine is 4-char too but translated in spaces, always
<fullermd> Yeah, I believe in tabs for indentation.
<igc> night
<fullermd> (not, of course, for alignment.  I shouldn't _have_ to say that, but it seems like so many people get caught up in conflating the two...)
 * fullermd waves to igc.
<vila> night Ian
<vila> fullermd: I believe in editors handling the indentation for me and providing a way to share settings inside projects
<LarstiQ> lifeless: he left HAR early, the 14th or 15th, to go on a biking trip
<LarstiQ> lifeless: from Utrecht to Switzerland iirc
<vila> LarstiQ: pff, and no wifi on his bike ?
<samkramer> any good links on configuring bazaar from scratch as a centralized server?
<montywi> anyone that could help to get bzr 1.17 to work with gtk 0.97.0-final ?
<montywi> After upgrading from bzr-1.13, 'bzr pull' dies with:
<montywi>   File "/usr/local/lib64/python2.5/site-packages/bzrlib/config.py", line 1246, in get_credential_store
<montywi>     cs = cs()
<montywi>   File "/usr/local/lib64/python2.5/site-packages/bzrlib/plugins/gtk/keyring.py", line 39, in __init__
<montywi>     gobject.set_application_name("bzr")
<montywi> AttributeError: 'module' object has no attribute 'set_application_name'
 * mneptok pokes poolie, igc, lifeless etc
<mneptok> our work is stalled until Monty can commit. :)
<montywi> mneptok: I got things going by downgrading to bzr-gtk 0.96.2, but it would be nice if bzr-gtk-0.97 would work too
<fullermd> Well, vila cut the release, so it's obviously his fault  :]
<bialix> lifeless: I should admit that I don't test your fixes yet
<bialix> lifeless: only cherrypicked them and planning to test them soon
<vila> montywi: that's bug #403430 and/or #397967, gobject API is a mess regarding the two functions needed there, worse than I thought it seems, please file a bug reporting what os/version you are using
<ubottu> Launchpad bug 403430 in bzr-gtk "bzr diff fails with traceback and error 'module' object has no attribute 'get_application_name'" [High,Fix released] https://launchpad.net/bugs/403430
<bialix> lifeless: quick test reveals that push now works ok, and shelve at least run without errors
<vila> montywi: in the mean time, just commenting out the offending line should do as the surrounding comments will tell you
<bialix> vila: bonsoir
<vila> bialix: hi !
 * vila fades 
<bialix> today everybody ran away when I want to ask someting
 * bialix watches for vila!
<vila-dinner> bialix: quick then, gf waiting :)
<bialix> gf?
<fullermd> I'll run away BEFORE you ask me anything, if that'll help break your streak.
<bialix> bon appetite, I'll wait
<vila-dinner> girl-friend
<Tak> hell - what was the solution to "ERROR: Operation denied because it would change the mainline history" with bzr-svn?
<Tak> girl...friend?
<bialix> so, I'm just curious, today is karmic featurefreeze, and what version of bzr was included there? I think it should be 1.18, but core devs insist on 2.0. who won in the end?
<maxb> !info bzr karmic
<ubottu> bzr (source: bzr): easy to use distributed version control system. In component main, is optional. Version 1.18-0ubuntu1 (karmic), package size 6593 kB, installed size 21304 kB
<bialix> cool, you know black magic
<bialix> then I'll continue backport fixes for some annoying bugs
<bialix> like https://bugs.launchpad.net/bzr/+bug/418931
<ubottu> Launchpad bug 418931 in bzr "AssertionError: _remember_remote_is_before((1, 18)) called, but _remember_remote_is_before((1, 15)) was called previously" [High,Fix committed]
 * Tak `bzr push --overwrite --no-strict`, wait for horrible things to happen
<bialix> !info qbzr karmic
<ubottu> qbzr (source: qbzr): Qt frontend for Bazaar commands. In component universe, is optional. Version 0.14-0ubuntu1 (karmic), package size 281 kB, installed size 1612 kB
<bialix> !info bzr-explorer karmic
<ubottu> Package bzr-explorer does not exist in karmic
<bialix> !info bzr-svn karmic
<ubottu> bzr-svn (source: bzr-svn): Bazaar plugin providing Subversion integration. In component universe, is optional. Version 0.6.4-1ubuntu1 (karmic), package size 234 kB, installed size 1540 kB
<jwhitley> Just popping in here to tell everyone that it *rocks* that "bzr upgrade bzr+ssh://..." works.  Just finished a repo conversion on a remote slice with too little memory to do the conversion locally.
<jwhitley> (That with bzr 1.18rc1)
<bialix> conversion to 2a?
<lifeless> moin
<lifeless> bialix: cool
<bialix> lifeless: hi?
<lifeless> bialix: I'm glad the fixes worked for you
<bialix> ah yes
<bialix> though new shelve lacks some nice features from old one
<jwhitley> @bialix: yes, conversion to 2a.  worked like a charm.
<bialix> that's good
<lifeless> jwhitley: thats a really good data point. We've got a desire to make upgrade always run remotely; we should document how to force it to do the work locally.
<lifeless> igc: ^ what do you think, just a line in the upgrade guide?
<jwhitley> lifeless: For some reason, I'd assumed for ages that upgrade was an inherently local operation.  Running out of memory on a remote host forced new awareness.  ;-)
<lifeless> jwhitley: oh, did I misunderstand... it ran remotely and that was good?
<lifeless> jwhitley: I thought you were saying, you had a remote branch ona server that doesn't have enough memory to do upgrades on  the server?
<jwhitley> lifeless: you're correct, sorry to randomize matters.  For no particular reason, I'd assumed that 'bzr upgrade' had to be done on the same host as the branch/repo's filesystem.  I'm terribly glad that isn't the case, since the server does not have enough memory for the ugprade.
<lifeless> ok
<lifeless> you may find you need more memory for regular push-pull operations though
<lifeless> as we're moving more and more code into the server to eliminate round trips
<lifeless> if you find this happens you can use 'nosmart+' at the front of a url to disable server side processing for that operation
<lifeless> vila-dinner: gimme a shout when you return
 * bialix wonder when vila sleep
<fullermd> Sleep is for wimps.
<fullermd> Happy, healthy, well-rested wimps.  But wimps nonetheless.
<bialix> I'm sure vila is not
<fullermd> Well-rested?  Yeah, probably not   :)
<bialix> :-#
<CaMason> how can I copy specific changes from one branch to another?
<CaMason> I have two branches, but they need to be kept slightly different
<bialix> it depends
<bialix> you can use merge -rN..M
<bialix> or rebase -r N..M
<bialix> err
<CaMason> what's the difference?
<bialix> replay -r N..M
<bialix> merge just merge
<bialix> replay will replay commit with all commit metadata
<bialix> with merge you can cherrypick changes to specific files
<bialix> not entire changeset
<CaMason> ok. Don't I lose the 'link' with a cherrypick merge?
<bialix> but merge will not carry commit metadata
<bialix> yes, you do
<CaMason> is my workflow wrong?
<bialix> that's why Daggy Fixes is better
<bialix> not necessary, it depends
<bialix> but at least I'd recommend to read about Daggy Fixes
<bialix> to understand another way
<bialix> CaMason: if you're OK to share history without sharing some changes, you can merge only istory to preserve "link", but revert wrong changes
<CaMason> so merge, commit, revert, commit?
<bialix> no
<bialix> merge, st/diff
<bialix> revert $FILES
<bialix> or shelve changes away
<CaMason> ah now that's an idea
<bialix> commit
<CaMason> shelve changes away?
<bialix> bzr shelve -h
<bialix> shelve aka selective revert
<CaMason> I see
<CaMason> what is the purpose of shelving them over reverting?
<beuno> CaMason, to bring back the change later on
<beuno> so maybe you shelve, commit, un-shelve, continue working on that change
<bialix> you may want to revert some changes in the one file and retain other changes in the same one file
<bialix> well, you can deleted shelved changes
<bialix> without bring them back
<bialix> unshelve --delete does this
<CaMason> I see, great :)
<bialix> because bzr require explicit commit after merge you can change everything you want before you commit your merge
<CaMason> I didn't realise that, thanks
<bialix> so you can do merge only for history without merging changes
<bialix> merge; revert . ; commit
<CaMason> that's precisely what I wanted
<bialix> revert . (dot is intended)
<CaMason> how about if I had a lot of files, and only wanted to keep 2 of them? Could I shelve them, then revert, then unshelve, then commit?
<bialix> ok, now you're armed
<CaMason> armed D:=
<bialix> yes you can
<CaMason> :)
<bialix> what a misterious smilie?
<CaMason> D:== that one?
<bialix> yeah. it's a cat?
<CaMason> lol no. My friend keeps using it
<CaMason> thing of that long faced guy from muppets
<CaMason> and it's reversed. a 'shocked' face
<CaMason> D:
 * bialix start s fear
<bialix> about armed: there is such russian proverbs: if you informed then you're armed
<CaMason> I figured. I wanted to double check
<CaMason> http://www.toymania.com/columns/spotlight/megabeaker.shtml
<CaMason> that's what the smiley is based on :)
<bialix> maybe I've translated it bad
<CaMason> D:=====
<CaMason> maybe it's just be being an idiot ;)
<bialix> funny muppets
<bialix> I saw this show
<igc> morning
<bialix> igc: hi
<bialix> you're early today
<lifeless> hi igc
<bialix> lifeless: btw about test. is there a way to test NotBranchError?
<lifeless> bialix: in what regard?
<bialix> I have some code that trying to open branch and show error dialog if there is none
<bialix> I've mocked gui
<lifeless> raise errors.NotBranchError("woo hoo")
<lifeless> ?
<bialix> inside function?
<bialix> how?
<lifeless> well just like that
<lifeless> raise the exception wherever you want it raised
<bialix> lifeless: http://pastebin.com/mf2f7519
<bialix> I want to test the code path for except NotBranchError
<Sjors> hey :)
<Sjors> just reported this bug: https://bugs.launchpad.net/bzr/+bug/420188
<ubottu> Launchpad bug 420188 in bzr ""Svndiff contains a too-large window" error" [Undecided,New]
<bialix> I can't create empty dir in test sandbox
<bialix> lifeless: err, I can, but empty dir won;t raise NotBranchError because root of sandboxed temp dir for tests has guard tree
<lifeless> bialix: try this
<lifeless> make a dir
<lifeless> bzrdir.BzrDir.create('dir')
<lifeless> this will make an empty dir
<lifeless> should stop the search and raise NotBranchError
<lifeless> alternatively you could hook into BzrDir.pre_open
<lifeless> and raise NotBranchError from there yourself, for the path that you'll be opening
<lifeless> that would be a little harder to write the code for; but do less IO/be faster
<bialix> I'll try to play with it
<lifeless> its basically
<lifeless> bzrdir.BzrDir.hooks.install_named_hook("pre_open", my_deny_function, "deny a directory")
<lifeless> with
<lifeless> def my_deny_function(transport):
<lifeless>     raise errors.NotBranchError(transport)
<lifeless> this is a global hook, gets reset at the end of the TestCase automatically.
<bialix> pre_open is new thing?
<lifeless> 1.14
<bialix> cool
<bialix> that's nice
<bialix> thanks
<bialix> Sjors: looks like the bug actually in bzr-svn plugin
<Sjors> bialix: yes, indeed
<bialix> retargeted
<lifeless> vila-dinner: ping
<poolie> hello bialix, lifeless, vila, igc,
<lifeless> hi poolie
<lifeless> poolie: oh, btw - http://twitter.com/search/users?q=martin+pool&category=people&source=users
<poolie> huh
<poolie> updated, it may take a while
<lifeless> hi jcastro
<lifeless> figured you should be around here as you deal with upstreams <-> launchpad, and we're a big part of that
<lifeless> poolie: remind/confirm 12 for lunch
<vila> back from movie, lifeless ? I won't stay long though
<poolie> still fine
<poolie> hello vila
<lifeless> vila: hi
<vila> hey :-D
<lifeless> vila: what movie?
<vila> pff, a story about the end of world, french actors, quite good, very strange story. a bit a la Bunuel :)
<vila> s/the/an end/
<lifeless> vila: I highly recommend district 9
<vila> k, noted, will check availability :)
<lifeless> vila: I'm thinking of recording somewhere the test themes we have to work through to solve this problem
<lifeless> a bit of a todo
<lifeless> we could use bugs
<lifeless> or a wiki page
<lifeless> or something
<vila> amazing, I was thinking about using a wiki page to handle bug lists as an alternative to assigning bugs to myself without working on them... But you're talking more about something like the url jml gave for launchpad I presume ?
#bzr 2009-08-28
<lifeless> I haven't seen that
<lifeless> bzr list?
<vila> poolie: I submit a backport on lp:bzr/1.18, hope it's ok with you (windows lock)
<poolie> vila, you mean a mp back into 1.18?
<poolie> or something else?
<vila> no here, yesterday, you didn't remember at first and then siad you edited it
<lifeless> vila: oh yes, that wiki page.
<lifeless> vila: uhm, something less broad
<lifeless> 'problems to solve'
<vila> poolie: http://bazaar.launchpad.net/~bzr-pqm/bzr/1.18/revision/4599
<vila> lifeless: ok, I will think about it, at least I should brain dump a bit about incremental selftest
<lifeless> vila: testing based on changes?
<vila> yup
<lifeless> vila: I should give you my code that does that then :P
<vila> You surely should push that somwhere :)
<poolie> ok i see
<poolie> yes, that's fine
<vila> poolie: great
 * vila goes to bed
<lifeless> vila: gnight
<lifeless> vila: theres another test patch for your pleasure tomorrow :P
 * lifeless sighs at check
<lifeless> its still a very ugly duckling
<poolie> quick poll: how does http://launchpadlibrarian.net/30906325/download.png look for a mockup of the downloads page
<lifeless> seems fine. The how-recently-it-was-downloaded text is a bit awkward
<lifeless> it makes the table taller
<poolie> true
<lifeless> for something ~ noone looking at the page cares about
<poolie> this bug was actually about including the release notes
<poolie> at the moment the page is too barren=
<poolie> but it's a good poitn
<lifeless> oh right
<lifeless> perhaps expandable?
<lifeless> This release of Bazaar marches on ... \n
<lifeless> [more ...]
<lifeless> some projects have very long release notes
<AfC> poolie: feedback: "so Bazaar is a Windows only project?"
<AfC> "Lots of Windows and .exe on that page. I use Linux, though. Guess I'll go elsewhere"
<lifeless> heh
<poolie> lifeless: lp distinguishes the notes from the changelog
<poolie> the former is supposed to be fairly concise
<poolie> afc, excellent point
<lifeless> poolie: we're pushing it on that page then
<poolie> though kind of a larger bug
<lifeless> poolie: Alternatively, put them under the table.
<AfC> poolie: (ie, even if it's essentially no-op, links to either direct .deb & .rpm files, or at the very least links to instructions one per distro. Windows should, at best, just be another distro.
<lifeless> Windows PPA's!
<lifeless> \o/
<AfC> heh
<poolie> direct integration with Steam
<lifeless> yup
<lifeless> poolie: have you spoken to valve?
<AfC> poolie: (ie, you and I know what to do with a .tar.gz, but ...)
<poolie> this is kind of the 'details' view of downloads
<poolie> both on the bzr site and the launchpad project page, there should be an easy way to say
<lifeless> poolie: I think the blurb we have should include links back to the wiki downloads page, or something
<lifeless> poolie: as a workaround
<AfC> poolie: also, I wouldn't include download numbers. Who cares? My software gets downloaded approximately 4 times per release. Once by Gentoo, once by Debian, once by Launchpad for it's own twisted and nefarious purposes,...  hm yup, that's about it.
<poolie> "i'm running (windows/ubuntu/mac os/...) and I want the (latest stable/latest beta/...) release"
<AfC> poolie: yeah, I'd do it with icon pairs:
<poolie> anyhow i spent ages yesterday afternoon on launchpad
<poolie> it's enough for now
<AfC> Tux / Shadowman ; Tux / Debian Swirl ; Tux / Ubuntu thing ; ... ; Apple logo / MacOS smile ; Microsoft logo / Windows logo
<poolie> bialix, re https://answers.edge.launchpad.net/bzr/+question/60728 shouldn't bzr on win32 automatically use paramiko if you don't have putty?
<poolie> or is that only after your change?
<poolie> lifeless: are you doing bug 416732 now, or today?
<ubottu> Launchpad bug 416732 in bzr "check reports "Missing inventory {('TREE_ROOT'..." for trivial non-rich-root branch" [Critical,Confirmed] https://launchpad.net/bugs/416732
<lifeless> poolie: nearly finished
<poolie> yay
<poolie> but
<poolie> given your comments about assignment, you should have assigned it:)
<lifeless> I wish launchpad wouldn't mail me twice
 * lifeless files a bug
<poolie> for what?
<poolie> or just at all? :)
<jml> poolie, spiv just told me about your quandary with the review system
<jml> poolie, change the review team of the 2.0 branch to something that you're a member of, and I think everything will work out just fine.
<poolie> how do i do that?
<jml> https://code.edge.launchpad.net/+branch/bzr/2.0
<jml> look for "Review team"
<poolie> i can see it there
<poolie> i can't see any control to change it
<jml> ahh.
<jml> there's a bootstrapping problem!
<lifeless> spm: hi
<poolie> that's one word for it :)
<poolie> heh
<spm> lifeless: hey hey
<lifeless> spm: you can loging as pqm-launchpadthingy right?
<poolie> spm, would you please strap our boots?
<lifeless> spm: so please do ^ the above to make it bzr-core [thats right isn't it poolie?]
<spm> -ENFI what you're talking aboot ? :-)
<jml> poolie, I find it odd that you have a branch _created_ by a robotic user.
<lifeless> spm: and update the docs, to do that on every new release branch
<lifeless> jml: it pushes, the branch is made
<poolie> jml, also, (and this is now your problem :-P) launchpad has a bit of a general problem in describing why you can't do something, or who is allowed to do something
<poolie> specifically it doesn't :)
<jml> poolie, yes.
<poolie> it reminds me a bit of interacting with some govt departments
<lifeless> spm: go to our bzr2.0 branch
<lifeless>  on launchpad
<poolie> you're just told you're wrong
<poolie> not what to do
<jml> poolie, that's a low blow.
<spm> lifeless: the link above? yup.
<poolie> fortunately we have very helpful developers :)
<lifeless> spm: not quite
<spm> ah
<lifeless> spm: that the milestone
<poolie> did spm make the branch while logged in as bzr-pqm?
<lifeless> poolie: pqm made it when pushing
<poolie> oh i see
<lifeless> which spm will have done from the shell on balleny
<spm> yes
<poolie> it almost seems like you need a separate acl for "allowed to modify the branch" from "allowed to modify branch metadata"
<lifeless> spm: ok, are you there?
<poolie> i want the second, and _not_ the first
<spm> lifeless: I think so :-) https://code.edge.launchpad.net/~bzr-pqm/bzr/2.0
<jml> poolie, maybe.
<lifeless> poolie: you want ^pqm to have^ , right?
<poolie> but that would complicate it
<poolie> no i want ~mbp to have
<poolie> or ~bzr-core
<lifeless> spm: on the right, set the reviewer
<poolie> i want bzr-pqm to be able to push
<poolie> there's a longstanding request that project owners should be able to sudo change any contained object, but that's controversial
<lifeless> poolie: I think you've confused me with your defintions of branch / branch metadata
<lifeless> we want bzr-core as the reviewer team, right?
<poolie> ~mbp should be able to change eg the review team of this branch
<spm> lifeless: the review team is currently bzr-pqm
<poolie> ~mbp shouldn't be able to push to this branch
<poolie> that's the behaviour we actually want
<lifeless> spm: change it please, to bzr-core
<poolie> it's what we're executing indirectly through spm here
<lifeless> poolie: yes, fully acking here. One way to do that would be to add permissions to series branches
<spm> lifeless: done
<lifeless> I don't mean manual config, I mean 'the owner of a series can alter data about the branch the series is connected to'
<poolie> i'm not immediately suggesting coding that in because it may magnify complexity
<spm> poolie: by proxying thru me - doesn't that imply you have the sudo perms? eg sudo spm do XYZ. ??? ;-)
<lifeless> spm: thanks
<poolie> right, thatseems to make sense
<lifeless> spm: sudo make me a sandwich
<poolie> shut up and make me a sandwich
 * jml has to go
<poolie> :)
<lifeless> poolie: reviewer team set to bzr-core; please ack that that was the desired team.
<spm> lifeless: I said poolie; not you; this attempt has been logged.
<poolie> yes
<lifeless> spm: sudo make me a sandwich
<lifeless> spm: sudo make me a sandwich
<lifeless> spm: sudo make me a sandwich
<lifeless> spm: sudo make me a sandwich
<spm> nagging doesn't work either. I haz a 6yo recall. :-D
<lifeless> its fine, I don't like sandwiches anyhow
<lifeless> :P
<glyph> does bzr allow concurrent writers to a shared repository?
<spm> bwhahahahahahaha
<glyph> spm: was that an answer to me? :(
<poolie> glyph: yes
<lifeless> glyph: yes
<spm> glyph: no, sorry. to a thread with lifeless. :-)
<lifeless> glyph: no the answer was not to you.
<poolie> for about a year or more
<spm> my coworkers. charming folks.
<glyph> okay
<glyph> so, I'm checking out Twisted trunk, and a branch, from Launchpad
<glyph> concurrently
<lifeless> glyph: it doesn't allow concurrent writers to a branch
<glyph> and the twisted trunk checkout is spewing "ï»¿inconsistent details in skipped record"
<lifeless> glyph: because of domain model, nottech.
<glyph> lifeless: right, that makes sense.
<glyph> should I be worried about these errors?
<lifeless> glyph: so, that means either a bzr-svn bug
<lifeless> [likely]
<lifeless> or you [or launchpad] have reconciled and the other has not
<lifeless> its nothing to do with the concurrency
<lifeless> glyph: I will note though that you probably have a lot of duplicate data being pulled doing that.
<glyph> lifeless: I'm going to try this again because I've screwed up a bunch of stuff and I don't know if I can reproduce this repository reliably
<lifeless> glyph: you can just ignore it
<lifeless> glyph: file a bzr-svn bug with the log/output
<lifeless> glyph: and keep on working
<lifeless> poolie: launchpad has way to many bits
<lifeless> e.g. whats a confirmed-assigned vs in-progress-assigned vs inprogress-unassigned
<poolie> regarding ACLs?
<poolie> yeah
<poolie> there's only one logical state change here: robert is working on it
<poolie> but it's getting better!
<poolie> i'm pretty sure there used to be priority and severity?
<poolie> and look at all the bits on blueprints!
<glyph> lifeless: bugs in my VCS scare me :-\
<glyph> lifeless: is it a harmless bug?
<lifeless> glyph: yes; it means that two bits of inferred metadata (file graphs) differ in the two repositories, *and* that one repo chose to send that text to you though you already have it.
<lifeless> The worst thing that can happen(assuming you're using 1.RECENT) is that 'bzr log file' might show too much/too little.
<glyph> man, this is taking a really long time
<lifeless> glyph: the pull?
<glyph> is there any option or configuration that I might have forgotten which would cause a download to come down at 2kb/s?
<lifeless> glyph: ~/.bazaar/locations.conf, set [/]\ngo_slow=False
<lifeless> glyph: more usefully, what protocol are you pulling over?
<glyph> lifeless: bzr+ssh
<lifeless> glyph: are you suffering any packet loss or the like?
<glyph> mtr says no
<lifeless> spm: ping
<lifeless> spm: meet glyph. glyph is seeing 2/kb [do you mean bits or bytes] a second downloading from codehosting over bzr+ssh
<lifeless> glyph: also, is your machine thrashing
<lifeless> do you have spare memory
<spiv> glyph: whihc branch?
<lifeless> is your cpu maxed
<glyph> lifeless: nope
<glyph> spiv: lp:twisted
<glyph> lifeless: my CPU seems to be oscillating quite a bit; between 5% and 80% utilization, roughly
<glyph> lifeless: sorry, KB/s, as reported by bzr itself.  I don't know ;)
<glyph> you tell me if it's bits or bytes
<spiv> bytes :)
<spiv> Oh, and which version of bzr are you using?
<glyph> spiv: 1.17
<glyph> spiv: most recent from the hardy PPA
<spiv> Hmm.  Into an empty shared repository?
<glyph> Yep.
<glyph> created as --2a, as suggested by the web page
<spiv> Ah.
<spiv> Oh!
<spiv> You're hitting two bugs,
 * spm defers all codehost slowness operational issues to spiv as bzr bugs for the forseeable future
<spiv> the first is relatively minor, and it's that branching into an empty shared repository wastes a bit of time recursing through the remote revision graph first looking for common history with the existing repo that is your target.
<lifeless> glyph: capital B - bytes
<spiv> But the second is that with that version of bzr cross-format fetches over the network do a ridculous number of round trips.
<lifeless> glyph: stop the operations
<lifeless> glyph: do this:
<lifeless> bzr branch <launchpad's trunk> /tmp/old
<lifeless> cd /old
<lifeless> bzr reconcile
<lifeless> bzr upgrade --2a
<lifeless> delete the repo you had made
<lifeless> and bzr push /path/to/repo/trunk
<lifeless> then go back to doing whatever
<lifeless> glyph: 2a is radically different to older formats. It would be wonderful if twisted upgraded all its branches.
<glyph> lifeless: I'm really confused :(
<glyph> http://twistedmatrix.com/trac/wiki/BazaarMirror
<lifeless> poolie: bug 420247
<ubottu> Launchpad bug 420247 in malone "assigning bugs generates spam [and not just the bug-metadata-change]" [Undecided,New] https://launchpad.net/bugs/420247
<spiv> The cross-format slowness is fixed in 2.0rc1 (but requires both client and server to be that new)
<glyph> is that page wrong?  lp:twisted doesn't require rich roots?
<lifeless> glyph: 2a is more than rich roots; its a change from xml to temporal hash tables
<spiv> glyph: lp:twisted requires rich-roots, but on launchpad it's in 1.9-rich-root format, not 2a format.
<lifeless> ok
<spiv> 2a is newer, faster, smaller, sexier.
<lifeless> lets fix launchpad
<lifeless> glyph: -> #twisted
<spiv> But it's a different format than 1.9-rich-root, so it hits a crummy code path that only got fixed a couple of weeks ago.
<spiv> Or rather, a code path that was optimised for local fetches.
<glyph> lifeless: I'd rather not discuss the specifics of Twisted.  Obviously in order to use bzr I need to know a lot about formats and conversions in general.  So I'd appreciate it if you could explain how to detect the format of a branch before fetching it, so I can create an appropriately-shaped shared repository first
<spiv> "bzr info URL"
<lifeless> glyph: bzr info -v url, to be robust
<spiv> (or look at the branch's web page on Launchpad...)
<lifeless> bzr info url won't tell you enough sometimes
<lifeless> glyph: we're trying to fix the issue with formats.
<lifeless> glyph: its a great sadness that its the way it is
<glyph> lifeless: well, to your credit, at least when it flat out doesn't work it tells me why :)
<lifeless> small mercies ;)
<glyph> okay
<glyph> I created with --1.9-rich-root-pack and now everything's working great.
<glyph> How come sometimes 'bzr diff -r ancestor' works, and sometimes it doesn't?
<spiv> glyph: sometimes it doesn't?
<spiv> (more details, please :)
<SamB_XP> lifeless: so ... what's the client-side upgrade picture going to look like after lp:bzr is converted ?
<lifeless> SamB_XP: for branches of bzr itself?
<SamB_XP> yeah
<SamB_XP> I, for one, don't think I have enough RAM to convert an entire branch to 2a
<lifeless> of bzr?
<SamB_XP> at least, not in a reasonable amount of time
<SamB_XP> yeah
<lifeless> how much ram do you have?
<SamB_XP> 512 MiB total
<lifeless> thats tonnes
<SamB_XP> ... well, it was taking forever 2--3 weeks ago ...
<lifeless> SamB_XP: please try and file bugs
<lifeless> worst case though, pull fresh, make a repo, branch your old branches into it after trunk from the web is in it.
<lifeless> I have a train to catch -> poolie
<SamB_XP> ... anyway, I was just hoping there would be well-publicized directions for how to upgrade without converting lp:bzr itself
<dvheumen> lifeless, hi, about the "Missing inventory" bug ... I've been looking through the source code yesterday, but I couldn't make much of it (because of my very limited experience with python and bzr). But I did notice that *every* revision is reported as missing and this same set of keys is reported as absent in bzrlib/knit.py line 1416: absent_keys = keys.difference(set(positions))
<dvheumen> Hopefully it's some useful information
<dvheumen> anyway, you don't seem to be here at this moment so I'll post it as a comment in the bug
 * igc lunch and medical appointment - bbl
 * SamB_XP suddenly wonders what prominent bzr devs do bzr-relevant blogging ...
<lifeless> planet.bazaar-vcs.org
<SamB_XP> hmm ...
<SamB_XP> ... probably don't want to subscribe to that ...
<lifeless> SamB_XP: I'm on advogato if you want to subscribe directly; or twitter or facebook
<lifeless> review wanted: https://code.launchpad.net/~lifeless/bzr/bug-416732/+merge/10828
<lifeless> this is for 2.0 and trunk
<SamB_XP> lifeless: ah, that's a bit more my size ;-)
<poolie1> spiv, how is bug 406687?
<ubottu> Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Critical,In progress] https://launchpad.net/bugs/406687
<mwhudson> i have the very vague impression that there's a bug where bzr up in a checkout attempts to write lock the source
<mwhudson> can someone confirm/deny this?
<AfC> mwhudson: that sounds familiar (and horrid)
<poolie1> mwhudson: yes
<vila> hi all
<vila> lifeless: check your comment 'is da... below' doesn't make sense to me, the rest is ok though ;D
<vila> lifeless: and you dind't assign the bug to yourself it seems... (despite your comment reserving it... (you're obeying your own rules a bit too much here :))
<vila> err, strange... ha ok, page refresh missing, forget me
<poolie1> cheer squad :)
<poolie1> hello vila
<igc> back
<igc> hi vila, poolie1
<vila> hi igc
<mwhudson> poolie1: i found the relevant but report in the end
<vila> hi poolie1 (1!1!! :)
<spm> vila: there can be only ... 1 ;-)
<vila> spm: Referring to 'The One' with Jet Li you are ? :)
<spm> nope - never seen a Jet Li movie. was actually thinking Highlander :-)
<vila> spm: pff so last century... showing your age here ;-P
<spm> vila: I have 2.5 months of being "young" for values of "young". I intend to maximise that period!
<spm> 2.5 months *left*
<vila> spm: I personally decided, a couple of months ago, that I will stay as young as I was 20 years ago, for the rest of my life. Sounds good so far :D
<spm> vila: !?!?! why would you want to stay 63? wouldn't you be better off aiming for .. say.. .30? :-P
<vila> spm: your forgit do divide by 3, 63 is 7 * 9, so people born that year got a special exception :)
<spm> I don;t suppose there's any chance of that exception being extended to those from 69?
<jml> spm, it depends
<jml> spm, when did you get your first real six string?
<spm> jml: sadly still waiting....
<jml> dammit now I have that song stuck in my head
<spm> ha! revenge is sweet! ;-)
<vila> spm: 69 is 3 * 23, 23 is prime but 17 in hex so that's too young, sorry
<spm> vila: I think my brain just imploded on that!
<vila> spm: Try http://bazaar-vcs.org/Quotes any day :) (Search for SHA256 for example :)
<poolie1> why does russel have to use such breathless subject lines?
<vila> poolie1: nice reply... :)
<poolie1> mm, to russel?
<vila> yes
<poolie1> i probably should have changed the subject myself
<bialix> poolie1: paramiko used by default even without my patch
<poolie1> bialix: hm i wonder what's happening then
<bialix> without looking in .bzr.log I even don't guess
<vila> to your initial question, I was thinking that I noticed a trend in being harsh with us to get more/quicker feedback... dunno what we can do about it, I think it's human :-/
<bialix> answer opened in February, today is August
<poolie1> mm, i think it is
<bialix> something bad with topic starter install
<poolie1> probably
<bialix> poolie1: my best gues he can BZR_SSH=plink but removed plink at some point
<poolie1> probably
<bialix> ?
<poolie1> we should probably change that detection code
 * bialix wonder what was initial question to vila, but maybe I should not ask
<vila> bialix: you asked. You're right. You shouldn't have :-P
<bialix> bump
<bialix> sorry
<vila> oooops
<vila> too late to explain the joke obviously :)
<poolie1> about him being harsh to get a response
<poolie1> maybe
<poolie1> vila, i'm just going to send a metronome
<poolie1> kinda rusty mentronome actually :)
<poolie1> what are you planning to do today?
<vila> getting back to conflicts resolution I hope
<vila> while keeping an eye on a couple of reviews for jam
<vila> bug #402652 looks too tied to what jam is working on already to be addressed before he finished #402645
<ubottu> Launchpad bug 402652 in bzr "smart fetch for --2a does not opportunistically combine groups" [Critical,Triaged] https://launchpad.net/bugs/402652
<vila> bialix-mute: oh, you got the joke finally :-D
<bialix-mute> *nods*
<vila> pfew
 * bialix-mute got the mail. vila you're absolutely right
<poolie1> vila i'd expect Mr 3-minute-test-suite not to have typos in his tests :-P
<poolie1> vila, could you see if he wants a buddy on them when he wakes up?
<poolie1> otherwise, conflict resolution ++
<vila> LOL, just got the typo joke :)
<vila> rats, he's gone, did my jokes smell bad today or what ?
<vila> fullermd: will you run away if joke about freebsd being loser to geentoo than I thought ? Or will I make Afc goes away instead ?
<vila> Ha, Afc quit *before* the joke even...
<LarstiQ> maybe you should stop now ;P
<vila> fullermd: ha ha, no reply, very funny
<vila> LarstiQ: You're kidding ! I've got an infinite supply of jokes for the day with such a start :)
<vila> montywi, mneptok : did you file a bug about keyring ?
<gga> Hello! I have some trouble when using " bzr test-gtk". Can somebody help me ?
<cody-somerville> Lets say I've branched a branch and I've committed some changes
<cody-somerville> And I want to create a patch to send to a mailing list
<cody-somerville> How would I go about doing that?
<cody-somerville> The upstream uses git so I don't want to create a bundle
<cody-somerville> besides using bzr diff I mean
<cody-somerville> I'd like it to work like the git command does I guess
<LarstiQ> cody-somerville: if you have bzr-git, `bzr send` should generate a git consumable patch
<cody-somerville> really?
 * cody-somerville tries.
<cody-somerville> How can I tell that its git consumable?
<cody-somerville> LarstiQ, how do I consume with git?
<LarstiQ> cody-somerville: git apply or somesuch?
 * LarstiQ hasn't used it, only knew jelmer wrote it
<vila> cody-somerville: I think you need an option to send to specify the git format...
<sabdfl> morning team bzr
<sabdfl> is it possible to tell the version of a remote bzr server?
<sabdfl> for example, bzr version bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk/
<vila> sabdfl: from the command line, I'm pretty sure you can't
<sabdfl> thanks vila - can you file a bug on that please? seems like a reasonable thing to do
<vila> sabdfl: I'll check the existing one first, the subject comes back often, may be on 'bzr info' instead of bzr version though...
<sabdfl> why? it's the version i want
<sabdfl> i don't mind if it's also displayed on info -vv
<vila> bzr version is for the client
<sabdfl> says who
<vila> ?
<vila> you don't specify an url to bzr version
<vila> bzr info <url> gives you info about the url, including ... bug #308472
<ubottu> Launchpad bug 308472 in bzr "bzr info should show the server version" [Medium,In progress] https://launchpad.net/bugs/308472
<vila> sabdfl: here you are, enjoy the patch :-D
<sabdfl> vila
<sabdfl> i would like this information on bzr version if a URL is supplied
<sabdfl> don't tell me that "version does not take a URL"
<sabdfl> i'm asking that you add that ability
<vila> sabdfl: while filing a bug for that, I came across bug #308472, which already implements that on bzr info, I could add your comment there but... I think it makes more sense to accept that patch than to change the meanign of bzr version...
<ubottu> Launchpad bug 308472 in bzr "bzr info should show the server version" [Medium,In progress] https://launchpad.net/bugs/308472
<vila> the rationale for adding it to info rather than version is that:
<vila> version url can gives info only if url is a smart server,
<sabdfl> that's true for info, too
<vila> whereas info will display it additionally when talking to a smart server
<vila> now, it may seem weird to not be able to ask for the server info with 'bzr version <server>' but....
<sabdfl> ok, i hear you, and appreciate the feedback, but the decision is to add an optional <url> to bzr version
<vila> ...but maybe we can fill the other slots that bzr version displays for the server...
<vila> that's more work though, so I'll see that the info patch lands and file a bug for bzr version with that discussion
<vila> sabdfl: what prompted your question at start ? Only the bzr version or also the python version used there, the various paths the revid, etc ?
<sabdfl> i just wanted to know the version of a server i was using
<sabdfl> and that was the command i typed
<sabdfl> then i remembered i did the same thing previously
<sabdfl> i believe others will have done the same
<vila> I agree
<sabdfl> please, file the bug and implement it after 2.0
<vila> So the basic info you wanted is what the info patch provides, adding an url to bzr version is what I file the bug with
<vila> right
<sabdfl> post-2.0 we will focus on user experience, and I'll be part of the review of that, so i'm confident this will pass review
<vila> sabdfl: :-D
<vila> sabdfl: bug #420408 if you want to subscribe
<ubottu> Launchpad bug 420408 in bzr "bzr version URL should display smart server information" [Undecided,Confirmed] https://launchpad.net/bugs/420408
<fullermd> vila: Whutwhut?  You?  Joke?  I didn't authorize that...
<vila-bike> hehe, timing is everything, I should quit though ;)
<bialix> abentley: hello
<abentley> bialix: Hi.
<bialix> abentley: I want to ask about your nested trees
<bialix> as you maybe know I have plugin scmproj which is poor emulation of NT
<abentley> Right.
<bialix> because there is still no working solution I want to continue improve my plugin, because I'm using it in my real job
<bialix> I'd like to reuse as much as possible of your work
<bialix> I think I need your CompositeTree
<bialix> is it possible to reuse it regardless of entire NT infrastructure?
<bialix> abentley: i.e. how standalone CompositeTree is?
<bialix> err, sorry. I wonder if I can just get your code hack it a bit and reuse for my needs?
<abentley> bialix: it requires the contained trees to be referenced by TreeReferences.
<abentley> bialix: I don't think that it would be easy to change that requirement.
<bialix> can I create fake TreeReferences?
<bialix> I wonder if some generic solution possible here
<abentley> bialix: The code is here: http://bazaar.launchpad.net/~abentley/bzr/nested-trees
<bialix> i.e. for Bzr-Trac plugin there is used some generic code that represents multiple of standalone branches as big mixed branch
<bialix> abentley: your mereg proposal for NT docs seems to be approved. At least it in the approved but not merged queue. Or am I wrong?
<abentley> It's a bit fuzzy what state it's in.
<abentley> bialix: Martin approved the text without approving the plan.
<bialix> do you think you will continue to work on NT in next 3-6 months?
<bialix> abentley: it seems a bit controversial?
<abentley> bialix: I don't think it's likely.  I was working on Canonical time, and my team needs me right now.
<bialix> I understand.
<bialix> But I need something like scmproj right now too, so I'm trying to figure out what I can reuse
<abentley> bialix: That's a sane thing to do.
<bialix> in the ideal worls I'd like to make scmproj as much as possible similar to future NT so I can switch painless
<bialix> some of you rideas (AFAI) is very close to my implementation
<bialix> your ideas, sorry
<bialix> I'll try to read your current code, so I'll have more specific questions
<bialix> abentley: last question: did you try to use your current code for real trees?
<abentley> bialix: Like real codebases?  No, not for a couple of years.
<bialix> couple of years? ok, it's a joke
<bialix> we're using scmproj for ~ 6 months
<bialix> I have enough feedback to understand what's wrong with my current scmproj
<bialix> so do you think you'd like to change something in your current concept?
<abentley> bialix: Not a joke, I started work on nested trees in 2006.
<bialix> sorry, I misunderstood
<bialix> I knew you started them a lon ago
<bialix> but it seems they were more prototype
<bialix> scmproj is ugly but we realy using it
<abentley> bialix: They weren't meant as a prototype, and they haven't changed significantly since I stopped working on them in 2007.
<bialix> ok, but there was no much news so most of the people know they're planned but not exist. at least I was under this impression.
<bialix> maybe I was wrong
<abentley> bialix: They're planned, there's an implementation, the implementation is out-of-date with the current plan.
<bialix> "the implementation is out-of-date with the current plan" -- what it means?
<bialix> you said Martin did not approved plan
<bialix> ok, sorry for bother you. thanks
<ajb> Can anyone explain what "M 040000 - content" means in the context of a fast-export?
<Wox> someone that has time for a question?
<mgedmin> hi folks!
<mgedmin> suppose I've got an svn repository full of unrelated little tools, and I'd like to extract the history of a single file into a new bzr repository
<mgedmin> how would I go about that?
<mgedmin> svnadmin dump + svndumpfilter + ?
<mgedmin> svnadmin import + bzr-svn?
<phinze> sorry if this is a FAQ, but what is the current status of Cherry-pick metadata in bzr?  i.e. if i merge a single revision from one branch to another i get the file changes but no pending-merge revisions
<phinze> and i found a blueprint from 2005 about it but no other info
<phinze> mgedmin: that sounds like it would work
<mgedmin> it did work :-)
<phinze> huzzah ;)
<bialix> hi garyvdm
<garyvdm> Hi
<bialix> is there any deadline for 0.14.1?
<garyvdm> before bzr 2.0 final
 * garyvdm is working on bug 420534
<ubottu> Launchpad bug 420534 in qbzr "When in ui-mode, some errors go to the console." [Undecided,Confirmed] https://launchpad.net/bugs/420534
<bialix-qbzr> garyvdm: look at util.py open_tree
<garyvdm> funny - was just looking at it.
<bialix-qbzr> I'm working on better wrapper class to open tree or branch and show errors better
<garyvdm> I don't even think we need a wrapper class.
<bialix-qbzr> do you want to use some universal error handler instead?
<garyvdm> yes
<garyvdm> Which is currently in place
<bialix-qbzr> I need wrapper class to simplify args passing
<bialix-qbzr> and to solve bug #.. wait
<bialix-qbzr> bug 387320
<ubottu> Launchpad bug 387320 in qbzr "qgetupdates doesn't refresh working tree when asked" [Medium,Confirmed] https://launchpad.net/bugs/387320
<bialix-qbzr> I'm tired about duplicating the same code to support both treeless, standalone and light co cases
<bialix-qbzr> so I want wrapper
<bialix-qbzr> garyvdm: btw, weird question that bother me a bit: can we move some of our GUI-specific code to some subpackage e.g. lib/ui and keep in lib/ only algorithmic stuff?
<bialix-qbzr> we have ~66 files in lib/ now
<bialix-qbzr> half of them is auto-generated UI files and simple dialogs
<bialix-qbzr> other half very complex algorithms and com[lex GUI like qlog, qdiff, qann, qbw
<bialix-qbzr> I wonder if we split them does it makes the code base any clearer? or you better keep current layout?
<bialix-qbzr> garyvdm: ^
<garyvdm> I was thinking we could split in into 1. reusable widgets (currenly log, treewidget), 2. browseing windows (log, annotate, browse, diff), and 3. actions windows....
<bialix-qbzr> and 4. inner stuff
<bialix-qbzr> like bugs.py, commmmit_data.py
<garyvdm> util, trace,
<garyvdm> commands
<bialix-qbzr> commands is special
<garyvdm> subprocess
<bialix-qbzr> I like your 3 categories
<garyvdm> or subprocess could go with all the actions windows.
<bialix-qbzr> perhaps
<bialix-qbzr> or keep it in the utils category
<bialix-qbzr> so 4 is utils category
<bialix-qbzr> or something like that
<bialix-qbzr> the edge is fuzzy here
<garyvdm> bilaix-qbzr: I would leave the common thing in lib/ - like this http://paste.ubuntu.com/261126/
<bialix-qbzr> garyvdm: +1
<bialix-qbzr> I think I'll wait with such serious changes till 0.14.1 is out
<garyvdm> This is not important to me, but I might help new contributors. There are lost of other things I would prefer to spend time on..
 * bialix-qbzr too
<garyvdm> If you want to do it thats fine..
<bialix-qbzr> yes, I want if you do not object
<garyvdm> No objections..
<bialix-qbzr> great
<bialix-qbzr> right after 0.14.1
<bialix-qbzr> year ago I moved everything into lib/ now time came to change layout again because qbzr is growing too much!
<garyvdm> Does not have to wait. Last time I checked, the version control we use is very good a handling renames :-)
<bialix-qbzr> I'll have to change a lot of imports statements
<garyvdm> bailix-qbzr: I remember that was just after I started contributing...
<bialix-qbzr> this may introduce conflicts on merging 0.14 branch back
<garyvdm> Not a problem.
<bialix-qbzr> garyvdm: you joined in June or July 2008
<bialix-qbzr> ~ year ago ;-)
<bialix-qbzr> and this was a great year, you rock
<garyvdm> Only a year - seems much longer.
<garyvdm> Ah - I was doing some hacking on bzr-gtk before qbzr
<bialix-qbzr> check qlogs :-D
<bialix-qbzr> I was under impression you working on bzr-gtk a lot
<bialix-qbzr> always wonder why you switching
<bialix-qbzr> do you remember?
<garyvdm> The people I was developing for are Windows users.
<fullermd> He's making the rounds of toolkits.  Next year he'll be working on bzr-motif.
<garyvdm> qbzr much better than bzr-gtk on windows
<bialix-qbzr> fullermd: lol
<bialix-qbzr> garyvdm: yes, qt is much nicer on windows
<bialix-qbzr> so I'm grateful to those people
<garyvdm> I actually started on bzr-xul - but did not do much...
<bialix-qbzr> never heard
<garyvdm> xul is mozilla's toolkit
<fullermd> That's pretty frightening...
<garyvdm> firefox, thunderbird, etc are built with xull
<garyvdm> *xul
<bialix-qbzr> I'm slightly aware. Never heard about "bzr-xul"
<garyvdm> Ah - it never got further than mu hdd
<garyvdm> *my
<bialix-qbzr> bug 420757
<ubottu> Launchpad bug 420757 in qbzr "[todo] change code layout" [Medium,Confirmed] https://launchpad.net/bugs/420757
<bialix> twins?
<garyvdm> Yhea - I stared porting viz to qlog late june 2008
<bialix> indeed
<garyvdm> Actual the revision that I started working on way may 2008 - maybe my branch was just out of date when I started.
<garyvdm> My first commit to bzr-gtk was in August 2007 - 2 years ago
<bialix> cool
<bialix> I've discover qbzr ~ 2 years ago
<garyvdm> I started working almost straight away on the viz algorithm - That was crazy....
<bialix> september or cotober 2007
<bialix> :-D
<bialix> and there is still a lot of things we can do to improvw it
<bialix> garyvdm: btw, about that bug with report to console
<bialix> open_containig* methods could emit nagging message about deprecated wt/branch format
<bialix> docstrings insisst this info emits via ui module
<bialix> we either need supress it, or show accordingly
<bialix> this will become a problem in the future (post 2.0)
 * bialix ~
<SmileyChris> in a bit of a mess...
<SmileyChris> had a bound branch, did bzr unbind to do some local work
<SmileyChris> after restructuring entire project and checking it all in, i did bzr bind
<SmileyChris> then ran bzr up, which checked out the pre-unbound revision
<SmileyChris> bzr status showed all the files changed, with a pending merge
<SmileyChris> tried bzr merge, but it said there were uncommitted changes
<SmileyChris> so i ran bzr revert...
<SmileyChris> and now it's the pre-unbound revision, with no pending merge... did i just lose everything?
<garyvdm> :-(
<garyvdm> No
<garyvdm> run bzr up
<garyvdm> You will then get "bzr status showed all the files changed, with a pending merge"
<garyvdm> Now run bzr commit
<garyvdm> No need to run bzr merge, bzr up does that for you
<garyvdm> :-)
<garyvdm> SmileyChris ^
<garyvdm> SmileyChris: "pre-unbound revision" Should have all of your restructuring work.
<mgedmin> I think I did once lose some data that way
<mgedmin> there ought to be a bug about bzr bind not complaining when you've diverged
<mgedmin> by "there ought to be" I mean "I either filed or found a bug already filed, but now I'm too lazy to look up the url"
<garyvdm> jam: KnowGraph has shaved off 1.5 sec off loading mysql in qlog :-)
<mgedmin> it's possible that the commits still exist in the revision graph somewhere
<garyvdm> jam not here ::-o
<mgedmin> shaving secs is nice
<mgedmin> how many are left?
<garyvdm> mgedmin: 15sec - but thats on a KnitIndex repo (1.6)
<mgedmin> I remember reading release announcements saying "bzr someoperation is now 50% faster" and wondering if that means it's still very slow, just not as horribly slow as it used to be, or if it's now actually fast
#bzr 2009-08-29
<garyvdm> mgedmin: MySql is a very big branch - I need to upgrade my copy to 1.9, because thats what it's using
<garyvdm> 1.9 = btree index
<mgedmin> how many megs in ~/.bzr ?
<mgedmin> mysql moving to bzr was very good PR for bzr
<lifeless> hai marius
<lifeless> we're fast now
<lifeless> with the 2a format, which will be default in 2.0
<garyvdm> mgedmin: ../.bzr/repository = 643300 kb
<garyvdm> The thing that makes qlog slow is 67003 revisions
<garyvdm> mgedmin: SmileyChris said "and now it's the pre-unbound revision" - So I don't think he has lost anything, just the merge that bzr up did.
<mgedmin> lifeless: hi!
<mgedmin> awesome to hear that!
<garyvdm> Hi lifeless
<lifeless> hi garyvdm
<mgedmin> zope 3 svn currently has 103359 revisions, but then it contains a multitude of projects
<mgedmin> still, 6-digit revnos scare me -- they start to look more like shortened hashes
<ronny> sup
<ronny> m i license-technical ok, if my code is cappable of running a directly imported bzr, but the backend-loader chooses to run it in another process instead
<ronny> i taught anyvc to run its backends in different processes and on different computers
<lifeless> ronny: I'm not sure I understand the question
<ronny> lifeless: ie not getting gpl imposed
<ronny> lifeless: i want to have fontends for anyvc that are bsd-licenses, so i need to get the gpl'd backends out of the process
<lifeless> IANAL
<lifeless> I suggest you bring this up on the list
<lifeless> http://www.gnu.org/licenses/gpl-faq.html may have something to say
<ronny> i belive im ok
<ronny> night
<johnjosephbachir> hello. where can i read about what's coming in 2.0?
<cha0s> hey guys, i'm wondering if there's a flag i can pass to make bzr merge into an existing directory...
<cha0s> i'm sorry, i meant 'bzr branch'
<lifeless> james_w: do you know why config-manager was removed from debian?
<lifeless> (and ubuntu in intrepid)
<lifeless> all I've found so far is 'abandoned upstream', which is utterly utterly false.
<james_w> lifeless: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501890
<ubottu> Debian bug 501890 in config-manager "config-manager: should this package be orphaned?" [Important,Closed]
<lifeless> yes, found that since asking - thanks
<james_w> so I guess no maintainer in Debian would be more accurate
<lifeless> I'm a bit miffed
<lifeless> I wasn't asked
<lifeless> no beer for anand
 * lifeless ITP's the silly thing
<ciss> hi
<ciss> i'm quite new to cvs-managing projects. i'm looking for a way to create/manage a bzr repository via ftp on a shared hosting account without shell access. is this possible?
<lifeless> bzr init ftp://username@host/path/to/branch
<lifeless> you should give the getting started guide a read
<ciss> i did, but i guess i got lost somewhere :) didn't hope it would be that easy. thx!
<ciss> is there a way to get the status of the remote branch? "bzr status ftp://user@domain/path/branch" doesn't work for me, although init did
<ciss> could it be the ftp plugin won't work with that command?
<fullermd> No remote protocols handle WT's, so bare status won't work.
<fullermd> Though I think historical status should...
<fullermd> (of course, if you init'd it remotely, there wouldn't be a WT anyway, so even if it worked, it wouldn't ;)
<ciss> i guess i didn't fully grasp the concept ... *sigh* looks like there's no way around the deeper docs :(
<fullermd> Sooner or later, the docs always win...
<ciss> yeah, "i fought the docs, and the docs won"
 * fullermd wanders off for a few hours.
<Stavros> hello
<Stavros> i have a branch i was working on a feature in, and i merged it to head, where did these changes go
<Stavros> ?
<Stavros> log-wise, i mean
<ciss> hi again
<ciss> asked before, but i think i can clarify a bit what i'm trying to achieve:
<ciss>  i'd like to directly work with a remote branch via ftp. that is, init the branch remote, add all files remote, commit remote. there are several reasons not to mirror the branch and work locally on it. environment is a shared hosting space without shell access.
<ciss> is this possible?
<fullermd> In a word, no.
<ciss> darn
<ciss> is there an in-three-words, "you could instead ..."?
<fullermd> Well, sorta, but it mostly boils down to having or faking shell access.
<fullermd> I suppose if somebody smoked enough crack to write a ftpfs implementation, you could fudge it that way.  You'd probably have to REALLY like pain, though.
<fullermd> Basically, the only thing you can do via remote protocols is ship revisions around.  You have to make 'em somewhere localish.
<ciss> well, the server does speak python. would that help?
<fullermd> And while you COULD theoretically do that without having a local copy of a branch or local files and all, it would have to be such a contrived setup...
<ciss> e.g. would it be possible to set up bazaar as cgi and commit via a web interface?
<fullermd> You could write a web interface that would do such things.  I'm not aware that anybody has.
<fullermd> If the CGI could write into $WHEREVER and execute /usr/local/bin/bzr (or, if you wrote python, load bzrlib and do stuff directly), it would be workable.
<fullermd> I dunno about _usable_, really, but...
<fullermd> The best answer, really, is to address the "reasons not to mirror the branch and work locally on it", IMO.
<fullermd> That's the point of the D in DVCS after all   ;)
<ciss> it's the differences between the local and the remote environment and the dependance upon some db tables that would have to be fetched each time
<ciss> i don't even need anything fancy like branching or merging. a simple add, commit and revert will be all i need
<fullermd> The quick&dirty way would be to just throw together a bargain-basement-hax0r style CGI where you just type in the command lines and it runs them.
<ciss> sounds tempting :)
<fullermd> (of course, it goes without saying that whatever you do needs to at least PRETEND to be secure ;)
<ciss> like, don't post the link on boards, right? :D
<fullermd> You'd probably be happier in the long run with local dev environments, though.  I do web work, and essentially all my dev is on my workstation.
<fullermd> It means I have to make a copy of the DB schema, but that's easy.  It's in the VCS anyway.
<fullermd> Yeah, that would be a useful first step   :p
<fullermd> (of course, if it were properly secured, you COULD post it on boards.  That's kinda a touchstone, actually...)
<ciss> that gives me an idea: placing fake haxxor links on script kiddies boards to pages rimfilled with adds (or disguised subscription forms)
<ciss> ads
<ciss> but yes, i should probably rework my workflow
<gcerquant> I have what seems a very simple question, but Google couldn't help me
<gcerquant> I want to export my current revision, but without any history nor logs
<gcerquant> just the current files, in the state they are
<fullermd> gcerquant: Something different from 'bzr export'?
<gcerquant> I guess I could remove all .bzr files, but was looking for something less hacky
<gcerquant> I tried bzr export, but it seems all the info is still there (commit logs, ...)
<gcerquant> unless I miss something?
 * fullermd blinks.
<fullermd> What's the _opposite_ of missing something?
<fullermd> export should just export the files...
<gcerquant> I just tested again
<gcerquant> Here is what I did:
<gcerquant> In my repo, I did: bzr export /tmp/test
<gcerquant> it exports all my files as expected into /tmp/test
<gcerquant> but when in /tmp/test, if I do bzr logs, I get all the commit logs
<gcerquant> I don't want them
<fullermd> Are you sure you're in /tmp/test?
<fullermd> export has never exported a .bzr/ dir at all, TTBOMK, much less one with a copy of the history.
<fullermd> And doesn't for me here in a quick test.
<gcerquant> there is no .bzr directory in /tmp/test
<gcerquant> but bzr revno gives me the revision number
<gcerquant> and bzr logs all the commit logs
<fullermd> What does info tell you?
<gcerquant> Checkout (format: pack-0.92)
<gcerquant> Location:
<gcerquant>        checkout root: /private/tmp
<gcerquant>   checkout of branch: /directory_of_initial_branch
<fullermd> Is /private/tmp the same as /tmp?
<gcerquant> yes
<fullermd> So, you're not seeing logs of /tmp/test.
<fullermd> You're seeing logs of /tmp.  Because you're inside that branch (presumably, in a 'unknown' dir inside it, but that doesn't bother bzr)
<gcerquant> ?
<gcerquant> Ok, I get it
<fullermd> Branches extend down to infinity.  If you mkdir /tmp/foo/bar/baz ; cd /tmp/foo/bzr/baz ; bzr log  you'll get the same thing.
<gcerquant> ok, I got it
<gcerquant> at the beginning of my test, I did a bzr branch to /tmp
<gcerquant> I had removed it, but the invisible .bzr directory was still there
<gcerquant> and that's what I was seeing
<gcerquant> thanks for the help
<fullermd> NP  :)
<gcerquant> good evening
<ronny> does bzr-svn support something like partial clone/checkout? of a svn repo?
<meoblast001> hi
<meoblast001> if i create a bzr server, how do i actually write to the branch?
<fullermd> meoblast001: That question is rather nebulous to try and answer.  Can you be a little more specific?
<meoblast001> do i just do bzr push bzr+ssh://mysshaccount@myserver.com/foo/bar?
<fullermd> If (a) bzr is installed or otherwise accessible on the server, and (b) you can write to /foo/bar, yes.
<meoblast001> if the ssh user can, not the bzr server user, right?
<fullermd> They're the same thing in this case.
<fullermd> bzr+ssh boils down to "ssh host -c 'bzr --talk-to-myself-on-stdin'"
<meoblast001> fullermd: nothing is happening :(
<meoblast001> if the bzr server user doesn't own the directory, does it fail?
<fullermd> It'll error if it can't write there, yes.
<meoblast001> i just get a 0 transfer rate
<meoblast001> fullermd: /      0kB @    0kB/s
<meoblast001> i did bzr push bzr+ssh://braden@192.168.1.100:9090/meo3d
<fullermd> Odd port to be running sshd on, but that's your business.  Path seems a little more suspect; you really mean to put things right off the root?
<meoblast001> oooh
<meoblast001> the sshd port?
<meoblast001> i thought it wanted the BZR port
<meoblast001> which do i give it?
<fullermd> If you're talking to a "bzr serve" server, you want to use bzr://, not bzr+ssh://.
<fullermd> Very different things   :)
<meoblast001> what is the difference?
<meoblast001> bzr: ERROR: Server sent an unexpected error: ('error', 'Permission denied: "/meo3d": [Errno 13] Permission denied: \'/meo3d\'')
<meoblast001> who needs permission to that folder?
<meoblast001> ssh or bzr?
<meoblast001> i'm really running short on time and wasn't expecting all these problems
<fullermd> The difference is that bzr:// talks to a server you manually started (as whatever user you ran it is).
<meoblast001> what if i want to talk to both?
<fullermd> bzr+ssh:// ssh's into a server (as whatever user you specify), spawns off bzr on the server side, and talks to it across the ssh channel.
<meoblast001> oh, ok
<meoblast001> now i get it
<fullermd> It's the difference between pserver and :ext: in CVS.
<meoblast001> i chowned that directory to braden
<meoblast001> how can i check that it is?
<fullermd> (also, not that bzr:// servers by default won't allow any writes at all, since they don't do any AAA.
<meoblast001> fullermd: how do i get a listing of who owns a particular directory?
<fullermd> ls?
<meoblast001> man ls told me nothing about how to get the permisions
<meoblast001> at least not while skimming the manual
<fullermd> -l
<meoblast001> drwxr-xr-x 2 braden braden 4096 2009-08-29 18:16 meo3d
<meoblast001> ssh is ran by root, and i log in as braden
<meoblast001> and bzr server is ran by user bzrserver
<meoblast001> why do i choose to do things when i don't have time :(
<lifeless> meoblast001: when you say bzr server is run by
<meoblast001> the user
<lifeless> if you use bzr+ssh, the bzr server is run by *the user that logs in via ssh*.
<meoblast001> sudo su bzrserver, password, bzr server --blah blah blah
<meoblast001> no
<lifeless> meoblast001: not with bzr+ssh
<meoblast001> how do i make this not so
<meoblast001> i want to run 1 bzr server for all users
<lifeless> if you're short on time, put it back the way it was ;)
<lifeless> meoblast001: I mean, I'm delighted to help you out, just thinking it might be less stressful for you to do it another day
<meoblast001> with no vc and transferring a freaking tarball to my laptop
<meoblast001> i'm stressed all the time
<meoblast001> might as well get it out now than later
<lifeless> ok. so why do you want 1 server (this is a serious question, its not obvious to me)
<meoblast001> yes
<meoblast001> 1 server, and then i can use ssh for any user on the server, given he/she has access to the directory we are pushing to
<lifeless> you don't need 1 server for that
<lifeless> bzr+ssh does that anyway
<meoblast001> so i just don't run a bzr server at all?
<lifeless> thats right
<meoblast001> ok, so what about that error i'm getting?
<lifeless> bzr+ssh creates a server process when the user logs in
<lifeless> the permission denied one?
<meoblast001> yes
<meoblast001> wait
<meoblast001> wtf
<meoblast001> i'm confused
<lifeless> the user that is logging in doesn't have access to the folder
<meoblast001> how does it know the root directory of the repo?
<meoblast001> and yes i do
<meoblast001> i checked
<meoblast001> drwxr-xr-x 2 braden braden 4096 2009-08-29 18:16 meo3d
<meoblast001> bzr push bzr+ssh://braden@192.168.1.100:8090/meo3d
<lifeless> when you type 'bzr push bzr+ssh://host/foo/bar/baz', it starts a server at /, and looks at foo/bar/baz for the repo
<lifeless> meoblast001: that will be trying to access /meo3d
<meoblast001> what if i don't want the repo at the root of the server?
<lifeless> then put it in a subdirectory
<lifeless> e.g. /srv/bzr/meo3d
<lifeless> bzr push bzr+ssh://braden@192.168.1.100:8090/srv/bzr/meo3d
<meoblast001> oh
<meoblast001> lifeless: something weird (but not fatal) happened
<meoblast001> i pushed on my desktop to my server
<meoblast001> then branched on my laptop
<meoblast001> and an OpenSSH message came up on my desktop
<lifeless> heh
<meoblast001> is that normal?
<lifeless> I don't know. What was the message?
<meoblast001> prompt for password
<meoblast001> thanks for the help
<meoblast001> i should be going though
<meoblast001> this is only a temporary personal BZR server so that shouldn't matter
<meoblast001> i use launchpad for my actual projects
<meoblast001> bye
<lifeless> jelmer: welcome back
<lifeless> https://code.launchpad.net/~lifeless/subunit/next/+merge/10871
#bzr 2009-08-30
<lifeless> jelmer: ping
 * fullermd grumps about the wiki.
<lifeless> fullermd: thank you
<fullermd> For which?
<lifeless> fasces
<fullermd> Ah.  Well, I've been threatening to write out those thoughts for weeks.
<lifeless> I imagine we all have ideas about this, and its good to be able to read others
<fullermd> And today, it was either do that, or have to actually do some real work   :)
<fullermd> I wanted to get it out 'cuz I believe we can rework it as sheer gain, without hampering current workflows in the slightest.  Unadulterated wins FTW.
<fullermd> (plus, this gives us the chance to be the "Friendly,  Flexible, Fascist VCS"   8-)
<lifeless> groan
<fullermd> Thank you, I'll be here all week.  Try the veal!
<lampliter> good evening.  Trying to set up the bzr eclipse plug-in on Windows 7.  When I installed the Windows bzr package, it says something about tortoise bzr but I can't seem to find it in the Windows Explorer
<lampliter> what should I be looking for?
<lampliter> doh  found it
<lampliter> anyone around who knows about the eclipse bzr plug-in?
<lifeless> a little
<yek401> I'm at a loss with regard to 'bzr join --reference foo'
<yek401> is there a preferred format I should use, 2a, rich-root, etc?
<lifeless> its not a supported feature yet, sorry.
<yek401> so that's it?  I was ready to switch our team from svn to bazaar, but we rely on svn:externals
<yek401> If there's no way to duplicate externals functionality right now, I guess we can't use bzr
<yek401> any idea when it should show up?
<lifeless> You could use config-manager, which various folk have used. Its manages a similar thing to externals.
<lifeless> https://launchpad.net/config-manager
<lifeless> its not as tightly integrated as nested trees will be once they are ready.
<lampliter> sorry, I fell asleep
<lampliter> I'm having trouble figuring out how to drag files a launch pad into an eclipse project
<yek401> well, I have a multi-part project, where each designer is working on a relatively sperate piece, but there are several resources that are shared across the project.. we handled these in externals.. is there a better way to handle that in bzr?
<lifeless> so my first question is, are they really separate?
<lifeless> or were you using externals as a way to emulate DVCS, which bzr has built-in.
<lifeless> lampliter: sorry, I don't think I know enough to help you on that.
<lifeless> verterok: do you know enough to help lampliter ?
<lifeless> lampliter: verterok is the bzr-eclipse author; may not be around at the moment though
<lampliter> it's okay.  It seems like the integrated eclipse bzr fantasy may be a bit on the fantasy side
<lampliter> I'm having so much not fun trying to integrate eclipse, Python, and speech recognition
<yek401> yes, truely seperate.. the design is actually a collection of integrated circuits.. one of the externals is the collection of technology files.. then there are a few core libraries, and then each desiner builds his or her own IC from those resources..
<lampliter> I just keep slogging away and it's like climbing a mountain.  The top seem so close but it's always much further away than you think
<lampliter> I think I better go to bed.  I'm falling asleep way earlier than usual (midnight versus 2 a.m.)
<lifeless> yek401: so there are two ways that should work well. One is just to start with the tech circuits, and each designer builds on that; they have a separate branch thats just the tech circuits, and commit to that to change the circuits
<lifeless> yek401: alternatively, a config (config-manager) would easily combine the different components.
<yek401> hrm, 1) where do I read about how to use config-manager
<lifeless> http://launchpad.net/config-manager
<lifeless> I'll be back in a while, house stuff to do
<yek401> I don't mean to suggest that I'm daft, but where within that site is there a howto or description of the interface.
<yek401> ok, thanks for the help
<lifeless> yek401: oh hm
<lifeless> http://bazaar.launchpad.net/%7Elifeless/config-manager/trunk/annotate/head%3A/README
<lifeless> and
<lifeless> http://bazaar.launchpad.net/%7Elifeless/config-manager/trunk/annotate/head%3A/sample-config.txt
<yek401> great! thanks
<yek401> (didn't occur to check within the repo for that)
 * lifeless is gone now
<jelmer> lifeless: pong
<lifeless> hey
<lifeless> welcome back
<jelmer> hi!
<lifeless> -> #subunit :)
<jelmer> you've been busy I see :-)
<lifeless> a tad
<lifeless> jml: btw, did you find the torchwood cover?
<maxb> According to specs/import-dsc in the bzr-builddeb source tree, incremental import support is basically not done yet. Should I even be attempting to use bzr-builddeb for anything than an initial import at this point?
<MTeck> What causes point versions? Like 105.1.1
<MTeck> OH!
<MTeck> Wrong channel for my sudden epiphany - still confused
<fullermd> MTeck: That designates a revision that was brought into the branch via a merge.
<MTeck> oh
<MTeck> fullermd: so will it ever go away and go back to an integer?
<fullermd> Possibly, if it ever ends up in the lefthand ancestry line of a future head rev.
<MTeck> fullermd: ?
<MTeck> you lost me at lefthand
<fullermd> It's the opposite of righthand   :)
<MTeck> you lost me at "lefthand ancestry" :P
<fullermd> How deep do you want to grok it?  It's hard to answer that question without understanding exactly how the numbering comes about.
<MTeck> .... I'm really really tired
<MTeck> so.. if you explain it - I'll try to understand and reread it again tomorrow
<MTeck> I'm up for knowledge though :)
<fullermd> Theoretically, every time the head rev of the branch moves, all the numbers could change.
<fullermd> In practice, that happens some time between "almost always" and "never", depending on exactly how your workflow...  flows.  Or whatever it is workflows do.
<fullermd> OK.  So, in a purely linear system (like CVS or SVN), numbering is easy, since every rev "comes from" the one before.
<fullermd> I make a commit, that's 1.  You make one, that's 2.  I make one, that's 3.  Etc.
<MTeck> you used cvs and easy together? :S
<fullermd> Sure.  It's easy like that head cheerleader in high school  :p
<fullermd> And about as sane and sanitary.  But anyway.
<MTeck> :P
<LarstiQ> oi, CVS has dotted file revnos
<MTeck> ya, like DRUPAL-6--1-0
<LarstiQ> MTeck: that's a tag
<LarstiQ> like 1.1.1.1
<MTeck> oh
<fullermd> In a nonlinear system (like most DVCS's, though there's nothing _stopping_ a central system from being so), that's no longer the case.
<fullermd> LarstiQ: Pfft.  It's still linear going forward.  Don't confuse the case  :p
<LarstiQ> sorry, sorry
<fullermd> If we're both working based on a branch at say rev 10, and we both make a commit, now we both have 11.
 * LarstiQ detaches
<fullermd> But our 11's have nothing to do with each other.
<MTeck> fullermd: both users pull same branch you mean?
<fullermd> So far no problem though, since if you're looking at my branch, we don't see, care, or even know about your 11 (and vice versa)
<MTeck> or different branches entirely
<fullermd> But when we try and merge the branches together, what can we do?  We can't have TWO rev 11's.
<fullermd> And it doesn't make sense (in bzr's opinion; hg does sorta this) to call one 12, since that implies that it's based on 11 (which it's not; neither of our revs is based on the others', they're both based on 11)
<fullermd> So, we could have NO 12 at all, and call both something-implying-descent-from-11, and then have a 13 later.
<fullermd> And various other even more confusing options.  But they're confusing.
<fullermd> So, if I merge your branch, your 11 is named something "off to the side".  And that fits how I'll think of it; I didn't make it, I brought it in from somewhere else.
<fullermd> Of course, the numbering doesn't actually come from that sort of question inside bzr; that's just how it appears.
<fullermd> What actually happens is, revs don't inherently have numbers; if you run 'log --show-ids', you'll see the revision id's, which are long opaque strings.
<fullermd> Those are associated with the rev forever; wherever you are, that string means that rev.
<fullermd> Numbers are local to a given branch; a given rev can have many different numbers, depending on the structure of the branch its in.
<fullermd> The way those are assigned depends on the shape of the ancestry of that branch, which always works backward from the head rev.
<fullermd> A branch works by saying "THAT rev right there is my head", and that rev's parents, and its parents' parents, and their parents, and so on back to null, are part of the branch.
<fullermd> If every rev had a single parent (like in the linear case above), that would be easy; you figure how many there are, and number backward from that.
<fullermd> But when you merge, you create a rev with 2 parents; your last revision, and the [head] revision you merged in.
<fullermd> (Technically, you can have any number of parents, because you could do multiple merges at once, but you practically never do, it's a bit more confusing, and it doesn't change the essentials of this analysis anyway)
<MTeck> so far this is really really easy to follow
<fullermd> In theory, merges are symmetric ("merge these two things together"), but socially and mentally we generally consider them asymmetric ("merge that into this")
<stbuehler> bzr: ERROR: subvertpy.SubversionException: ('Svndiff contains a too-large window', 185001)
<fullermd> So you don't, in mental modelling, "merge two branches together", you "merge that branch into this branch"; often in the sense of "merge Joe's branch into my branch".
<stbuehler> can someone please tell me what that is...?
<fullermd> stbuehler: You probably want to ask jelmer when he shows up; that's his pigeon.  Or mail the list.
<fullermd> MTeck: Now, merging has to create a new rev, since you're making a new state.  And that rev has two parents; your branch's previous head, and the rev you merged.
<fullermd> (in merging someone else's branch, you probably actually merge many revs, but you do that by merging its head, and thus implicitly pulling the ancestors of that head you don't already have.  So you only have that previous head as a parent; the rest show up in the ancestry just like your previous history does, transitively through that head)
<fullermd> So now, if we try and look back from the head to number, we have a branching; there are two paths backward from that.  So which way do we follow to number?
<MTeck> down
<fullermd> We could pick one way at random, but that would be stupid.  We can try and create some sort of linear projection, but then we end up with the problems described above; you end up with a '12' that isn't based on '11', etc.
<fullermd> What bzr does is preserve and exploit the asymmetry described above.
<fullermd> We preserve an ordering of the parents of a rev; the 'first' or 'left' (depending on how you look at things) parent of the merge rev you created is YOUR previous state, and the 2nd (and 3rd, 4th, if necessary) or right-side parents are those you merged.
<fullermd> So at every branching in the history (we're looking backward remember, so in this sense that means "every rev with more than one parent"), we take the left-hand or first-parent path, when figuring stuff for numbering.
<fullermd> And so the number of steps on THAT path, ignoring the right-side path, determines how many number we have.  And the revs on that path are the ones that get the numbers.
<fullermd> The upshot of that scheme is that the revs that get numbers, and are considered a branch's "main line" in bzr terms, are those that were "made on this branch"; e.g., those you made by 'commit', rather than those you acquired from elsewhere via 'merge'.
<fullermd> (that definition is necessarily fuzzily and somewhat incomplete (and in some ways flat wrong), but it gives sort of a flavor of what's happening)
<fullermd> Internally of course, all revs are equal, but UI-wise, it can be valuable to consider that sort of dichotomy for various reasons.  So bzr chooses to present based on that.
<fullermd> Now, we've used the monotonically-increasing integers for those revs on the left-hand path.  What can we do for numbering those remaining revs?
<fullermd> Well, we could just not number them, and use the revid string if we need to refer to them.
<fullermd> We used to just do that (pre-0.13 I think?).  Little ugly though; revids are long.
<fullermd> Or we could give them numbers that aren't integers.  That's where dotted revnos come from.
<fullermd> At the moment, those numbers are generated by basing them from the 'mainline', integer revision they descend from.
<fullermd> So if we have a branch with 10 revs, we both branch from it and create an 11, then I merge you.
<fullermd> My history looks like:
<fullermd> 1..10: The original 10 revs.
<fullermd> 11: My 11.
<fullermd> 12: Merge of your branch.
<fullermd> 10.1.1: Your 11.
<fullermd> If, at the same time I do that (before my 12 exists), you merge my branch, you end up with a similar numbering.
<fullermd> Except your 11 is still 11, and my 11 is 10.1.1 in your branch.
<fullermd> (it's not necessarily the _only_ way to assign those dotted numbers, but it's how we currently do it.  Remember these aren't _stored_ or part of the rev, they're just derived on the fly, so we could change it easily)
<fullermd> So, now we both have branches with 13 revs in the history (though on both cases, only 12 are on the mainline; the 13th is off to the side and gets a dotted revno)
<fullermd> 12 of those 13 are common; it's only that last, number 12, that's different.
<fullermd> And our rev 12's, while different revs, are probably much the same; we probably didn't have merge conflicts.  So the files all look the same.
<fullermd> Looking at the files, I probably couldn't tell whether I was in my branch or yours.
<fullermd> So socially (not technically necessarily), we could choose to use my 12 or your 12 going forward with equal ease.  But depending on which it was, a different rev would get the dotted number.
<fullermd> Now, let's suppose you make a new 13 rev, and then a 14 merging my branch (which makes no file changes, but brings the history graphs together)
<fullermd> My 12 (my version of the merge) ends up with a dotted number (10.1.2 I think, in the current scheme).
<fullermd> (after all, it's "off to the side" in your perspective there)
<fullermd> Now, I want to sync up with you.  I could merge again, and I'd end up with a '13', and your 12, 13, and 14 'off to the side' with dotted numbers.
<fullermd> But, since your history graph is a strict superset of mine, I could 'pull' instead, which basically turns my graph into a copy of yours.
<fullermd> So now my head is your 14.
<fullermd> The result, then, is since we have the same heads, we have all the same numbers.
<fullermd> And my 11, which previously had an integer revno, now has a dotted.
<fullermd> Your 11, which previous had a dotted (10.1.1), is now on my mainline, so it's no longer dotted.
<fullermd> My head rev changed in a way that was strictly forward (it includes my previous head in its ancestry, and thus everything prior to that too), but the new head implies a different 'mainline' through its left path, so [some of] the revs get renumbered.
<fullermd> If I move my head forward solely by 'commit', that will never happen; that's the commonish case in the bzr world, socially.
<fullermd> MTeck: Put you to sleep yet?  :p
<MTeck> I've been enjoying it - but I am also tired :P
<MTeck> I've been up for ~30hr actually
<fullermd> Oh how I wish I could say I wasn't on a first-name basis with that state of being...
<MTeck> I've understood every bit of this though
<fullermd> So, you have the tools now to answer your question; if your branch's head rev moves in such a way that the left-hand path through the ancestry changes, revnos (integer and dotted) can change.
<fullermd> In rough colloquial terms, that happens when your head moved to a rev somebody 'commit'd elsewhere, rather than one you 'commit' locally.
<fullermd> Via you 'pull'ing some other branch, or another branch 'push'ing onto you.
<fullermd> Merge will never do it (since merge doesn't create a new head, just changes in your working tree waiting for you to commit them)
<MTeck> makes sense :)
<fullermd> Commit will never do it, since the first/left parent of the new rev you commit is your previous head, so all that ancestry is unmoved.
<fullermd> And while there are probably other ways to move your head than the above, that's pretty much it through the UI leaving extraordinary circumstances out.
<fullermd> Of course, it's possible that that 'outside' head could _not_ change the numbering, if it doesn't change the left path.
<fullermd> e.g., I have 10 revs, you branch from that and create an 11, and (without making any local changes), I 'pull' you.
<fullermd> I have a new rev tacked on the end now, but everything that was previously on the mainline still is, so existing numbers weren't changed.
<fullermd> There's a branch.conf setting you can make that will refuse changes that would change the left path.
<fullermd> append_revisions_only, I think.
<fullermd> You can set that on a branch, and then you can commit and pull into and push-onto all you want, but it will error out if the action would change the left path.
<fullermd> That can be useful on branches like 'trunk', where you want the numbering (and the view of history) to remain stable.
<fullermd> But again of course, this is all social; technically all that matters is questions like "is rev X in my ancestry".
<fullermd> Other systems, like git or mtn, don't assign any meaning to left vs right or first vs later parents.
<fullermd> And they don't have revnos, either.  The two kinda tie together; revnos would be less useful if they changed all the time.
<fullermd> [other theoretical discussions elided in favor of sleep]
<MTeck> :P
<MTeck> This was fun - but I think I agree
<MTeck> thank's professor :)
<fullermd> I'll give you a day or so to recover before the test   ;p
<MTeck> test :(
 * MTeck turns white
<MTeck> in all honesty - I think I could do ok on the test (after the sleep recovery)
<MTeck> heh - 1hr drive in front of me, then 1hr moving in, then sleep for ~4hr and then my gf will probably be around
<MTeck> ya, it's time to take off - I need food somewhere too
<MTeck> fullermd: thanks again
<fullermd> MTeck: NP.  Hope it helped   :)
<MTeck> helped a lot actually
<MTeck> I'll catch you all later :)
<kwk> Hi! When I install Bazaar on any of my windows machines (XP and Windows 7), the "new folder" function from the menu bar is broken in explorer. the "right click"->new->folder still works. Is this a known issue?
<kwk> I searched the questions on launchpad for "new folder" but there's only one irrelevant answer
<kwk> Ah, here's a solution, I guess: http://www.sevenforums.com/general-discussion/20656-new-folder-button-explorer-toolbar.html
<kwk> It seems to be a problem of the installer, not the binaries.
<kwk> anyways thanks for such an awesome tool
<mtaylor> how do I prevent push from trying to stack?
<_steven_> does anyone know of a way to have bzr automatically add commit messages to a changelog upon commit?
<verterok> _steven_: I'm not aware of a plugin that do that, but you can easily doit with post commit hook: e.g: http://stackoverflow.com/questions/43099/how-can-i-get-a-commit-message-from-a-bzr-post-commit-hook
<_steven_> if it's post commit, will that commit the newly updated changelog to the bzr branch?
<_steven_> or does that just update local files?
<verterok> _steven_: as it's post commit, another commit is needed, but you can use a pre commit hook
<verterok> _steven_: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks
<_steven_> verterok: thanks
<verterok> _steven_: np
<_steven_> I'm surprised no one else has done this before and released a plugin
<_steven_> If I can get it to work properly, I may create a plugin
<verterok> _steven_: there is a gnu changelog plugin, but don't work ^ that way
<verterok> _steven_: if pre commit isn't enough to get this working, take a look to the extend_command hook ;)
<_steven_> I tried the gnu changelog plugin, it didn't seem to format things properly
<_steven_> or it's possible I just don't like gnu's changelog format :)
<verterok> _steven_: I have a pre-commit lint plugin (it's hack, not a "plugin"), but you can get an idea of the use of extend_command hook
 * verterok looks for the branch url
<verterok> _steven_: lp:~verterok/+junk/pre-commit-lint
<_steven_> verterok: thanks, I'll take a look
<phinze> anyone here using bzr over a netcat bounce to get around firewalls?
<phinze> i used to have it working great but on the latest version i'm getting trouble
<phinze> i guess a related easier question would be: how do i get bzr to spit out as much ssh exchange data as it has?
<phinze> ah nm looks like i have to debug the netcat bounce first; tried it manually and it's not working
<lifeless> moin
<maxb> I've got a lot of directories corresponding to versions of a project that had no version control before - what's the best way to import them all into a branch?
<lifeless> bzr import
<lifeless> + for x in y
<lifeless> maxb: is this the lp dependencies thing?
<maxb> yes
<lifeless> I just had a look for a branch of it, no sign
<lifeless> sorrt
<Blizzz> is it save to edit and copy files while `bzr commit` is running?
<lifeless> if you're on windows, doing so can cause errors because of platform limits. On linux it should be ok as long as you don't move the tree around: but it is possible that commit will end up reading only part of the file if you save it at the wrong time.
<lifeless> if your editor uses atomic replacements  for files it should be totally safe. (Most editors don't).
<Blizzz> lifeless: yes, linux here. is it depending on a specific stage, too?
<lifeless> Blizzz: commit should only be a second or two long
<Blizzz> lifeless: it usually is, but sometimes it takes up to some minutes
<lifeless> are you committing to a local or remote branch?
<Blizzz> perhaps i use it not properly?
<Blizzz> bzr copies it to the remote server directly
<lifeless> anyhowok
<lifeless> ok
<lifeless> when its copying it to the server its safe to edit locally
<lifeless> what protocol are you connecting to the server with?
<Blizzz> sftp
<lifeless> that will be why it takes minutes every 10 commits
<lifeless> it has to do database maintenance over the network
<lifeless> if you can use bzr+ssh, it will be much faster
<Blizzz> ok, i'll have a look :)
<Blizzz> thank you so far
<danbhfive1> I can't seem to branch a launchpad project.  I had forgotten the password to my ssh, so I wiped ~/.ssh and regenerated a key, added to launchpad.  But, bzr branch lp:project sill gives me a permission denied error.
<lifeless> danbhfive1: are you using the right username with launchpad ?
<danbhfive1> lifeless: I don't know, how do I check?
<lifeless> whats your launchpad username
<danbhfive1> lifeless: danielhollocher
<lifeless> if you do 'ssh danielhollocher@bazaar.launchpad.net echo'
<lifeless> what happens
<danbhfive1> same error
<lifeless> and the error is?
<danbhfive1> Agent admitted failure to sign using the key.  \n  Permission denied (publickey).
<lifeless> hmm
<lifeless> have you added the new key to your ssh agent, whatever one you are using?
<danbhfive1> I've been changing the keys a few times, since I forgot my password.  Maybe I have to reboot?
<lifeless> perhaps
<danbhfive1> ok, well, let me try that, even though it seems strange...
<danbhfive> lifeless: thanks for your help.  Turns out the reboot worked.  I suppose maybe ssh needed restarting?  I don't know, but thanks
<lifeless> danbhfive: your ssh agent needed to know about the new key
<lifeless> ssh-add, for instance in a command line agent
<danbhfive> ah, cool
<lifeless> fooding
<lifeless> http://pqm.bazaar-vcs.org/ in progress
<bob2> spiffy
<lifeless> bob2: wait till you see rev 200 of pqm deployed
<lifeless> *thats* spiffy
<igc> morning
<lifeless> hi
#bzr 2010-08-30
<spiv> Good morning.
<lifeless> oh hai
<AfC> Hm. Can you suggest a reason why installing the bzr-builddeb package wants to bring in the entire libqt stack?
<lifeless> its in love!
<mwhudson> is qbzr being dragged in somehow?
<AfC> mwhudson: as far as I could tell, no
<AfC> This was a nearly naked server system;
<AfC> (ie, no Desktop)
<AfC> I subsequently removed the *qt* and apt didn't try to remove bzr-builddeb
<AfC> so I was really at a loss as to wtf
<lifeless> recommends vs depends
<AfC> I install with -o Install-Recommends=false
<AfC> (and it still came in; I look closely for that sort of thing)
<lifeless> what does apt-cache bzr-builddeb show for you
<lifeless> under depends, recommends & suggests
<AfC> (ie, there was something in the Recommends: column that was nothing to do with libqt*
<AfC> lifeless: I looked through that too. Its innocent, as far as I can tell
<AfC> [which is why I raise this casually here; it was _weird_]
<lifeless> so, to diagnose it
<lifeless> apt-cache rdepends
<lifeless> the package that was being brought in
<AfC> yeah, I didn't think to try that at the time
<lifeless> and/or remove bzr-builddeb and install it again
<AfC> lifeless: I tried that too
<lifeless> oh
<lifeless> and /var/log/apt/ has some debug stuff
<AfC> (I'll keep an eye out for this; at the moment that machine is churning away building things, so...)
<AfC> true,
<AfC> looking
<AfC> ah ha
<AfC> it was arora, depending on libqt4-webkit
 * AfC wonders what arora is
<AfC> some kind of web browser, obviously... but what pulled it? Weird.
<fullermd> Well, embedding mail reading in everything was SO 1980's.  So now all apps grow until they can render HTML.
<AfC> lifeless: nice call on /var/log/apt/history.log
<lifeless> if don't have a browser
<lifeless> then the first explicit one listed (if one is) is pulled in
<lifeless> someone has a clause like
<AfC> some kind of virtual package requirement, presumbably
<lifeless> arora | web-browser
<AfC> yeah
<AfC> eek
<poolie> hi all, i'm back
<lifeless> wb
<mwhudson> poolie: wb
<poolie> thanks
<andrewblack> Hi. Is there any gotchas in makine /etc a bzr working tree.
<mwhudson> andrewblack: bzr doesn't track permissions very closely
<spm> andrewblack: permissions on funky files within the /etc tree within the .bzr directory.
<mwhudson> so i think you might want to use a wrapper like etckeeper
<spm> or lock down /etc/.bzr
<mwhudson> http://joey.kitenet.net/code/etckeeper/
<andrewblack> ok - will look at etckeeper
<spm> mwhudson: nice tag teaming there. high-five :-)
<mwhudson> spm: aren't we supposed to do that in a privmsg?
<mwhudson> :)
<spm> um....
<andrewblack> It says it tracks changes during package updates. What about manual changes to /etc/xxxx files
<spm> you can manually check those in
<spm> it'll also auto check those in next package update
<spm> if you want; you can always setup some sort of cron script that alerts/or auto-commits changes
<spm> at $job-1, we had a process rule; any /etc or other config changes were always done thru a wrapper script that would check the edited file in/out/diff of an RCS store.
<spm> ho hum. said article has gone the way of the dodo. was on the samag.com website; now defunct.
<andrewblack> Thanks spm
<andrewblack> so basically it sets up the repos in a way that is permission friendly
<andrewblack> ok - I wanted to edit a cron job (and get it under bzr first)
<andrewblack> turns out the that thing I needed to change was in a file it calls that was already in a bzr tree.
<spm> hrm. not so much permission friendly; more permission *unfriendly*. /etc/.bzr ==> 0700 type of thing.
<thumper> http://bazaar.canonical.com/en/ seems to be a little old on the released bzr status
<poolie> thanks thumper, i'll check why later
<thumper> poolie: we should have a chat some time
<thumper> soonish
<poolie> we should
<poolie> now is good with me, if you like
<poolie> (or in about 2m)
<thumper> poolie: I'm sprinting this week, but would still like to organise something...
<thumper> induction for wallyworld_
<poolie> yay wallyworld_ !
<poolie> thumper: how about now
<wallyworld_> hi poolie
 * thumper fetches headset
<vila> hi all !
<vila> wv poolie !
<vila> meh
<vila> wb
<poolie> hello vila, how are you?
<vila> first typo in second msg, looks like a good way to start the week :)
<vila> poolie: great, about to half the active review queue by landing those long awaited fixes :)
<poolie> only 660 messages to go ..
<GaryvdM> Hi all.
<vila> hey GaryvdM !
<poolie> spiv, vila, did either of you do anything about unlocking on interrupts, or coping when we were interrupted?
<vila> poolie: nope, I thought you were working on it and then... went to other things
<bialix> poolie: ping
 * bialix waves at ddaa
<GaryvdM> Hi bialix
<bialix> Heya Gary! I happy to see you
<GaryvdM> I'm trying to write some tests for qlog. I need to create branches with interesting graphs. I looked at BranchBuilder to see if it would make things easier, it helps some what, but one thing that is crufty is having to branch my branch on disk so that I can create a diverging graph. Is there a helper to make this easier?
<poolie> np, i might look at it this week
<bialix> GaryvdM: invoke `bzr branch` command via self.run_bzr?
<spiv> poolie: no, I didn't either.
<poolie> what did you two get up to?
<vila> poolie: resuming working on transform targeting allowing deleting dirs containing .pyc files
<vila> s/resuming/resumed/
<poolie> nice
<bialix> GaryvdM: can you look at https://code.launchpad.net/~s-dumbie/qbzr/ench_qdiff/+merge/33986
<bialix> one russian guy contacted me with patch couple of months ago. then yesterday friend of him decided to finish that patch
<bialix> GaryvdM: as I understand some of their changes should be reworked with new toolbar in qdiff. but we don't have one yet.
<GaryvdM> bialix: Ok
<bialix> we (I) may ask him to split the patch into smaller pieces
<bialix> if it helps
 * vila banhs head on desktop, from pqm: "Exception processing merge: Unknown branch format: 'Bazaar-NG Loom branch format 7\\n'"
<GaryvdM> bialix: Hopefully the search stuff can be made common with annotate too.
<vila> yeah, banhs, brohe a teeth doing that
<bialix> vila: we're with you!
 * fullermd broke a tooth on the bottom of a pool once.
<vila> tooth yeah, the only remaining one in fact
<vila> fullermd: forgot to check for water ?
<fullermd> Oh, no.  There was water.  It was pretty bizarre; I probably couldn't do it again if I tried.
<fullermd> Not that I plan on trying, though.  Unpleasant experience.
<vila> fullermd: and *that* was the last time you left your basement right ?
<fullermd> Well, it shoulda been   :p
<vila> :-D
<fullermd> But I was young and foolish, and therefor sociable, back then.
<vila> fullermd: such a loss of time...
<fullermd> I know!  All those afternoons I could have spent plotting the downfall of humanit...   er, studying and improving myself.
<poolie> spiv, what's new with you?
<vila> errr, what did I miss ? pqm got a faster machine ? I wasn't able to see my requests on http://pqm.bazaar-vcs.org/, yet they have landed...
<bialix> today speed of light is much faster I suppose
<poolie> hi bialix
<poolie> vila, oops
<poolie> i suggest you send one you know will fail
<bialix> hi poolie
<poolie> and make sure that it does
<poolie> spiv does my guess on bug 626649 sound plausible?
<ubot5> Launchpad bug 626649 in Bazaar "pull from one ssh branch into another fails with TooManyConcurrentRequests (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/626649
<vila> poolie: you're kidding ? Time to send all those controversial patches instead :)
<vila> poolie: yes, very plausible, I waited far too long to report it wanting to write a test for it :-}
<vila> poolie: I work around it with: 'bzr unbind ; bzr pull -v ; bzr push ; bzr bind'
<poolie> yup, it's a dupe of bug 483661
<ubot5> Launchpad bug 483661 in Bazaar "bzr pull bzr+ssh into a bound branch fails with TooManyConcurrentRequests (affected: 3, heat: 4)" [High,Confirmed] https://launchpad.net/bugs/483661
<spiv> poolie: yep, that sounds plausible.  Not 100% sure, but definitely plausible.
<spiv> poolie: I did some measurement of where we're at with gcc-linaro, and found a 15% win for one of the cases.
<poolie> oh, nice, what was that
<spiv> Although for some reason I'm having trouble with getting useful results with --lsprof-file and kcachegrind, I'm not sure why yet.  It might be something about trunk, or something about maverick...
<spiv> It turns out that InterTree.iter_changes was doing "if file_id in self.target.all_file_ids()" in a loop.
<poolie> so recalculating all the ids every time?
<spiv> Right, which means set(tree.inventory)
<poolie> maybe that should be deprecated
<poolie> hm
<spiv> Anyway, Tree already has a __contains__ method that does that check without iterating over an entire inventory, so "if file_id in self.target" is the trivial and faster replacement.
<poolie> ok
<poolie> no, i guess profiling is probably a better way to find expensive things called repeatedly
<poolie> i'd like to delete __contains__ etc
<poolie> vila does this mean all those recently merged things of yours perhaps should not have merged?
<poolie> or did you integrate them and then send the whole thing?
<vila> poolie: investigating
<vila> poolie: I went with pqm-submit instead of feed-pqm because looms were involved (and not supported by pqm) but that still use the "regular" pqm way
<vila> hmm, looks like I used syntax accepted by python-2.6 but not 2.5, so probably not 2.4 either
<vila> that in turn would mean that pqm accepted the merge when selftest failed with a syntax error... bad bad
<spiv> vila: !
<vila> rhaaaa, on no more py25 on lucid... shudder
<vila> spiv: Isn't it a nice way to land a patch ?
<vila> poolie, spiv: here is the fix: http://paste.ubuntu.com/485753/
<vila> poolie, spiv: I will send this to pqm *now* and check for fallouts (unless you yell loud)
 * poolie looks
<poolie> vila, is this because py25 won't let you use *args and also regular kwargs?
<vila> poolie: seems so, 2.4 and 2.5 fail without and succeed with this patch
<poolie> but doesn't pqm use 2.4?
<vila> I don't remember if it stills uses 2.4 or 2.5, but I've filled bug #626667
<ubot5> Launchpad bug 626667 in PQM "syntax error doesn't prevent merge (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626667
<vila> losa: can you help diagnose bug #626667 by checking the recent logs on the bzr pqm instance ?
<vila> poolie: ok to land the above fix ?
<poolie> vila, i guess so
<poolie> i really want to work out why it wasn't rejected though
<vila> sent
<poolie> as i'm sure you do too :)
<vila> poolie: yup, hence the bug
<vila> losa: first data point: which python version is used there ? 2.4 or 2.5 ?
<lvh> hey
<vila> http://paste.ubuntu.com/485756/ hmpf
<lvh> I accidentally uploaded some stuff to lp without fixing bzr whoami first
<lvh> is there a way to fix my commits?
<spiv> vila: not loud yells from me
<spiv> s/not/no/
<vila> bug 626667 updated... just lovely
<ubot5> Launchpad bug 626667 in PQM "syntax error doesn't prevent merge (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626667
<bialix> lvh: uncommit, or push --overwrite
<lvh> bialix: so if I fix whoami, and then push --overwrite, it'll be fixed? Cool, thanks
<bialix> lvh: no
<lvh> bialix: huh? what do I do then
<bialix> lvh: you have to redo your commits locally and then push --overwrite
<bialix> how many of them do you have?
<lvh> so 10:36 <bialix> lvh: uncommit, or push --overwrite => uncommit *and* push locally
<lvh> twenty or so
<lvh> I didn't have a working internet connection to push to lp
<lvh> so it took me about a day to notice
<bialix> what's wrong with your old whoami?
<lvh> lp doesn't link it to my user profile correctly
<lvh> it doesn't have my email address
<vila> lvh: and you don't get karma ?
<bialix> it's not too bad
<lvh> vila: maybe, I don't know
<lvh> yes, it's not a major issue
<lvh> I was just hoping there's a way of letting lp know "oh hey that guy, that's me"
<vila> lvh: that's the only consequence I can think of
<poolie> lvh it has no address at all?
<lvh> poolie: worse, it has a useless one
<bialix> 20 commits... you can redo them one by one, or maybe use bzr-rewrite plugin
<lvh> It says Laurens Van Houtven <lvh@bruichladdich>
<vila> lvh: try adding this email to your lp profile
<bialix> you can add it to your profile as alternate mail
<lvh> vila: aha, okay
<hno> bialix: Is that possible without mail confirmation?
<vila> lvh: not sure lp willl accept an invalid email but worth a try
<lvh> A confirmation message has been sent to 'lvh@bruichladdich'. Follow the instructions in that message to confirm that the address is yours. (If the message doesn't arrive in a few minutes, your mail provider might use 'greylisting', which could delay the message for up to an hour or two.)
<lvh> That'll backfire :)
<bialix> lp is too smart
<vila> lvh: all you have to do now is register this TLD :-D
<hno> lvh: You could as in #launchpad if there is a way around that, or fix up the commits and push again..
<bialix> maybe you can file a bug report against lp itself and ask for such deature
<lvh> Okay, thanks :)
<bialix> s/feature
<lvh> https://launchpad.net/bzr-rewrite is that the rewrite plugin I want?
<spiv> lvh: yes
<poolie> vila is it just me or is --parallel still a bit flaky?
<poolie> i get "failed to connect to ssh server"
<poolie> oh, heh, and the strace tests are broken by maverick's policy change there
<vila> poolie: ENOTENOUGHCONTEXT
<vila> poolie: is that with the leaking tests fix landed ?
<poolie> ERROR: bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh: Unable to connect to SSH host localhost:51613; [Errno 111] Connection refused
<poolie> that's just in trunk as of a few minutes ago
<lvh> Okay, so lets say I want to fix all my commits and then push --overwrite, how does rewrite make my life easier
<spiv> poolie: on maverick?  That's a paramiko bug relating to IPv6
<vila> poolie: sounds like either a transient one or something related to a spiv fix for paramiko
<poolie> oh ok, thanks
<poolie> how about bug 626679
<ubot5> Launchpad bug 626679 in Bazaar "test_strace_result_has_raw_log fails on maverick (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/626679
<spiv> I should nag upstream and/or the Ubuntu packager to include my patch, I guess.
<bialix> poolie: I'd like to draw your attention to bazaar.canonical.com/en/index.html page
 * poolie looks
<poolie>  i need to go soon
<poolie> hi bialix
<bialix> that page has section "Developer's Blog"
<poolie> what about it ?
<bialix> hi poolie
<poolie> but it links to "None", i see
<bialix> the section is empty for me.
<bialix> but when I'm regenerating the index on my machine it's not empty
<bialix> does this index regenerated on the production server?
<bialix> it seems production server has no access to wordpress feed, or something like that
<bialix> I have no idea how that page deployed, but there is definitely some problem
<poolie> i'll check it out on the production server
<vila> ping LOSA
<bialix> and btw local index has link to http://bazaarvcs.wordpress.com/ and not to None
<bialix> something weird
<mthaddon> vila: hi
<vila> mthaddon: hey !
<vila> mthaddon: really bad bug on pqm bzr instance: bug #626667
<ubot5> Launchpad bug 626667 in PQM "syntax error doesn't prevent merge (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626667
<vila> <vila> losa: can you help diagnose bug #626667 by checking the recent logs on the bzr pqm instance ?
<vila> <vila> losa: first data point: which python version is used there ? 2.4 or 2.5 ?
<lvh> Okay, I installed bzr-rewrite. I don't think rebase is what I want if it's anything like git's
<vila> mthaddon: a fix for *bzr* is currently landing, but pqm needs to be fixed, we prefer to rely on pqm to *detect* such problems :)
<mthaddon> vila: it's a hardy chroot, so python 2.5 is the default
<vila> mthaddon: ok, that's one thing
<mthaddon> vila: in what way does PQM need to be fixed?
<vila> see the bug report, despite an *error* it happily merged the submission
<nomatter001> hi
<poolie> bialix: it's a problem with the proxy setting being not seen
<nomatter001> when doing bzr export i get the following error: bzr: ERROR: zlib.error: Error -3 while decompressing data: incorrect data check
<poolie> fixed now, thanks for letting me know!
<bialix> poolie: :-)
<nomatter001> after googling i found that this means an data error
<nomatter001> is there some way to fix this
<nomatter001> bzr status / bzr commit and so on still work
<bialix> nomatter001: try to branch it to new location
<spiv> nomatter001: try 'md5sum .bzr/repository/packs/*' and check that the md5sums match the filenames
<mthaddon> vila: pqm just works by submitting if the command you give it returns a "0" exit code - if for some reason the conditions you're describing still return a 0 exit code, then PQM is still doing the right thing
<vila> mthaddon: right, so what is this command for the bzr instance ?
<nomatter001> spiv: not for all files
<lvh> Hi. I don't understand how to use the rewrite plugin to change the author of a bunch of commits.
<mthaddon> vila: for which branch?
<lvh> bzr rebase appears to be for rebasing branches like git's rebase, which isn't quite what I want (I think).
<vila> mthaddon: bzr.dev
<vila> mthaddon: but I hope it's the same for all  bzr branches :-}
<nomatter001> spiv: for 1 file it is different
<nomatter001> spiv: what can i do?
<mthaddon> vila: "make check PYTHON=python2.4" :(
<vila> mthaddon: LOL, good so it's 2.4 finally, I'll look into 'make check' now
<nomatter001> spiv: rename the file?
<poolie> i'm off, see you later
<vila> mthaddon: wow, reproduced, indeed, there are two commands for the make target and the second one is eating the first error :(
<mthaddon> good to have reproduced...
<vila> mthaddon: thanks a lot
<vila> mthaddon: I've enough info to propose a fix
<mthaddon> ok, cool
<spiv> nomatter001: if they don't match, the data in the repository doesn't match what bzr thought it was writing to disk, which probably indicates filesystem corruption has occurred :(
 * vila re-re-re-re-reading the make doc to find the right prefix
<nomatter001> spiv: so what can i do?
<nomatter001> spiv: can i get a diff between real data and what bzr thinks it should be?
<spiv> nomatter001: ideally, rebuild the repository from backups or other (good) copies that don't exhibit that error
<fullermd> First, you reverse MD5...
<nomatter001> spiv: i have an online repository which i branched right now where no error happend when i exported
<nomatter001> but i made a push into it (i think after error happend)
<nomatter001> can this still be valid?
<vila> nomatter001: is the file that doesn't match an empty one ?
<nomatter001> villa: no
<spiv> nomatter001: ok, so I'd make a new repository from that one, and then if you have new data in the damaged one branch/pull the new branches/revisions into it and hope they aren't affected.
<nomatter001> spiv: ok thx
<spiv> 'bzr check' when you're done should tell you if it the result is ok
<spiv> (Although just checking the md5sums would be a good and quick sanity check too)
<spiv> nomatter001: out of interest, which filesystem and OS, and has your system crashed at all?
<vila> ha, yeah, 'cmd1 | cmd2' in a Makefile... nice way to ignore errors in cmd1...
<nomatter001> spiv: archlinux, ext3 and no
<nomatter001> no crash at all
<vila> nomatter001: then it could be your HD slowly dying :-/
<nomatter001> vila: hd is 2 months old
<vila> nomatter001: the pack files are named with their md5sum and are *never* modified after that
<spiv> nomatter001: wow, that's really surprising then!
<nomatter001> vila: would be quickly dying
<nomatter001> :-/
<vila> nomatter001: what the english expression for that: infant mortality ?
<spiv> vila: exactly
<vila> nomatter001: some electronic devices die young or never, something like that
<spiv> I've also heard "bathtub curve of reliability"
<nomatter001> vila: yes i think its called mtbf
<vila> nomatter001: *I* would closely monitor this HD
<nomatter001> mean time between failure
<fullermd> These are hard drives.  It's not a bathtub, so much as an endless abyss.
<spiv> It's a question of the shape of the curve, not just where the mean is :)
<vila> nomatter001: all reports I've seen about such corruptions were massively empty files after crashes, the few others were hardware problems
<nomatter001> vila: ok great ...
<vila> nomatter001: I wish you the best but... if you really had no crashes nor rude reboots...
<nomatter001> nomatter@nomatter-laptop ~ % uptime
<nomatter001>  11:30:52 up 11 days, 14:47,  1 user,  load average: 0.00, 0.02, 0.05
<vila> scary, and you're sure the pack file has been created since then ?
<nomatter001> vila: hmm thats another question
<nomatter001> i have no idea when this files are created?
<vila> nomatter001: oh, the modification time should be good for that :)
<vila> nomatter001: they are *never* modified ;)
<spiv> 'stat that_file' should show you the mtime (and the ctime)
<nomatter001> vila: -rw-r--r-- 1 nomatter nomatter 55804179 Aug 10 07:40 925afb86da175268da810b3337d50eea.pack
<fullermd> Except by the hard drive  ;)
<nomatter001> ok no before
<vila> nomatter001: right, so that's before your uptime
<vila> fullermd: ;)
<nomatter001> vila: i have no idea what happend in that timeframe
<nomatter001> but what i know is that i could make exports since then
<vila> nomatter001: so hope for a crash, cross your fingers, kill a chicken, and monitor this HD for any suspicious activities ;)
<vila> nomatter001: follow spiv directions, if 'bzr check' is ok, then you're fine
<nomatter001> ok seems that the online repo is finde
<nomatter001> *fine
<nomatter001> i'm lucky
<nomatter001> so i have only to hope that another of my local branches is ok then i'm rescued
<nomatter001> thx for the help so far
<vila> nomatter001: if you use a shared repo, you only need to fix the repo
<spiv> nomatter001: you're welcome, and good luck with the mysterious corruption :/
<nomatter001> vila: how can i fix the repo?
<vila> nomatter001: ECONTEXT, I thought you just did that ?
<nomatter001> vila: i created a new repository
<nomatter001> and branched the trunk branch from the online repo
<vila> nomatter001: a shared repo ?
<nomatter001> vila: no normal repo
<nomatter001> or no shared-repo
<nomatter001> damn
<vila> nomatter001: let step back
<vila> how many branches did you have on your laptop, are they sharing a repo or are they standalone branches ?
<nomatter001> i have no idea i just followed the tutorial
<nomatter001> i made a repo with bzr init-repo
<nomatter001> wo i think a shared one
<vila> yup
<nomatter001> and in that i had several branches
<vila> err, init-repo creates a repo, if your create branches below that, they'll use this shared repo
<nomatter001> ok
<vila> run 'bzr info' in such a branch and you can confirm that
<nomatter001> yes
<nomatter001> and this shared repo doesn't work
<vila> ok
<nomatter001> cause one pack doesn't match the md5
<nomatter001> i also have a online-repo
<vila> so a shared repo contains all revisions ever created by any branch there
<nomatter001> and now i just created a new shared repo
<nomatter001> and branched the one branch in the online-repo into the new shared repo
<nomatter001> and that seems to work
<vila> good
<vila> how many branches do you still need to get back ?
<nomatter001> vila: only one is important
<vila> nomatter001: is it in the online repo ?
<nomatter001> vila: the other ones have no changes i still need (all important ones are in trunk and online)
<nomatter001> no that one is not online
<nomatter001> but if it doesn't work i have the code (outside of the repo online)
<vila> ok, but all the changes are still in the working tree, right ?
<nomatter001> vila: yes
<vila> nomatter001: try running 'bzr revno' in this branch
<nomatter001> ok
<nomatter001> its 50
<vila> nomatter001: try branching this branch under  the new repo, this will transfer all needed revisions from the broken repo to the new one OR fail
<nomatter001> vila: ok i'll try right after fixing the testserver (last scriptrun destoyed code there after incorrect export)
<vila> nomatter001: meh, this is unrelated right ?
<vila> nomatter001: then ping me when you're back
<nomatter001> vila: 1 minute
<nomatter001> vila: so now i'll try branching
<nomatter001> ok seems to work
<nomatter001> thx a lot
<vila> nomatter001: good
<nomatter001> perfect timing: its mealtime ^^
<chx> hi. how can i preview what bzr up would do?
<vila> chx: bzr missing ?
<chx> ooooooo
<chx> nice.
<chx> thanks
<vila> chx, well, not exactly, but it should help
<chx> vila: yes, it helped
<vila> mthaddon: can you check the last submission on bzr pqm instance, it has not been merged but I got no email either
<vila> mthaddon: I've seen it run there but not until the end
<mthaddon> vila: all I see is this, but that doesn't seem like it would cause a failure - https://pastebin.canonical.com/36445/
 * vila shudders
<vila> mthaddon: indeed, I can't see why it would change anything for this submission
<vila> mthaddon: but there should exist some more precise log of what happened for it no ?
<vila> mthaddon: or is it yet another email-too-big problem ?
<mthaddon> vila: https://pastebin.canonical.com/36446/
<mthaddon> not sure why you wouldn't have received that...
<vila> mthaddon: great, that's a better explanation
<vila> mthaddon: this is a random failure I've seen for a long time, first time it happens on pqm though... I'll try to re-submit :-/
<mthaddon> k
<vila> mthaddon: double shudder, yeah, AFAIK, I'm the only one not receiving such failures, I *receive* some failures, but not all... go debug that...
<mthaddon> spam filter?
<vila> mthaddon: me ? no. My ISP ? May be, but on which criteria ? Size ? spam filtered on size ? Hard to believe
<vila> delayed because of size maybe...
<sergio__> salve
<sergio__> !list
<ubot5> This is not a file sharing channel (or network); be sure to read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â»
<vila> mthaddon: sorry to bother you again, but re-submitting led to the same result: no merge, no mail :(
<vila> mthaddon: if you could confirm that the failure is the same for the same test, it would help
<mthaddon> vila: sure, gimme a sec
<vila> mthaddon: a whole minute even :)
 * vila tries to setup an hardy vm to reproduce
<mthaddon> vila: yep, same error
<vila> same test then ?
<vila> hmm, I wonder what the return address is on pqm emails... may be some mailbox contain same feedback on mails not passing through...
<vila> ha, pqm@bazaar-vcs.org, mthaddon, is that a mailbox you can reach ?
<mthaddon> nope
<vila> mthaddon: pff, silly me, that's the one that receive the submissions... I wonder what happened when it receives a "can't deliver" mail...
<vila> mthaddon: ok, I can reproduce the msg you got here, but that's not a failure and selftest succeds, there should be something else
<amogorkon> i need help with diverged branches
<amogorkon> i've got rev 43 on my local branch commited and another has rev 43 on their branch, both are connected with trunk
<amogorkon> when i want to pull or push to trunk, the branches have diverged
<vila> amogorkon: both ?
<amogorkon> bzr missing tells i'm missing one rev
<amogorkon> dunno, at least on my side
<amogorkon> when i try to merge, it says nothing to do
<amogorkon> when i try to commit, there's nothing to do
<vila> amogorkon: do you have uncommitted changes ? ok, that answers my question
<amogorkon> no conflicts
<vila> amogorkon: try 'bzr update'
<amogorkon> Tree is up to date at revision 43 of branch /home/amogorkon/Dropbox/PiLife bzr
<amogorkon> is that good?
<vila> meh
<vila> bzr missing
<vila> bzr info -v
<vila> check the later, it seems you should find that something is not as you think it is
<vila> amogorkon: and paste the ouput of 'bzr info -v', it will help to understand your setup
<amogorkon> http://pastebin.com/5RXJz5Df
<amogorkon> what does submit branch mean?
<vila> amogorkon: that's where you want your changes to land and is also the default merge source. Generally, that's trunk
<amogorkon> that.. is the cause of the issue then, i suppose
<amogorkon> how can i change that?
<vila> could be.
<vila> edit .bzr/branch/branch.conf and either remove the submit_branch line or put your trunk url there
<hno> bzr send --remember also changes the submit branch location.
<amogorkon> many thanks
<amogorkon> i'll try that
<vila> now if 'bzr missing' says you're *missing* one rev, 'bzr pull -v' should pull it
<vila> amogorkon: are your sure 'bzr missing --mine-only' is empty ?
<amogorkon> vila, now it displays me "1 extra revision" - the one i commited previously
<vila> amogorkon: then you should push it
<mgz> vila: would you be interested in a bug report with the tests that hit hangs with your leak fixes?
<mgz> so we don't lose track of them even if we can't fix them now.
<vila> mgz: indeed
<amogorkon> yeah, i think it works now
<vila> mgz: if only to see we get the same ones...
<amogorkon> another 40 min of my life spent fixing diverged branches :p
<amogorkon> thanks anyway :)
<mgz> I'll set up a full before and after run now.
<vila> amogorkon: may be worth changing your workflow :)
<amogorkon> vila, i'll take it into consideration if this submit branch thing doesn't fix it
<amogorkon> okay, thanks again
 * amogorkon bows out
<mgz> urk, syntax error in test_config I take it you know about vila and that change to the makefile was involving?
<vila> mgz: yes and yes
<vila> mgz:  the problem *right now* is that I can't land the fix because pqm is failing somewhere else
<mgz> what's the patch?
<mgz> I'll apply it locally so I can do this comparision
<vila> mgz: and since I don't get email failures I don't know where
<vila> mgz: lp:~vila/bzr/integration
<mgz> ta.
<vila> hmm, now I know which test is failing....tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
<vila> oh my, what a mess. I succeds on lucid/py26, fails on hardy/py24, succeeds on hardy/py25 with a traceback, succeeds on karmic/py24, failed on karmic/py25 (like hardy/py24), succeds on karmic/py26 (with the same tb than hardy/py25)
<vila> s/I succeds/It succeeds/
<vila> quite interesting for a test but obviously it's trying to test too much at once....
<vila> ...and poolie mentioned it this morning on maverick...
<vila> jam: ping, pp advice needed
<jam> hi vila
<jam> what's up?
<vila> I sent a submission this morning with a syntax error that pqm happily accepted
<vila> that was the lockable config files one, 3 things happened then
<jam> vila: yeah, I've run into that in the past, too
<jam> complained at the time, not much happened, I guess
<vila> 1) I sent the leaking test submission (accepted too on top of the previous syntax error merged cleanly)
<vila> 2) I noticed that pqm was damn quick and filed bug #626667
<ubot5> Launchpad bug 626667 in Bazaar "syntax error doesn't prevent merge (affected: 1, heat: 6)" [Critical,In progress] https://launchpad.net/bugs/626667
<vila> 3) I fixed the syntax error and submit the fix
<vila> The fix is at lp:~vila/bzr/integration right now
<vila> This last submission wasn't merged and I didn't get the failure email
<vila> I've been able to reproduce locally (make check PYTHON=python2.4) and this generates a 47M selftest.log which I suspect leads to a too-big email that is dropped somewhere between pqm and me
<vila> Anyway, the offending test is bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
<vila> And as I mentioned above:
<vila> <vila> oh my, what a mess. It succeds on lucid/py26, fails on hardy/py24, succeeds on hardy/py25 with a traceback, succeeds on karmic/py24, failed on karmic/py25 (like hardy/py24), succeds on karmic/py26 (with the same tb than hardy/py25)
<mgz> okay, I'm going out but have full run of r5395 and r5396 going with the syntax error fix
<vila> I feel a urgent need to disable this test to unblock pqm :) Thoughts ?
<vila> mgz: and ?
<mgz> and nothing till it finishes, I guess :)
<vila> jam: I feel a urgent need to disable this test to unblock pqm :) Thoughts ?
<vila> mgz: ha, I thought you had the results not that you launched the runs :) Cu !
<jam> vila: I'd feel best if you reverted to old code and worked back up
<vila> jam: my gut feeling is that this is a latent bug revealed not *caused* by the leaking fixes
<jam> so instead of just disabling it, submit a revert patch
<jam> that goes before the original borked submission
<jam> otherwise I can look more closely
<jam> if you want
<vila> I'd prefer that yes, that would be more productive, I'm filing a bug right now with details
<vila> this test have been failing intermittently for... months across all the platforms on babune
<jam> vila: given that you have 3 + patches that you don't actually know if it passed ...
<vila> jam: no, I just re-run the tests on my pqm-like setup and that's the only one
<jam> I'm not worried about that one test, but if you have 45MB of test failure
<jam> that is indicative of many tests failing
<vila> jam: no, only one test failure, the 47M are the *normal* subunit output
<jam> vila: here it is only 7MB, are you sure?
<jam> I've gotten several :)
<vila> 7MB compressed ?
<jam> possibly
<jam> well, compressed and then base64 encoded, I think
<vila> 47M uncompressed unfiltered here
<vila> jam: subunit stream or | subunit2pyunit stream ?
<jam> pqm-stdout.gz IIRC
<jam> note the discussion about whether we should remove 'logs' from skipped tests
<vila> jam: I have never been able to receive one so I really can't tell
<vila> jam: that's why I mentioned the 47M :)
<vila> jam: but getting rid of only the skipped ones will not help enough I'm afraid
<jam> My mailhost is configured to 10MB attachments
<jam> not sure about yours
<jam> default is often smaller, like 2-5MB, IIRC
<jam> I'd like you to chime in there
<jam> since being unable to get PQM output is pretty serious
<vila> jam: bug number ?
<jam> vila: merge proposal
<jam> https://code.launchpad.net/~jameinel/bzr/2.3-filter-tests/+merge/33938
<vila> hmm oh yes, I thought it was on testtools
<jam> well, lifeless saying "you really should have the log on skips" ...
<jam> given that we used to have a single "reason" line, that is now 50 lines of reason + formatting + log
<jam> not to mention subunit overhead
<vila> Well, I'd be happy to get this stream. I don't really like getting *less* details to debug. Skipped tests are only a minor part of the whole...
<vila> jam: can you check which stream you get on failures ?
<jam> I often can't get *failure* emails because they go above 10MB
<jam> pqm-stdout.gz is the interesting stream
<jam> for the subunit stream, everything is in the same output file
<vila> jam: yes, I don't have such mails, can you open or forward me one of yours
<jam> well, I can't forward it, since you can't get them :)
<jam> but I can post it somewhere :)(
 * vila slaps himself
<vila> jam: further evidence involving this test: bug #579530
<ubot5> Launchpad bug 579530 in Bazaar "paramiko does not try all available address families (affected: 1, heat: 3)" [Medium,Confirmed] https://launchpad.net/bugs/579530
<jam> think it is a ipv6 vs v4 thing?
<vila> jam: not sure in the case at hand, but it confirms that the tests is trying to test too many things at once
<la_kavrohi> How can I get my bazaar hook to access branch specific config values? Specifically, those stored in branch.conf.
<la_kavrohi> http://dpaste.com/236288/
<la_kavrohi> http://dpaste.com/236289/
<jam> vila: on chinstrap:~jameinel/pqm-stdout.bz2
<la_kavrohi> Nevermind. The push_result.local_branch or push_result.master_branch is the target of the push.
<vila> jam: 'time: 2010-08-24 16:55:43.668882Z' is enough identify it as a subunit stream right ? And it's 45M uncompressed anyway
<jam> vila: the log is in the subunit stream *and* 'bzr selftest' normal
<jam> if that is what you are asking about
<jam> so also in "subunit2pyunit' output
<jam> and 7MB of stuff we won't look at obscures the stuff we do care about
<jam> well, 47MB from what you said :)
<vila> jam: but how do you the stuff is not relevant until you understand the failure ?
<vila> jam: but how do you know the stuff is not relevant until you understand the failure ?
<jam> vila: not failures, *skips*
<jam> and test-not-applicable
<jam> and xfail
<jam> is what *I'm* trying to change
<jam> not actual failures
<jam> basically everything that wasn't *success* was getting the log attached
<vila> then why not keeping *only* failures ?
<jam> well, that and errors
<jam> but I think that is ~ what I've done
<jam> though doing it as a blacklist rather than a whitelist
<itamar> anyone know of a wiki that uses bazaar as a backend?
<vila> jam: no, you said that you only get rid of the skipped tests, this account for ~10%, this doesn't even guarantee that *I* will get email for failures
<jelmer> itamar: wikkid and ikiwiki both can
<jelmer> itamar: http://launchpad.net/wikkid, http://www.ikiwiki.info/
<itamar> ikiwiki had some caveats I didn't quite understand
<jam> vila: well, skips and xfail, I think account for most of it
<jam> at the least, it will account far a fair amount of shrinkage
<jam> though yeah, probably the subunit overhead might be part of it, too
<itamar> I'll look at wikkid
<itamar> thanks!
<vila> jam: I've been trough enough subunit/testools bugs on xfail and skip to know that they represent only a fraction of the tests...
<vila> err, xfail, not applicable not skipped
<vila> err, xfail and not applicable not skipped
<jam> vila: 2k out of 21k is a significant fraction, I'm trying to determine the verbosity now
<vila> jam: will that be enough to goes below the threshold that blocks the emails pqm is trying to send me ?
<jam> ah, I see what you mean, I didn't realize success also had a log, since it isn't output by selftest -v, which is where I really cared about it
<vila> how about an option for the logs ?
<vila> AAAAAAAAAARGHHHHHHH
<jam> vila: ??
<vila> jam: who was able to land parthm submission ?
<jam> other than parth?
<vila> anybody ! Currently pqm will accept *any* submission since they all inherit the syntax error
<vila> well, anybody than can submit that is
<vila> and of course it *has* to refuse the one that fix the error....
<vila> bah, yes of course, this the one that fixes the error is the only one that runs the test suite...
<jam> 5397 Canonical.com Patch Queue Manager 2010-08-30 [merge]
<jam>      (parthm) bzr homepage url fixed in docs. (Parth Malwankar)
<jam> looks like parth did it
<jam> anyway, yeah, we should do something quick to get pqm back to correct. either your patch or the idea of set -e.
<vila> set -e ?
<jam> I think for right now, just revert back pre-fix, add the Makefile fix
<jam> 'set -e' in bash says if any command fails with non-zero, exit immediately
<vila> I don't think we can do that from/for make
<vila> ha come on, the leaking test fix have been waiting for far too long and I'm 98% sure it doesn't cause this failure. Don't let the better be the ennemy of the good :-(
<jam> vila: we have failures in what was submitted, we don't know how much
<vila> jam: have you *looked* at this test ?
<jam> of what was submitted since then
<jam> I'm not worried about your 1 test
<jam> I also don't know why it would fail now when it has been passing for *years*
<vila> no, I said it already, only one failure, this test, reproduced locally
<jam> vila: how do you know if you aren't getting pqm failure reports :)
<jam> ?
<vila> I can propose various explanations, and no, it has not been passing for years, it has been *failing* randomly for years
<jam> other than knowing that you have an occasional failure locally which doesn't seem to have been happening on pqm
<vila> because I don't get my submissions landed either
<jam> vila: I don't think I've had a submission kicked back because of that test that I can think of
<jam> and I've submitted a lot
<jam> vila: right, but you don't know why *PQM* think you can't land it
<vila> read the logs, mthaddon gave enough info for me to reproduce
<jam> vila: set -e seems to work for me in Makefile
<jam> vila: so if it *is* random, then you should also be able to resubmit and have it work
<vila> ok, I resign, you're the patch pilot, go, send a revert-fix and don't forget to also unmark the bugs fixed
<jam> vila: I'm not trying to be extra difficult, but what you're saying doesn't match up to what I understand. You ran with python2.4 on your machine, and that was the only test that failed?
<jam> vila: also, I think we still have a bug with your fix that if the selftest.log has content, but has *no tests* then it still succeeds by accident
<vila> jam: yes, starting with bzr.dev as current before parthm submission and adding the fix in lp:~vila/bzr/integration, aka skipping this test until it gets rewritten as proposed in bug #626876
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876
<vila> jam: right, but that's a step in the right direction and plug a hole that have been present for *months*
<rubbs> Is there anyway to get a launchpad type interface for locally hosted branches? I ask, because I really like the way lp's UI deals with branches and their relationships, but my boss will never go for a third party hosting our code, ever.
<jam> vila: the test really isn't that big, all it is doing is implementing an ssh server, which you could pull out anywhere you want  if the number of lines concerns you
<jam> the test *is important* to make sure that we actually hook up the whole via ssh code
<dash> rubbs: well, worst case you could install launchpad :)
<jam> since *all the other tests* skip it and talk over a loopback
<vila> jam: I fully realize how important it is, but it fails far too often for far too many different reasons
<rubbs> dash: is there documentation on how to do that? I knew it was Open Source, but I couldn't find any way to do that itself.
<jam> vila: we need an (single) integration test or we have just as big of a whole
<jam> We've certainly in the past broken the ssh connection code
<jam> rubbs: there is some stuff around here: https://dev.launchpad.net/
<jam> but the big thing is, you have to create your own icons because the lp ones are trademarked
<jam> (similar to CentOS vs Redhat, and whatever Debian did with Firefox, IIRC)
<rubbs> jam: icons are no big thing. We got a designer here with little to do atm so I can give him that task
<rubbs> jam: thank you very much.
<vila> jam: I realize that, but the actual test is brittle, I've said it for months as I had to diagnose several failures where it was involved and delete/re-run countless jobs on babune just because it's capricious
<vila> jam: and I'm not surprised to see it fail on pqm as fixing the leaks shakes the socket handling code BIG times
<jam> vila: but then you remove one test that covers the actual case that people care about (nobody cares if you can connect via a loopback :)
<vila> jam: I don't want to suppress it, I want to replace it with several tests to get a better isolation of the failures
<rubbs> dash: jam: Oh, this is perfect thank you. I'll look into this right away
<jam> vila: the only thing it does after creating an ssh server is 'mkdir'
<vila> jam: at least one slave on babune is running a version of paramiko provided by spiv *explicitely* to *not* skip this test already
<jam> (well, creating one, connecting to it, and then issuing one command)
<vila> jam: and it currently fails for a ConnectionReset !
<jam> vila: which honestly sounds like we have a bug in our connection handling...
<jam> vila: anyway, my specific point... how can you get more granular on that test
<vila> jam: yeah, one that is not reproducible on all platform/python combos ?
<jam> I really don't see a way to rewrite it that isn't *connect to an ssh server*
<jam> vila: for example, on Windows and different versions of Python, they've had OSError.errno change from being the *windows* error, to a regular errno
<jam> (ENOENT versus WINDOWS_ERROR_NO_ENTRY as a not-quite accurate example)
<jam> vila: and I know we've had spew to the terminal for a while on Windows because when the client disconnected we would raise the exception rather than suppress it as we did on other platforms
<jam> (but it wouldn't die because it was an exception raised in a thread, etc)
<vila> well, separating a simple connect/disconnect first, then the simplest hpss handshake and so on up to mkdir
<jam> vila: I honestly doubt it is failing because of the mkdir + stuff
<vila> jam: exactly why a better isolation will be achieved by *not* having it
<jam> vila: if you really thought that mkdir was the problem, you could have trivially fixed that by now. I have the feeling you feel it runs deeper
<jam> also ,we only really want 1 test that exercises the handshake code
<jam> since it is fairly slwo
<jam> slow
<jam> if you want to pull out mkdir, I don't care *at all*
<jam> I care that we connect to a real ssh server
<vila> and this is test is lying anyway, there is no process launched, it's all in the same process and fixing leaks revealed that python + sockets + client + server in the same process... can lead to exceptions being thrown at different points from one excution to the other
<vila> my point is: I think we'll be better served by disabling this test until it's fixed (which can only occur soon since it's Critical) than reverting all the work already done and discussing endlessly while pqm is accepting any patch :)
<jam> (I think your optimism about 'only occur soon' is a bit high :) however, I am looking over your integration patch, etc now while we're discussing this
<jam> and I've queued up some stuff in pqm, as well
<vila> meh, it spwans a process
<vila> jam: you won't be able to land anything once you fix the syntax error
<vila> jam: unless you revert the leking tests submission that is, which doesn't mean that test won't fail either one day or the other
<vila> that's the whole point of fixing the leaks, selftest can blow up at any time as mgz realized lately
<vila> it hasn't occurred on pqm so far, we're still lucky
<vila> not fixing the leaks also means windows test can't be fixed using babune, osx slave can't be added on babune, etc
* jam changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.2-final has gone gold, build those installers
<jam> vila: so the typo... it is only a python2.4 typo? As 'test_config' loads just fine on python2.6
<vila> jam: 2.4/2.5, pqm runs in an hardy  chroot with 2.5 as the default python but we override that by running 'make check PYTHON=python2.4' as checked with mthaddon earlier
<vila> jam: I discussed the fix with poolie and spiv before sending it, short-circuiting the mp to go faster....
<jam> vila: the typo fix?
<vila> yes
<jam> sure, I'm certainly fine with the change, just trying to understand, as it looks like that fix is already in pqm, but you said it had failed
<vila> huh
<jam> vila: well, I was trying to submit the 'make check' fix you had, but it is behind your 'integration' fix
<jam> which claims to be at 50% complete
<vila> yeah, I send that when I saw parthm submission before realizing why it was useless (unless the failure is random...)
<vila> jam: check your setup, the test_config.py fix is not in bzr.dev AFAICS
<jam> vila: Oh I agree, as I said I'm running 2.6 and wasn't sure why it was a problem
<vila> GaryvdM: ping, don't upgrade your bzr.dev branch yet, pong me first
<vila> GaryvdM, bialix: can you test lp:~vila/qbzr/config-get-filename-deleted before upgrading bzr.dev ?
<vila> jam: if you submitted straight from my branch it should fail, I'd be interested to know if you get a pqm failure mail though :)
<jam> vila: well, it has passed 18k tests so far, and is on: bzrlib.tests.test_bundle.V08BundleTester.test_binary_bundle
<jam> not sure if that is before or after the test in question
<vila> it's the 24199th test out of 24758
<jam> vila: well doesn't that suck :)
<vila> jam: I had a brief, very brief, instant of pure joy this morning when I saw my submissions land in no time
<vila> that was quickly followed by the depressing understanding...
<vila> ..and the problem is still not fixed :(
<mgz> gra, r5396 didn't run, thought it'd merge over the syntax fix but it lost it
 * mgz runs it now
 * jelmer waves
<jam> vila: I did get the failure with attachment this time
<jam> vila: and it is giving a "ConnectionReset" error after spending ~5s (the test runs in 5.6s, I assume that is a timeout of some sort)
<jam> and as near as I can tell, that is the server failing to actually respond to the 'mkdir()' request...
<jam> log file is in the same plcae
<jam> plcae
<jam> place
<jam> (if my fingers could type)
<vila> jam: glad you got this email :)
<vila> jam: but it's failing here in 0.533s so not the kind of timeout you're suspecting
<jam> vila: so 'set -e' works as I wanted it to
<jam> I get the failure early rather than late
<vila> jam: good, as long as it works everywhere, I'm happy
<jam> vila: well at this point 'test_bzr_connect_to_bzr_ssh' seems to be failing reliably (though it also happens in 665ms here
<vila> jam: here ?
<jam> I just got it by only running test_transport
<jam> on my machine
<jam> and on pqm
<vila> python and paramiko versions ?
<jam> vila: http://www.davidpashley.com/articles/writing-robust-shell-scripts.html#id2384206
<jam> python 2.6, paramiko ... ?
<vila> regarding the interaction with leaks, the previous sftp server was just leaving threads around never joining them, so this may have hidden the problem
<jam> 1.7.5
<vila> jam: can you add that to the bug report please
<vila> jam: and that's with my fixes for leaks right ?
<jam> vila: that is current bzr.dev
<vila> ok
<vila> jam: only the traceback or more ?
<jam> vila: I don't understand "only the traceback"
 * vila on phone
<vila> jam: but look at bug #628876, there are a lot of variations
<ubot5> Error: Could not parse data returned by Launchpad: 628876 (https://launchpad.net/bugs/628876)
<jam> fullermd: you use csh? (well, something other than bash), right? Do you know if 'set -e' works there?
<jam> vila: wrong bug, I think
<jam> 628876 isn't a bug
<vila> bug #628876
<ubot5> Error: Could not parse data returned by Launchpad: 628876 (https://launchpad.net/bugs/628876)
<vila> meh
<jam> vila:  bug #626876
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876
<vila> bug #636876 gettubg there
<ubot5> Error: Could not parse data returned by Launchpad: 636876 (https://launchpad.net/bugs/636876)
<jam> you had a 6=>8
<vila> twice :)
<vila> can type and phone :)
<vila> cant :)
<jam> vila: everything I saw looks like a variant on connection reset
<vila> jam: there are other tbs sometimes
<jam> in your python2.5 it is raising EOFError (aka, no more data, aka connection closed)
<vila> that can be ignored
<vila> on which platform ?
<jam> vila: https://bugs.edge.launchpad.net/bzr/+bug/626876/comments/1
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed]
<vila> jam: that's freebsd
<jam> vila: everything looks like connection reset, just variants on how well the python + paramiko + bzr stack handle translating it as such
<vila> jam: we shouldn't lose the connection, that's the root problem
<vila> jam: and I would happily suspect my fixes if there wasn't *successful* tests
<vila> so I'm more inclined to suspect the bug to reveal itself more blatantly now, since, after all, this is what happened numerous times while debugging the leaks,
<jam> vila: well it fails if I run the test by itself, so I'm not sure that it has anything to do with leaking threads...
<vila> jam: have you tried to establish how many threads/sockets/pipes are involved in this test ?
<vila> have a guess
<jam> Approx 5
<jam> but paramiko does threads also, so I'm not positive
<vila> I'd say 2 processes, 7 threads, 3 sockets and 3 pipes
<vila> we should be able to get down to 2 processes 3 threads 3 sockets and 0 pipes
<jam> vila: perhaps, but it certainly passes @ -r5395 and fails @ -r5396
<vila> that's a fact, but it says little about the cause
<jam> vila: I think I found it
<jam> vila: http://paste.ubuntu.com/485997/
<jam> note that you don't actually save a reference to *test_case_server*
<jam> nope, not it
<jam> at least, not trivially so
<vila> that would not explain a succesful test
<jam> vila: what successful test, btw
<jam> also, I don't seem to be able to get trace information in my log file from the sftp thread, any ideas why?
<vila> https://bugs.edge.launchpad.net/bzr/+bug/626876/comments/2
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed]
<vila> also succeds on hardy/py2.5/paramiko-1.6.4 with a traceback from a thread that can be ignored
<vila> - succeeds on karmic/py26/paramiko-1.7.4 with the same traceback than hardy/py25
<vila> all of them mentioned in bug #626876
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876
<vila> Ha ! Got it right !
<vila> all of the run involve 0 to 2 failures in ferry_bytes (including the ConnectionReset except this one comes a bit later in the code)
<jam> vila: I'm also getting: No handlers could be found for logger "paramiko.transport"
<jam> which would hint that paramiko is trying to warn us about something, but the logging module isn't initialized
<jam> which may be "I couldn't actually start up as requested"
<vila> that's not in your comment or is it ?
<jam> givien the other hints
<jam> vila: not sure
<jam> I probably didn't paste that part
<vila> ok, I got it too on some combinations
<jam> vila: I get it much before the final traceback
<vila> yeah, at the start of the run, probably when loading
<vila> where I get it it's about Random.Pool being BROKEN or something
<jam> vila: nope
<jam> if I add a "trace.enable_default_logging()" in the middle
<vila> nope what ? 8-)
<jam> I get: http://paste.ubuntu.com/486002/
<jam> vila: not during import
<jam> maybe during import of a subprocess or something
<jam> vila: that is with this patch: http://paste.ubuntu.com/486003/
<jam> Basically, on my machine, I'm not *getting* to ferry_bytes
<jam> it fails first
<vila> oooh, right, yet another different failure ! Fireworks !
<jam> vila: well still a connection failure
<vila> but still a problem while client and server are trying to communicate
<jam> with this patch: http://paste.ubuntu.com/486003/
<jam> on my machine, I'm not even getting into check_channel_exec_request I think
<jam> at least, I am unable to log what is happening there
<vila> not the way to go then ? :)
<jam> vila: I fixed logging, a bit more info now:
<jam> http://paste.ubuntu.com/486008/
<jam> paramiko is trying to say: Socket exception: Bad file descriptor (9)
<vila> right, that's still match the: "someone is trying to read or write at the wrong time" pattern and paramiko use timeouts
<vila> jam: no traceback ?
<jam> vila: doesn't seem to be one on the server side
<jam> trying to sort it out
<vila> Connected (version 2.0, client paramiko_1.7.5)
<vila> Connected (version 2.0, client paramiko_1.7.5)
<vila> Twice ???
<jam> vila: I'm playing around with trace stuff, so it is possible I'm just getting 2 outputs to stderr
<jam> but yes, it does say that
<jam> vila: if I change paramiko to 'raise' where it was just logging I get: http://paste.ubuntu.com/486010/
<vila> here is my traceback on babune: http://paste.ubuntu.com/486012/ ferry_bytes is involved
<vila> forget about the .bzr.log error
<vila> meh, no .bzr.log error there, forget the 'forget' remark ;)
<jam> vila: 'failed to load compiled extension' is a bit surprising
<vila> the weird thing is that I ran this on windows
<vila> jam: fresh branch
<vila> we don't care about extensions for this test
<vila> hmm, indeed, and it was failing already: http://babune.ladeuil.net:24842/job/selftest-windows/139/#showFailuresLink
<vila> I just didn't notice it because it was down to 7 failures on windows (from 306 but for runs interrupted by can't start new thread)
<vila> anyway, way too late to continue, EODing
<vila> http://babune.ladeuil.net:24842/job/selftest-windows/138/testReport/junit/bzrlib.tests.test_transport/TestSSHConnections/test_bzr_connect_to_bzr_ssh/
<vila> is evidence that we *had* a failure with ConnectionReset *before* my patch
<vila> jam: so make sure it was passing for you on *windows* *before* my patch
<jam> vila: it passes
<jam> if I revert
<jam> fails after
<jam> -r5395 passes, -r5396 fails
<fullermd> jam: Not as set -e, no.  There's an -e command line arg just like sh.  Why?
<vila> rha, right, same branch, I'm too tired
<jam> fullermd: trying to get "make check" to fail if there are any failures. I don't think it is required to run a bash, though
<jam> fullermd: we're having the bug that the right kind of error will make PQM think everything is ok
<fullermd> Well, it better run a sh.  set -e is standard on Bourne shells AFAIK.
<jam> (currently a syntax error)
<lifeless> jam: do you need any help with this
<lifeless> fullermd: I think its pipefail thats not set
<lifeless> fullermd: -e affects the results of a pipe, not the steps
<vila> fullermd: yup, as lifeless said, the root cause is an action in a makefile: cmd1 | cmd2
<vila> fullermd: cmd1 fails, cmd2 succeeds, make is happy
<vila> fullermd: how will you convince make to abort when cmd1 fails ?
 * fullermd isn't sure why people are telling me   ;)
<lifeless> vila: pipefail
<vila> fullermd: oops, it's GNU make :)
<lifeless> vila: man bash - look for pipefail
<vila> lifeless: just found it, but it's bash, if we require bash in addition to GNU make.... well, that may work
<lifeless> you're using bash
<lifeless> make doesn't have a shell interpreter
<fullermd> _I'm_ not using bash.
<lifeless> fullermd: you aren't you're
<vila> make use ${SH}
<lifeless> true
<vila> fullermd: but is it always available on freebsd >
<lifeless> anyhow
<fullermd> Yes, but make won't use it.
<lifeless> easiest way - put the test command in a bash script
<lifeless> call that script
<james_w> SHELL=/bin/bash in the Makefile and it will
<fullermd> There is no /bin/bash on all sorts of systems.
<lifeless> fullermd: this is just for pqm, so that point, while entirely true, is irrelevant
<vila> easier : https://code.edge.launchpad.net/~vila/bzr/626667-check-no-docs-swallow-errors/+merge/34059
<vila> lifeless: ! could be
<vila> lifeless: but could fail if the log file is not empty.. somehow
 * fullermd just sees this as a good reason to keep working on his make(1) replacement   :p
<mkanat> fullermd: You and everybody else? ;-D
<mkanat> There actually are like two or three good autotools/make replacements.
<fullermd> Well, sure, but mine is obviously the important one.  Everyone else is just marking time 'till I'm done   :p
<mkanat> fullermd: lol
<fullermd> I don't really need to build a replacement for autotools.  I can slit my wrists with a rusty spoon already.
<mkanat> LOL
<fullermd> I wasn't overly thrilled with any of the make replacements I saw.  Hence, firing up the ol' Arrogance Engine.
<mkanat> Heh. :-)
<mkanat> Well, nothing wrong with that. :-)
<fullermd> Part of the problem is that I don't want a "build system", so scons and the like are out.  I really do just want a make(1), except without the suck.
<vila> jam: so, it seems bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh has never been run on babune except for my tests for leaks where it has always failed :)
<vila> jam: so good luck with it, see you tomorrow, keep me informed of your progress !
<vila> g'night all
<jam> lifeless: I think we have a handle on how to make 'make check-nodocs' fail (set -e works, as would Vincent's suggestion, or figuring out how to set pipefail).
<jam> the problem right now is do we disable a test that used to pass, but was a bit brittle in some cases, but now *always* fails
<jam> I don't think I've ever had it fail on PQM, but it now fails on PQM and on my machine (where it also used to pass)
<lifeless> self.skip ?
<lifeless> I mean, mark it as a skip? would that do? then once pqm is locked down safely again, start landing attempts that un-skippify it
<jam> lifeless: yeah, to get it unblocked I'll probably do that. I was hoping to actually fix it
<jam> but since I'm going off the clock in about 5min, I'll have to take the easy route
<bj0_> there was a file in my directory that somehow got renamed to "\",  and when I did a "bzr add ."  it would crash bzr trying to add that file
<mgz> okay, film was fun. seems like the entertainment has continued here as well.
#bzr 2010-08-31
<spiv> Good morning.
<poolie> hi all
<JaredW> I think there was a plugin that automatically finds the revision where something broke (by running a command on different revisions in a binary search). Does anyone remember the name?
<spiv> bisect
<poolie> hello spiv
<spiv> Hi poolie
<poolie> i might have a look at this spurious test failure
<poolie> should we actually keep the strace facility?
<poolie> nothing uses it but its own tests
<poolie> lifeless: ^^
<poolie> i can see it being useful for some effort tests, but i can also see that causing deadlocks etc by trying to trace ourselves
<lifeless> poolie: if its a pain, nuke it.
<lifeless> I doubt I'll be doing low level perf work on bzr in the near term :(
<poolie> :(
<poolie> if you were, do you think you'd use this?
<lifeless> I did anytime I needed strace stuff
<poolie> how did you use it? by logging the activity of a particular bit of code?
<poolie> or actually writing tests that inspected it?
<lifeless> the former
<poolie> i can see that being useful, to catch just a particular seciton
<poolie> wbn for prof too
<lifeless> right, prof does that :)
<poolie> prof does what?
<lifeless> sorry, brb
<poolie> https://code.edge.launchpad.net/~mbp/bzr/626679-strace/+merge/34157
<lifeless> poolie: sorry, was otp
<lifeless> back now
<poolie> np
<poolie> i decided it was worth keeping around
<lifeless> bzrlib.lsprof lets you call a specific section easily.
<poolie> you can review it if you have a moment
<lifeless> when it updates the diff I shall
<poolie> sorry i meant perf, not prof
<poolie> which is an external tool like strace
<fullermd> Most profs get annoyed if you perf them...
<mkanat> Prof perf.
<poolie> hello mkanat
<mkanat> Hey poolie!
<poolie> hi there
<poolie> i'm back from my trip
<mkanat> Oh great. :-)
<poolie> did you get to working on loggerhead yet?
<mkanat> poolie: I didn't, unfortunately. I'm thinking it will be after Sept 2.
<mkanat> poolie: Although I did do a bit of work last week.
<poolie> np, just wondered if you were blocked or anything
<mkanat> poolie: Okay. :-)
<vila> hi all !
<mgz> morning all.
<mgz> vila: these are the tests that are different between r5395 and r5396 from my run:
<mgz> http://float.endofinternet.org/temp/landed_leaking_diff.xml
<vila> mgz: meh, http://float.endofinternet.org/temp/landed_leaking_diff.xml#bb.test_branch.TestSmartServerBranching.test_branch_from_trivial_branch_to_same_server_branch_acceptance
<vila> AttributeError: 'TestAncestry' object has no attribute '_cleanups' ? You're cleaning up too much my dear :)
<mgz> yeah, I think this is to do with TestCase instances sharing too much
<vila> mgz: first you don't want me to use closures and now I can't even use cleanups ? :)
<mgz> no, I just think it's a pre-existing bug :)
<mgz> like bug 625574 or something
<ubot5> Launchpad bug 625574 in Bazaar "testtools details should not be shared between parameterised tests (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/625574
<vila> mgz: TestCase instances sharing... anything sounds scary, that needs to be precisely diagnose to know whether or not we can do that (by default: no, but there could be exceptions for read-only things (methods, functions, whatever, I think there is at least a _test_root_dir or something that is legal to share)))))
<vila> mgz: hmm, interesting bug... this really needs to be dug
<vila> mgz: anyway, back to your initial remark, can you summarize your feelings about the differences ?
<mgz> well, took 72mins vs. 51mins which I think I can live with for the moment, and basically everything but the run time is an improvement
<mgz> (pretty sure all the new orange is equally shallow)
<vila> mgz: so on this precise point, I'm pretty sure it's only the hung threads adding their 5s timeouts which a 'kill thread' should fix
<mgz> I prefer 5s waits to thread killing.
<vila> why ?
<mgz> TerminateThread is scary in a way TerminateProcess isn't
<vila> I've diagnosed those as being: both client and server are waiting for each other or, said otherwise, python seem to not shake some bytes in the socket under unknown scenarios only encountered on windows
<vila> mgz: ha, yes, this fear :) Well, the plan is to test first how this behaves, since all threads (we care about in this precise case) catch exceptions, it will be totally safe (the kill will happen during test shutdown where, by definition, we know we are done with whatever socket or any other resource used)
<mgz> ah, you just mean raising an exception in the threads?
<vila> spiv: have you seen bug #626876
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876
<mgz> not killing them dead?
<vila> mgz: hehe, 'kill thread' is implemented by raising an exception in the thread :)
<vila> and AFAIK we can raise *any* exception
<vila> but that's what I want to test
<mgz> okay, that's less scary then
<vila> good
<vila> Knowledge 1 - Ignorance (driving fear) 0
<mgz> I'm out for the day, see y'all later.
<lifeless> ciao
<spiv> vila: seen, yes.  Thought carefully about... not yet :)
<vila> lifeless: cu
<vila> spiv: right, so I think there are two ways to rewrite it: 1) use a server in the same process, 2) spawn a real server as a separate process
<vila> the actual version is a mix of both (the real server is spawned at connection time)
<vila> I favour (1) and may give it a shot today
<poolie> hi mgz, vila
<vila> poolie: hey !!
<poolie> thanks for the speedy review vila
<vila> my great pleasure ;)
<vila> poolie: made me feel, like, 5 years younger or something :)
<poolie> :)
<GaryvdM> Hi vila. I'm trying to fix the test error with https://code.edge.launchpad.net/~vila/qbzr/config-get-filename-deleted/+merge/34095
<GaryvdM> It's failing because TEST_DIR/home/.bazaar does not exist.
<GaryvdM> vila: Can you give me any pointers on how to fix?
<vila> GaryvdM: that's ensure_config_dir() call missing, rats, old bzr or current ?
<vila> GaryvdM: lunch time, here, bbl-ish
<GaryvdM> vila: That error is only on old bzr, not on current
<GaryvdM> vila: ok - Busy reading diff of you lock config files patch
<vila> GaryvdM: right, ok, so for old you can call ensure_confdir_exist with a check for bzr version :-/
<vila> GaryvdM: yeah, you should read it carefully and I advice you now inherit from LockableConfig, just to protect yourself against multiple qbzr instances runnning conccurrently (qlog here, qblame there, yet another qlog, etc), I dunno if you're yet ready to have a 2.2 branch in addition to a trunk branch though
<vila> GaryvdM: but definitely interested in how you handle the transition
<vila> GaryvdM: off now, back in <= 1h
<GaryvdM> vila: ok
<lvh`> Hi
<lvh`> is it possible to revert the damage done by the rewrite plugin? I'm guessing no.
<lvh`> Actually, it's probably okay. No commits were lost.
<luks> I'm sure they are not
<luks> revisions are never deleted from a repository
<lvh`> right
<luks> use bzr heads --dead to see all the revisions which are not referenced by the branch
<lvh`> they're just organized a bit bogusly and I found a better way to fix the original problem
<luks> then you can use bzr pull -r revid:XXX --overwrite to get the revision  back
<vila> lvh`: daggy-fix is your friend then, start again from before your first attempt and redo your commits from there in the right order. 'bzr merge -rx..y' (aka cherry-pick) can help you, as well as 'bzr diff --old <old> .' to see how you converge
<vila> GaryvdM: I'm back
<GaryvdM> Hi vila.
<GaryvdM> vila: I think I need to do alot of cleaning up of the qbzr config code.
<vila> GaryvdM: Will you try to maintain compatibility with bzr-2.2 ?
<GaryvdM> vila: Yes
<vila> GaryvdM: good, I'm all ears about potential problems then, especially if we could make the transition easier by adding some deprecated helpers in bzr.dev
<GaryvdM> vila: Well in not sure why we have 2 different classes to write to qbzr.conf. So I'm going to start by deleting QBzrGlobalConfig...
<vila> wow
<GaryvdM> QBzrConfig does not inherit from bzrlib.config.XXX classes, so compatibility should not be a issue...
<vila> WOW
<GaryvdM> I'm going to copy your locking code to QBzrConfig
<vila> GaryvdM: it's abit of a shame that this code isn't shared, but on the other hand, it addresses the compatibility issues :)
<stianse> hi. i'm trying to create a svn mirror of a bazaar branch, that for instance in a cron job pulls from the bazaar branch and pushes into the svn repository.
<stianse> However, the "bzr push svn://whatever/path" fails due to "Tags not supported"
<stianse> The revisions are there, so it seems to work, but is there a better way that does not cause the command to fail?
<stianse> I've tried dpush, but then the next pull won't work since I get the message about diverged branches.
<jelmer> stianse, hi
<jelmer> stianse: your local branch has tags, and bzr-svn doesn't know where to add them.
<stianse> jelmer, yes i figured. That's why I tried dpush, but that had bad side effects for the next pull.
<stianse> Perhaps there is a way to delete all tags before pushing to svn?
<jelmer> stianse: did you use the --no-rebase option perhaps?
<jelmer> stianse: You can delete the tags using "bzr tag --delete"
<parthm> hello. i update my bzr.dev trunk today and `bzr selftest` fails with error importing TestLoader. has something changed? http://pastebin.com/KSbvutec
<vila> parthm: perhaps you didn't run the tests for bzr-search for a long time ?
<parthm> vila: ah. yes. ... i just noticed it was the plugin. never mind. i will just disable it. i wanted to run the test on the trunk :)
<parthm> vila: thanks.
<vila> parthm: you're welcome
<parthm> hmm. it seems to fail for plugin_info also.
<stianse> jelmer, the problem about using tag --delete is that you have to know the tag names. since I plan to run this in a automatic script this is not very practical
<jelmer> stianse: can you just not create the tags in the first place, or push to a svn location that supports tags?
<vila> jelmer: Russel mentioned bzr-svn trunk being broken with bzr.dev, I'm 95% sure it's related to my second fix for bug #525571 which introduced real lock for config files, feel free to ping me if you need help. Otherwise, your feedback is welcome if you encounter problems migrating to the new config objects.
<ubot5> Launchpad bug 525571 in Launchpad Bazaar Integration "No locking when updating files in ~/.bazaar (affected: 7, heat: 52)" [High,Fix released] https://launchpad.net/bugs/525571
<stianse> jelmer, I could if I had control of either of the two. unfortunately I don't
<stianse> jelmer, dpush --no-rebase causes the next dpush to fail because they have diverged. not using --no-rebase causes the next pull to fail
<jelmer> stianse, how does the next pull fail exactly?
<jelmer> stianse: well, you can push to the svn repository so you have /some/ control over it :-)
<vila> jam: can you test lp:~vila/bzr/626876-bzr-connect-to-bzr-ssh on windows ?
<jam> morning vila
<jam> sure
<vila> jam: morning !
<vila> This "fix" it for me on hardy and karmic so far
<mgolisch> can i create a new branch from changes i did but not actualy commiting them to the current branch?
<GaryvdM> parthm: I've logged that as bug 627435
<ubot5> Launchpad bug 627435 in bzr search plugin "ImportError running selftest -s bp.search in bzr.dev (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/627435
<vila> jam: I totally forgot about the FIXME above the one-liner fix :)
<stianse> jelmer, uploaded the commands and output at http://pastebin.com/hghpLeYQ
<parthm> GaryvdM: thanks for the ticket :)
<jam> vila: well, not really a fix per say just a hack around :)
<jelmer> stianse, you're pulling from a different location than you're dpushing to
<stianse> jelmer, i know. isn't that allowed if i don't have any new commits?
<vila> jam: well, you've read the comment ? I was deep into paramiko internals when I wrote that, it's a shame we have to wait there, but it's needed to make paramiko happy.
<stianse> jelmer, the location I'm pushing to is just a mirror and won't have any additional commits
<jelmer> stianse: it is, but please read up on what dpush does - it changes the revisions in the current branch
<jam> vila: paramiko is doing a 'wait' on a Threading.event() I don't see why we should need to sleep at all
<jam> though it may depend on version
<vila> jam: Otherwise, we get all sort of random failures (as collected in the bug report) because some sockets are checked too early and considered broken
<jelmer> stianse: thus making your current branch deferred from whatever branch you might be pulling from
<vila> jam: because multiple threads are involved and if the wrong one is awaken too soon it draws the wrong conclusion about the socket
<stianse> jelmer, ok I understand. That leaves me with the push command.
<jam> vila: any sort of delay like this is going to be wrong sometimes... depending on load, etc.
<jam> but I'm running it now
<jam> (while my system is otherwise heavily loaded :)
<vila> having several threads handling the same socket (from both sides) *and* using timeouts is a Bad Idea
<jam> failed
<vila> jam: shouldn't matter
<vila> try increasing the timeout
<jam> vila: changing 0.2 => 0.5 would have a strong indication on load
<jam> running again, it fails in a different place, at least
<jelmer> stianse: You can either add "/trunk" to the URL you're pushing to, and bzr-svn will push tags to "/tags/tagname", or remove the tags before pushing.
<vila> jam: I don't intend to propose this fix, I just wanted to know if I had a fallback
<vila> jam: I encounter the comment while setting up a new test smart server :)
<jam> vila: if I set the time.sleep to 5.0s then it does pass
<jam> at 1.0s, it sometimes passes, sometimes fails, and still gives: No handlers could be found for logger "paramiko.transport"
<vila> jam: ok, thanks, that's enough for me. It means paramiko is somehow broken and should be used with caution, once I had the test rewritten, I'll get rid of the sleep too
<stianse> jelmer, that "/trunk" in the URL was exactly what I was looking for. I didn't know about that feature.
<stianse> jelmer, thanks for your help
<jelmer> stianse, np
<bcurtiswx> is there a step-by-step for a proper merge.. I keep getting Branches have no common ancestor, and no merge base revision was specified.
<GaryvdM> bcurtiswx: Merging branches that don't have a common ancestor in quite uncommon. Is there a reason why you are doing that?
<GaryvdM> bcurtiswx: May be you are merging branches from different projects.
<bcurtiswx> well, i think my issue is with getting that common ancestor
<bcurtiswx> i branch lp:ubuntu/lucid-proposed/empathy
<bcurtiswx> which is version 2.30.2
<maxb> A common ancestor naturally results from normal bzr usage
<maxb> You must be doing something unusual :-)
<vila> ... when faced with parallel imports :-/
<vila> ... except when faced with parallel imports :-/
<bcurtiswx> maxb: im not denying that, i'm trying to figure out where my stupidity has started from :P
<vila> bcurtiswx: what is your other branch and where is it coming from ?
<bcurtiswx> so I want to take the new 2.30.3 and merge with 2.30.2,..
<bcurtiswx> i bzr init empathy/empathy-2.30.3
<bcurtiswx> move file contents over, bzr add
<vila> stop
<vila> wrong
<maxb> uh, yes, don't do that :-)
<bcurtiswx> OK, so where to go from here :)
<vila> bcurtiswx: doing that will create a different ancestry which is why you wont have a common ancestor :)
<vila> err, sry, where do you get 2.30.3 ?
<bcurtiswx> vila http://ftp.gnome.org/pub/GNOME/sources/empathy/2.30/
<bcurtiswx> bottom
<vila> ha, right, a tarball
<vila> so, tar xf on top of your branch unless there is a lp:empathy,
<bcurtiswx> sorry for the newbish but what do you mean on top of my branch?
<vila> bcurtiswx: sry, I meant, in the directory where you have your 2.30.2 branch
<vila> i.e. you will update your working tree which is 2.30.2 with the sources that are 2.30.3
<vila> bzr st ; bzr diff; should show you what have changed
<maxb> except, wait, if this is an Ubuntu packaging branch, you presumably want bzr merge-upstream
<vila> bcurtiswx: oops, listen to maxb !
<bcurtiswx> my goal is to make a branch of the changes, and request a merge
<bcurtiswx> yes ubuntu
<bcurtiswx> maxb: how does a bzr merge-upstream work, and whats the correct syntax?
<maxb> I'm not very familiar with bzr-builddeb's voodoo, but I do know you definitely need to use it
<maxb> james_w`: You don't happen to be around, do you?
<james_w`> maxb: I do
<maxb> james_w`: bzr merge-upstream confuses me, but I know it's what bcurtiswx needs to use - do you have a good initial reference to point him to?
<james_w`> hi bcurtiswx
<bcurtiswx> james_w`, hi
<james_w`> bzr merge-upstream takes a tarball and merges it in to your packaging branch
<bcurtiswx> james_w`, whats the correct syntax then?
<james_w`> it does this in a way that means that it builds on the previous upstream changes, but merges in your packaging changes
<vila> mgz: ping, I have another instance of selftest unable to complete because of a unicode error (on OSX). testtools and subunit up-to-date, Do you have something in the pipe I can try or do you want a bug report ?
<james_w`> the basic syntax is (in the branch you want to merge to) bzr merge-upstream --version 2.30.3 http://ftp.gnome.org/pub/GNOME/sources/empathy/2.30/empathy-2.30.3.tar.gz
<vila> mgz: or is there some existing bugs I should check ?
<james_w`> that will then churn for a minute, then should tell you either that there were conflicts or that the merge went fine
<james_w`> either way "bzr diff" will show you the changes bought in by the new upstream version
<bcurtiswx> james_w`, 'bzr merge-upstream <tar.gz file>' from the packaging branch?
<james_w`> tweak the changelog as necessary, and make any other changes that need making, including resolving any conflicts, and then commit
<bcurtiswx> james_w`, thx, i will go try that right now
<james_w`> bcurtiswx: you currently need --version as well, as it is not smart enough to infer that yet
<james_w`> for the tar.gz file it can take any local path, or http, ftp, sftp, etc. uri
<bcurtiswx> james_w`, i get an "unknown command 'merge-upstream'"
<maxb> You need the bzr-builddeb extension
<james_w`> bcurtiswx: install bzr-builddeb
<bcurtiswx> hmm, thought I had that. thx
 * maxb wonders if anyone has thoughts on my "testtools and subunit in the ~bzr PPA" email
<bcurtiswx> hmm, may still need some advice
<bcurtiswx> bzr push lp:~bcurtiswx/lucid-proposed/empathy | bzr: ERROR: Invalid url supplied to transport: "lp:~bcurtiswx/lucid-proposed/empathy": No such project: lucid-proposed
<bcurtiswx> i wanted it to create lp:~bcurtiswx/lucid-proposed/empathy , it has before, idk why not now
<maxb> bcurtiswx: Basically, there are two kinds of lp: URLs
<maxb> Project, and Distro-Source-Package
<maxb> So, lp:~user/project/branchname, but lp:~user/distro/series/package/branchname
<maxb> And then each of those has abbreviated forms for important branches
<bcurtiswx> so i want lp:~bcurtiswx/ubuntu/lucid-proposed/empathy ?
<maxb> no - look again at my 5-element example (most importantly, there must be 5 elements :-) )
<bcurtiswx> so i want lp:~bcurtiswx/ubuntu/lucid-proposed/empathy/empathy-2.30.3
<maxb> Nearly, but the 3rd component is just a series, not a series-pocket
<bcurtiswx> so it doesn't matter that it will end up in lucid-proposed, i just need lucid?
<maxb> yes
<maxb> and yes, this is a bit arcane
<maxb> especially since the 3-element shortcut form for DSP branches does have a series-pocket in it
<mgz> vila: is the OSX problem bug 625589 as well? in which case, yeah, I've got something lined up.
<ubot5> Launchpad bug 625589 in Bazaar "babune junitxml not well formed on Python 2.7 (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/625589
<exarkun> Why can't I see any loom data when I check out nosmart+bzr+ssh://bazaar.launchpad.net/~exarkun/+junk/modules ?
<vila> mgz: I don't think so: http://paste.ubuntu.com/486389/
<mgz> ah, I see. Yeah, I've hit that before and just changed this line in the bzrlib TextTestRunner:
<mgz>   stream = osutils.UnicodeOrBytesToBytesWriter(encode, stream)
<mgz> to add a 'replace'
<mgz> wonder why the mac stdout is 'ascii' rather than 'utf8' like other nix boxes.
<vila> hmmm, ascii, indeed, why ?
<mgz> 'v written code in testtools 0.9.4 that's a bit more robust about how it prints test results to stream, but didn't want to change the bzrlib code to require it till people had time to upgrade
<maxb> exarkun: According to http://bazaar.launchpad.net/~exarkun/+junk/modules/.bzr/branch/last-loom, your loom has no threads
<vila> mgz: mail the list, pqm should come first
<maxb> exarkun: that is somewhat broken, as I understand it
<mgz> vila: what does python -c "import bzrlib.osutils;print osutils.get_terminal_encoding()" give you?
<exarkun> maxb: The branch I pushed had two threads
<mgz> +bzrlib.
<vila> exarkun: sounds like an old bug in loom
<exarkun> Last night lifeless suggested that if I re-pushed with a new version of loom everything would be great
<exarkun> But I did that and it didn't appear to help
<maxb> exarkun: Perhaps you could try pushing to a fresh launchpad branch?
<vila> mgz: just a sec, locale under emacs (where I ran selftest) says: LC_ALL='' and the rest C, while launching a terminal properly put utf8 all over the place
<mgz> ha. that'd be the immediate cause then.
<exarkun> Hm.  Okay.  When the machine with the original branch comes back.
<mgz> there is a real bug with printing results to non-unicode-encoding streams though, that I'll file.
<maxb> exarkun: based on 'bzr heads --dead' not showing anything, it appears the loom metadata has not made it up to launchpad at all
<vila> mgz: yup, US-ASCII under emacs, UTF-8 in terminal, that maybe a bug in my setup though
<GaryvdM> vila: I'm trying to write better tests for qlog. I just wrote this: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/annotate/head:/lib/tests/test_loggraphprovider.py#L47
<GaryvdM> vila: what do you think. one thing I don't like about it is I can't easily visualise the expected data that I am specifying.
 * GaryvdM starts writing a printComputed method for debugging...
<vila> GaryvdM: argh, I've EODed, cooking right now :-/ Can you send me an email so I don' forget to look at that ?
<GaryvdM> vila: np - ok
<vila> GaryvdM: but after quick glance, you want to look at branchbuilder.py and hmmm what;s the name LogCatcher ? in bt.test_log ?
<GaryvdM> vila: I did look a branchbuilder. I will take a look at test_log.
<GaryvdM> woot! qlog data represented as unicode text: http://pastebin.com/Eruy5wnC
<GaryvdM> And as ascii, for test results: http://pastebin.com/WSjGe2TJ
<jam> GaryvdM: interesting, though the dot doesn't seem quite right in the ascii case
<jam> or maybe it is, but it doesn't match the unicode version
<GaryvdM> jam: I fiddled with the data to cause a failure.
<GaryvdM> jam: In the ascii, you see 2. The second is correct
<jelmer> 'evening Gary, John
<GaryvdM> Hi jelmer
<jam> hi jelmer
<mgolisch> if i wanted to save the changes i did to my current branch as a new branch, how would i go about that?
<GaryvdM> mgolisch: If you have allready commited: push to new branch. uncommit & revert in old
<GaryvdM> mgolisch: If you have not yet committed: branch. then merge --uncommited
<GaryvdM> and revert in old branch
<mgolisch> oh i see
<mgolisch> that was what i was looking for
<mgolisch> thx
<GaryvdM> jam: How do you think about this: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/revision/1323
<GaryvdM> s/How/What/
<jam> GaryvdM: you mean what do I think about having a DummyBranch that just proxies the graph information? It looks like it does what you want it to do
<jam> I believe I've written similiar code myself
<GaryvdM> jam: So doing that in a test is ok.
<jam> though it also makes me wonder if it would be better to have a specific function on loggraphprovider.BranchInfo that didn't require going through self.branch.repository.get_graph()
<jam> such as... passing in the Graph object yourself
<GaryvdM> jam: Or a custom version of LogGraphProvider that you can just pass a graph.
<jam> GaryvdM: I don't know the qbzr internals all that well, but yeah, basically all you need for what you are doing is a Graph and a tip pointer
<GaryvdM> jam: Ok - Thanks
<jam> GaryvdM: though I guess you also are doing something with tags?
<jam> what about fixed bugs, etc
<GaryvdM> jam: fixed bugs come from the revisions, which get loaded lazyly
<maxb> jelmer: Is a bzr-svn LogWalker iter_changes supposed to traverse copy history?
<jelmer> maxb: yes
 * maxb is confused - I have an invocation with strict_node_history=False, yet I'm not seeing history traversed
 * maxb wonders if the Apache repository is just being *odd*
<GaryvdM> jam: Better solution: http://bazaar.launchpad.net/~garyvdm/qbzr/log_refactor/revision/1323
<exarkun> I get this error when I try to push this branch with loom info to a new location on launchpad
<exarkun> bzr: ERROR: The revision exarkun@twistedmatrix.com-20100830220539-v8ovhik3byonepog is not recorded in the loom LoomBranch7
<exarkun> What does that mean?
<exarkun> Well, I guessed that it means that I should run `bzr record ''` again, and that let the push succeed at least.
<exarkun> not a particularly comprehensible error message though
<exarkun> However, my threads are still destroyed by the process.
<exarkun> branching nosmart+bzr+ssh://bazaar.launchpad.net/~exarkun/+junk/modules-with-loom doesn't give me something very closely resembling the original branch
<mwhudson> exarkun: what version of bzr-loom do you have?
<exarkun> 2.1.0
<mwhudson> i have to admit i've never been able to predict what will happen when i push or pull looms
<maxb> Hmm, well it's definitely possible for it to work, since I took your previous branch, pushed it to a new non-loomed branch, loomified it, and pushed it to lp:~maxb/+junk/to-loom-or-not-to-loom, and it seems intact
<maxb> looms are woefully underdocumented. After trying for quite some time, I only finally understood them after turning to the source code
<maxb> After which, I finally went "ooh, what a clever idea"
<exarkun> When I branch lp:~maxb/+junk/to-loom-or-not-to-loom I get something without any threads
<maxb> hrm
<maxb> When I do, I get a loom with one thread called 'base'
<exarkun> Ah, but it works when I branch nosmart+bzr+ssh://bazaar.launchpad.net/~maxb/+junk/to-loom-or-not-to-loom
<exarkun> But the nosmart trick didn't help my modules-with-loom branch
<maxb> Why nosmart+, ooi?
<mwhudson> bzr show-loom sftp://bazaar.launchpad.net/~exarkun/+junk/modules-with-loom doesn't give any output
<maxb> exarkun: Well, I'm guessing the lack of any threads listed at http://bazaar.launchpad.net/~exarkun/+junk/modules-with-loom/.bzr/branch/last-loom indicates the loom never made it up to the server successfully
<exarkun> I heard a rumor that bzr+ssh doesn't support looms properly
<maxb> Well, I've both pushed and branched my to-loom-or-not-to-loom over bzr+ssh
<maxb> smart bzr+ssh, that is
<maxb> Are you on Ubuntu?
<exarkun> yes, 9.10
<mwhudson> whereas bzr show-loom sftp://bazaar.launchpad.net/~maxb/+junk/to-loom-or-not-to-loom does
<exarkun> with versions of everything from the bzr ppa
<maxb> exarkun: hmm, interesting. Let me downgrade my bzr-loom.....
<exarkun> maxb: downgrade?  so you've got something newer than 2.1.0?
<maxb> I generally run tip of trunk for most bzr plugins
<exarkun> hey so I just pushed again to nosmart+bzr+ssh: instead of lp: and I think that helped
<exarkun> yea, branching that, also with nosmart+bzr+ssh: gives me something with threads
<exarkun> mwhudson: is sftp: the same as nosmart+bzr+ssh:?
<maxb> ahaha
<maxb> Using 2.1 my loom comes back broken
<mwhudson> exarkun: for the purposes of this discussion, yes, i expect so
<exarkun> I was wondering if they indicated the same protocol
<mwhudson> the bytes on the wire will be different
<maxb> Hmm, so using 2.1, my push pushed a working loom, but I couldn't branch it back until I upgraded to trunk again
<mwhudson> with nosmart+bzr+ssh there's still a bzr serve process on the other end
<mwhudson> rather than something talking sftp
<exarkun> gotcha
<maxb> So it's sounding like we need a bzr-loom release
<lifeless> doit
<maxb> bug 201613 sounds likely
<ubot5> Launchpad bug 201613 in Loom "fetching looms does not work properly with bzr+ssh (dup-of: 193893)" [Critical,Fix released] https://launchpad.net/bugs/201613
<ubot5> Launchpad bug 193893 in Loom "branching over bzr+ssh does not propogate loom threads (affected: 2, heat: 16)" [Critical,Fix released] https://launchpad.net/bugs/193893
 * lifeless throws the reins in the air
<maxb> heh
<exarkun> thanks for the help
#bzr 2010-09-01
<mneptok> TODO: tonight when the moon is high in the sky, go and let loose a prolonged howl. think of igc.
<poolie> heh
<spiv> Morning.
<poolie> hi spiv
<maxb> poolie: Hi. Could I trouble you to add a new PPA under ~bzr called 'builddeps', to use as a container for common build-time-only dependencies for ~bzr/proposed, ~bzr/ppa, ~bzr-beta-ppa/ppa ? (Mainly debhelper for older distroseries)
<mwhudson> +1 mneptok
<poolie> sure
<poolie> can you add that to the ppa.txt doc?
<maxb> ah yes - will do
<spm> mneptok: +1 indeed
<maxb> hmm. we really need --stacked-on= to support lp: urls
<spiv> Hmm, I thought that there had been a patch towards that a while back...
<poolie> maxb, done
<maxb> thanks poolie
<spiv> spm: bzr's pqm seems to be stuck?
<poolie> spiv, yes, the job i sent up yesterday didn't seem to succeed or fail
<poolie> spiv, did you ping anyone?
<spiv> poolie: not apart from just then.
<poolie> spm: could you help us with pqm?
<mneptok> http://blogs.gnome.org/mneptok/2010/09/01/ian-clatworthy-howl-a-thon/
 * mneptok smiles upwardly
<fullermd> Well, it's not yet midnight.  I have strict rules about howling at the moon too early in the evening...   but I'll definitely put it on the docket for later.
<mneptok> \o/
<mneptok> AAAAAAAAAAAOOOOOOOOOOOOOOOOOOOOOO!
<spm> poolie: looking
<spm> poolie: spiv: https://pastebin.canonical.com/36543/ looks pretty stuck to me; shall I stab with a sharpened hammer, or did you want some debug first?
<spiv> spm: I suppose it'd be interesting to know where exactly 24617 is stuck, although hopefully sending SIGINT to that process would make it exit with a relevant traceback.
<spiv> spm: I'll be a lot more interested in debugging it if it recurs :)
<spm> heh, call it a one off and stab then?
<spiv> Hmm, there's been a bit of flux in the test infrastructure lately (ironically to try reduce these sorts of issues), so I guess it's moderately likely to recur.
<spiv> spm: how about just do a quick strace to see which syscall it's stuck in then kill it with SIGINT?
<spm> attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted <== sigh
<spiv> Oh, joy.  Possibly related to the strace subprocess left over from the test suite...
<spiv> Or at least, I presume it's a left over and not used by the test in question...
<spm> that would make sense. I'll try killing that first; see if that frees things up at all
<spm> haha. that just fired off another strace
<spm> fwiw, stracing the strace gives:
<spm>  strace -p 1816
<spm> Process 1816 attached - interrupt to quit
<spm> wait4(4294967295,
<spm> <urk>
<spm> oki, killed 24617; things *seem* to be moving again
<spiv> Wow, starting a new strace isn't what I would have guessed.
<spm> i tried it twice; same. so ... whee
<spm> and yup; things are definately moving again.
<spiv> Well, I guess that means it was probably stuck in the strace tests, rather than where the http://pqm.bazaar-vcs.org/ suggested it was stuck.  Hmm.
<lifeless> :<
<spiv> spm: thanks
<spm> spiv: I'm quietly confidant that bzr blame will show it's your fault; no matter who really did the change that caused it. fwiw. :-P
<maxb> lifeless: Hi. the debian/control Vcs-Bzr field of subunit points to a branch missing the last few uploads. Has it moved somewhere else?
<lifeless> i don't think so
<lifeless> what url are you seeing?
<maxb> http://bzr.debian.org/collab-maint/subunit/unstable/
<lifeless> if its bzr+ssh://bazaar.launchpad.net/~lifeless/debian/sid/subunit/sid I'm pushing against just in case
<maxb> ahh, so the collab-maint branch is a red herring
<maxb> Also, looks like you didn't 'bzr mark-uploaded' the last upload :-)
<magcius> Is there a decent way to show the changes brought by the current commit?
<GaryvdM> magcius: bzr diff -c -1
<magcius> next question: is there any way to set it up so that if it's on a tty it uses a pager?
<vila> hi all !
<vila> igc: good bye, AAAAAAAAAAAAAAAAAAOOOOOOOOOOOOOO ;-(
<lifeless> maxb: hmm, sorry.
<lifeless> maxb: I should probably do that
<spiv> Hmm, the test suite seems to have slowed down quite a bit for me recently.
<spiv> And as a bonus an https test seems to be tripping over http://bugs.python.org/issue9729
<vila> spiv: yup, you can safely ignore the failure in that case, it's transient. I encounter it from time to time on babune.
<spiv> Yeah, somehow my CPU cores now seem to be about 50% idle, so it's taking twice as long :(
<vila> spiv: your bug report is indeed pointing the problem, EBADF should be raised (and will be caught by the test suite)
<vila> spiv: I don't observer that *at all* if it helps
<vila> spiv: I don't observe that *at all* if it helps
<vila> spiv: is that for a full test run or a partial one ?
<spiv> Yeah, the interaction between SSLSocket and _socketobject is clearly broken for those methods in that case once you know what to look for.
<spiv> Full run.
<spiv> The utilisation is varying, actually.
<spiv> But there was definitely a point about midway through the run where it was literally 50-50, despite having one process per core.
<vila> hmm, see lp:~vila/bzr/626876-bzr-connect-to-bzr-ssh but it could only be relevant if you happened to run sftp tests at this precise point
<spiv> And concretely it used to take just under 10 minutes to run the full no-plugins suite, now it's taking just over 20!
<vila> spiv: I meant, see the patch itself, we actually slow down sftp tests to cope with paramiko
<vila> spiv: doesn't match my experience nor babune ones
<vila> spiv: I'm still waiting a bit for more data to analyze but I even expect the leak fixes to *improve* the performances (if only because there are far less dangling threads and sockets for python to care about)
<spiv> Well, 3000 tests sleeping for 0.2 seconds would equal 10 minutes.
<vila> spiv: I'd be glad to proven wrong though :)
<vila> spiv: well, one more reason to consider bug #626876 critical then :-D
<ubot5> Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876
<spiv> vila: I'll trying commenting out that time.sleep and see what happens
 * bialix waves hello
<vila> spiv: excellent !
<vila> bialix: _0/
<spiv> vila: is that time.sleep there really there to make just one test pass?  10 minutes is huge cost to pay for that!
<vila> spiv: yes.
<spiv> (And 25 minutes if you're going to increase it from 0.2 to 0.5!)
<vila> spiv: yes
<spiv> Ok, so please please please find a way to apply that hack for just the duration of that one test if it has to stay.
<vila> spiv: jam even said that it needed to set it to 5.0s to make it pass on a heavily loaded windows machine
<spiv> Well, basically time.sleep is never the right thing to do in an automated test suite.
<vila> spiv: I strongly prefer to get rid of it by rewriting that test as I complained about for months :-P Care to help ?
<spiv> Because there's never a value where it will reliably cause the test to pass.
<vila> spiv: agreed, hence the FIXMEsssss
<GaryvdM> Hi bialix
<bialix> Hi Gary
<spiv> vila: incidentally, no ssl-related member_descriptor error on this run so far, but a EBADF traceback has leaking onto my stderr
<vila> spiv: speaking of timeouts, paramiko use a 0.1s timeout for every ssh socket (and an associated thread)
<spiv> s/leaking/leaked/
<spiv> Oh, no, spoke too soon, there's the ssl bug again :)
<spiv> vila: well, in my ideal universe, Twisted's SSH implementation would be more suitable for us which would avoid that sort of mess ;)
<vila> spiv: I expect a *few* and shallow fallouts from the leak fixes and babune confirms that so far
<spiv> Ah, the EBADF is from a paramiko thread in fact.
<vila> :-D
<vila> which test ?
<spiv> vila: don't know, it's a traceback from a thread
<spiv> 'Thread-630' :P
<vila> spiv: but still... 20 minutes ? How many concurrent runs ?
<vila> ha, this one :)
<spiv> But this run is so far looking to take roughly 20 min too :(
<poolie> hello maxb, vila
<spiv> --parallel=fork on a 4 core laptop.
<vila> spiv: so, regarding paramiko threads, one idea is to monkey patch the thread creation to inject ThreadWithException, but I haven't looked at the details yet
<vila> spiv: so concurrency == 8 or 4 ?
<spiv> == 4
<vila> hmm, weird, you do use tmpfs for /tmp right ?
<spiv> I don't.  (Although I've been meaning to play with that at some stage)
<vila> spiv: just try
<vila> spiv: most important optimization for selftest, ever
<spiv> vila: Well, I'd really like to fix selftest to not hit the filesystem so much in the first place :)
<vila> spiv: sure, but I'm not holding my breath on that and using tmpfs in the mean time doesn't hurt and will even help getting there sooner :D
<vila> spiv: I don't hold my breath but I keep thinking about it though...
<vila> poolie: hey :) ;) :-| ;-/ AAAAAOOOO
<poolie> i know :(
<vila> ok, with that last patch for gentoo, babune is back in blue except for the usual suspects and even that 's' may disappear soon (windows, I'm looking at you)
<vila> Ran 24311 tests in 4727.204s
<vila> FAILED (failures=1, errors=4)
<vila> Recording test results
<vila> ERROR: Failed to archive test reports
<vila> mgz: we're getting there... finally
<vila> spiv: still running without sleep ?
<vila> oh my, how will that be interpreted....
<bialix_> GaryvdM: can you look at https://answers.launchpad.net/qbzr/+question/121019 please
 * GaryvdM looks
<bialix> GaryvdM: I'm not sure how we're interacting with extmerge
<vila> bialix: http://paste.ubuntu.com/486635/  \o/
<bialix> vila: cool
<bialix> sorry, today I'm not able to enjoy
<vila> bialix: and that's the real stuff running from bzr.dev
<vila> bialix: I know :-(
<bialix> aaaoooooowww!
<GaryvdM> vila: That is great.
<vila> GaryvdM: so, regarding your qlog tests, you may simplify the expected data to make your tests more readable by using helpers like assertLogRevnos or assertLogRevnosAndDepths in bb.test_log
<spiv> vila: oh wow
<vila> GaryvdM: the idea is that you don't always need to check all the details and using revids matching the revnos also simplify reading (come to think about it, I should even use raw ints and stringify them in the helper themselves)
<spiv> vila: so it's because when I don't have my battery in my laptop the CPU is throttled to half speed!
<vila> spiv: LOL, thanks for that laugh :)
<spiv> vila: note that I'm on AC power either way
 * spiv boggles
<vila> spiv: what a trap :)
<vila> laptop want a battery, laptop want a battery !
<GaryvdM> vila: I was quite busy last night, and wrote a assertComputedLines method. If the assertion fails, it shows the rendered graph as an ascii art.
<fullermd> If you put two batteries in it, does it go to double speed?
<vila> GaryvdM: I read something about that in the IRC logs but I haven't realized it was generated, great !
<GaryvdM> vila: and I wrote a whole bunch of tests for existing bugs
<vila> 4 ! 8 ! Give it more batteries ! Tell Intel we've solved their problem with Moore's law !
<vila> GaryvdM: Excellent ! Isn't it nice ?
<spiv> Hmm.  /sys/devices/system/cpu/cpu*/cpufreq/bios_limit drops when I remove the battery.
<vila> GaryvdM: meh, stringify won't work for dotted revnos, I'm an idiot :)
<GaryvdM> vila: http://pastebin.com/YdsrMyEw
<vila> GaryvdM: wow, amazing !
<spiv> Perhaps it's http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling
 * vila checks that virtual machines have a soldered battery....
<vila> GaryvdM: So concretely, you may want to reduce ('rev-f', 3, None, [(0, 0, 0, True), (3, 1, 0, True), (3, 3, 3, True)])  to ('3', '3.1.0', '3.3.3') when applicable and use the full version only when needed
<vila> GaryvdM: or something
<GaryvdM> vila: If I could output unicode, I could make the graphs more readable, like this: http://pastebin.com/ZW7i4nZF
<vila> GaryvdM: but still, wow, I will certainly look at that the next time I play with ancestry graphs
<vila> WOW
<vila> GaryvdM: wow wow wow, you need to make this available outside of tests  !
<GaryvdM> vila: like a ncurses version of qlog?
<vila> GaryvdM: no, as a generic utility to visualize graphs
<vila> so we can use that when discussing, here, in mails, anywhere
<vila> hmm, I suspect it uses quite a lot of qlog code though... may be tricky to extract... but that will certainly make the qlog internal design clearer
<vila> GaryvdM: anyway, you may have better things to do right now but it may be worth considering as a long term goal...
<poolie> i'm going to update and re-fire the strace things
<poolie> hopefully not causing another hang
<poolie> hm, i can imagine why that's hangign
<poolie> but this is a kind of unprofitable mole to whack
<GaryvdM> Very interesting website igc had linked on his site: http://headrush.typepad.com/
<GaryvdM> Aaaoooooowww
<poolie> it is, though it came to an ugly end a few years ago
<poolie> vila, i'm going to re
<poolie> re-send the strace thing, with the tests disabled
<poolie> which should not make pqm hang
<poolie> but if it does, please just as a SA to kill it
<vila> poolie: ok, I'll keep an eye on it
<Odd_Bloke> Hello all.  I want to push a branch to Launchpad that is stacked on another branch on Launchpad.  I'm hitting some problems, however, as detailed at http://paste.pocoo.org/show/257054/.
<vila> Odd_Bloke: 1) I'm not sure you can do that on lp itself... 2) You got 2 different error messages for the same command ?
<spiv> Odd_Bloke: hmm, that's odd.  Try removing/renaming the branch through the web UI, and then try using the expanded bzr+ssh: URL with --stacked-on
<spiv> vila: the first command created a bzrdir with a repo
<vila> ha!
<spiv> Odd_Bloke: although
<spiv> Odd_Bloke: why specify the stacked-on branch manually?
<spiv> Odd_Bloke: LP should have that set up for you by default
<spiv> Also, that first error is weird!
<Odd_Bloke> spiv: Ignorance. :)
<Odd_Bloke> So just 'bzr push lp:~username/projectname/branchname' should do stacking automagically?
<lifeless> yes
<Odd_Bloke> Ooh, shiny.
<spiv> Odd_Bloke: well, assuming you have set a development focus for the project in Launchpad
<spiv> Odd_Bloke: which I was assuming you had because you were trying lp:openerp-addons in your command, but actually I don't see that any such branch exists...
<vila> spiv: gee, I so mis-read the paste :-/ Anyway, does lp support stacking on a branch other than dev focus ?
<spiv> Which may be related to the original failure
<spiv> vila: yes (but may require some amount of prodding, I don't recall)
<vila> kthks
<vila> Right, poolie's strace patch landed
<vila> (jelmer) Add ControlDirFormat.supports_workingtrees cvar. (Jelmer Vernooij) is currently failing on pqm, let me know if you get the failure email from pqm
<jelmer> vila: Will do, thanks.
<vila> jelmer: I just had a look at revno 3464 in bzr-svn trunk, inheriting from LockableConfig is not enoug, you need a needs_write_lock decorator on set_user_option. Otherwise the way you ensure compatibility with older bzr releases is nicely short.
<vila> jelmer: something like http://paste.ubuntu.com/486734/ should be enoug (not tested)
<vila> urgh no, you need more :-/
<mgz> vila: http://babune.ladeuil.net:24842/job/selftest-windows/149/console <- looks good
<mgz> I see bug 625574 and bug 273978 and bug 581311 and use of osutils.safe_unicode which should be called osutils.break_randomly
<ubot5> Launchpad bug 625574 in Bazaar "testtools details should not be shared between parameterised tests (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/625574
<ubot5> Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii (affected: 1, heat: 4)" [Low,Confirmed] https://launchpad.net/bugs/273978
<ubot5> Launchpad bug 581311 in Bazaar "bt.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset fails on windows (affected: 1, heat: 2)" [Medium,Confirmed] https://launchpad.net/bugs/581311
<vila> mgz: yeah :)
<mgz> I've got the first one, which will mean we get the pretty result display when you install a fixed pyjunitxml
<vila> mgz: err, I meant for the windows run, for safe_unicode, I'm a bit surprised
<mgz> The second I'm going to get back to now I've fixed testtools so can actually test it without breaking the infrastructure
<vila> pyjunitxml, I had *that* installed ? Where ? 8-/
<mgz> safe_unicode tries decoding as utf-8, which means you can pass it arbitrary byte strings and it'll appear to work on nix nearly all the time
<mgz> but actually the code could be totally bogus.
<vila> mgz: well, we should get rid of safe_unicode and safe_utf8 completely. AIUI, they help because we are not fully clear about which API expect one or the other
<mgz> right.
<mgz> they're little plasters over api mistakes.
<mgz> all in all though, looks in  pretty good shape, babune's closer to green than I am :)
<vila> blue blue ! Because he is frustrated to not be able to report failures, it turns red when it laugh at us :-D
<vila> but I don't seem to have python-junitxml installed...
<mgz> you must have something, I see in the log your pipeline is:
<mgz> Python 2.7.0+
<mgz> + ./bzr selftest -x TestBreakin --subunit
<mgz> + subunit2junitxml -o tests.xml -f
<mgz> + subunit2pyunit
<mgz> it's the subunit2junitxml that's failing because of bad unicode/xml handling, and that code is in pyjunitxml
<vila> hmm, then I think it may be part of udson which is written in java, no python involved there
<mgz> but but but!
<mgz> http://bazaar.launchpad.net/~lifeless/pyjunitxml/trunk/revision/16
<vila> meh, subunit2junitxml may be failing then, but it's part of subunit
<vila> 8-)
<mgz> the last revision on the branch is an encoding change to fix a problem you reported!
<mgz> so... you must have it :)
 * vila asks his clones
<vila> oh ! right, got that on babune master, running from sources... wth
<vila> oh ! and also on slaves, running from sources too, geee
<mgz> okay, so I'll give you a new branch to try later, should give us nice results for maverick and xp
<vila> Pfew, up-to-date with trunk so far. Pfew
<vila> mgz: yummy :)
<mgz> first... lunch!
<vila> mgz: enjoy !
<jelmer> re
<jelmer> vila: Yep, I did get the email.
<jelmer> vila: The testsuite was passing with current bzr-svn
<vila> jelmer: yeah, current should be fine since there is no tests for "foreign" config files (they would be hard to define anyway), but that also means that the bzr-svn test suite didn't trigger the _write_config_file assertion about being locked (of course since you don't use it...)
<vila> jelmer: anyway, it means that your are not *yet* using a lock to protect your config file against concurrent write accesses
<jelmer> ahh, ok
<vila> jelmer: just a heads-up :)
<jelmer> vila: Thanks
<jelmer> I'll have a look tonight.
<vila> jelmer: I'm still interested by your feedback on the transition, I see you use _get_filename.... hehe, you redefine it :)
<vila> jelmer: anyway, if you think we should change something in bzr.dev to ease this transition, let me know
<jam> GaryvdM: I should note your graphs don't line up correctly in unicode for me in Firefox
<jam> and they don't format at all in VIM
<jam> vila: ping about the connection code
<jam> I just noticed this line in the old "SocketListener" code that you removed:
<jam> -            readable, writable_unused, exception_unused = \
<jam> -                select.select([self._socket], [], [], 0.1)
<jam> also, I noticed that 'self.serving' is just a boolean in TestingTCPServerMixin, and I've found that to get reliable start/stop you really need an event
<jam> vila: I tried changing 'serving' from being a boolean to being an Event, and once I do that, it fails regardless of the amount of time.sleep I have
<jam> I have the feeling that we *are* actually calling 'serving = False' at some point, but because the threads aren't always synchronized we don't see it sometimes
<jam> so the test accidentally passes
<jam> IOW, I think we are somehow asking the service to shut down early, but it just didn't know yet
<jam> ah wait, I have at least 1 boolean inverted, let me fix that first
<vila> jam: hmm, I seem to remember using an Event for self.serving before realizing it was useless, so I revert to a boolean, let me check
<jam> vila: I also see "TestingTCPServerMixin.server_bind" where it calls bind() but doesn't call .listen(1). Do you know where 'listen(1)' is occurring?
<vila> jam: yup, that was revno 5247.5.31
<vila> jam: probably SocketServer.py
<jam> vila: you're right, there is a server_activate() function
<vila> jam: yup, in the implementation of server_activate
<vila> which is called by default at init time
<jam> though why do you override server_bind only to get rid of the 'setsockopt' option?
<jam> same for 'get_request', etc
<vila> jam: for compatibility with previous python versions IIRC
<vila> SO_RESUSEADDR is useless in our case and IIRC have different semantics between unix and windows
<jam> vila: I know there is a comment to that effect in places, at least
<jam> vila: so one interesting change. The default "listen(*)" amount is actually 5, and not 1
<vila> and ?
<jam> vila: just an interesting difference
<zyga> bzr lp-propose-merge suddenly stopped working for me: http://pastebin.ubuntu.com/486840/
<zyga> I'm not sure what is missing but should it not be a dependency handled by dpkg/apt?
<vila> zyga: try 'bzr -Derror lp-propose-merge' that should give a traceback
<zyga> vila, http://pastebin.ubuntu.com/486842/
<vila> zyga: that's from lazr imported from launchpadlib.... a bit surprising but I don't know launchpadlib enough to tell you more
<zyga> vila, it's quite surprising as it was working just a few days ago
<zyga> (apart form all the updates I got in between)
<vila> zyga: indeed
 * zyga needs to reboot after kernel update
<vila> hmm, if python libs needs a reboot now...
<jam> vila: I think I've found the race event in the paramiko code
<jam> if you're interested
<vila> jam: you can bet I am ! (But I've EODed so expect some lag :-)
<jam> vila: Transport._parse_newkeys sets: completion_event.set()
<jam> which makes the outer loop say "oh he must be done, lets exit"
<vila> jam: so the fix is just to remove that set() ?
<jam> not sure yet :)
<jam> still digging
<jam> as to why it succeeds sometimes
<vila> ...or move it elsewhere/later
<vila> I've made some progress rewriting the test but I'm not done yet, it will be very simple.... a handful of lines... but each word counts there :-/
<jam> vila: current thoughts
<jam> The completion event gets set *multiple* times
<jam> the first time it is set, is after the key exchange
<jam> after that, it gets set when messages are done processing
<jam> we only wait for the first one, but used to leave the thread running
<jam> so now we are killing the thread once it is "ready"
<jam> and the race is such that if we can complete before the kill comes through
<jam> then we succeed
<vila> what thread are you talking about ?
<jam> vila: paramiko.Transport()
<jam> is its own thread
<jam> with its own 'completion_event'
<jam> if I wait(), then clear(), then wait() again, the test passes
<vila> err, without any other change ? Where are you waiting ?
<jam> I'll put up a diff to make sure
<jam> vila: where you used to call' time.sleep()'
<vila> hmmm, very promising
<jam> vila: http://paste.ubuntu.com/486894/
<jam> or: lp:///~jameinel/bzr/2.3-bzr-connect-ssh
<jam> vila: what I was noticing was that while "completion_event" was set, it *also* has "self.active" still True
<jam> note that at this point, I probably have hacked-up paramiko as well, so I'm working to make sure everything is clean
<vila> what is self.active ? another paramiko attribute ?
<jam> vila: paramiko.Transport().active
<vila> k
<jam> vila: at the end of "start_server" it returns completion_event.isSet() == True, and active == True
<vila> hmm
<jam> vila: looking at the start_server docstring
<vila> jam: doing that right now
<jam> it says "this method will not return until negotation (sic) is done"
<vila> active should be checked
<jam> it doesn't say when all conversation is doen
<jam> just that it has finished negotiation
<vila> what if you just set completion_event to None ?
<jam> vila: we still want to loop on it to know when the channel gets shut down (IMO)
<jam> we can't set it to None for start_server because it creates one if you pass None
<jam> and it waits until the negotiation has finished
<jam> we then need to wait until the conversation has actually completed at some point
<jam> we may as well clear() and wait on completion_event
<jam> though there is a potential race condition then
<vila> you said you had to clear it, who is setting it again ?
<jam> vila: Transport.run() sets it at the end 'if self.active: self.active = False; self.completion_event.set()"
<vila> My suspicion is that several events are needed and paramiko seems to just use completion_event if it's set
<jam> vila: I would guess that you are correct. There is the race that the rekey finishes and then the next action also finishes before we notice
<jam> we can pass in our own completion event, though, rather than using the paramiko loop
<vila> this... sounds promising (did I say that already or what :)
<jam> vila: so I think a race still exists in the new code, but it is much better than just 'time.sleep()'
<vila> I think you're on the right track, check that the other sftp tests are still passing though
<vila> jam: and as soon as you have a testable branch, let me know, I'll try to run it on babune (if you have a subset of tests that would help too)
<vila> jam: I'm off to dinner, gf yelling :)
<vila> <jam> vila: so I think a race still exists in the new code, but it is much better than just 'time.sleep()'
<vila> yup that was my gut feeling when I wrote the comment above the sleep, but I hadn't time to dig into paramiko code
<vila> jam: just I thought: there is one thread for the server and one for each connection. If I'm not mistaken, sftp is the only case where my changes may have allow both of them to run concurrently (explaining the bug). Why they use the *same* event (as you seem to demonstrate) is yet to be understood, otherwise using two events (as you seem to hint) should address the problem
<jam> vila: well, there is 1 more thread as well. TestServerInAThread spawns a thread per request, which calls the Handler, which then spawns a paramiko.Transport thread to actually handle the request
<jam> vila: and I'm having good results with 2 events
<jam> though AFAICT, only the connect_bzr_ssh code actually runs the gives "SFTP" handler
<jam> not sure why that is yet
<jam> at least, running "bzr selftest "(?i)sftp" ran all the tests even though I had tyos
<jam> typos
<vila> jam: yes, but I was ignoring the paramiko thread here
<vila> jam: request == connection in this context
<chx> hi. i made a merge. it warned about criss-cross. then it gave me 18 conflicts, all of the are adding files. the files being added are the very same as the files exisitng. yet bzr did not check this just created the conflicts.
<tedg> Howdy, where does one file bugs for bzr-launchpad?  It seems they don't use Launchpad for bugs.
<tedg> Which is richly ironic.
<rubbs> https://launchpad.net/launchpad
<rubbs> specifically https://bugs.launchpad.net/launchpad
<rubbs> tedg: ^ sorry forgot to ping you with the answer ;)
<tedg> rubbs, Okay, thanks.
<vila> rubbs: nope, tedgis talking about bzr-launchpad with indeed didn't activate the bug tracking. jml, that's indeed pretty ironic :-P
<rubbs> np
<rubbs> oh, sorry I missread
<rubbs> tedg: my bad.
<vila> tedg: I'm sure jml will see to that quickly
<tedg> rubbs, Ah, okay.  I figured jml would see it there as well :)
<tedg> vila, He's probably boycotting their bugs.  Switching to bugzilla or something.
<tedg> ;)
<vila> tedg: yup, I think we've discovered yet another hint about his evil plans... not sure which though
<vila> tedg: meh, there is no code either.... what do you refer as bzr-launchpad ?? :-)
<vila> tedg: there is a launchpad plugin in the core bzr plugins, if that's the one, you can file the bug against bzr itself
<vila> tedg: but nobody calls it bzr-launchpad, it's just the launchpad plugin for bzr
<tedg> vila, Ah, that's what I was thinking, bzr help lp-propose-merge says that it's in the launchpad plugin.
<vila> I think bzr-launchpad may be the next generation, jml talked about it, but he hasn't released anything yet apparently
<tedg> Ah, okay.  I'm already ahead of the game ;)
<vila> tedg: then, yes, that's from the launchpad plugin (as mentioned in the help) and you can wee were it's installed on your system with 'bzr plugins -v'
<vila> tedg: its path should end with bzrlib/plugins/launchpad
<tedg> vila, Yeah, but wouldn't all packaged plugins be there?
<vila> have a look
<tedg> Yeah, and things like bzr-search turns into bzrlib/plugins/search.
<vila> if you use external plugins, the path should be different
<vila> can you !paste the output ?
<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.
<tedg> vila, http://pastebin.com/gGZtdgsR
<tedg> vila, Those aren't all core, but they're all packaged.
<vila> wow, all in the same place ! Hmm, I didn't know about that
<vila> Hmm, in that case I don't know how to differentiate the core ones from the others using the command line only...(python one-liners doesn't count ;)
<tedg> vila, Isn't that kinda the point of a good plugin system ;)
<vila> well, it means there could be a name collision... Dunno how this is handled
<tedg> vila, In Ubuntu that's handled through the packaging, but typically those get distro patched so they don't conflict.
<tedg> vila, If you use something unpackaged, well, you're insane :)
<vila> right, that indeed guarantee that the packagers will warn us if we create a plugin with a name which is already used. But it also means we need to be vocal when a new release introduces a plugin.
<vila> Which is already the case anyway.
<lifeless> vila: this is how plugins are designed to work
<lifeless> cooexist as regular submodules of bzr
<vila> lifeless: yes
<vila> lifeless: But if jml defines a bzr-launchpad plugin that overrides the core one, this must be somehow handled by the packaging (the core one should never replace the external one).
<chx> (this is a re-question but noone seemed to be active when i asked ~2 hours ago) i made a merge. it warned about criss-cross. then it gave me 18 conflicts, all of the are adding files. the files being added are the very same as the files exisitng. yet bzr did not check this just created the conflicts.
<vila> lifeless: and this still defeats making a difference between BZR_PLUGIN_PATH=user:site and BZR_PLUGIN_PATH=user:site:core
<lifeless> vila: I had no idea about such a proposal, it seems pointless to me
<lifeless> vila: there isn't IMO a 'core' plugin definition, doesn't exist.
<lifeless> vila: sure there is 'we ship it' but thats the extent of the separation IMO
<vila> lifeless: that's not a proposal, that's how it works today and without it you can't run from source
<lifeless> vila: oh, well it seems strange to me
<vila> lifeless: it makes no difference as long as there is no name collision
<lifeless> vila: FWIW I run from source all th etime and have never set BZR_PLUGIN_PATH
<vila> lifeless: :-P
<vila> lifeless: that's because you don't always run the full test suite :-D
<lifeless> anyhoo
<lifeless> back to lp code; getting performance under control :)
<FryGuy-> is there an easy way to get the list of files modified from revision X to Y?
<lifeless> st -r x..y
<FryGuy-> :D thanks
<poolie> FryGuy-: bzr st -r X..Y
<FryGuy-> i didn't even think about status
<FryGuy-> even though that's the format I wanted it in
<FryGuy-> that's in the range (X, Y], right?
<FryGuy-> i get confused if it's inclusive or not.. i'll just double check myself
<lifeless> half open
<FryGuy-> thanks again
#bzr 2010-09-02
<spiv> Good morning.
<billy> hi folks - i'd like to use bzr for delphi projects but some files are binary - is bzr limited to text only data?
<spiv> No, you can commit binary files too.
<maxb> Not at all, other than the obvious problem that you can't merge binary files
<maxb> But that's a problem with binary file formats, not a problem with bzr :-)
<billy> thanks folks
<poolie> hi there spiv, maxb
<maxb> Hi poolie. I have a question about hydrazine. Shall I do a merge proposal to add lp-promote-ppa, or shall I just push it straight to trunk?
<poolie> if you do an mp i'll read it
<poolie> then you can merge it yourself
<poolie> if i ever stall for too long please nag or circumvent me
 * maxb wonders why bzr lp-propose complains of "bzr: ERROR: No reviewer specified
<lifeless> bug thingy
<poolie> somebody just duped it
<lifeless> <-
<poolie> maxb oh i just saw your mp
<poolie> apparently the homepage feeds are failing to revalidate because the datacentre cache isn't revalidating them
<billy> maxb: i don't follow your remark about obviously not being able to merge binary data - doesn't bzr generate a diff file - how is that handled?
<spiv> billy: internally bzr has a database that can store binary deltas
<spiv> billy: for sharing changes with other people you usually just tell them to access your branch directly, but bzr can also generate a "merge directive" that looks somewhat like a diff but copes with changes to binary files (and preserves all the bzr metadata).
<ReachingFarr> OK, so I'm in the process of setting up my bzr server.  I currently have it running with the --directory option set to /data/bzr.  First question: should I do a bzr init-repo on /data/bzr?
<billy> spiv: that's good - i assume maxb meant merging of branches which i don't need - i'm just tracking changes inn private development
<spiv> billy: right
<spiv> ReachingFarr: generally you make a repo for every project you are versioning.
<ReachingFarr> spiv: OK.  Makes sense.  Next question: There is an option to specify the protocol when using 'bzr serve' but I don't see any list of options.  Are there any?
<billy> another question - quite different - a project on sourceforge uses subversion - can i checkout the repository to my system using bzr?
<billy> i don't really need every vcs on the planet installed - one is enough
<lifeless> yes, install bzr-svn
<billy> lifeless: is that a separate package or a plugin?
<lifeless> yes
<poolie> lifeless: quick squid qn
<billy> thanks folks
<poolie> the dc squid was always caching feedparser requests
<poolie> which is reasonable given the heuristics
<lifeless> its also for security
<lifeless> known-bug-contact-point
<poolie> if i change the client to send an i-m-s and/or etag, will it revalidate?
<poolie> you mean having a squid at all is a security measure? yes, that's fine
<lifeless> to force revalidation?
<poolie> i realize the answer depends on the particular setup
<lifeless> or to permit revalidation ?
<poolie> at the moment the client sends no cache control headers and it does not revalidate
<poolie> if i set pragma: no-cache it respects that
<poolie> what i want to know is if i send i-m-s will it probably revalidate?
<lifeless> squid will be revalidating internally based on the age heuristic from the upstream
<poolie> does i-m-s affect that?
<lifeless> a few things do
<lifeless> I'm just listing them
<ReachingFarr> Also, how do people tend to secure their bzr servers? I'd really like to use the smart server AND have write access.
<lifeless> patience ;)
<lifeless> ReachingFarr: most folk use bzr+ssh
<lifeless> poolie: so, a plain GET requires the objet to be fresh, or squid revlaiadates; IMS IIRC will be exactly the same, but squid can tell you Not-modified if it isn't changed.
<lifeless> poolie: if you're trying to trigger revalidation, you should use
<lifeless> max-age
<lifeless> or similar
<poolie> or must-revalidate?
<lifeless> right
<lifeless> do you have the response headers?
<spiv> ReachingFarr: the only options for protocol at the moment are 'bzr' (the default) and 'svn' (if you have the bzr-svn plugin installed), which is still somewhat experimental I think.
<lifeless> from a request where squid did not revalidate ?
<spiv> ReachingFarr: often people don't need 'bzr serve' at all
<lifeless> poolie: and, what are the symptoms/problem you're fixing
<spiv> ReachingFarr: if you have bzr and ssh installed on the server then bzr+ssh is usually the simplest and best solution.
<spiv> ReachingFarr: so the URLs would look like bzr+ssh://server/data/bzr/...
<poolie> lifeless: the symptom is that new feed entries don't show up
<lifeless> poolie: at all, or for <time period> ?
<poolie> for over a day
<lifeless> ok
<poolie> the prior change to the feed was in july
<poolie> and the returned headers give that as the l-m
<lifeless> a response header from squid when it should have updated but hasn't can be very useful
<lifeless> squid will include in there the original l-m, and *its* status about age and freshness
<poolie> so it's kinda reasonable for it to think it's a slowly-changing resource, but i do want max-age like behaviour
<lifeless> poolie: I'd set max-age
<poolie> X-nc: HIT ord 20
<poolie> Age: 233704
<poolie> Content-Length: 40088
<poolie> X-Cache: HIT from druzhnaya.canonical.com
<poolie> X-Cache-Lookup: HIT from druzhnaya.canonical.com:3128
<ReachingFarr> spiv: Is there no way to set a base directory for use with bzr+ssh?  I know it's not much, but I'd like to not have to type /data/bzr
<lifeless> whee that is old
<poolie> ok
<poolie> so feedparser doesn't directly expose a way to set that, or to give arbitrary headers
<poolie> but i'm sure there is a way
<poolie> that's why i was wondering if something else might get the same behaviour
<poolie> but it'd actually be a bit of a kludge, and cache control is better
<lifeless> pretty sure neither ims nor etag wil
<lifeless> becuase they are all about getting NM back to the client, rather than triggering/avoiding squid doing work
<spiv> ReachingFarr: if you use a separate SSH key (and user, if you like) for accessing the server's bzr repo, then you can arrange that via the authorized_keys file and a script from bzr's contrib directory: http://doc.bazaar.canonical.com/bzr.2.2/en/admin-guide/security.html#access-control
<spiv> ReachingFarr: although bzr will tend to remember locations for you, so you don't necessarily need the full URL very often
<lifeless> or chroot the ssh server
<ReachingFarr> spiv: Ya, I was thinking of all of the times I would have to type in the full path... and it turns out it isn't that often.  I have now been convinced to use bzr+ssh instead of messing with this server stuff.
<lifeless> run it on a different ip / port
<spiv> ReachingFarr: another option is to make a simple client-side plugin to provide a shortcut like "foo:...", e.g. like how bzr comes with the Launchpad plugin which (among other things) provides the "lp:" shortcuts
<lifeless> spiv: I think a very useful thing we could do is /etc/bazaar/bazaar.conf
<lifeless> spiv: it would let us have a place to configure stuff like this
<spiv> lifeless: yes, that would be nice I think
<spiv> Or possibly /etc/bazaar/serve.conf?
<lifeless> spiv: or both
<spiv> Right.
<lifeless> spiv: /etc/bazaar/bazaar.conf as an underlay for ~/.bazaar/bazaar.conf would be a nice small self contained patch
<lifeless> with benefits immediately
<lifeless> ditto ignores
<spiv> lifeless: yeah, that's what I was thinking
<lifeless> server stuff could be a [server] section
<spiv> Well, without necessarily assuming it would be a small self-contained patch ;)
<lifeless> or a separate file
<spiv> But you're probably right.
<poolie> wbn; i filed a bug for this
<poolie> sigh, apparently only a monkey can do it
<lifeless> poolie: ?
<poolie> apparently the only way to get extra headers in is to monkeypatch it
<poolie> "it" being feedparser, or urllib2
<poolie> oh i guess i could get the rss myself and pass that in
<poolie> that would be a bit cleanecr
<lifeless> presumably it would be a nice feedparser feature to do this for other folk
<poolie> it would be nice, but then i'd need it packaged and deployed to run on escudero
<poolie> i guess we could run it from a branch
<lifeless> poolie: I can't see a bug for /etc/bazaar/bazaar.conf
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/348640 is related but not it
<ubot5> Launchpad bug 348640 in Bazaar "Want a variable to override location of ~/.bazaar etc (affected: 0, heat: 0)" [Low,Confirmed]
<poolie> bug 419854
<ubot5> Launchpad bug 419854 in Bazaar "should have a system-wide configuration file (affected: 1, heat: 5)" [Medium,Confirmed] https://launchpad.net/bugs/419854
<poolie> i think you're right though
<poolie> it's possible to patch it in, but it's a bit gross
<poolie> i can't believe other people don't want it too
<lifeless> poolie: specifically, technically, you want s-max-age, I don't know if thats supported by the squid you're connecting through
<poolie> s-maxage
<poolie> what do i want about that that max-age won't do?
<lifeless> just correctness
<lifeless> pedanticness
<poolie> feedparser boasting "4000 unit tests" is less impressive if 32 fail in a checkout of tip :)
<lifeless> _lol_
<poolie> though tbf most may be just lack of isolation, like they assume (but don't document) they're run in utc
<poolie> hi spiv, what are you up to?
<spiv> poolie: I had an idea about deleting some cruft from TestCase, which appears to work although without noticeably speeding tests up.  Just submitting that now.
<spiv> poolie: and managed to figure out why the python-profiler package's postinst was failing on my system
<poolie> that sounds good
<poolie> oh, why?
<spiv> I have a /usr/local/bin/python2.7
<spiv> So the postinst assumes that because there's a python2.7 on the path that /usr/lib/python2.7/py_compile.py must exist.
<lifeless> har har har
<poolie> but it was an orphaned binary?
<poolie> deleting cruft is always good for its own right i suppose
<poolie> i'd like to look at removing some more of the weird testcase subclasses in favor of asking for the resources the test actually needs
<poolie> through fixtures or something similar
<spiv> Well, I have local installation of python2.7 from the upstream SVN (via bzr) branch, for testing and hacking purposes.
<spiv> At the time I started doing that python2.7 wasn't packaged, I think.
<spiv> I could install it into my home directory I suppose, but GNU stow has served me well until now...
<spiv> +1 on removing clumsy TestCase hierarchies in favour of something like fixtures.
<lifeless> lp:python-fixtures. have at it.
<poolie> ok
<poolie> i'm trying to write a test for the feedparser patch
<spiv> Ok, submitted.  I'm going to have a quick stab at https://bugs.edge.launchpad.net/bzr/+bug/619872 because I think it should be easy to do.
<ubot5> Launchpad bug 619872 in Bazaar "bzr: ERROR: exceptions.ValueError: tag/value separator not found in line '' reading lockdir info file (affected: 1, heat: 6)" [Medium,Confirmed]
<poolie> that would be nice
<poolie> if you can work out what case makes it fail
<thumper> should this work? bzr cat lp:bzr/trunk/bzrlib/tests/test_log.py
<poolie> i'd really like to progress the locking thing this week
<poolie> thumper: ought to; i think there's a bug and you need to give -d
 * poolie wonders if bicyclerepair works in mavericj
<spiv> Well in general we shouldn't traceback just because the lock file has malformed rio
<poolie> spiv true
<poolie> oh wow
<poolie> it registers the tests to run by setattr-ing them onto unittest.TestCase
<poolie> that's creative
<poolie> sorry, no, onto it's own testcase, that's not so bad
<poolie> done
<poolie> spiv, re the logs, i think i made it a file so that we could more easily redirect external processes into it
<vila> hi all !
<AfC> How do you do `bzr status` in a specific directory without it recursing down?
<AfC> $ bzr status .
<AfC> isn't it.
<spiv> poolie: I thought so, but AFAICT we aren't using that... external processes will log into the test_home_dir/.bzr.log, which isn't the same as self._test_log_file (which is a mkstemp file with 'testbzr' prefix)
<spiv> And nothing outside of TestCase uses the ._log_* attributes, except for the one test_setup test I updated.
<johnf1> I'm getting a weird error without much google love - NoSuchRevision: CHKInventoryRepository('bzr+ssh://bzr@bzr/.bzr/repository/') has no revision johnf@inodes.org-20100902070043-0hximuhab4del54e
<johnf1> on the remote end I'm using ssh keys to run bzr server in /srv/bzr/foo
<johnf1> I have done cd /srv/bzr/foo; mkdir repo
<johnf1> cd repo; bzr init-repository .
<johnf1> I can then on my laptop create a bzr repor and push it to the server. I can then check it out
<johnf1> when I try to commit to the checkout I get an error like the one above
<spiv> That rings a bell
<spiv> Which versions of bzr?  Any stacking involved?
<johnf1> spiv: No stacking and I upgraded both sides to 2.2
<johnf1> actually server was alway 2.2 and I just moved client to 2.1
<johnf1> didn't make any difference though
<spiv> What was the client using?
<johnf1> sorry moved client from 2.1 to 2.2
<spiv> Ah ok
<spiv> pastebin the full traceback?
<johnf1> one sec
<johnf1> spiv: http://pastie.org/1133240
<spiv> Oh hello:   File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/verify_whoami/__init__.py", line 13, in pre_commit_verify_whoami_hook
<spiv> That plugin may be tripping over something like https://bugs.edge.launchpad.net/bzr/+bug/574226
<ubot5> Launchpad bug 574226 in Bazaar "repository.fetch(same_url_repository, revision_id=revision_added_after_write_lock) fails (affected: 1, heat: 1)" [Wishlist,Confirmed]
<johnf1> ahh thanks
<johnf1> should have thought to turn off plugins
<johnf1> yes, works fine with --no-plugins
<spiv> I *think* get_revision(future_revid) is not expected to work during pre_commit
<spiv> It'd be kind of nasty, but I am tempted to introspect the traceback when we exit with an error and if any stack frames involve a plugin tell the user to try --no-plugins.
<spiv> Although in the case of running hooks we can probably avoid the introspection and at least make it clear that the error occurred while running a $foo hook from $plugin.
<maxb> Are there any environment variables which will suppress the extra strictness of requiring 'bzr whoami' in 2.2?
<maxb> I am wondering what etckeeper should do
<spiv> You can set a value in the branch.conf IIRC
<maxb> Would that be overridden by any per user settings?
<maxb> etckeeper actually works best if it *does* get a guessed username in there
<spiv> Hmm, no, setting email = ... in branch.conf will override the user.
<spiv> (And putting an email address in .bzr/branch/email overrides *that*)
<maxb> ah, I think I see, etckeeper needs to grow a special case to export BZR_EMAIL in /etc/cron.daily/etckeeper, like it exports HGUSER for hg
<spiv> That sounds plausible.
<poolie> yay, the homepage feeds finally update correctly
<poolie> hi vila
<vila> poolie: hello
<ddaa> The bzr-keywords project on lp is owned by Ian Clatworthy.
<ddaa> Is there any plan yet about transferring ownership of this?
<ddaa> What is the expected release date of bzr 2.3?
<vila> ddaa: 2.3 should be released in about 6 months
<ddaa> vila: thanks
<ddaa> In the help of "bzr tag", I see "Tags are stored in the branch.". I remember when poolie first hacked tag support in, they were a property of the repository, not branches. Was that changed?
<ddaa> Or maybe did I misunderstand.
<vila> They are stored in .bzr/branch/tags
<ddaa> So, that means tags should only refer to revisions in the branch ancestry, right?
<vila> I don't know tags very well, I'm not sure they *are* constrained to the branch history
<vila> There may be bugs too
<ddaa> I would not expect they are constrained by the system.
<ddaa> But e.g. if one puts a tag to a diverged release revision into trunk, without merging the actual revision, there would be no guarantee that the tagged revision would be accessible.
<jam> vila: about https://code.launchpad.net/~jameinel/bzr/2.3-bzr-connect-ssh/+merge/34331
<jam> I think we still disagree about what is going on
<jam> and I'd like to sort it out before we land it
<jam> (I think the correct thing is to move 'ssh_server' into an attribute with a better name, and move the .join() into the .handle() method
<jam> )
<vila> I think we should do one event.wait() in verify_request to wait for the key exchange and set an event, wait for this event in handle() and do a join() in finish()
<vila> What I suspect is going on is that the thread spawned by paramiko is using the other side of the channel (the unencrypted one) and this should be blocked during th key exchange
<vila> joining the connection should occur only when the conversation through the encrypted channel is finished
<vila> your fix works, because it does that but it doesn't expose how the things work (or at least how I think they work)
<vila> I'm pretty sure there is something similar in paramiko when handling sftp connections
<jam> vila: I thought about having a second event, and even did that for a while
<jam> but the event only triggers when the run() method exits, which is equivalent to .join()
<vila> the run method always exist on Thread
<vila> meh, are you saying run == join ???
<jam> vila: I'm saying that triggering an event at the very end of run() and waiting on that event is equivalent to waiting on the thread via join
<vila> That's unrelated to what I'm talking about then
<vila> What I'm saying is that I suspect that the key exchange and the socket use happen in different threads and these threads needs to be sync
<jam> vila: are you saying socket or channel?
<jam> it all happens in the same thread, it happens *in the same loop*
<jam> (partially because a long running ssh connection will need to re-key itself after ~2^30 bytes, so it makes sense to have the check be in the loop)
<vila> really ? There could be multiple Channels for the same Transport and I thought the key exchange is shared between the channels so handled by the transport
<vila> whereas the "socket" I'm referring to is the unencrypted side of the *channel*
<jam> vila: still digging through the code a bit
<jam> there is only one thread that processes the communication
<jam> (Transport.run())
<jam> and things it calls must only be entered via a single thread
<jam> however, when spawinng a channel and doing something like 'shell' request
<jam> paramiko itself doesn't implement those functions, so it is a bit hard to say for sure. Certainly our implementation spawns a subprocess and 3 threads to pass the bytes from the process back to the channel
<jam> the channel itself is threadsafe, in that you can have multiple threads calling 'send()' simultaneously
<jam> which, honestly, seems like a bad design
<jam> given that you'll fill a single channel with random intermingled content
<vila> that's exactly what ssh is about IIUC...
<jam> vila: well from what I can tell if you had multiple threads you *should* be putting them into different channels
<vila> urgh, where ?
<jam> I guess if your messages are small, you might be able to squeeze a full message w/ header into a single send window
<jam> vila: you have 1 socket, w/ N channels, and potentially M threads writing to 1 channel
<vila> you shouldn't have to care about that but I'm wondering if that may explain some problems with the smart server on lp
<vila> oh, one thread one channel, yes, sorry misread transport there
<jam> maybe I should say "M threads *per* channel"
<jam> so N*M potential threads writing
<vila> I think there is always and only 2 threads per channel, the (hidden) paramiko one and the user one
<jam> your earlier statement... yes the key exchange is shared between channel
<jam> vila: no extra thread for a channel for paramiko
<vila> between channelS , one per transport
<jam> if you have 1 transport and 10 channels
<jam> you have 1 thread from paramiko, and N for the channels from the *user*
<jam> vila: we, for example, spawn *3* threads all talking on the same channel
<jam> with the extra complexity that you can read, write and write-to-stderr on the same channel
<vila> well, one reading, two writing to the same socket propably.. but wow, both closing the same channel..
<jam> vila: so what happens is that you have 2 messages you can put on the channel
<jam> MSG_CHANNEL_DATA (which is stdout)
<jam> and MSG_CHANNEL_EXTENDED_DATA which allows you to prefix it with yet-another identifier
<jam> in this case '1' to indicate stderr
<vila> right, so Transport and Channel can more or less be seen as the encrypted side and the non encrypted side right ?
<jam> vila: transport is the multiplexed controller, I don't know that I would call it the encrypted side, though it probably does do the encryption
<vila> because the encrypted bytes goes into it and goes out of it, the channels see only unecrypted bytes
<maxb> Hrm. I just emailed the bazaar ML, and got a stupid autoresponse from joe1@assistly.com, as if someone has signed an automated support desk up to the mailing list
<jam> vila: so in paramiko terms the 'packetizer' is the one that actually encrypts and decrypts content
<jam> however, there is only 1 and it is controlled by the Transport
<vila> jam: fits my mental model
<vila> jam: So the key exchange happens there right ?
<jam> vila: key exchange is controlled by transport
<vila> jam: isn't it what I just said ?
<jam> (Transport._send_key_init)
<jam> vila: a bit unclear where 'there' was, since I listed both Packetizer and Transport
<vila> <vila> right, so Transport and Channel can more or less be seen as the encrypted side and the non encrypted side right ?
<vila> <jam> vila: transport is the multiplexed controller, I don't know that I would call it the encrypted side, though it probably does do the encryption
<vila> <vila> because the encrypted bytes goes into it and goes out of it, the channels see only unecrypted bytes
<jam> so actually, *Transport* tends to deal in unencrypted bytes (including the key exchange) and packetizer is the one that encrypts/decrypts it
<vila> jam: now you're really playing with words... the initial problem is no know whether we need to sync the thread doing the key exchange and the one doing the smart server stuff
<vila> s/no know/to know/
<jam> vila: we shouldn't start the smart server until the key exchange has completed
<jam> but 'start_server()' is enough to ensure that
<jam> and given that 'starting the smart  server' occurs as a 'please spawn the server' request via a channel, we don't have an opportunity to start it earlier
<vila> jam: if it was enough join() wouldn't be needed
<jam> vila: the reason we have to *join* is because we have to have the StubSSHServer not *stop* until we've actually finished talking
<jam> and it stops when the requests have been "handled"
<vila> jam: which is why I want to do that in finish()
<jam> vila: the way the code is written it doesn't matter, but sure, it does make sense to do it there
<jam> I don't think I've ever argued that point
<jam> I've argued that adding an event that you wait on before you wait on .join doesn't make sense
<vila> But I never said that
<jam> vila: you wanted to wait on an event in '.handle' and then 'thread.join' in finish
<vila> jam: not *that* event you're talking about
<vila> yes, that's a different one
<vila> I'd like to have setup only goes until the key exchange is done
<jam> what event are you talking about?
<jam> sure
<vila> handle covers only the smart server stuff
<vila> and fiinish only doing join
<jam> handle does nothing today, and we don't have a point to interrupt to actually do something
<vila> :)
<jam> unless you want to .join() in handle, or add an artificial event to wait for
<vila> the later
<jam> vila: why add an artificial event that only fires when the thread is exiting?
<vila> except I'm still not convinced it's so artificial because I think the key exchange and the smart server stuff are in different threads (and by that I mean replacing the subprocess spawn (which takes time) by a direct call to TestingSmartConnectionHandler   which is the inline version
<vila> not when it's exiting, when the key exchange has been done
<vila> jam: i.e. you had a comment: This blocks until the key exchange has been done
<vila> jam: it's a good comment, let's make it true and clear :)
<jam> vila: it is true today
<jam> vila: regardless the "check_channel_exec..." can only happen once the transport has established the key exchange, since it is an explicit request from the client to the server that it wants us to spawn 'bzr'
<jam> vila: I don't really care whether we wait for the key-exchange to finish in 'setup' or in 'handle', but it seems to me that 'setup' is perfectly reasonable
<vila> I view setup and finish as responsible for the Transport and handle as responsible for the channel, if you're sure the key exchange has occured once start_server returns, I'm happy
<vila> jam: Reading the history of your branch, I got the feeling this wasn't the case, IMBW
<vila> jam: the fact that you waited on two events for example... now, if paramiko does it job I'm fine
<vila> jam: but I still don't get how the Transport was shut down early (especially since paramiko use daemon threads)
<jam> vila: I can create an event pass it in and wait for it, but ssh_server exits when the key exchange has completed. *I* did not realize that until recently
<vila> jam: ha, good, one missing bit less
<jam> vila: the Transport isn't stopped, the *socket* is closed
<jam> http://paste.ubuntu.com/487305/
<jam> notice the try/except close_request()
<jam> or in the success case: http://paste.ubuntu.com/487306/
<vila> on exceptions only
<jam> which also calls "close_request()" when the processing completes
<vila> right, but handle() is called only after setup() returns
<vila> so that rules out these close_request()
<jam> vila: no it doesn't
<jam> what was happening is that we weren't waiting for paramiko.Transport to finish
<jam> which meant that .setup() .handle() .finish() was being called
<jam> and then the calling process would then call close_request()
<jam> which would close the socket
<jam> before Transport was able to finish talking
<vila> jam: but now we're calling join(), which means  we are waiting for paramiko.Transport to finish and yet we are able to process the request ?
<jam> vila: nothing happens in .handle or .finish, so the request is initialized and finished in .setup()
<jam> I don't understand where you are confused
<jam> while we are blocking the request thread in waiting for Transport to finish
<jam> a request is sent by the client thread, which is then processed by transport, and handled on a given channel
<jam> which says "start the smart server" which we spawn a process and 3 more threads
<vila> ok, ok, got it, we closed the encrypted side
<jam> to ferry_bytes
<jam> vila: right
<vila> ...and there was one more thread still running on the channel side ?
<vila> no, the transport one, but it gounf the socket closed
<vila> gounf, interesting, found
<vila> one-by-one on qwerty
<vila> ok, that was indeed where I was confused, in all the other implementations there is no distinction between the 'request' socket on the one seen by the bzrlib.transport, whereas here, they are different, not wrapped or anything, really different
<vila> jam: so, s/ssh_server/ssh_connection/ ?
<vila> jam: that would at least make things a bit more inline with the rest of the code base, but less with the paramiko side :-/ Shudder, see ? How can we address your remark about 'server' being overused, now that you've hacked a bit more in the space ?
<jam> vila: for example, using 'paramiko_transport' instead of ssh_server, probably
<jam> for the rest of the stack
<jam> I think using 'connection' or 'request' is nice
<jam> we use TestServer
<jam> which then spawns a real server
<jam> I'm not sure about that
<jam> maybe calling it a Resource ?
<vila> using 'paramiko_transport' instead of ssh_server +1 (explaining that it's close to an ssh server from a user pov)
<vila> s/TestServer/Resouce/ ?
<vila> s/TestServer/Resource/ ?
<jam> TestServer => TestResource maybe
<jam> though I see "Test*" and I think it is a TestCase
<vila> a bit vague :-/
<vila> ServerProxy ?
<vila> pfff
<jam> the other thing is where else do these 'servers' act?
<jam> the SFTP server, the FTP server, etc
<jam> Service versus Server ?
<vila> FTPSocketServer and keeping TestServer...
<vila> hmm, may be that whole discussion could have been avoid by s/setup/handle/....
<manus_> quick question: is there a way to check in a file once, and then tell bzr to ignore any *further* local changes? e.g., a default configuration file is checked in that everyone will change locally, but which should never be recommitted (unless explicitly unignored first)?
<manus_> is that even possible?
<manus_> I guess this says "not yet": https://bugs.launchpad.net/bzr/+bug/209025
<ubot5> Launchpad bug 209025 in Bazaar "ignore local changes (affected: 4, heat: 18)" [Wishlist,Confirmed]
<manus_> huh
<vila> manus_: the best answer I know of is to have a template file that is copied on install
<vila> manus_: a file is either versioned or not versioned, if you have to decide for each change, you may as well use two files, at least it makes the consequences clearer
<vila> manus_: when you have interested changes, you can always do 'cp <file> <template>' + edit + commit
<manus_> true, though it would be nice to have "ignore --local" and "ignore --remote" options
<facundobatista> hello everybody
<facundobatista> I have this niiiiiiice error message:
<facundobatista> $ bzr merge-upstream ../magicicada_0.2.orig.tar.gz --version=0.2 lp:magicicada
<facundobatista> Using distribution maverick
<facundobatista> bzr: ERROR: An inconsistent delta was supplied involving u'/COPYING', 'copying-20100604211115-39tdwa0pbzb5kj4b-1'
<facundobatista> reason: Attempt to add item at path already occupied by id 'copying-20100608181145-hj2h11vcpksyqwck-36'
 * facundobatista is not even understanding it :|
<jelmer> facundobatista: Hi
<facundobatista> hello jelmer
<jelmer> facundobatista: If I remember correctly this is a known bug for which a fix is available.
<abentley> jam, I heard something about bzr allowing merging branches with differing file-ids.  Is that something being worked on?
<jam> abentley: it isn't something that *I've* been working on
<abentley> jam, and not something you've heard about?
<jam> I think I've heard about it, but more in the context of something like bzr-builder
<abentley> jam, e.g. using the MergeIntoMerger?
<jam> abentley: more using by-path merging
<abentley> jam, okay, thanks.
<facundobatista> jelmer, do you know what that fix would be?
<jelmer> facundobatista: Not off the top of my head.
<jelmer> facundobatista, I would recommend having a look at bzr-builddeb
<jelmer> facundobatista, I would recommend having a look at bzr-builddeb's bug tracker
<facundobatista> jelmer, I think this is the one: https://bugs.edge.launchpad.net/bzr-builddeb/+bug/619614
<ubot5> Launchpad bug 619614 in bzr-builddeb "InconsistentDelta during merge-upstream (affected: 1, heat: 5)" [Critical,Fix committed]
 * facundobatista patches his bzr
<facundobatista> jelmer, it worked!!!
<facundobatista> jelmer, thank you!
<jelmer> facundobatista: great :-)
<jelmer> jam: 'morning
<jelmer> jam: do you know what happened to bzrlib.tests.TestLoader ?
<jelmer> jam: bzr-plugin-info relies on it existing, so I wonder what it should be using instead; NEWS doesn't mention anything.
<ReachingFarr1> I currently have a project on my local machine.  I would like to place a copy of it in a shared repository on my server, make that copy the "master", then bind my local copy to it.  What is the correct series of commands to do such a thing?
<dash> ReachingFarr1: 'bzr init-repo /path/to/repo' on the server
<ReachingFarr1> dash: Got that one done.
<dash> 'bzr push bzr+ssh://host/path/to/repo/branchname' on the client
<dash> then 'bzr bind bzr+ssh://host/path/to/repo/branchname' on the client
<ReachingFarr1> dash: Ok, and that will work because the destination is inside an initialized directory?
<dash> right
<ReachingFarr1> dash: Ok.  I think that was the problem I was having with push earlier.  Thanks a lot.
<ReachingFarr1> dash: So on my server that directory now has a .bzr folder and nothing else.  How would one cause the current version of the files to appear?
<dash> ReachingFarr1: 'bzr checkout'
<ReachingFarr1> dash: Excellent.  Thanks  again.
<jam> jelmer: vincent recently changed tests/__init__.py to only import the module rather than the classes themselves. I'm voting to bring back the old style, but it hasn't gained much traction yet
<jam> vila: ^^ care to respond (if you get back online tonight)
<lifeless> jam: old style ?
<jam> lifeless: from bzrlib.tests import TestLoader, TestCase, TestSuite
<jam> or
<jam> from bzrlib import tests; tests.TestCase tests.TestLoader, etc.
<lifeless> ah yes, several plugins got hit by that
<lifeless> +1 on restoring it with a backport :)
<jam> lifeless: I thought it only made it into 2.3, is it a 2.2 thing, too?
<lifeless> I'm not sure; I'm seeing bug reports on plugins increasing is all
<jelmer> jam: Ah, ok
<jam> lifeless: yeah, it is just bzr.dev, just happened with Vincent's recent "clean up leaking tests" change
<lifeless> I *thought* it would be 2.2 because I saw a release happen
<jelmer> jam: For now I've just proposed imports from the TestUtil module directly.
<jam> jelmer: I'd rather see TestLoader from tests, as it makes a better model than finding it in bzrlib.tests.TestUtil, but you're right that your method still works across all versions
<cody-somerville> Whats the correct way to revert a single revision?
<jam> cody-somerville: you mean to reverse the changes created in a given rev?
<jam> bzr merge -r REV..REV-1
<cody-somerville> aye
<cody-somerville> Okay, thanks.
<jam> sorry small typo
<jam> bzr merge . -r REV..REV-1
<cody-somerville> will that work if I have uncommitted changes in my tree?
<jam> the '.' is important, since otherwise it reverts the rev from the default merge location
<jam> cody-somerville: you can supply --force if you must, depends on whether the changes getting intermixed matters to you
<jam> jelmer: do you remember the bug #?
<jam> bug #627438
<jam> found it
<ubot5> Launchpad bug 627438 in Bazaar PQM Plugin "import failure in plugin-info during selftest (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/627438
<jam> lifeless: timeout trying to submit the merge proposal... :)
<jam> OOPS-1706EC2006
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1706EC2006
<jam> second submit worked
<jam> jelmer: https://code.edge.launchpad.net/~jameinel/bzr/2.3-test-loader/+merge/34481
<lifeless> jam: thanks
<jelmer> jam: thanks
<jelmer> jam: r=me
<lifeless> jam:
<lifeless> Total time: 13419 ms
<lifeless> Statement Count: 34
<lifeless> SQL time: 13260 ms
<lifeless> jam: timeout on the INSERT INTO - 13 second query. has to be lock contention I think.
<lifeless> jam: could you file a bug ?
<jam> lifeless: sure, but against what project?
<lifeless> jam: launchpad-code
<jam> lifeless:  bug #629087
<ubot5> Launchpad bug 629087 in Launchpad Bazaar Integration "timeout submitting merge proposal (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/629087
<jam> lifeless: on your new "search only grabs 3-out-of-4 hits", would it be possible to remove 'common' words?
<jam> I find I rarely get any hits while submitting new bugs now, and while I can chop things out of my summary
<jam> it seems like words like "the" "while" etc make for better summaries
<jam> but make for bad hits in the db
<lifeless> problem is that common is defined in the corpus
<lifeless> so that was one of the cuases of timeouts - it analysed the corpus on every reqyest
<lifeless> yes, its fixable, not short term.
<jam> lifeless: true, though you could hard-code some pretty easily
<lifeless> jam: not for 20K projects ;P
<lifeless> stop words are eliminated already
#bzr 2010-09-03
<poolie> hi all
<spiv> Hi poolie
<poolie> hi spiv
<poolie> spiv, today, starting quite soon, i'm going to try to improve the broken lock bug
<spiv> bug 619872?
<ubot5> Launchpad bug 619872 in Bazaar "bzr: ERROR: exceptions.ValueError: tag/value separator not found in line '' reading lockdir info file (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/619872
<poolie> sorry, no, the failure to release locks when we're interrupted
<spiv> Ah, good, because I'm working on 619872 :)
<poolie> great
<poolie> so you said the file is full of nuls? or has a nul?
<spiv> Well, rio.read_stanza(['\0']) is the minimal way to reproduce that exact error text.
<spiv> But any number of nuls would do it too.
<poolie> :/
<poolie> i'm glad we know why it's happening but that's a bit disturbing
<poolie> i wonder how they get in there?
<spiv> (pedant: any natural number...)
<poolie> ooh, that's high grade pedantry
<poolie> :)
<poolie> it reminds me of the other duped bug that was active recently where the dirstate file is truncated
<poolie> well, it's not very similar, but both are "don't trust the filesystem too much"
<spiv> I think some filesystems like XFS have been known to leave files full of nuls after a crash?
<poolie> many unix things can
<poolie> if the inode update is not strictly ordered with writing data
<poolie> xfs may be more prone too it
<poolie> some have had the bug that you could get bits of other files
<poolie> but that's a bit of a security bug and should be uncommon
<spiv> Right.  And ext3/4 has a bunch of different options that affect that sort of thing.
<spiv> The original bug report in this case appears to be windows.
 * fullermd supposed you mean "... appears to be ON windows", but it's funnier read the other way   8-}
<poolie> hi spiv, teddy?
<poolie> i'm getting in to the locking bugs
<poolie> i might try just closing a terminal with bzr running, holding a lock
<poolie> and see what signal it gets and what it does after that
<lifeless> bam
<poolie> presumably sighup
<poolie> ?
<lifeless> mental image
<lifeless> row of bzr's lined up
<lifeless> in terminals
<lifeless> and a firing squad
<poolie> mm
<lifeless> trying to get them at just the right moment
<lifeless> <- strange
<lifeless> I think thats a great way to get a handle on what is happening to python/bzr
<poolie> in some ways i think coping with broken locks by detecting them and asking if you want to steal them, would be better
<lifeless> something you may have already considered is adding some instrumentation to capture in .bzr.log signal info
<lifeless> poolie: we should definitely do that for same-machine locks
<poolie> i know
 * lifeless was emitting moral support
<spiv> poolie: I'm pretty sure it's SIGHUP
<spiv> poolie: I did an experiment along those lines a while back, registering a SIGHUP handler in a simple python script, blocking on raw_input(), then closing the terminal
<poolie> it is
<poolie> i'm not confident that unwinding will really fix all cases but it's worth a try
<spiv> Hmm, if you want to be fancy you could subclass KeyboardInterrupt as SIGHUPInterrupt, and raise that from a SIGHUP handler.  All code that expects to let KeyboardInterrupt propagate would still work, and then at the top level you could potentially distinguish from KI in cause you didn't want to print 'bzr: interrupted' or whatever.
<lifeless> poolie: one more suggesting
<lifeless> poolie: when stealing, we should run some recovery / check code for half-done alterations to the repository in particular (think pack-names).
<poolie> good idea spiv
<poolie> and lifeless
<poolie> i might hook it from library_state.py
<CcxCZ> hi, I managed to break bzr http://paste.pocoo.org/show/257906/
<CcxCZ> all I did was 'bzr remove --keep <DIR>' for a dir with versioned files and then it all went breaking here and there
<spiv> CcxCZ: hmm, that sounds familiar
<spiv> CcxCZ: hmm, sounds like another instance of https://bugs.edge.launchpad.net/bzr/+bug/377261
<ubot5> Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update" (affected: 4, heat: 2)" [High,Confirmed]
<spiv> CcxCZ: FWIW I can't reproduce with simple experiments locally with 'bzr remove --keep' of a dir, if you can figure out a recipe to reproduce your scenario that would be very helpful
<spiv> CcxCZ: also there's a comment on https://bugs.edge.launchpad.net/bzr/+bug/504836 (a dupe of 377361) that may help you recover
<ubot5> Launchpad bug 504836 in Bazaar "AssertionErorr "name .. already in parent" during _generate_inventory (dup-of: 377261)" [Undecided,New]
<ubot5> Launchpad bug 377261 in Bazaar ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update" (affected: 4, heat: 2)" [High,Confirmed]
<CcxCZ> ok, I'll mark myself affected and I'll post my dirstate
<spiv> CcxCZ: thanks!  Please give as much info as you can about how you got into this state, e.g. any uncommitted changes or merges before you ran bzr remove --keep.
<vila> hi all !
<spiv> Hi vila
<vila> \o_
<CcxCZ> spiv: submitted. Right now I don't have time to try to reproduce it, but I have the state archived.
<spiv> CcxCZ: great, thank you!
<poolie> spiv, so as i feared, once we try handling sighup as an exception, we get back into ERESTARTSYS
<poolie> hi vila?
<vila> poolie: hey !
<poolie> hey there, how are you?
<vila> poolie: I'm fine
<poolie> i just saw, catching up on my mail from last week, that the january epic is already settled
<poolie> that's truly epic organization :)
<vila> ;)
<vila> Yeah, found your pm only this morning, we need to discuss before end of September (we should have booked the flights by then)
<spiv> poolie: :/
<spiv> poolie: one option would be a C module like https://code.edge.launchpad.net/~spiv/bzr/sigwinch-without-signalmodule-583941 proposed, or only enabling this on sufficiently new CPython. (>= 2.6.6, IIRC)
<spiv> (2.6.6 is the version where signal.siginterrupt actually works)
<poolie> :/
<poolie> that seems like quite a heavy solution considering that this probably won't fix most unlocking cases
<spiv> IIRC the C module would provide basically the same behaviour as Python gives us for SIGINT
<poolie> i feel a bit more convinced now it would be better to just let the lock break and then cope gracefully later
<vila> poolie: as in better stealing a broken lock ?
<spiv> FWIW I'm trying to be pretty rigorous with tests and corner cases with my lock work atm.
<poolie> vila, yes-
<poolie> spiv, i'm glad, but what's the connection?
<vila> poolie: lock :)
<poolie> ?
<spiv> Well, coping with perhaps damaged locks, e.g. incompletely written.
<poolie> oh ok
<poolie> i was just confused because in the cases i'm thinking about, there's not much we can do about them
<poolie> these are stale locks left behind by bzr dying, or the connection dropping
<spiv> Right.
<poolie> or, for example, it being killed by sighup
<spiv> My hope is that what I'm working on will make the recovery from those situations very reliable, because as you say they are hard to avoid.  (And in the worst case the network connection drops midway and there's nothing bzr can do to tidy up the interrupted op)
<spiv> Or after a messy system crash.
<spiv> It's a bit of a shame to have to code to cope gracefully with non-bzr things failing, but that's life :)
<poolie> oh, maybe we're overlapping then?
<poolie> i was going to put this aside and give you a ui to break locks interactively
<poolie> and to detect locks probably owned by dead processes
<spiv> Hmm, I don't think there's much overlap, I think probably what I'm doing is more complementary.
<spiv> Partly test coverage, partly giving better exceptions in previously unexpected cases.
<spiv> Anyway, it's past 6 on a Friday, and V is letting me know by reaching for my laptop, so I should go :)
<poolie> :)
<poolie> i hope you're all getting better?
<vila> meh, how can "error: (32, 'Broken pipe')" be uncaught by a  "except (OSError, IOError), e:" ?
<vila> err, followed by: if e.errno not in (errno.EPIPE,):
<vila>                 raise
<poolie> vila, i'm guessing it's actually a socket.error
<poolie> which is a different beast
<poolie> annoyingly
<poolie> i think that's what it was
<vila> gimme my bazaar.launchpad,net back
<poolie> i know!
<vila> ha, planned hardware maintenance: http://identi.ca/launchpadstatus/
<vila> one hour to go
<vila> hmm, I can delay writes, but reads...WIBNI a read-only version was always available...
<vila> poolie: hmm, socket.error, sounds like it. We have some latent bugs then
<poolie> there's a bug asking for readonly mode
<poolie> though if it's a hardware fix, this might be a case where we can't do it
<poolie> there's also a bug about socket.error
<poolie> vila, i'm thinking of giving the ui a concept of "does the user want interaction on topic x"
<poolie> then we can just turn that off for break-lock
<poolie> indeed perhaps that's overcomplicated and they just want "is this interactive at all?"
<vila> poolie: yup, that matches up with having config variables accepting y/n/ask instead of being pure boolenas
<vila> booleans even damn delete key being too close to enter ;)
<vila> I thought about that recently, we ould then have a '-y' generic option that would always reply yes without any user interaction
<vila> s/ould/could/
<poolie> right, i'm thinking we should just have that poke some state in to the ui factory
<poolie> we could also add configuration options to control them
<vila> yup, that could be implemented as a ui factory, which will be well suited for script usage
<vila> then you could chose between the config variable and the generic option or any combination that fits
<poolie> should we have a separate concept of asking whether you want to be interactive, or should the core ui code perhaps just ask "should i break the lock"
<poolie> it's a bit look-before-you-leap
<poolie> vila, what do you think of http://pastebin.ubuntu.com/487726/
<poolie> i might sign off in a bti
<vila> poolie: at first glance: I was thinking of a specific type for config values but I don't have a clear answer about how that should interact with the ui factory, having to register all interaction messages won't scale right
<vila> I think the idea was that the code still calls get_boolean, but if the value is 'ask' then the user is prompted, unless the ui is non-interactive
<vila> that doesn't say what the default should be though, but I think get_boolean can already return None
<vila> I kind of feel that the message and the default value should stay in the caller code...
<poolie> it seems useful to me to put the message into the ui so that guis or whatever can present it differently
<vila> poolie: and when I mentioned the '-y' option, I was vaguely thinking about a '--no' option too, but the consequences are unclear...
<poolie> rather than just getting a string
<vila> right, and i18n issues too, but doesn't get_boolean accept a prompt parameter (or should it ?)
<poolie> i was going to then make the ui look up that value in the config
<poolie> it does take a prompt parameter
<poolie> but it folds the other parameters in to it
<poolie> whereas really we want to do i18n before that
<vila> Well, if we reach the point where every constant is a config variable, then, msgs are constants...
<poolie> so what do you think?
<vila> so your idea will fly too but turning all messages into constants... will not rejoice everybody :-/
<poolie> heh, i wouldn't like that
<poolie> but i have a feeling that ui interactions are a bit different
<poolie> i suppose you're right though that it does make things more indirect that you can't just put them inline in the code
<vila> I think I prefer get_boolean(prompt=xxx) rather than interaction_messages, the prompt is indeed an interaction message
<poolie> i think for setting interactivity and defaults
<vila> to step back a bit, my primary example was uncommit's 'Are you sure' , where I'd like a config variable
<poolie> and for letting the ui do something smarter than just showing the string
<poolie> we want a symbolic name, not just a string to match against
<poolie> but perhaps not?
<vila> err, as far as config variables are concerned, strings *are* symbolic names
<poolie> so what would you anticipate having in the config file?
<poolie> "Are you sure" = no?
<vila> ho no ! You mean that get_boolean is called with a prompt and without referring to a config variable
<poolie> i thought that's what you were asking for
<vila> in this case, we need config.get_uncommit_xxx() which implementation check for a conf var and fallback to get_boolean('Are you sure')
<vila> to ui.get_boolean('Are you sure') so GUIs still have a chance to trigger
<poolie> i'd like to keep it at still just one line for application code
<poolie> so how about ui.get_boolean('Really uncommit?', id='bzr.uncommit.confirm')
<vila> could be: config.get_user_option('bzrlib.builtins.cmd_uncommit.confirm') hehe
<poolie> heh, something like that
<vila> aliases could be defined
<poolie> and then the other thing to change is to put the variables to insert into it as kwargs to the ui factory
<vila> so, it depends on whether config can use ui or the opposite
<poolie> right
<poolie> i could go either way
<poolie> but i think of ui as being a somewhat higher-level thing
<vila> so far I think there is only get_user_option_as_bool that uses config, I don't know if ui uses config
<vila> I don't know, a user should be able to configure the ui to use but that doesn't forbid all uis to implement all the needed features
<poolie> istm that making them symbolic would also possibly help later with testing
<vila> The uis use env variables which can be seen as config vars as well
<poolie> right, they should be unified
<vila> indeed, partly by defining where they are in the config layering and partly by defining either aliases (to the corresponding config var) or a rule to go from one to the other
<poolie> just keeping things at a more symbolic layer rather than going straight down to strings would be good
<poolie> oh, rules from env variables to config things? yes
<vila> yes
<vila> I think my (slight) disagreement is the same regarding the show_xxx and warn_xxx additions to ui, my feeling is that this shouldn't be part of ui but stay in application code
<vila> I understand the benefits to group them in a single place but... dunno, something feels wrong
<poolie> do you mean things like show_cross_format_fetch?
<vila> yes
<poolie> ah ok, so show_user_warning is already going in this direction isn't it, of having a warning_id
<vila> by the way, 'bzrlib.builtins.cmd_uncommit.confirm' is accepted as a key by configobj (I just checked)
<vila> that's what I'm saying, yes
<poolie> ok
<vila> on the other hand, we also have a config.suppress_warnings
<vila> which is to say, we may need more data points to triangulate :)
<poolie> ok so it seems like we agree there should be an id passed through
<poolie> and the arguments should be separate
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | bzr 2.2.0 is out
<poolie> (still needs an announcement i think)
<vila> and this id is probably the config var
<poolie> right
<poolie> so there's the question of whether the standard text for it should be inline in the caller
<vila> stepping back to the application code, I want a boolean, I may describe its intent to the user with a string (which could be the docstring for the default value of the config var)
<poolie> which will make it easy to see how to add new ones
<vila> hehe
<poolie> ok?
<vila> all this proposals came from my thinkings about config vars to be honest
<poolie> i think it would be nice to have purely declarative stuff for config vars
<poolie> no methods per var
<vila> exactly
<poolie> except those that have a calculated default
<vila> even them
<poolie> and then describe where it's read from and what env var it may map to
<poolie> well, no method, just a callable
<poolie> so in this particular one
<poolie> we can declare them essentially inline at the place that uses them
<poolie> which may be reasonable if they are mostly used from one call site
<poolie> or we could have a central registry
<vila> not even a callable, we can manage to have declarations in bzrlib.config or just a registry so anybody can declare them inline
<vila> hehe
<poolie> well, if it's for example determined by reading /etc/mailname then at some level there needs to be a callable
<vila> right, the default value can be a callable
<vila> which in turn can use othe conf vars, haha, only serious
<vila> and of course plugins can override the default value... endless fun
<poolie> ok, so
<vila> in this context, the user can speak too, hence the 'ask' special value
<poolie> adding id and args parameters to get_boolean and friends is a small change for the callers
<poolie> and probably makes it maximally easy to implemetn new uis
<vila> ohhhhh, yeah ! That's the ui side !
<vila> hmm, so the conf var docstring can be a format, hence the kwargs
<poolie> then i guess if for some thing we want to take the default text out of the application code, we could just make the text parameter optional
<poolie> what's the conf var docstring?
<vila> <poolie> so there's the question of whether the standard text for it should be inline in the caller
<vila> <vila> stepping back to the application code, I want a boolean, I may describe its intent to the user with a string (which could be the docstring for the default value of the config var)
<poolie> hm, and where would that be in the code?
<vila> I don't know if this will work for all cases but the ui level don't have to care
<vila> in the registry
<vila> that is, if you use conf vars, you pass the docstring to the ui
<vila> if you get straight to the ui, well, you provide it, so it will be inline in the caller
<vila> if you go straight to the ui, well, you provide it, so it will be inline in the caller
<vila> when you said ui higher than config, I thought, well, orthogonal
<poolie> so do you still see the app code calling a method on the ui?
<vila> if there is no config variable, yes
<poolie> i would have thought we'd have a clear distinction between things that are meant to behave like config variables, and things that are possibly user interactions
<vila> ISTM that some/most? of the  user interactions can be linked to a conf var
<poolie> mm, but i think specifically blocking and asking the user something needs to be taken account in the code in a way that looking up a config variable does not
<poolie> maybe not
<vila> warnings about format deprecations, confirming uncommit, forcing push/pull/commit
<vila> that's why I say conf vars, newbies may want to be asked whether their push is valid, experienced users hate that
<poolie> oh, i definitely agree that should be configurable
<poolie> i just think that the intent of the app code is "here's something to possibly warn about" not "look up a configuration variable"
<vila> hmm
<poolie> ok
<poolie> i'm tired; i should stop
<vila> but the code flow may depends on the user answer or a conf var... I don't have a definitive answer, both config and ui are involved it may be clearer for the application code to refer to ui, may be the call itself should be ui and the parameters from config, or just hidden in the call
<poolie> istm there are going to be a number of callers
<poolie> and we want them to have the simplest experience we can
<poolie> so at least a facade that covers up checking with either config or the ui
<vila> sounds good
<starenka> hi can i hook a shell script which would be executed on the server as soon a rev is pushed to it? (bzr+ssh)
<jam> starenka: look into the "post_branch_tip_changed" hook. It is a python hook, but you can have it hook into a script
<jam> I think jelmer also had a plugin that exposed bzr hooks to shell scripts
<starenka> jam: thanks
<C-S> For all the guys who asked for testtools on FreeBSD... Here it is: http://www.freshports.org/devel/py-testtools/
<C-S> Just ported it and it got accepted today :-)
<C-S> this is in particular news for fullermd :-)
<jelmer> C-S: \o/
<C-S> jelmer: what you guys wanted, right?
<jelmer> C-S: Well, I don't use FreeBSD but it's great to have testtools available on more systems.
<C-S> jelmer: You should give it a try! FreeBSD is just a dream :-)
<jelmer> :)
<jelmer> I've used it in the past and quite like it
<fullermd> C-S: Sweet   :)
#bzr 2010-09-04
<billy> hi folks - can bzr-svn import a subversion repository?
<lifeless> yes
<billy> lifeless: i used the command bzr svn-import (url) and got the error (url) appears to contain a branch. For individual branches, use 'bzr branch' - help
<billy> anyone?
<lifeless> sorry, got stuff happening here
<lifeless> have you read the user docs on migration? they are pretty good I think
<billy> lifeless: no - they are woeful
<james_w> billy: did the url have /trunk/ or something at the end?
<billy> james_w: yes
<james_w> then remove that part
<billy> james_w: trying now
<billy> james_w: while i'm waiting the error said use 'bzr branch' so would 'bzr svn-import branch' be a valid command?
<maxb> billy: No. It works like this: 'bzr branch svn-url' to import a single branch, or 'bzr svn-import svn-url' to import all branches below a directory
<billy> maxb: thanks
<Ddorda> hey, i'm havign troubles branching any lp: link, any ideas what might be the reason
<Ddorda> ?
<lifeless> without a description of what happened, no
<Ddorda> lifeless: not sure. didn't do anything special. any lp:something i'm trying to branch give me an error for no existence
<Ddorda> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~
<lifeless> what happens if you try bzr branch lp:python-fixtures
<Ddorda> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~python-fixtures/python-fixtures/trunk/".
<lifeless> ok
<lifeless> can you ssh to bazaar.launchpad.net successfully ?
<Ddorda> trying
<lifeless> it should tell you that no shells are permitted
<Ddorda> seems so
<lifeless> this is very odd
<lifeless> its also very late for me
<Ddorda> wait.. not sure
<Ddorda> sec
<lifeless> can you please file a question on https://answers.launchpad.net/launchpad-code/
<Ddorda> i had conf problem with ssh. trying now again
<Ddorda> okay, i found what was the problem. it was ssh configuration problem
<lifeless> cool
<Ddorda> lifeless: many thanks
<lifeless> np
<Pilky> if two people are working on a project and one wants to use git and the other bzr, is it reasonable to use svn on the server as a sort of go between? Or will that cause issues in the long run? And if so has anyone experience with git and bzr working together?
<jelmer> Pilky: that should work
<Pilky> and I assume merging can be done locally so git and bzr manage it, rather than having to fight with svn?
<jelmer> Pilky: bzr can, I'm not sure about git
<Pilky> ok, thanks
<Pilky> we may still end up using one or the other, I just don't want to force this other guy into using bzr but I really do not want to have to deal with git :p
<jelmer> :-)
<mgz> wow, I thought pyjunitxml was flakey, but bzr-xmloutput makes it look like something designed to run fighter planes
<mgz> sure, python doesn't actually make it easy to do xml The Right Way, but there are alternatives to print-and-hope
<jelmer> mgz, in what way is bzr-xmloutput flakey?
<mgz> it's not very careful in ensuring what it's creating is actually well-formed
<mgz> I think I will not worry about that right now and just fix the import like I was going to.
<mgz> ...aren't plugins meant to import their bits from bzrlib.plugins rather than the root namespace?
<jelmer> mgz: yes
<mgz> ugh, I'm failing to see a way to fix this without fixing one of several larger problems
<jelmer> mgz: What are you trying to do with bzr-xmloutput?
<mgz> jelmer: https://bugs.launchpad.net/bzr/+bug/614522 <- comment #2
<ubot5> Launchpad bug 614522 in Bazaar "Monkey patching private escaping functions breaks with ElementTree 1.3 (affected: 1, heat: 6)" [High,Fix released]
<jelmer> ah, hmm
<mgz> I think the shortest path for me is fixing all the weird import/lazy import stuff first, then just taking the function from elementtree as I suggest
<mgz> +ed
<mgz> means I don't need to worry about the (lack of) correctness over the actual xml generation
<mgz> okay, I now kinda wish I hadn't fixed that Python 2.5ism in the test suite, I did not want to see the result...
<mgz> Ran 83 tests in 15.609s
<mgz> FAILED (failures=10, errors=48)
<jelmer> mgz, whoa
<mgz> I good number are from a bug I noticed earlier and nearly commented on in here
<mgz> there's this copy-coded all over the place:
<mgz> self.outf.write('<?xml version="1.0" encoding="%s"?>' % \
<mgz>         bzrlib.osutils.get_user_encoding())
<mgz> vs.
<mgz> "t is RECOMMENDED that character encodings registered (as charsets) with the Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just listed, be referred to using their registered names; other encodings SHOULD use names starting with an "x-" prefix."
<mgz> expat doesn't like all the encoding names the python encoding module knows about
<mgz> there's also some weirdness with an extra args element for errors, probably python 2.4 related:
<mgz> http://float.endofinternet.org/xmlbin/2.2_bp.xmloutput#bp.xmloutput.tests.test_info_xml.TestInfoXml.test_info_non_existing
<lifeless> mgz: hi
<mgz> hey lifeless.
<lifeless> I'm looking at a similar sort of thing
<lifeless> intern() in 2.5 is blowing up (thing is unicode), and not in 2.6, and I can't tell if its:
<lifeless>  - internt
<lifeless>  - writlines
<lifeless>  - stringio
<lifeless> blah
<mgz> intern needs str objects on 2.4 at least.
<lifeless> yeah
<lifeless> it does on 2.6 too
<lifeless> so stringio or writelines or *something* is casting.
 * lifeless hates on autocasting some more
<mgz> cStringIO should be safe (doesn't like unicode at all), but StringIO will autocast
<mgz> writelines... depends on the file-like
<lifeless> yeah
<lifeless> this is 2.5 breaks, 2.6 works
<lifeless> 2.5 is of course only accessible in an ec2 instance.
<mgz> anything I can run for you, or does this mission start by branching launchpad? (which I've still never succeeded at)
<lifeless> the latter
<lifeless> its test isolation, which makes me even happier
<mgz> okay, getting somewhere, import fixing and hacks got me down to FAILED (failures=17, errors=10), and if I could work out IllegalUseOfScopeReplacer weirdness I'd be even happier
<lifeless> ok
<lifeless> so that one can be fun
<lifeless> calling gc.collect() can cause it
<lifeless> IIRC, alternatively it was using gc.objects can trigger it
<lifeless> either of those being done?
<mgz> as far as I can see, no, but this is in blackbox-style testing so there's a *lot* going on. it may just be circualr import weirdness, I've not finished cleaning all this up yet.
<lifeless> I was beating me head on the wall on friday with something similar
<lifeless> the tests for much of launchpad go via the entire stack
<lifeless> skipping only http wire protocol
<lifeless> so this includes a thing called the 'publisher' whose job it is is to make sure no information about internals escapes to the web client
<lifeless> ... can you see the problem :P
<mgz> there's a place for end-to-end testing, just... not everywhere please ;_;
<fullermd> Of course not.  Only at the ends   8-}
<mgz> okay, this is so far from where I started, but the lazy_import thing is starting to make sense
<mgz> for some reason, the find-tests-in-plugin code is both triggering the lazy import load (understandable, probably just touches every object in scope), and cleans it up (why?) before any test ever runs
<mgz> ...okay, this is funny, and stupid.
<mgz> okay, fixed, and I'm going to poke bzrlib so no one else gets into that kind of tiz again
<mgz> summary, "from thispackage import module" is a bad idea
<jelmer> mgz: we use that a lot, I think that's the recommended way of importing modules
<mgz> lazy import lets you do it, but module is a lazy object, that when it tries to resolve the import... finds *itself* in the package __dict__ and doesn't actually import anything
<mgz> you just get a lazy object containing... itself... that then goes away
<mgz> I hadn't really thought through what the code I'd written was doing...
#bzr 2010-09-05
<mangojambo> hi, I 'm using bazaar explorer on mac and  when I try to go to Settings > Configuration > User configuration it is giving me this error: QFileSystemWatcher: failed to add paths: /Users/myuser/.bazaar/bazaar.conf
<dev001> I've had xmloutput installed as a plugin.  it recently started reporting: "cannot import name _escape_cdata; Unable to load plugin 'xmloutput' from '/usr/local/lib/python2.6/site-packages/bzrlib/plugins'" at any/all bzr pulls ...
<dev001> I've not found any related/recent bugs (yet)  ... anyone heard of this?  maybe a config issue on _my_ end?
<maxb> dev001: can you check the traceback in .bzr.log and see what module that symbol is being imported from?
<dev001> maxb: sorry, didn't hear you 'ping' ... here's the log output: http://pastebin.com/jNf0nD1S
<maxb> dev001: I'm supposing your bzr version is too old, then
<mgz> that's me.
<mgz> see bug 614522 for the whys
<ubot5> Launchpad bug 614522 in Bazaar "Monkey patching private escaping functions breaks with ElementTree 1.3 (affected: 1, heat: 6)" [High,Fix released] https://launchpad.net/bugs/614522
<mgz> I'm still planning on working out some kind of minimal xmloutput branch that doesn't get my name in the blame all over the place
<mgz> what else was I going to say in this review comment to vila... I forget
<vila> mgz: then just finish that patch :-D Sorry, I didn't found the time to work on it myself, I just reverted the deletion of __escape_cdata as a quick-and-dirty fix :-}
 * vila off for dinner
<mgz> ah, on bzr.dev already?
<vila> mgz: but your pyjunitxml fixes did wonders...
<vila> mgz: no ! only locally
<mgz> okay, okay, branch up today to get it out the way :)
<mgz> I'll leave my other >_< over xmloutput for later
<vila> (locally for both the _escape_cdata fix and the pyjunitxml one
<dev001> maxb I'm using an up to date pull of: Bazaar (bzr) 2.3.0dev1
<vila> mgz: indeed, you should talk with verterok about it anyway as bzr-xmlouput is used by other plugins, but the long term plan should be to have an 'xml' log formatter and from there the same kind of formatter for other commands. After all, this is supposed to be a supported way to comunnicate with some IDEs or something
<mgz> dev001: as I was saying, that's the problem, I just broke it a few days ago
<vila> mgz: that's what should drive the 'cleanless' of the xml used, may json should be used even
<dev001> mgz: ah, just catching up reading ... thx.  so, update xmloutput branch?
<mgz> you can cherrypick out r5407 on bzr.dev for the moment, and I'll get a fix up for xmloutput in a bit
<dev001> mgz: np, and thanks!
<dev001> hm.  while i'm 'looking', i also see: "/usr/lib64/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken RandomPool_DeprecationWarning)"
<dev001> which, i think, is unrelated ... checking
<mgz> that is, it's... bug 271791
<ubot5> Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 5, heat: 26)" [Medium,Triaged] https://launchpad.net/bugs/271791
<dev001> mgz: jeez!  to which I'd posted ... getting old & forgetful.  thx!
<mgz> so you had :)
 * dev001 blames it on the weather, or moon phase, or a black-cat, ... or sumthin ;-p
<dev001> tracking the bug-trackers is a job in itself!
<micahg> does bzr have an issue with non-ascii commit messages?
<vila> micahg: it had, I shouldn't anymore. Which version ? (bzr version)
<micahg> vila: 2.1.1
<vila> micahg: 2.2 is out, try it and file a bug if the problem persists. I'm 80% sure we fixed bugs in this area
 * micahg tries adding the bzr dev PPA to see if it helps
<vila> micahg: 2.1.2 is out in case you want to be extra careful about updates
<vila> micahg: oh, ppa, you're on Ubuntu then, which release ?
<micahg> vila: lucid, about to upgrade to maverick though
<micahg> maverick has 2.2.0, I guess I can jsut wait :)
<micahg> thanks vila
<vila> micahg: what's your locale ?
<micahg> C ATM, I need to fix it
<vila> micahg: this alone could explain the problem. bzr needs to know how to decode your non-ascii message, so if you tell it it's C...it can't
<vila> just try export LC_ALL=UTF-8
<micahg> I tried setting LANG to en_US-UTF.8, but it didn't help
<micahg> oops, might have had the syntax wrong :)
<vila> micahg: the last I tried to understand which one has to be set, I resigned, I just use LC_ALL :-/
 * micahg tries again
<micahg> vila: it's happy, thanks
<vila> micahg: great, care to file a bug ? We should issue a better error message in that case I'm afraid
<micahg> vila: well, it warned that it was an unsupported locale string
 * micahg just didn't read the error messages well (running on 4 hrs sleep :))
<vila> micahg: but enough to help you find the solution. bzr can't (... or could it ?) guess the encoding, but it could tell you that you tried to use a commit message that requires one
<vila> micahg: but NOT enough to help you find the solution. bzr can't (... or could it ?) guess the encoding, but it could tell you that you tried to use a commit message that requires one
<micahg> vila: no, it was clear enough, I just focused on the bzr error, the locale error should've tipped me off
<vila> micahg: It looks like we are in violent argument :) What I mean is that WARNING about locale could be nicely complemented by an additional help in the bzr ERROR to tipped you off :)
<vila> grrr, joke ruining typo of the day: s/argument/agreement/
<fullermd> Typo?  You?
<vila> blast on that's typo ruining joke, even fullermd missed it or kindly believed it was a joke in itself ;-}
<fullermd> Hey!  No recursion!
<vila> yeah, always put a stop condition or it degrades into a mere loop...
<micahg> vila: http://pastebin.ubuntu.com/488920/
<vila> fullermd: hey, look at that: http://babune.ladeuil.net:24842/ freebsd is the only one with 5 successful builds ;-)
<fullermd> Naturally.  Good solid American code.  None of that flaky European imitation hackery   ;p
<vila> fullermd: yeah, who cares if some of those accented letters get translated into CR or even LF when they lose their high bit, really who ?
<fullermd> High bits are a device of the devil anyway.
<vila> fullermd: and anti-democratic at that, what with high and low bits, all bits are equal !!
<fullermd> 7 bits were good enough for Jesus, and they're good enough for m1
<fullermd> And me.
<vila> fullermd: really ? I thought he multiply them... didn't know he stopped at 7... IMBW though
<fullermd> Yeah.  Just vicious lies told by the people who tried to sell 36 bit words  :p
<vila> micahg: ha ! _get_uicode_argv is now called _get_unicode_argv and... http://pastebin.ubuntu.com/488925/
<vila> micahg: looks like we don't to fix *that* bug ;)
<vila> micahg: looks like we don't need to fix *that* bug ;)
<_habnabit> Is there a web interface similar to hg's interface but for bzr? Really what I'm looking for is loggerhead + easy tarball exports.
#bzr 2011-08-29
<jelmer> poolie: that looks like fun :)
<jelmer> ouch, the speed and the angle in those videos looks pretty scary..
<dcoles> Is fastimport still the best way of doing round-trip compatable mirroring of a bazaar repository to git?
<jelmer> dcoles: fastimport isn't round-trip compatible
<jelmer> dcoles: what do you mean exactly?
<dcoles> I think I read some information on a Question that said bzr-git now did 'push' but maybe not in the Natty version
<jelmer> dcoles: there is some support for it, but it's not enabled yet
<jelmer> dcoles: however, if you're looking for functionality equivalent to fastimport, bzr-git might do that, depending on what you're looking for.
<dcoles> A friend wants to use github for various reasons. He "migrated" the Bazaar repository in one commit. I want to be able to 1. Preserve the history and 2. Be able to pull back new revisions to Launchpad
<jelmer> dcoles: that's a parallel import, for which we don't really have a good answer yet
* poolie 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
<jelmer> dcoles: I think diff+patch are really the only way of dealing with that at the moment, though perhaps others have better ideas
<dcoles> jelmer: Yeah. I've looked at things a few times in the past (such as when I want a bazaar mirror of svn/git repos). I guess fast-export is going to have approximately the same results as a dpush would have.
<jelmer> dcoles: dpush would work if your friend had done the export to github using dpush
<dcoles> jelmer: Hm. Well I'm redoing the export now. I know dpush munges some revision ids - will that cause any issues for the bazaar repo? Or only branches off my bazaar branch?
<jelmer> dcoles: it will rewrite the history of your bzr branch, so any other bzr branches of your project will appear unrelated
<dcoles> jelmer: Right. So I'd have fun trying to pull new revisions from the launchpad repo? Unless I pushed to launchpad with --overwrite (which I'd rather avoid)
<jelmer> dcoles: yes
<dcoles> jelmer: Alright. Thanks for the advice.
<AuroraBorealis> anyone have any idea how to clone a remote cvs repo so i can import it into bzr? :<
<vila> hi all, as PP, I wish you an happy flight this week !
<fullermd> Will there be an in-merge movie?
<bob2> hahaha
<vila> Inside Job ? (far-fetched ;)
<fullermd> The Good, The Bad, and The Uncommits?
<poolie> hi vila, jelmer, all
<poolie> thanks vila
<poolie> jam, hi?
<vila> hmm, first wtf of the week, root cannot do 'ls -l' at the root of a disk ? Cannot umount it either >-/
<fullermd> We control the horizontal; we control the vertical.
<vila> hmm, rather, it's not that I can't it's that I get an IO error ...
<poolie> vila, oops
<vila> yeah, no time to investigate, will reboot (and lose all my sessions :-/)
<vila> that was the disk where I did some fdatasync experiments so I'm totally safe am I not ?
<vila> right, back to normal
<poolie> backups :)
<vila> poolie: it *is* one of my backup disks :) And also my slowest one which is why I wanted to experiment with fdatasync there to amplify the fallouts ;)
<vila> so no critical data there
<Anteru> Hi, what is the state on per-branch rules? The discussion in the bug (https://bugs.launchpad.net/bzr/+bug/395731) seems to indicate that .bzrmeta/rules has been decided as the location, so has this been implemented or is something still holding it off?
<ubot5> Ubuntu bug 395731 in Bazaar "Need a way to set content-filtering rules across the project" [High,Confirmed]
<Anteru> The problem I'm facing is that I'm working on a plugin, and currently I have to set it via the global rules file, while I'd definitely like to use it for my single test branch only.
<fullermd> vila: So we've established that fdatasync is dangerous?  ;p
<vila> hehe, that won't be my first bet ;)
<fullermd> Pfui.  Don't try and argue with the facts.  If correlation didn't imply causality, why would they start with the same letter?
<Anteru> or is there some easier way to restrict a content filter plugin to a single branch only?
<fullermd> Anteru: AFAIK there is not.  Nobody's implemented .bzrmeta/rules AFAIK.
<bob2> facts are a well known liberal myth
<vila> Anteru: there is a work in progress to make that easier, but only for non-versioned stuff, not sure if your plugin can deal with wt specific *config* options or if you need versioned properties
<Anteru> Hm, allright.
<Anteru> How hard to you expect that to be?
<Anteru> brb, gotta reconnect
<Anteru> vila: How complicated do you expect the per-branch rules to be?
<vila> Anteru: bug #395731 raise a number of different issues, I don't have answers for all of them nor can I make an estimate, so my question was about whether you need versioned properties or not (non versioned *can* be addressed with config)
<ubot5> Launchpad bug 395731 in Bazaar "Need a way to set content-filtering rules across the project" [High,Confirmed] https://launchpad.net/bugs/395731
<jam> morning poolie
<poolie> hi thar
<Anteru> vila: Ok, sounds complicated. I was looking at Mercurial's bfiles extension, and Mercurial has this per-branch setup using .hg/hgrc: http://hg.gerg.ca/hg-bfiles/raw-file/tip/usage.txt My thinking was that porting that extension over to Bazaar should be the easiest, but well ...
<Anteru> At least their big-file extension is reasonably documented
<vila> poolie: thanks for the updates on doc.bazaar.c.c, I usually do that while announcing but that should occur soon now (so less work for me ;)
<poolie> Anteru: i don't know if specifically porting that code will help a lot but something broadly like that would be a good first step
<poolie> or, perhaps, second step, you could perhaps get value out of something even smaller
<Anteru> poolie: Just found there's a much further advanced version being prepared for inclusion into Hg back, https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles-mercurial-truncated
<Anteru> That's based on Kiln's kbfiles, which was the reason I actually started looking into this.
<ryanhaigh> hi all, im looking for some help with bzr explorer
<ryanhaigh> im currently trying to set up the editors using file>accessories
<ryanhaigh> the problem i am running into is that the editor program requires the full path to the file, and bzr explorer appears to be passing only the relative path from the branch root
<poolie> hi ryanhaigh
<poolie> i don't know an answer off hand
<ryanhaigh> thanks poolie, im not sure how many people use this feature, i only found out about it today
<ryanhaigh> and none of the defaults work
<poolie> explorer as a whole?
<poolie> i don't personally use it often but others do
<ryanhaigh> no the custom editors based on file extension
<ryanhaigh> which is a part of explorer
<poolie> ah, ok
<poolie> i suggest you file a bug about it and bialix or someone might be able to help you out
<poolie> or maybe Riddell
<poolie> it doesn't sound like it would be very hard to change if there is a gap there
<Riddell> aye, ping me when you file a bug ryanhaigh
<ryanhaigh> Will do Riddell, will be a while through im going to a minsite for at least 2 wks
<ryanhaigh> thanks for taking the time to answer
<vila> jelmer: I'm about to deploy the fix for bug #833097, including upgrading bzr-builddeb
<ubot5> Launchpad bug 833097 in Ubuntu Distributed Development "bzr-builddeb needs to be updated on jubany" [High,In progress] https://launchpad.net/bugs/833097
<jelmer> vila: ok
<vila> jelmer: should I get the tip or stick to 2.7.7 ?
<jelmer> vila: I'd go with tip, it shouldn't have anything dangerous
<vila> ok, I'll try that first then
<vila> ok, deployed and importer restarted, I'll monitor it after lunch
<jelmer> vila: thanks for working on that update
<vila> jelmer: np ;)
<vila> so, no blatent failures so far (good)
<vila> jelmer: what's the status on bug #653757 (bird's eye view) ?
<ubot5> Launchpad bug 653757 in Ubuntu Distributed Development "Can't import packages with multiple upstream tarballs yet" [Medium,In progress] https://launchpad.net/bugs/653757
<jelmer> vila: getting close to being finished. The internals in bzr-builddeb have been updated to support multiple upstream tarballs, which was the bulk of the work. The main bit now is getting import to deal with multiple upstream tarballs and testing.
<jelmer> vila: it's up next for me after fixing the FTBFS of various plugins in oneiric
<vila> ha, ok, make sense (was wondering about the related commits in builddeb)
<vila> oh cool !
<ryanhaigh> Riddell: thought id nock it over tonight, here is the bug report
<ryanhaigh> hope the patch is useful
<Riddell> ryanhaigh: what's the number?
<ryanhaigh> haha sorry forgot link https://bugs.launchpad.net/bzr-explorer/+bug/836631
<ubot5> Ubuntu bug 836631 in Bazaar Explorer "Editing via status window passes relative path to editor" [Undecided,New]
<vila> jelmer: regarding the spurious failures for 2.4.0 on hardy, Tests on the buildds are run without --parallel=fork right ? And you don't use a chroot locally right ?
<jelmer> vila: I use a VM locally
<vila> jelmer: k, and the tests are run sequentially in both cases ?
<jelmer> vila: no, with --parallel=fork
<vila> jelmer: how many processes in both cases ?
<jelmer> vila: I'm not sure, 2 on my local machine
<jelmer> vila: I don't know how many processors the buildds have
<vila> jelmer: try running without --parallel locally ?
<jelmer> vila: is there a particular reason you think that's relevant? Aren't the tests all run in their own subdirectory?
<vila> jelmer: that may be useless, but... the failure makes no sense, so I vaguely suspect some issue in the test infrastructure that *could* lead to a file handle starvation and in this case I've seen non sensical failures in the past
<jelmer> vila: ah, ok. I'll give it a shot
<vila> jelmer: when you get one failure, do you get other failures as well ?
<jelmer> vila: not necessarily
<vila> :-/
<vila> jelmer: sorry, not much more ideas, at worst, if the traceback is always in write_index, you can try displaying the path when getting that exception, because there is no way we create a *directory* names after an index file
<vila> s/names/named/
<jelmer> vila: np, thanks for thinking about it
<vila> jelmer: I've disabled the hardy builds on babune because we require python-2.6, if you have a branch where you addressed the compatibility with 2.5 I can give it a go
<AuroraBorealis> question: does anyone have any experience cloning a cvs repo when you only have remote access to use fast-export-from-cvs?
<jelmer> vila: yep - lp:~jelmer/bzr/2.4-python2.5
<jelmer> AuroraBorealis: launchpad-cscvs is the only thing I'm aware of that doesn't require local access to the CVS repository
<AuroraBorealis> ok i'll try that
<AuroraBorealis> 'cvssuck' and 'cvsclone' are woefully out of date and don't seem to work =(
<vila> jelmer: http://babune.ladeuil.net:24842/view/%20High/job/selftest-hardy/483/ , 4915 failures 8-/ http://paste.ubuntu.com/677208/ is required here to properly compile the extension (which may explain a lot of the failures)
<jelmer> vila: oh, that's interesting. I didn't need that
<vila> which is weird...
<jelmer> vila: well, I'm applying a whole bunch of patches and building against the cat archive
<vila> yeah, nothing caught my eyes in this branch, are you sure the extensions are built and if yes with pyrex ? version ?
 * AuroraBorealis sighs as he has to update this very old python script to work with python2.7 :<
<vila> AuroraBorealis: wanna try to help jelmer debugging an issue while backporting bzr-2.4.0 to python-2.5 instead ? :)
<AuroraBorealis> i have to leave for school in a hour and a half =P
<vila> jelmer: http://babune.ladeuil.net:24842/view/%20High/job/selftest-hardy/485/console, only 4 failures which I suspect have to do with some subunit/testtools weirdness, but nothing looking like your failure :-/
<vila> jelmer: retrying with only 2 procs (instead of 8), will take longer  ;)
<jelmer> vila: the package also includes a backport of the fix for testtools
<vila> jelmer: at least there is evidence that the failures are spurious which could help you decide if you want to disable the tests for your particular needs
<jelmer> vila: The thing I'm actually trying to build is at lp:~canonical-bazaar/ubuntu/hardy/cat
<jelmer> but that's a debian package, so may be harder to build on babune
<jelmer> vila: Yeah, I'm considering that.
<jelmer> Given this is what's being used on the buildds I'd rather be sure that it won't happen (spuriously) in production.
<vila> yeah, good point, but a file turning spuriously into a directory... You always get the same exception right ?
<jelmer> yes
<vila> madness
<vila> jelmer: upgrading the buildds to lucid is not an option ?
<vila> jelmer: upgrading the buildds to lucid is *still* not an option ?
<jelmer> vila: nope, not for a while
<vila> just checking
<vila> k
 * jelmer restarts the build another time to see if there are different failures
<AuroraBorealis> this is probably totally not worth it, going through all this trouble just to convert a cvs repo >.>
<antivirtel> hello! I'm new to bazaar, and to VCSs too. I started a new project on LP yesterday. I haven't created trunk directory, and now I want to move the files to the trunk dir. Can I do that without a new commit? (Otherwise, can someone tell me what is the default dir system of a bzr repo? like in Unix: /usr,/home...)
<jelmer> antivirtel: hi
<jelmer> antivirtel: the directory structure is up to you, and what your project needs
<antivirtel> aham, so the trunk is not required? If I want to make a new branch, where it will on the LP? I have no dirs upper, right?
<abentley> jelmer: now that bzr has a "branches" command, what should happen to the bzrtools branches command?
<jelmer> antivirtel: I'm not sure I follow; trunk is just the name of a branch
<jelmer> abentley: its functionality is different, as it scans the filesystem rather than just asking the control directory. I can think of a few options:
<jelmer> abentley: * rename it to "bzr scan-branches / bzr find-branches / etc"
<jelmer> abentley: * make bzrtools decorate "bzr branches" and add a --scan option to it with the current functionality
<jelmer> abentley: * move the current functionality into bzr core as an option to "bzr branches"
<abentley> jelmer: I'm leaning toward the last option.
<jelmer> abentley: works for me
<jelmer> abentley: will you propose that as a patch to bzrlib or should I ?
<antivirtel> ok, jelmer thanks - an other question: I have some files(static, like images; commited separately), which I don't want to put in the main branch, because it is needed for a sub-project only (but it uses the main branch's code). Can I separate it from the main branch, and place it to the "cloud", because I want to make that float with the lastest version of the main branch?
<jelmer> antivirtel: what do you mean with cloud exactly?
<bigjools> hey folks. Why do I need a working tree to do a merge?
<AuroraBorealis> because what else does it do a merge with?
<antivirtel> jelmer, if I commit something on the main branch, I want to these selected commits automatically move up, and if I want to release a new version, these commits are there... is it possible?
<AuroraBorealis> a shared repo can contain multiple branches
<bigjools> I have a branch with no tree
<bigjools> not sure why it needs to be checked out to merge a different branch
<AuroraBorealis> then its probably a 'no working tree' branch, which is usually meant to be on servers
<jelmer> bigjools: I think in theory it could be anything that implements the treeinterface, not necessarily a working tree. In practice there are a few things that rely on disk during merge.
<antivirtel> or jelmer I have to move these commits to a new branch and if I release one version, I have to merge the main to the sub-project?
<jelmer> bigjools: also, disk is probably the easiest place to let the user deal with conflicts.
<jelmer> antivirtel: what do you mean with moving the commits up?
<bigjools> jelmer: ok thanks.  I guessed that might be the case :)
 * vila blinks bzrtools version 1.15.0 on jubany ...
<abentley> jelmer: I'm willing to do it, but you'd probably get it done faster.
<antivirtel> jelmer if you visualize a branch tree (like this: http://goo.gl/yHXde) you see that if I create a new branch, and I commit there e.g. 2 times, these commits are separated from the main line. But, I want to move this branch's (like the blue colored one on the img) commits up to the top, 'cos if I want to release a new version (in the sub-project), I want to use all code, but with these static commits (like logo images etc...) ... is it possible, or it re
<antivirtel> quire new branch and merging from the main on each release?
<abentley> jelmer, bigjools as the source of a merge, it shouldn't need a tree.  As something you're merging into, it does, because commit only works on working trees.
<jelmer> abentley: commit requires any tree, it doesn't have to be a working tree
<jelmer> abentley: my understanding was the merge/treetransform had trouble doing the merge into anything but a working tree
<abentley> jelmer: I mean the commit command.   AFAIK, that still requires a working  tree.
<jelmer> abentley: ah, sorry. Yes, that's true.
<abentley> jelmer: TransformPreview doesn't require a working tree.
<abentley> jelmer: bzr-pipeline does merge and commit using preview trees, for example.
<jelmer> abentley: but it still requires disk access doesn't it?
<jelmer> abentley: it was my understanding there wasn't a way to do a merge fully in memory, without hitting disk.
<abentley> jelmer: TransformPreview currently requires disk access, but it uses a temp directory, not the working tree.
<jelmer> abentley: ah, right
<abentley> jelmer: I have code that permits doing a merge fully in memory, but it needs a bit of polish.
<jelmer> antivirtel: Sorry, I still don't follow
<jelmer> abentley: ooh
<antivirtel> jelmer no problem :) I will use new branch, and merge it from main technology
<antivirtel> :)
<abentley> jelmer: lp:~abentley/bzr/memory-storage
<antivirtel> in Bazaar Exlorer, Bazaar>Work>Bind branch creates a new branch based on the current rev?
<AuroraBorealis> no
<AuroraBorealis> that 'binds' a branch to another branch (usually remote one)
<AuroraBorealis> so that when you commit to the branch, then it also commits to the one you specified, keeping them in sync
<antivirtel> aha, thanks AuroraBorealis - and can I make a new one with the BE?
<AuroraBorealis> be?
<antivirtel> Bazaar Explorer
<antivirtel> :D
<AuroraBorealis> yeah
<Noldorin> hi jelmer
<AuroraBorealis> i mean, i have a branch on my server, and then i 'branch' it to my computer, then bind it back to the remote one
<jelmer> hey Noldorin
<AuroraBorealis> so that way it acts kinda like a centralized branch
<Noldorin> jelmer: how's co-located branch support going? :-)
<Noldorin> jelmer: i hear 2.5b1 will be out soon...and LP support for co-located branches in coming too?
<jelmer> Noldorin: yeah, launchpad should support importing colocated git and mercurial branches soon
<Noldorin> jelmer: awesome...what about exporting?
<jelmer> Noldorin: exporting too
<Noldorin> i guess that just requires it to support colocated bzr branches
<Noldorin> right?
<Noldorin> i have to do the dpush manually myself
<jelmer> yeah
<vila> jelmer: about to EOD, but: http://babune.ladeuil.net:24842/job/selftest-subset-hardy/85/console
<vila> jelmer: i.e. adding the missing patches (compared to cat), no failures, even with 2 procs
<Noldorin> jelmer: sounds good. timeframe for 2.5b1 is early-mid september, right?
<Noldorin> and launchpad when?
<jelmer> vila: :-/
<jelmer> vila: Thanks for running that, btw!
<jelmer> Noldorin: Launchpad probably next week
<Noldorin> cool.
<Noldorin> 2.5b1 same time then?
<Noldorin> jelmer: would that be on edge or normal LP?
<jelmer> Noldorin: edge is no more
<jelmer> Noldorin: I have no idea about bzr 2.5b1
<jelmer> Noldorin: it would be production. launchpad is deploying every couple of days now, so once something lands it gets to production quickly
<Noldorin> jelmer: oh cool....yeah, i haven't used edge in ages, so no wonder
<Noldorin> jelmer: well the 2.5b1 milestone says september 7th i think ... :)
<jelmer> Noldorin: ah, ok
<Noldorin> jelmer: i will have a look at sorting out that bzr-git error i was having, now i am back from hols
<Noldorin> mabye you can include a fix in next release
<jelmer> Noldorin: cool; if there's anything I can help with, let me know
<Noldorin> thanks
<Noldorin> it will be over the next few days most likely..
<Noldorin> jelmer: also, will LP ever get auto-dpush to git/hg branches you think?
<jelmer> Noldorin: Personally, I think it would be more likely it would run the equivalent of "bzr serve --git"
<Noldorin> jelmer: oh wow, i didn't know bzr had 'server' now... must have come recently. works like hg serve?
<mgz> ...since when has the contributor agreement required printing out a pdf and scanning it back in?
<Noldorin> well that would be cool. would still require github to auto-import though....
<mgz> did someone decide it wasn't quite hostile enough to casual contributors?
<jelmer> Noldorin: "bzr serve" has been present for years. bzr-git adds the --git option
<Noldorin> oh
<jelmer> hi mgz
<Noldorin> jelmer: it surely came after Hg serve though... i remember trying both at one point and bzr not supporting :S
<Noldorin> jelmer: the problem is github is not likely to get bzr importing any time soon though...
<AuroraBorealis> the bzr serve documentation is prettymuch not existant
<AuroraBorealis> thats probably why you have not heard about it.
<Noldorin> ah right
<jelmer> Noldorin: it was introduced in bzr 0.11, apparently
<Noldorin> lies!
<Noldorin> i remember trying it
<Noldorin> and saying it's not supported
<Noldorin> :S
<Noldorin> maybe not on windows
<Noldorin> very odd
<AuroraBorealis> but still, someone needs to write docs for it
<Noldorin> indeed
<jelmer> AuroraBorealis: http://doc.bazaar.canonical.com/latest/en/user-guide/server.html
<jelmer> but I guess it isn't really easy to find at the moment
<AuroraBorealis> thats pretty thin :>
<AuroraBorealis> what are the operations that are 'improved' by a smart server?
<AuroraBorealis> there is only one option specified, are there more? etc
<Noldorin> brb
<AuroraBorealis> does this work for all operating systems? these are the questions i was asking myself when i was looking at this a while ago
<jelmer> AuroraBorealis: most operations become faster when used over the smart server, but it's the same set
<AuroraBorealis> well, i'm just saying that the doc says The high-performance smart server (hpss) performs certain operations much faster than dumb servers are capable of. In future releases, the range of operations that are improved by using the smart server will increase as we continue to tune performance.
<AuroraBorealis> i dunno, showing the time with a smart server vs dumb server would be useful
 * jelmer files a bug about the smart server docs
<AuroraBorealis> and another big thing: authentication
<jelmer> AuroraBorealis: Authentication is not yet supported using "bzr serve", only over http (or when tunneled over ssh)
<jelmer> AuroraBorealis: that would indeed be good to mention though
<AuroraBorealis> i read somewhere that it doesn't really want to support authentication, and to do it you just use ssh?
<jelmer> AuroraBorealis: yep
<jelmer> vila: hmm
<jelmer> vila: failed again, with two different tests
<AuroraBorealis> and jelmer, where is the bug you just submitted about the docs?
<jelmer> AuroraBorealis: bug 836812
<ubot5> Launchpad bug 836812 in Bazaar "mention authentication in "bzr serve" docs" [Medium,Confirmed] https://launchpad.net/bugs/836812
<jelmer> AuroraBorealis: and bug 836815
<ubot5> Launchpad bug 836815 in Bazaar ""bzr serve" documentation is vague about what operations are quicker" [Medium,Confirmed] https://launchpad.net/bugs/836815
<AuroraBorealis> kk =)
<jelmer> AuroraBorealis: I don't think documentation is the right place to put benchmarks
<AuroraBorealis> it would be nice to have them somewhere, even if the docs link to them
<jelmer> AuroraBorealis: I'd rather just mention the smart server is quicker without getting into too many times quicker it is. There are a lot of factors involved.
<AuroraBorealis> that works
<AuroraBorealis> point is, that documentation is a bit lacking, which someone needs to fix. i could try and see if i can improve it, but like the other thing i'm working on, i need to take time to learn about it first
<jelmer> AuroraBorealis: M
<AuroraBorealis> m? o.o
<jelmer> AuroraBorealis: filing bugs about holes in the documentation is a great start, and thanks for bringing up the topic of the "bzr serve" docs here
<jelmer> AuroraBorealis: I guess it's one of these things you don't realize if you're familiar with the code already...
<AuroraBorealis> yeah haha
<jelmer> abentley: will you propose a merge of the bzrtools branches code into bzrlib or should I ?
<abentley> jelmer: probably best if you do it.
<jelmer> abentley: sure, will do
<ovnicraft> hello why trying to branch a project from LP i get an error about permission denied
<ovnicraft> ?
<ovnicraft> l login w/ bzr
<ovnicraft> then try to branch or pull and give the error
<ovnicraft> ?
<ovnicraft> any help around ?
<beuno> ovnicraft, can you pastebin the full output?
<ovnicraft> beuno, http://pastebin.com/Kwm72xqQ after bzr pull
<beuno> ovnicraft, and you're part of the OpenERP team?
<ovnicraft> beuno, not but to branch i guess is not necessary
<beuno> ovnicraft, no. What command are you using?
<ovnicraft> bzr pull
<ovnicraft> just to pull changes from LP i branch it before
<maxb> You should either sort out your ssh authentication to launchpad, or fall back to using anonymous http access
<ovnicraft> maxb, how i can use anonymous http access to branch ?
<maxb> Change the URL to an http: rather than bzr+ssh: one
<ovnicraft> maxb, if i pulled it via ssh it will works w/ change ?
<beuno> so bzr pull http://bazaar.launchpad.net/%2Bbranch/openobject-client-web/6.0/ --remember
<ovnicraft> beuno, bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/%2Bbranch/openobject-client-web/6.0/"
<beuno> ah
<beuno> ok
<beuno> so the url has to be constructed differently
<ovnicraft> how can i identify how construct the URL?
<jelmer> ovnicraft: try "bzr pull --remember lp:openobject-client-web/6.0"
<ovnicraft> jelmer, i think it will try ssh
<jelmer> ovnicraft: can you access other branches over ssh?
<ovnicraft> jelmer, no
<jelmer> ovnicraft: Do you have a ssh key uploaded to Launchpad?
<ovnicraft> si i dont know why? i understand projects are configured to required it
<ovnicraft> yes i  am openerp commiter
<ovnicraft> but in that project i dont commit
<ovnicraft> i just want to pull
<jelmer> ovnicraft: if you logged in use "bzr lp-login" then any access to lp: branches will try to use ssh
<jelmer> *using
<ovnicraft> jelmer, how i 'logout' with bzr ?
<jelmer> ovnicraft: bzr config --remove launchpad_username
<ovnicraft> jelmer, i get 2.1.4 version i dont get config ?
<jelmer> ovnicraft: ah, no. It doesn't exist in 2.1.4 yet. You can manually edit ~/.bazaar/bazaar.conf though.
<ovnicraft> jelmer, thanks !
<maxb> It should be noted that the smart server accessible via SSH is a considerably more optimal way for Bazaar to communicate than the dumb HTTP transport.
<maxb> For the sake of your time and bandwidth, it may still be worth fixing your SSH setup
<jelmer> launchpad really should allow anonymous access over ssh
<vila> jelmer: /me nods, read-only anonymous access
<vila> jam: any issue with building the 2.4.0 windows installers ?
<croddy> is there a FAQ i can read? i did not find what i was looking for in the answers app
<jelmer> croddy: the FAQs should all be on the answers page on launchpad
<croddy> thanks
<jelmer> croddy: you're always welcome to ask here, or open a new question on launchpad
<jderose> hi, is there a way to get the diff of a single file between 2 branches?
<jderose> i'm trying to narrow down the changes in couchdb between natty and oneric. i know how to do this:
<jderose> bzr diff --old=../natty/
<jderose> but that's a 20k line diff, mostly autotools generated stuff.... but i'd like to easy look at a single file, like just Makefile.in
<spiv> jderose: bzr diff -rbranch:../natty FILE
<spiv> IIRC
<jderose> spiv: ooo, fancy! thanks!
#bzr 2011-08-30
<jam> vila: no issues building the installers, I just haven't tried yet
<vila> jam: do you plan to try soon or should I announce 2.4.0 without them ?
<vila> hi all !
<vila> poolie: regarding HTTPErrors on jubany, here is an interesting one: http://paste.ubuntu.com/677730
<poolie> hi vila, jam
<poolie> hi vila
<jam> hi poolie
<jam> so... interesting news about fdatasync
<vila> poolie: hey
<poolie> i think i know what's happening there, which is that it's getting None for one of the branches so lp rejects the attempt to file an mp
<jam> test suite w/fdatasync 3h35min, hacking it out, 1h35min
<jam> still not as fast as bzr-2.3's 45min
<poolie> locally? or on pqm?
<jam> poolie: on pqm
<jam> so there is more going on than just fdatasync
<poolie> that's about what i would expect
<poolie> right
<jam> but it is clearly part of it
<poolie> i wonder if it's failing to load some extensions?
<jam> poolie: doesn't that issue warnings, and we use -Werror ?
<poolie> it's just kind of a shot in the dark about what could cause such a large slowdown
<poolie> do we know anything about the relative timing of particular tests?
<jam> poolie: yeah, the difference w/ 2.3 was where I was going to focus
<jam> poolie: we could do a failing pqm run that doesn't filter out successes, and we would get back a subunit stream containing all the timings
<jam> 2.4 has a few more tests, 26.3k vs 24.7k than 2.3
<jam> I doubt that accounts for doubling the time, though
<jam> poolie: I'll try to find another quiescent time for PQM and put another couple of test runs through
<poolie> you can also just ask the sysadmins to run something on that box
<poolie> i saw Sidnei wrote about having a tarmac-on-openstack set up for tarmac so i might try to convert that some time
<poolie> vila, that bug you mentioned with httperror i was going to keep tracking under the same number
<poolie> i fixed some of them but that's still a problem
<poolie> it's related to the Branch.getByURL call (that might not be the exact name)
<vila> poolie: not a bug, just something I caught while monitoring jubany after deploying bzr-builddeb yesterday
<poolie> it is a bug
<vila> right
<vila> what I mean is that I've seen different outputs usually, this one was mentioning something different (the missing branch)
<vila> ... and I didn't file a new bug before mentioning it to you, should I ?
<vila> so s/not a bug/not *yet* a bug/
<vila> jam: do you plan to try building the windows installers soon or should I announce 2.4.0 without them ?
<jam> vila: I'm working on them as we chat
<vila> jam: great, waiting for your feedback to do the announcement
<jam> anyone know if qbzr-0.21 is still the right version to build with?
<jam> there seems to be an 0.21.1, I'll go with that
<jam> though I think there was supposed to be a 0.21.2 coming soon
<vila> maxb: do you plan to upload bzr-svn-1.1.0 to the stable ppa ?
<poolie> are you ready to mumble?
<fullermd> Speaking of qbzr, is it just me or does it still completely hork the test suite on .dev?
<fullermd> ...  and of course, it figures I say that right before firing off a pull that gets the rev that fixes it...
<jam> poolie: I believe that has to be spelled "muuuummmbbbbbbbbllllllee" ?
 * fullermd sighs.
<jam> poolie: http://www.youtube.com/watch?v=WvufFwdqMzg&feature=player_detailpage#t=53s
<jam> but yes, I'm logged in
<poolie> yep
<jam> Or maybe "LETS GET READY TO *mumble*"
<jam> vila: it says it will be 20min for it to copy down to me, and then 5-10 min for me to upload them to launchpad
<jam> but -1 is built
<jam> vila: windows installers have been uploaded and announced
<vila> jam: thanks
<poolie> Riddell, so can people actually get into translating bzr now?
<poolie> i thought perhaps you should send an update on the state of i18n - perhaps it's better to wait until it's live though
<Riddell> you go to https://translations.launchpad.net/bzr and do the translation
<Riddell> it's set to restricted so you have to be an approved translator
<Riddell> I can e-mail the translators list and bazaar list to announce that
<jam> poolie: https://code.launchpad.net/~hid-iwata/bzr/fix-827721/+merge/73125 I don't know if you saw that I already made the fix, but accidentally submitted it to trunk instead of 2.4
<jam> I'm guessing you did the same fix?
<poolie> i saw a comment about that
<poolie> i sent just a correction of his patch to 2.4
<poolie> did you fix it in a substantially different way?
<jam> poolie: I just indented by 1 space
<poolie> that's what i did too
<poolie> it's running on jubany now
<poolie> *bellany
<jam> poolie: well, jubany does have better hardware, maybe we could install PQM and.... :)
<jelmer> jam: I'm looking at my bzr/move-hashcache branch; is it correct that just WT2 and WT3 use the hashcache?
<jam> yes
<jam> the cache is in the Dirstate for WT4+
<poolie> ok i'm going to sign off
<poolie> vila, if you commit that fix to trunk it should automatically get onto docs.b.c.c
<vila> poolie: yup, I know, submitting to pqm
<vila> poolie: grepping 2\.4 I found some references to python-2.4 that we don't support anymore, I'll file a bug for that as several docs needs a deeper fix
<jam> jelmer: rather than resubmit, I think just marking your submission back to NeedsReview
<jam> at least for me, it means that email threads get put on the right submission, etc.
<jam> like I *just* commented on the last one
<jelmer> ah, hmm
<jelmer> with some projects I find that reviewers ignore MPs that already have votes on them
<jam> jelmer: well, I just ignore everything you submit regardless :)
<fullermd> jam: Ignore who?  ;p
<jam> jelmer: I supposed it is project dependent. I do a lot of processing merge requests via email vs the web ui
<jam> and often keep "unread" things that are in queue to reviewe
<jam> unfortunately, LP does *not* link emails across resubmissions
<jam> so it starts a new email thread
<jam> and doesn't have a "this proposal has been superseded" email
<jam> in this particular case, it looks like we raced
<jam> where I was in the web app commenting, and you were resubmitting.
<jelmer> jam: Clearly the workflow isn't optimal yet :) I'm happy to just change the MP status for bzr though
<jam> for bzr, I would probably resubmit if there has been a long discussion that is now only partly relevant due to large changes
<vila> jam: additionally when you review via mail CC'ing the submitter, the submitter gets two mails, one of them without the lp links and headers which also break threading
<jelmer> jam: also, we don't always change the MP status when we vote so there's no way to indicate a MP is ready for another review
<jelmer> e.g. https://code.launchpad.net/~jelmer/bzr/move-hashcache/+merge/73299
<jam> sure, but you can also just *say* "ready for re-review"
<vila> jelmer: you can request an additional review from the web ui, which should send emails
<vila> jelmer: I did that yesterday for https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/72451 and got an email with the updated diff AFAICS
<jam> vila: yeah, but then jelmer resubmitted it as well :)
<jelmer> jam, vila: neither of those makes it easy to see what needs another review on the +activereviews page
<vila> jelmer: true :-/
<jelmer> anyway, I wasn't trying to be a pedant..
<jam> jelmer: *everything* needs review if it is still on that page
<jam> that page should always be pushed to 0
<jam> IMO
<jam> though yes, some with more or less priority
<jam> which isn't particularly easy to see
<jam> though, even when used "correctly" it isn't very easy to see
<vila> jelmer: I don't think you were
<jelmer> vila: several of the recent problems building against 2.4 seem fail because of the safety net
<jelmer> grmbl
<jelmer> vila: several of the recent problems building against 2.4 seem be because of the safety net
<jelmer> vila: e.g. https://launchpadlibrarian.net/78535248/buildlog_ubuntu-oneiric-i386.trac-bzr_0.4.2%2Bbzr117~ppa34~oneiric1_FAILEDTOBUILD.txt.gz
<jelmer> do you have any idea what might be causing that? It seems to be some weird interaction with fakeroot (which LD_PRELOADs and pretends the currents uid is 0)
<vila> jelmer: failing to call setUp for the parent class ?
<jelmer> it succeeds when not run under nosetests
<jelmer> argh, when not run under fakeroot
<jelmer> and as far as I can tell setUp() gets called where necessary
<vila> hmm, doesn't explain the attributeerror...
<vila> _SAFETY_NET_PRISTINE_DIRSTATE was introduced recently, let me check
<vila> created in _check_safety_net, called by _make_test_root
<vila> there is a comment there about tricky test dir on OSX,
<vila> the issue there was that /tmp is redirected to /private/tmp
<vila> jelmer: could it be that fakeroot is doing some trick too about /tmp ?
<vila> not that it would explain the AttributeError either...
<jelmer> vila: well, it pretends the owner of all files is root.root, for /tmp too.
<vila> brain dumping,
<vila> we had issues related to tests run as root, we had issues related to a very early failure with the test root not being properly created or something
<jelmer> fwiw the debian packages have always been using fakeroot, but this issue has only come up recently
<vila> jelmer: recently << 2011-07-11 ?
<jelmer> vila: I'm also surprised it's trying to access /root/.bazaar/locations.conf
<vila> jelmer: $HOME == /root ?
<jelmer> vila: nope, HOME=/home/jelmer
<vila> wow, test isolation
<jelmer> although getpwuid(0).pwd_home is /root
<vila> HOME is not set I presume, fallback to python whatever
<jelmer> in fact, it seems that if I change the home directory of root in /etc/passwd the tests all pass..
<vila> yup, python is getting there to get the home if nothing else is available
<jelmer> so the _SAFETY_NET_PRISTINE_DIRSTATE issue is a red herring
<vila> known issue
<vila> not sure they are related
<jelmer> vila: it looks like it's now reading the config because it wants to know if it should fdatasync, perhaps it wasn't doing that previously
<jelmer> vila: is the safety net perhaps created before BZR_HOME is overridden?
<vila> for the config stuff, yes, it wasn't and it's related to finding HOME from /etc/passwd and is a test isolation issue
<jelmer> because creating the safety net involves creating a tree, and that involves reading the config
<vila> yup
<vila> oh, and some exception is lost ?
<vila> so we miss the safety net not being created ?
<jelmer> vila: if creating the safety net fails then the exception is masked by the fact that the teardown fails, because we haven't set _SAFETY_NET_PRISTINE_DIRSTATE yet at that point
<vila> urgh, http://paste.ubuntu.com/677867 , indeed the safety net is created before overriding the env for tests
<vila> jelmer: in the short term, can you try a way to run selftest in a context where bzr *can* read its config files ?
<vila> s/try/find/
<vila> jelmer: like... BZR_HOME=<valid home> may be ?
<vila> jelmer: valid here doesn't imply there is a .bazaar dir, just that we get File not found instead of permission denied
<vila> alternatively we should catch permission denied and handle it as meaning we can't read the config files
<jelmer> vila: overriding the environment variables doesn't seem to work :(
<vila> may be fakeroot filters it ?
<jelmer> vila: nope
<vila> jelmer: hmm, does os.path.isfile(infile) raises permission denied ?
<vila> s/s//
<jelmer> it returns False
<jelmer> vila: still, that seems like the wrong thing to do. We shouldn't be reading the users' config
<vila> jelmer: configobj uses this to decide if the file exists
<vila> jelmer: why ?
<vila> jelmer: we're not *in* the test at this point, we are still in the user context setting up the test environment
<jelmer> vila: this is for the test setup, we shouldn't be using the users preferences for the repository we're going to use for testing
<vila> jelmer: we obey TMP
<vila> which is part of the user env
<jelmer> vila: sure, but this means you could get varying test results based on what the user has in ~/.bazaar/bazaar.conf
<vila> no, because we take care of that just after
<vila> but I think I've found the hole
<vila> TestCase.setUp has been called and there we clear BZR_HOME
<vila> jelmer: try moving _make_test_root *before* the upcall to setUp() ? (May not be enough)
<jelmer> AttributeError: 'TestRepository' object has no attribute '_bzr_selftest_roots'
<jelmer> vila: where do we reset the standalone working tree so it isn't affected by the users settings?
<vila> I don't follow
<vila> the safety net is supposed to be created... above the test dirs
<vila> the tests have no idea it exists
<jelmer> vila: ah, nevermind.. I see we just use bzrdir.BzrDir.create_standalone_workingtree() to get at the dirstate bytes
<vila> jelmer: try commenting out the calls to _create_safety_net and _check_safety_net
<jelmer> vila: that does mean we try to read ~/.bazaar/bazaar.conf for every test though, doesn't it?
<vila> yes, that's the main issue related to config in the fdatasync patch
<jam> vila, jelmer: We only create the safety net once per test suite run, right?
<jelmer> does remembering the raw bytes of the dirstate file really gain us all that much speed?
<jam> we just check it on every test
<jam> jelmer: spiv commented it was about 15% of the run speed for the whole test suite
<jam> so... yes
<jelmer> jam: yeah, I guess I'm just seeing it being executed multiple times because its setup fails
<jam> jelmer: the point of that code was we *used* to have a real problem with a test case not isolating itself from the environment
<jam> hence you can do "bzr log -r revid:A"
<jam> in bzr.dev
<jam> It honestly hasn't been a problem for a while, but perhaps that is because it gets caught easily. I would venture it is because TestCaseInTempDir/MemoryTransport et al make it easy to just inherit a base that is env safe
<jam> I think vila already submitted a bug that if _create_safety_net fails, it should just abort the test suite
<jam> rather than fail 20k times
<vila> https://bugs.launchpad.net/bzr/+bug/825027
<ubot5> Ubuntu bug 825027 in Bazaar "create_safety_net is brittle" [High,Confirmed]
<jam> vila, jelmer, Riddell: I'd like to do some more PQM timing runs, but I want to make sure not to block anything. Is there a reasonable time for me to do it?
<vila> jam: thanks !
<vila> jelmer: doh, but you *did* comment on this one !
<spiv> jam, jelmer: IIRC by reading the raw bytes we skipped open_workingtree and that in turn skipped reading all bazaar.conf and locations.conf
<vila> spiv: right, but the issue here is when *creating* the wt
<jelmer> jam: as long as you don't approve any MPs you should be good ;)
<jam> jelmer: k, I'll make sure to reject all patches. :)
<jam> jelmer: it is more "is there stuff you want to see land soon that hasn't been approved so I'll wait"
<vila> jam: fine with me, I'm finishing the announcement for 2.4
<spiv> (Because it is the safety net, not some wt inside it, that means reading the users real ~/.bazaar/locations.conf, etc)
<jam> we already have a Q depth of 4
<jelmer> jam: I figured :) Nothing from me.
<jam> hi spiv! good to see you around, btw
<jam> jelmer: is it "_create_safety_net" or "_check_safety_net" that is cousing problems for bzr-cia?
<vila> jam: i.e. nothing urgent from me, the one waiting can even be canceled (but let me know as it was a pqm-submit one)
<spiv> jam: thanks :)
<jam> vila: I have a strong suspicion that our current Q is going to overflow for at least today.
<vila> jam, jelmer: I suspect it's create_safety_net and the exception is caught
<jam> 4*2.5 is already 10 hours
<spiv> jam: If the Q overflows, I guess that makes it an R
<jam> spiv: I'm pretty sure it becomes QQ
<vila> jam: yeah, debugging a live pqm is not fun
<vila> jam: which is why I postponed it :)
<jam> spiv: from: http://www.urbandictionary.com/define.php?term=less%20qq%20more%20pew%20pew
<spiv> jam: two Qs?  Too cute :P
<jelmer> vila,jam: it's _create_safety_net (but that gets called by _check_safety_net)
<jam> spiv: It symbolizes tears coming out of eyes
<vila> jelmer: I don't think we reach that call
<jam> vila: we do if it is failing
<vila> jam: we get an AttributeError on _SAFETY_NET_PRISTINE_DIRSTATE so we don't reach it
<jam> ah
<jelmer> yeah, that's true
<jelmer> because _create_safety_net raised an exception
 * jelmer 's head spins
<vila> jelmer: try commenting out create/check safety_net
<vila> calls
<vila> safety net and permit_url kind of overlap in both their implementations and intents, in your case, if you don't get failures with safety net outside of fakeroot, then it's probably safe to disable it
<jelmer> yeah, that's fine (apart from a test isolation error because BzrDir browses up too far in the fs)
<spiv> jam: QQ makes me think of pearl tea (http://en.wikipedia.org/wiki/Bubble_tea), there's a tea place I used to go to that lists the tapioca balls on the menu as QQ.
<vila> "browses up too far in the fs" is a hard one
<jelmer> vila: could we just temporarily monkey patch config_dir in _create_safety_net ?
<jam> jelmer: http://paste.ubuntu.com/677891/
<vila> pfew, to which value ?
<vila> jam: that would make the test suite fails for jelmer, he is trying to get a successful run (or it could just not run it all otherwise)
<vila> s/it could/he could/
<jam> vila: well fix #1, if we can't set up, stop running the rest of the tests
<jam> fix #2, make it so we can run
<jelmer> jam: thanks, that would at least make it fail sensibly
<vila> jam: right, that's what bug #825027 is about
<ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [High,Confirmed] https://launchpad.net/bugs/825027
<jam> jelmer: I think there should be a better way, integrating it with our test suite runner, etc.
<jelmer> vila: set BZR_HOME to e.g. TestCaseWithMemoryTransport.TEST_ROOT while we run create_standalone_workingtree
<jelmer> vila: we don't care if that location doesn't exist
<vila> jelmer: yup, should work
<jam> jelmer: can you paste the actual traceback somewhere?
<jelmer> jam: http://pastebin.ubuntu.com/677896/
<jelmer> that's with a slight change to _check_safety_net to use getattr to get at _SAFETY_NET_PRISTINE_DIRSTATE
<jam> jelmer: well, I would say that if config gets PermissionDenied, it should just accept it and treat it as though the file doesn't exist
<jam> jelmer: by the time we get to _check* we should always have _SAFETY_NET set
 * jelmer looks at vila
<vila> <vila> alternatively we should catch permission denied and handle it as meaning we can't read the config files
<jelmer> jam: Perhaps we should just warn ?
<jam> jelmer: looking at the traceback you posted, it is clearly during "_make_test_root" not during "_check_safety_net"
<jelmer> that works for me I guess
<jam> jelmer: I could consider warning.
<jelmer> jam: If I don't make that slight change to _check_safety_net then I get an attributeerror from _check_safety_net.
<jam> jelmer: I'm thinking you're getting that after the previous failure, during tear-down time
<jelmer> jam: yes, I am
<jam> so setUp() fails, then we always run tearDown() and *it* fails
<jelmer> jam: that attributeerror is a red herring, but that's why I mentioned _check_safety_net in that bug report
<jam> sure
<jelmer> cool
<jam> jelmer: is bug #835183 actually fixeD?
<ubot5> Launchpad bug 835183 in Bazaar "bzr-svn 1.1.0 from daily PPA does not install with bzr 2.5.0 from same repository" [Undecided,New] https://launchpad.net/bugs/835183
<jelmer> jam: not yet - the right packages are available from the daily PPA but not from the regular PPA
<jam> jelmer: the bug at least claims to be the daily
<jam> "bzr-svn from bzr-daily repo doesn't install with bzr  from the same repo"
<jelmer> jam: in that case it might be a different one than I was thinking about
<jam> which is why I'm confused that you saying "use the daily repo" and he claimed it was fixed
<jelmer> jam: marked fixed, thanks for the pointer
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr/config-file-permdenied/+merge/73361
<vila> jelmer: cough, configobj based configs doesn't have the issue and TransportConfig is not involved either in your case
<vila> jelmer: the bug is that configobj uses os.path.isfile and doesn't see the permission denied while config.IniFileStore traps only NoSuchFile and should also catch permission denied
<jelmer> vila: updated
<jelmer> (and confirmed working against tracbzr)
<grumbel> I have here a bzr repository (based on a svn repo) with some user created changes, I (the one with write access to the SVN) want to merge those changes back into the main svn repository. How would I do that?
<jelmer> grumbel: if you have a checkout, it should just be a matter of running "bzr commit"
<jelmer> grumbel: if you have a standalone branch that's derived from the svn branch, commit and push back
<grumbel> jelmer: confusing part for me right now is that the bzr repository (not mine) is against anon-svn, while I would need to commit to the non-anon svn, which has a different URL
<jelmer> grumbel: if the bzr branch is standalone it should just be a matter of pushing
<jelmer> and specifying the non-anon URL to "bzr push"
<vila> jelmer: BB:tweak, can you check that my tweak still works for tracbzr ?
<vila> jelmer: finally, don't we want that for 2.4 ?
<jelmer> vila: either works for me; I'll have to ship it as a Debian patch anyway. I'm not sure if it's big enough of an issue for other users.
<vila> jelmer: wfm
<vila> jelmer: and sorry for the trouble, I should have thought about bug #825027 earlier :-/
<ubot5> Launchpad bug 825027 in Bazaar "create_safety_net is brittle" [High,Confirmed] https://launchpad.net/bugs/825027
<jelmer> vila: thanks for the review, I'll submit to PQM after John is done
<jelmer> vila: no worries, it's pretty hard to recognize what it breaks without knowing the exact cause
<vila> jelmer: where is fakeroot used in the whole bzr ecosystem ?
<jelmer> vila: it's used by pretty much all debian packages when building
<vila> jelmer: including ubuntu packages you mean ?
<jelmer> vila: yep
<vila> weird that we didn't encountered sooner...
<jelmer> vila: it only happens if there actually is a /root directory - on most build hosts there isn't
<vila> oh my...
<vila> jelmer: and 'fakeroot -u' is not applicable ?
<jelmer> nope
<jelmer> vila: the idea is that when installing binaries they don't end up being owned by some random uid
<vila> ok
<vila> it's still weird to pretend to be root while not allowing to read config files though, but well, I can't see how to fix that anyway
<vila> jelmer: ha, no, you mentioned the right fix earlier I think: force BZR_HOME to an existing place while creating the safety net, I'll add that to the brittle safety net bug
<jelmer> vila: thanks!
<jelmer> Speaking of weird FTBFS errors..
<jelmer>   File "/usr/lib/python2.7/dist-packages/bzrlib/osutils.py", line 822, in compact_date
<jelmer>     return time.strftime('%Y%m%d%H%M%S', time.gmtime(when))
<jelmer> ValueError: timestamp out of range for platform time_t
<vila> 8-(
<jelmer> my thoughts exactly
<jam> jelmer: clearly 'when' is negative?
<jam> or a BIGINT
<jam> I wonder if you need (time.gmtime(int(when))) or something
<jelmer> jam: yeah, it's probably something like that
<jam> the fact that it says out-of-range seems very strange
<jelmer> it's also something that only occurs on the buildds
<jelmer> anyway, I'll dig deeper
<jelmer> it just seems like *somebody* forgot to tell me that today is weird FTBFS day.
<jam> jelmer: didn't they just do an oneiric "rebuild" which causes everything to break?
<jelmer> jam: yeah, but usually that just results in one or two plugin packages that happen to still call a method that has been removed from bzrlib
<jam> jelmer: https://code.launchpad.net/~jelmer/bzr/move-hashcache/+merge/73299
<jam> appears to be duplicating _write_hashcache_if_dirty
<vila> jelmer: today is weird FTBFS day.
<jam> anyway, not to distract you from what you're up to
<jelmer> jam: it is - rather than using hashcache in the base class it makes WT2 and WT3 use it explicitly
<jelmer> I could've made that clearer in the comments.
 * jelmer adds a comment
<jam> jelmer: is it possible to unify them, such as by just having a non-class attribute, or an extra base class. It is a real pain to track down and fix a bug in duplicated code.
<jam> like NonDirstateWorkingTree or something
<jelmer> jam: yeah, it's always a tradeoff I guess. I'd be happy to add a base class
<jam> jelmer: I know it is old code that doesn't get touched much, but that's also why I'd like to not make it harder to support
<vila> jam: that's what I was trying to convey when I asked you that follow-up about get_parent_map :)
<jam> vila: except in my case there isn't code duplication, which is what I told you
<jam> it isn't copy and paste code, it is take data from a different format and extract it for the api
<vila> doesn't make the maintenance easier
<jam> It is a "give me data" interface, but there isn't a simple corresponding "insert data" interface
<vila> that's true
<vila> but that can be addressed for the tests
<vila> jelmer: do you have an easy way to test the build failure (without your patch for permission denied) ?
<jelmer> vila: yeah
<vila> jelmer: http://paste.ubuntu.com/677992/
<vila> jelmer: bah, waitasec
<jelmer> NoSuchFile: No such file: u'/tmp/testbzr-BmUC0T.tmp/.bzr/checkout/dirstate': [Errno 2] No such file or directory: u'/tmp/testbzr-BmUC0T.tmp/.bzr/checkout/dirstate'
<vila> jelmer: http://paste.ubuntu.com/677995/ the previous one was blatently bogus
<vila> or did you fix it yourself ?
<jelmer> vila: "1". Really?
<vila> for os.exit ? you prefer -1 ?
<jelmer> vila: see that pastebin :)
<vila> LOL
<vila> pastebinit epic failure :)
<vila> jelmer: http://paste.ubuntu.com/677998
<jelmer> vila: that works
<vila> ha, gooood, now, can I add tests for that...
<vila> jelmer: just checking by "works" you mean the test pass not that we abort at the first one right ?
<jelmer> vila: yep
<vila> jelmer: speaking of weird cases, something happens in a try: tree.lock_write() /finally: tree.unlock() that leaves a broken lock, what can 'something' be ?
<vila> jelmer: some failed imports can't be requeued without breaking these locks manually which is.. disruptive ;)
<jelmer> vila: hmm, not sure either :/
<vila> an unmatched lock/unlock ?
<vila> unlikely
<jelmer> could be, I guess
<vila> and we get a traceback... so the finally clause should be obeyed...
<lamalex> hi, so bzr status only showed 2 unknown files, so i can bzr add. and it added a fucking ton of other files. is there a sane way to remove them without losing all of the changes i had in my tree?
<LeoNerd> bzr rm --keep path/to/file   will forget an 'add'
<jelmer> lamalex: what kind of files did it add that "bzr status" didn't show?
<lamalex> jelmer, build files
<lamalex> can i bzr ignore build/ and have it disregard the add?
<lamalex> ha oh LeoNerd bzr rm --keep worked great
<jelmer> lamalex: yes, "bzr add" (without arguments) will ignore files that are in .bzrignore
<jelmer> lamalex: if you explicitly specify files it will add them regardless of whether they are in .bzrignore
<lamalex> yah
<lamalex> thanks
<lamalex> does anyone know of a good tutorial on bzr pipelines and bzr colo
<lamalex> i keep finding myself in space where i think i would really benefit from the workflow
<lamalex> but i can't find good docs about really how people use it
<lamalex> thumper, ^ don't you use these things?
<AuroraBorealis> is launchpadlibrarian slow as hell to anyone?
<AuroraBorealis> im downloading at 2 kb/s
<Quintasan> jelmer: http://paste.kde.org/116311 <-- any idea about that? recipe file: http://paste.kde.org/116317
<thumper> lamalex: yes, I use pipelines
<jelmer> Quintasan: sorry, was out. I'll have a look now
<Quintasan> jelmer: Thanks
<jelmer> Quintasan: can you run this: python -c 'from bzrlib.plugins.builder.cmds import get_maintainer; print get_maintainer()'
<Quintasan> ('Micha\xc5\x82 Zaj\xc4\x85c', 'quintasan@kubuntu.org')
<jelmer> Quintasan: bzr-builder needs to be calling .decode on that since python-debian (now?) uses unicode for changelogs
<jelmer> Quintasan: can you file a bug?
<Quintasan> jelmer: against bzr?
<jelmer> Quintasan: against bzr-builder
<Quintasan> jelmer: https://bugs.launchpad.net/bzr-builder/+bug/837741
<ubot5> Ubuntu bug 837741 in bzr-builder "bzr-builder has to call .decode on get_maintainer() output" [Undecided,New]
<jelmer> Quintasan: thanks
 * jelmer wished he could triage bugs from IRC
<jelmer> Quintasan: setting DEBFULLNAME to something that only includes ascii characters should work around it for hte moment
<poolie> hi all
#bzr 2011-08-31
<poolie> hi all
<vila> hi all !
<mgz> morning vila!
<vila> mgz: hey !
<vila> mgz: I did comment on your mp but lp dropped my mail
<vila> mgz: td;lr : please land whatever you can
<vila> mgz: I share your curiosity about the consequences on pqm slowness
<mgz> I will merge up to dev and see where I'm at.
<vila> mgz: see my last comment on https://code.launchpad.net/~jelmer/bzr/config-file-permdenied/+merge/73361
<mgz> vila: that branch should just land, but there does need to be a bug at least, and maybe a comment there
<mgz> twas a comment, not a needsfixing
<vila> mgz: can you file it and comment on the proposal ?
<vila> yeah
<vila> hmm
<vila> mgz: is there an idiom we can use today that would avoid the mangling ?
<vila> mgz: because this patch calls trace.warning twice, but the second call hides the path shuffling into a method that already contains a semi related FIXME (config.Store.external_url)
<mgz> delay as long as possible, and keep the actual objects around to stringify when there's an output stream for them to go to
<mgz> the logging module doesn't help much here
<vila> hmm
<vila> we are calling trace.warning to output *now*, so basically you're saying that trace itself should provide some way to encode the path/urls properly ?
<mgz> but it's going to two places
<vila> oh my, right
<mgz> one, a file where we should (but don't really) enforce a utf-8 encoding
<mgz> and (possibly) one to the console
<vila> so what ? define and use .format() instead of '%' and inject some path/url specifier in the format string ?
<vila> and will that be enough to cover cases where the fs encoding and the terminal encoding can't both provide a meaningful representation of the path ?
<mgz> this is where knowing it's a path/url and not just some string is useful
<mgz> because then you can percent-escape and get a correct reference
<vila> percent-escape == url-encoded ?
<mgz> if you've already stringified and just have the message to output, there's no safe transform you can do to get a correct path back again
<vila> right, I agree that this is the root cause
<vila> and I'm not amused by the fact that jelmer used 'utf8' instead of fs encoding either ;)
<mgz> it's correct for the log, and his terminal :)
<jam> morning all
<jam> mgz: its correct for how the api of trace.note() and trace.warning() are currently defined.
<mgz> which is a bug.
<jam> mgz: I don't disagree, but it is not his place to fix it here
<jam> I've *personally* decided not to focus on the issue, because I think if you really wanted to help windows users, you'd be better of polishing something like bzr-explorer
<mgz> I don't think it is, but the line added will need changing when that bug is addressed.
<jam> rather than trying to handle the 5-different possible-non-unicode encodings Windows has
<jam> mgz: actually, if we just changed how trace.note/warning worked to have them write to the Windows Console Unicode api
<jam> then utf-8 is just fine
<jam> it can be trans-coded to UTF-16 losslessly
<jam> which is where I'd *much* rather see the fix
<vila> jam: hey !
<vila> jam: ping
<jam> vila: /wave
<vila> jam: what exactly do you require to approve this safety net is brittle patch to be approved without delaying it for weeks ?
<jam> vila: I thought I was clear about what I would like to see, a way to stop the test suite if a critical piece of infrastructure fails, that doesn't require us to kill the running process
<jam> I'm willing to hedge on it that sys.exit is the best we can get
<jam> it isn't playing nicely as a test suite, but it works fine for "bzr selftest"
<vila> but you objected on using it
<jam> vila " doesn't require killing the running process"
<jam> that would be sys.exit()
<jam> if someone uses another test runner, it will die on them which could be rather surprising.
<vila> you objected on using sys.exit(), I removed it, you object again
<jam> vila: #1) The original point is that we don't want 20k tests failing in the same way, right? Otherwise we would have left it at the status quo
<jam> I'm not trying to go in circles. I do have a position I would like to see, all of the alternatives seem sub-optimal for different reasons
<vila> doesn't apply to jelmer's case and for mthaddon's case we already have -1
<jam> so I'm a bit ambivalent about picking one
<vila> then let's land self.fail() and continue discussing 'FatalError' so we progress on both fronts
<jam> vila: if it doesn't apply to either case then why do we have a patch?
<jam> vila: good enough
<vila> both cases are addressed: we get a meaningful error, mthaddon's case is less well addressed but also highly unusual
<jam> vila: ISTR that jelmer was surprised to have so many tests failing, but sure
<vila> I think jelmer (and I and mthaddon) were all confused because the error was masked and as such made the diagnosis hard
<vila> the root of mthaddon case was: running as a user not declared in /etc/passwd. OMG ! How the hell do you end up in such a mess on a posix system ?
<vila> the root of jelmer case was: you pretend to be root, yet, you don't have rights to even read files in your home dir. wtf ?
<vila> jam: I totally see your point about FatalError, but we are playing tricks by handling a shared resource without telling the runner already, detangling that when a 10lines fix is available ? Worth the time ?
<jam> vila: well, I was hoping it wouldn't be a lot of time by asking people who knew more about it. Unfortunately, one just got engaged and the other is going to have a baby RSN
<vila> exactly
<vila> so better separate the issues
<vila> jam: do you mind voting on that proposal ?
<jam> voted
<jam> approve
<Riddell> morning all
<vila> jam: thanks !
<jam> morning Riddell
<vila> Riddell: _o/
<poolie> hello europa
<vila> poolie: hellllo AU :)
<jam> ih eiloop
<poolie> hi maj
<jam> (i couldn't easily write it upside down, so I wrote it backwards)
<vila> :)
<fullermd> Hello Ganymede?
<poolie> vila, re bug 837926
<ubot5> Launchpad bug 837926 in Bazaar "needs a way to get precise timings on pqm landings" [Medium,In progress] https://launchpad.net/bugs/837926
<poolie> don't the subunit streams have enough data?
<vila> poolie: only if you're the submitter
<poolie> so this bug could be caused by logging the output?
<poolie> *closed
<vila> poolie: https://code.launchpad.net/~vila/bzr/837926-log-make-check/+merge/73492 is a simple and pragmatic way to address it
<vila> poolie: I don't want to dive into solutions that requires modifying pqm or anything else, I just want a couple of `date` in the log files (which are already mirrored on chinstrap
<poolie> if that's enough that's fine with me
<poolie> hm
<poolie> well, approved
<vila> poolie: the '.bzr' invocation already redirects stderr, so I'm more comfortable with adding statements *around* its invocation that risking breaking it
<vila> poolie: thanks for the review !
<poolie> then time $(SHELL) -c './bzr ... '
<poolie> but, ok, i see your point abotu risk
<vila> poolie: re quoting, simple of double quotes ? (Can't remember which one is more likely to fail ;)
<poolie> failing and non-failing quotes? :)
<vila> bah, I'll just remove  the brackets and go with double ones ;)
<poolie> it seems to all be rediceted already
<poolie> also, i thought we got rid of the separate run in ascii mode?
<poolie> did that come back? perhaps that accounts for the slow down
<vila> poolie: only for 2.0
<poolie> oh, i hadn't noticed this was into 2.0
<poolie> though you do say so
<vila> gone in 2.1
<vila> 2.2 added subunit
<poolie> i'm a bit skeptical about changing this in old series
<vila> 2.3 added robustness
<vila> poolie: I can start anywhere you want, I'm mostly interested by 2.3/2.4/trunk myself
<poolie> so, changing this stuff has historically tended to throw up environment-dependent failures
<poolie> therefore i wouldn't change it in a stable series without a really good reason
<vila> right, me too,
<poolie> what are you actually going to do with this?
<vila> the effect should be seen when landing the patch itself, so either it works or it breaks
<poolie> that hasn't always been true in the past
<vila> sure, I don't mind starting at 2.4/trunk or even only trunk if you prefer
<vila> the intent is to get timings and a poor-man's monitoring
<poolie> i think just trunk
<vila> ok
<poolie> so are you hoping to find out that eg it's consistently slower, or it's very variable from one revision to the next, that sort of thing?
<vila> yeah, I don't have any pre-conception
<poolie> ok
<poolie> so i wouldn't like to break anything just for kind of snooping-around investigation
<poolie> sidnei sent me some tarmac/etc instructions which i hope to set up some time
<vila> poolie: I'll stop and revert on first sign of an issue, I swear ;)
<jam> vila: for the datestamp, would you want to use: `date "+%F %T"` ? It seems a bit easier to parse than just date
<poolie> or date -I
<poolie> sorry, -Isec
<jam> that works, too
<vila> jam: th... err, ok, we still have some time before pqm catches up ;)
<jam> poolie: odd, 'man date' doesn't seem to report it, but 'date' supports it
<vila> right, I was about to ask about portability :)
<poolie> you have no mandate! i demand a new election.
<fullermd> date: illegal option -- I
<poolie> it is a gnu extension
<vila> fullermd: does BSD use gnu date ?
<vila> osx doesn't
<Riddell> is there an equivalent in python of  isinstance(foo, function) ?
<poolie> is it a function?
<ccxCZ> you have callable()
<poolie> probably you want 'callable(foo)'
<jam> Riddell: do you want something like callable() ? which has been deprecated
<fullermd> Of course not!  We ain't lettin' no commie control something as important as time!
<poolie> :)
<jam> note that a Class that implements __call__ is 'callable()'
<jam> well, an object ...
<poolie> so it depends on exactyl what you meaon
<poolie> anyhow, i should stop
<poolie> have a good day all
<Riddell> jam: if it's deprecated what replaces it?
<jam> have a good evening poolie
<jam> Riddell: something about abstract base class Callable, let me see if I can find it
<Riddell> docs don't say it's deprecated http://docs.python.org/library/functions.html#callable
<vila> jam, poolie, fullermd : I think I'll stick with bare `date` , parsing can be addressed
<ccxCZ> type(foo) == types.FunctionType
<jam> Riddell: maybe it is deprecated only in py3
<ccxCZ> if you want to check for functions only ^
<jam> but it certainly exists in 2.7 so feel free to use it
<jam> Riddell: http://docs.python.org/dev/whatsnew/3.2.html
<jam> says that they restored it
<jam> because they felt it was more readable than isinstance(x, collections.Callable)
<vila> poolie: cu
<jam> so I missed that part. And yes, it is not deprecated after all
<Riddell> lovely, thanks
<fullermd> vila: Well, if it's meant to be "parsed" by a human, plain output is at least as good as any other.
<fullermd> For auto-parsing, epoch would be simplest probably.  Ignoring the mess of nonmonotonicity/continuity of timekeeping in general anyway...
<jam> fullermd: I still find -I easier to parse as a human when I'm trying to do something like *compare* the dates
<poolie> thisi sa kludge; let's not overoptimize it
<poolie> remember you have the option to just ask sysadmins to run experiments for you
<jam> Especially if you have to wrap the months (though that shouldn't be a factor here)
<jam> poolie: well, I've been pqm-submitting branches that are known-broken which works fine. But for the historical record, it would have been nice to have the datestamps
<jam> and then "oh, in rev X things are a lot slower"
<vila> jam: python -c 'import datetime; print datetime.datetime.strptime("Wed Aug 31 12:16:18 CEST 2011", "%a %b %d %H:%M:%S %Z %Y")'
<jam> vila: still harder to think about, etc. Anyway, it isn't like it really matters, it was just a suggestion.
<vila> jam: sure, but poolie preferred trunk only to lower the risks, I'd rather not add risks for portability
<jam> I'm pretty sure +%F is portable
<jam> it is -Isec that isn't
<ccxCZ> %F doesn't seem to be in posix http://pubs.opengroup.org/onlinepubs/000095399/utilities/date.html
<fullermd> It's part of strftime in C99 (though not C89)
<jelmer> Riddell: hi
<jelmer> is it common practice for uploaders to request syncs from Debian, or is it also ok if I just re-upload packages directly to Ubuntu, by myself?
<Riddell> jelmer: it's better to request a sync
<Riddell> assuming there's no changes to be made
<jelmer> Riddell: Cool, thanks.
<Riddell> I can do the sync if there's no freezes to care about, just need the bug number
<jelmer> Riddell: that'd be great, I forgot you were an archive admin
<vila> jelmer: will be afk (lunch), let me know if/when bzr-2.4.0 is deployed on jubany, and thanks for doing it  ;)
<jelmer> Riddell: bug 831690
<ubot5> Launchpad bug 831690 in bzr-gtk (Ubuntu) "Sync bzr-gtk 0.100.0+bzr734-2 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/831690
<jelmer> Riddell: I'll have a couple of others later today for the other bzr plugin FTBFS bugs, if that's okay.
<jelmer> vila: will do :)
<Riddell> sure
<doude> Hi, all. I try to log with my launchpad login on bzr: bzr lp-login nickname
<doude> but I work behind a firewall, and I cannot contact launchpad on SSH port
<doude> and now each bzr branch commands fail
<doude> How I can unlogin to just clone some launchpad repository ?
<vila> doude: you need to remove launchpad_username from bazaar.conf
<vila> doude: do you have a bzr recent enough to run 'bzr config' ?
<doude> vila: yes
<jam> ugh. just accidentally passed a .gz stream to subunit, and it decided the whole thing should be "passthrough", which meant it sent 600kB of garbage to the terminal, which got the system bell *really* excited
<jam> if the bell is 3s long, and system-bell is 1/255 of the chars, I estimate it will take 2 hours for it to stop beeping
<vila> jam: ouch ;)
<doude> vila: thanks a lot for your help
<jam> fortunately 'mute' works, but volume itself doesn't
<vila> doude: then bzr config --remove launchpad_username in your home dir should do
<doude> vila: ok, it works
<vila> wow, the garbage killed jam :-/
<doude> vila: Is it possible to log to launchpad if the SSH port is blocked ? by another way ?
<vila> doude: short answer: no
<vila> doude: there are various tricks to route ssh but that will need cooperation from the firewall admin in most cases
<vila> jam is back \o/ death to the garbage ! ;)
<jam> :)
<doude> vila: ok
<vila> doude: you can access lp in read-only mode without ssh though
<doude> vila: ok
<doude> bye bzr men
<vila> doude: and if I remember correctly you can even make merge proposals via mail but I don't remember the details
<vila> no fast enough :-}
<vila> not
<jelmer> jam: just to confirm, you were happy with my move-hashcache MP if I added a common base class for WT2 and WT3 ?
<jam> jelmer: I think I approved it already, but if not, yes
<jam> ah,I think I forgot to actually vote
<jelmer> jam: yep, your last vote was needsinfo. anyway, thanks
<jam> I just updated it
<jelmer> I noticed, already sent it off to pqm :)
<Peaker> hey, what's the difference between -c and -r in bzr merge?
<Peaker> http://doc.bazaar.canonical.com/latest/en/user-reference/merge-help.html  doesn't make it clear
<Peaker> oh, I just read that cherry-picks via "bzr merge" are not tracked by bzr :-(
<Peaker> I was wondering whether my current gripe with git (cherry-picks don't track the history, merges force non-modular resolution of all conflicts at the same time) was solved by bzr
<jelmer> Peaker: hi
<jelmer> Peaker: unfortunately we don't really have either of those features either (yet)
<jelmer> we would like to support both, in particular tracking cherry pick merges, but it's a hard problem to solve if you want to get it right.
<Peaker> jelmer: well, we're using git, and I noticed some serious problems -- for example:  if you have two branches, A, and B.  You cherry-pick a bad commit A->B.  Now you revert the bad commit only in A. Then you merge A and B -- you will get the bad commit again, because a 3-way merge considers (bad+revert = 0  <  bad)
<Peaker> also, a "merge" in a large project that involves many people is pretty horrible -- conflict resolution requires the expertise of many different people!
<Peaker> (and they're all forced to share a working tree to work together on the problem)
<Peaker> and the conflict resolutions are later very hard to view in isolation, because merge diffs are hard to view (relative to which parent?)
<Peaker> So my conclusion is that cherry-picks are really the right way to move work around -- but without their metadata being tracked, it works horribly
<Peaker> I think darcs has the right model of "cherry picks" are the only way to move work around and are tracked.. but it has performance issues
<jelmer> Peaker: three way merges are relatively easy because there's really only three trees you have to care about
<jelmer> Peaker: with cherrypicks you could have to consider all changesets in a repository
<jelmer> it would be relatively easy to track cherrypick merges in bzr (in revision properties, for example) but using that information intelligently and without making merge scale badly is the hard bit
<Peaker> jelmer: I think darcs just makes merges scale badly :)
<Peaker> but I'm thinking it might be worth it... We're getting horrible horrible merges, and cherry-picking everything means we lose all DVCS tracking of everything
<Peaker> the only solution we have is to just merge extremely often so no divergence picks up
<jelmer> Peaker: btw, I'm pretty sure bzr will pick up the revert in the case you mention
<jelmer> Peaker: bzr does track per file history, unlike git, which just tracks content
<Peaker> jelmer: but you do a 3-way merge here, no?
<Peaker> the per-file history here is that in branch A, the file had changed, and then changed back, so sum of all changes = 0.   In branch B, it just changed. So the sum = change.   3-way merge of 0 and change = change, no?
<jelmer> Peaker: bzr doesn't look at the checksum to see if a file has changed. It keeps track of what revision it was last changed.
<Peaker> so what would bzr do here? it would see the file changed in branch A, and then changed back, and consider it a conflict?
<jelmer> Peaker: it should have enough info to create a conflict; I'm not sure if it actually creates one
<Peaker> jelmer: git has the same info, of course, it is also a question of whether it looks at that info
<jelmer> Peaker: git doesn't know what revision a file last changed in, unless it's going to scan history (which it doesn't)
<jelmer> it just finds the common base to use for the 3 way merge
<jelmer> abentley: hi
<Peaker> jelmer: ah, yes, perhaps
<abentley> jelmer: hi.
<Peaker> jelmer: though I think merge does scan history in various cases
<jelmer> Peaker: it scans it to find the base for the three way merge
<Peaker> jelmer: Well, that scan is per-file, so it had already encountered all of the version that changed it
<jelmer> Peaker: finding the base for the merge? that can only be done based on the revision graph
<Peaker> jelmer: yeah -- and when walking that graph, it sees whether that file changed in each of the revisions
<jelmer> Peaker: it doesn't look at the files during that scan, just the revisions
<Peaker> jelmer: I'm pretty sure it does the 3-way merge basis lookup on a per-file basis, according to the debug prints visible when encountering conflicts. But I'm not entirely sure
<Peaker> and if it does that -- it should not be expensive to see whether the file changed or not, in those revs, if it didn't already
<jelmer> Peaker: it is fairly expensive because to know what file has changed you have to apply the rename/copy detection heuristics
<jelmer> Peaker: to follow the changed files I mean
<jelmer> as far as I understand it it uses the revision graph to find the base revision, and then applies the heuristics between just the base revision and the other/this trees
<jelmer> Peaker: bzr's merge doesn't generate a conflict either
<vila> jelmer: care to have a look at https://code.launchpad.net/~vila/udd/806425-append-revs-only/+merge/73531 ?
<jelmer> vila: sure
<jblue> Q: is there a way to commit/operate on a specific set of changes after a 'bzr status'?  For example, if bzr status shows removed, modified, and unknown files, and I want to work only with the removed files, is there some way to specify that?
<vila> jblue: 'bzr commit file1 file2' should just work
<jblue> it does, but was looking for a method working with that set, in an instance where I have a lot of files being removed.
<jblue> but also have a lot of files modified, and their locations are intermixed
<jblue> so specifying them one by one is a bit tedious
<vila> may be 'bzr qcommit' provides some help ?
<vila> Did you get there after a merge or some heavy refactoring from an IDE ?
<jblue> heavy refactoring.. basically several files have been removed, modified, and added, and I'd like to do the removal first, then work with the others
<vila> but no file has been both removed and added right ?
<jblue> well it was, but I quickly saw that was going to be a headache, so I've reverted, and am doing the removal first
<vila> I meant, you didn't *rename* files by doing remove/add right ?
<jblue> no
<vila> ok, good
<jelmer> vila: r=me
<vila> jelmer: thanks, I'm deploying
<vila> ha, damn, been interrupted and forgot to answer
<vila> jelmer: my understanding is that a_r_o should only be applied in *some* cases so having a global switch doesn't make sense at this point
<jelmer> vila: I mean, having a global variable that's set to True or False
<vila> what for ? switch it back to True ?
<jelmer> yeah
<vila> AIUI, using it for local branches is just a Bad Idea, so after some checking I will probably just get rid of the calls themselves
<vila> for the lp branches, AIUI again, the rules are not well understood yet so we probably end up replacing the calls by some more logic
<vila> so in the end, none of the actual calls should survive
<vila> jelmer: or do you expect such a breakage that we want to come back to a_r_o=True ?
<jelmer> vila: I'm not really bothered either way :)
<vila> hmm, looks like lp has or had some transient issues...
<gypsymauro> I've some mess in my repo and if I try to do a ci it says: bzr: ERROR: Bound branch BzrBranch7('file:///....') is out of date with master branch BzrBranch7, To commit to master branch, run update and then commit. but I want to be sure that nothing in my working directory will be changed.. I'm sure my current version is the correct version
<gypsymauro> any hint?
<vila> gypsymauro: hi
<jelmer> gypsymauro: I think "bzr diff -rbranch:/path/to/master/branch" should tell you what it would change
<vila> what does 'bzr missing' says ?
<gypsymauro> is says that I've two extra revision (and is true, i done some ci --local)
<vila> any uncommitted changes ?
<gypsymauro> the bzr diffs displays me 29645 lines..
<jelmer> gypsymauro: in that case it shouldn't change your working tree, although it will change your local commits to be pending merges
<gypsymauro> vila: what do u mean? I committed locally, only this , how can I now commit to the remote repository?
<jelmer> gypsymauro: if you run "bzr up" and then "bzr commit" that will commit your changes to the local repository
<jelmer> argh
<jelmer> s/local/remote/
<gypsymauro> jelmer: and this for sure doesn't change anything in my local repository? (the update term scares me :)
<jelmer> gypsymauro: it will update bzr metadata in the local tree - it will change your two local commits to be pending merges, and your branch tip to match that of the remote branch
<jelmer> gypsymauro: if the remote branch doesn't have any extra revisions (as "bzr missing" seems to indicate) then it shouldn't change any of the files in your tree
<gypsymauro> jelmer: doh..
<gypsymauro>  bzr conflicts
<gypsymauro> Conflict: can't delete  foo/bar  because it is not empty.  Not deleting. Conflict because  foo/bar is not versioned, but has versioned children.  Versioned directory.
<gypsymauro> damn.. it creates a lot of .BASE .OTHER and .THIS file...
<gypsymauro> it's a nightmare..
<jelmer> gypsymauro: ouch, that sucks :(
<fullermd> I keep wishing we'll just squirrel ci --local away somewhere deep hidden...
<jelmer> gypsymauro: you had local commits that added foo/bar ?
<jelmer> fullermd: yeah, me too. I think we should just get rid of them.
<gypsymauro> damn...
<gypsymauro> if I recover from a backup my foo/bar? this resolves my conflicts?
<gypsymauro> or I've to merge manually ?
<jelmer> gypsymauro: I suspect "bzr resolve --take-other" might fix this for you, but I'm not entirely sure
<vila> gypsymauro: sry was called elsewhere
<vila> gypsymauro: if you have conflicts, a merge already occured (triggered by update)
<gypsymauro> jelmer: uhm i suppose the .THIS version is the correct
<vila> gypsymauro: how conflicts ?
<vila> gypsymauro: how many conflicts ?
<gypsymauro> vila: 47
<gypsymauro> wc -l
<vila> hmm
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<vila> gypsymauro: can you pastebin the output of 'bzr conflicts' ?
<vila> gypsymauro: and 'bzr st'
<gypsymauro> http://pastebin.com/TCYWVLy6
<gypsymauro> and http://pastebin.com/nWPRg99U
<jelmer> Riddell: still there?
<jelmer> Riddell: another sync is bug 837956
<ubot5> Launchpad bug 837956 in bzr-dbus (Ubuntu) "Sync bzr-dbus 0.1~bzr51-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/837956
<vila> gypsymauro: :-/ Looks like you added files that were also added remotely...
<vila> gypsymauro: but you said 'bzr missing' only reported local revisions right ?
<jelmer> vila: the problem is that update works in two phases; first it updates to the remote branch, then it merges in the local commits again
<jelmer> vila: I *think*
<vila> jelmer: but we stop as soon as we get a conflict (or was it discussed but not implemented ?)
<vila> gypsymauro: what bzr version are you using ?
<jelmer> vila: sure, but he was up to date
<fullermd> The usual cause of kerfufflage there is when you have uncommitted changes as _well_ as local commits.
<vila> fullermd: I asked for uncommitted changes first ;)
<fullermd> I thought we added some guard on that, but maybe we didn't.  I dunno, I stay too far away from those dragons to remember   :p
<gypsymauro> Bazaar (bzr) 2.1.2
<vila> gypsymauro: ouch, OS/version ?
<gypsymauro> debian squeeze
<jelmer> Riddell: and I have a bzr upload waiting for approval
<Riddell> jelmer: waiting where?
<vila> gypsymauro: rrright, let's do it the old fashion way then
<vila> gypsymauro: do you have the qbzr plugin installed ?
<jelmer> Riddell: waiting for approval by an archive admin; looks like it was just rejected
<ScottK> jelmer: I rejected 2ubuntu1.  You just uploaded 3ubuntu1.
<ScottK> At this point it needs to wait until after Oneiric Beta 1 is done.
<jelmer> ScottK: ah, my mistake. Thanks!
<ScottK> (I also pinged you on #ubuntu-devel about it ...
<ScottK> )
<gypsymauro> vila: now yes :D
<vila> gypsymauro: great, try 'bzr qlog'
<jelmer> ScottK: yep, not sure why I missed that
<gypsymauro> vila:  ok
<vila> gypsymauro: we need to find the last revision committed locally (we'll need the revision on your remote branch to, but this one will be easy to get)
<gypsymauro> i've two light blue circles
<vila> gypsymauro: 'bzr revno' ?
<gypsymauro>  ok the last is 14
<vila> do you see a 'pending merges' label ?
<gypsymauro> yes
<gypsymauro> 14.1.2
<gypsymauro> and another blue 14.1
<gypsymauro> 14.1.1
<vila> exellent, that's your local commits
<gypsymauro> without the pending msg
<gypsymauro> exactly
<vila> justasec
<vila> gypsymauro: roughly, we will create a branch from remote and 'merge ../with-conflicts -r14.1.2'
<gypsymauro> vila: I'm in ur hands... take care about 2 weeks of work :) I've a backup btw
<vila> gypsymauro: i.e.: in a new directory: bzr branch <remote> recover ; cd recover ; bzr merge <conflicts> -r14.1.2
<gypsymauro> vila: doing the first step
<vila> gypsymauro: no worries, try (above the dir with conflicts) : bzr branch <conflicts> -r14.1.2 my-precious
<gypsymauro> what do u mean with <conflicts>
<vila> your checkout dir
<gypsymauro> you mean where I've my precious sources?
<vila> I call it <conflicts> to denote that's the one where the conflicts are *now*
<vila> hehe, yeah, except you've committed them, so they are safe in a revision in the repo
<gypsymauro> my local repo
<vila> yes
<fullermd> Wait, he's committed the conflicted merge?
<vila> no
<fullermd> So how would the local commits (now pending merges) have a dotted revno available?
<vila> can't commit with conflicts
<fullermd> Wouldn't you need to go by revid?
<vila> hlol, good point, we need the revids
<vila> gypsymauro: sry, in that qlog window, note the revid for 14.1.2 checking that's indeed your last local commit
 * fullermd is a cheenius sometimes.
<vila> fullermd: thanks for the heads-up
<fullermd> vila: You'll get my bill in the mail   ;p
<vila> hehe, as usual, don't forget to bill for some more goats too, say half a dozen ?
<gypsymauro> vila: ok now I try , and all that .THIS and .OTHER will disappears?
<vila> gypsymauro: so you've got a copy of your remote branch ?
<gypsymauro> yes
<gypsymauro> I don e  bzr branch <remote> recover ; cd recover ;
<gypsymauro> steps
<gypsymauro> now I'm doing that bzr merge <conflicts> -r14.1.2
<vila> go there and do 'bzr merge ../<conflicts -r<revid>'
<vila> gypsymauro: as fullermd pointed out the revno is probably not available (qlog lied ;)
<vila> so you need,
<vila> gypsymauro: sry, in that qlog window, note the revid for 14.1.2 checking that's indeed your last local commit
<gypsymauro> bzr: ERROR: Requested revision: u'14.1.2' does not exist in branch:
<gypsymauro> doh...
<vila> right, fullermd was :)
 * fullermd buffs his nails and looks important.
<vila> gypsymauro: qlog *pretends* the revnos exist, but they don't until you commit
<gypsymauro> I'm getting lost
<vila> gypsymauro: just go back to qlog, select 14.1.2 and it should display a pane with some details on the revision
<gypsymauro> which detail do u need?
<vila> gypsymauro: one of them is the revid which is used internally and in some recovery contexts, normally you only deal with revnos (14.1.2 is a so-called dotted revno)
<vila> gypsymauro: a revid is ugly, except it probably has your id/email in it so it's not that ugly ;)
<gypsymauro> vila: it's something like email@....bla bla bla?
<gypsymauro> ah ok
<gypsymauro> so -rrevid?
<vila> yup, pedantically -rrevid:email@bla bla bla
<gypsymauro> All changes applied successfully.
<vila> bzr st ?
<vila> you should get something that looks like a summary of your two local commits
<vila> ditto for 'bzr diff'
<gypsymauro> vila: well where is applyed the merge?
<vila> gypsymauro: what does 'bzr st' says ? It should finish with 'pending revisions' blah
<vila> s/finish/ends/
<gypsymauro> I mean in the recover folder I've the old version of files
<vila> you did the merge there right ?
<gypsymauro> pending merge tips: (use -v to see all merge revisions)
<gypsymauro> yes of course
<vila> so you just merged the last 'commit --local' you did in <conflicts>
<vila> gypsymauro: there was no uncommitted changes when did update in <conflicts> right ?
<gypsymauro> no wait I didnt' made the last commit --local I tried to commit directly on the remote
<vila> argh
<vila> ><
<gypsymauro> I forgot the --local command..
<gypsymauro> if I move all the .THIS file to the original file?
<vila> the fatal trap :-(
<sidnei> what's that really shiny github-like site for bzr hosting which i can never remember the name?
<vila> well, now it depends which merge failed, it's unclear from there, so, chose a file you know well and check whether the right one is .OTHER or .THIS
<vila> gypsymauro: well, now it depends which merge failed, it's unclear from there, so, chose a file you know well and check whether the right one is .OTHER or .THIS
<gypsymauro> vila: is the .THIS
<jelmer> sidnei: http://wiki.bazaar.canonical.com/Hosting
<jelmer> sidnei: I'm not sure which one of those you mean
<vila> gypsymauro: two choices from here
<vila> gypsymauro: either you go back to <conflicts> and resolve the conflicts there OR
<sidnei> jelmer, might be mergebox, but it does not look like what i remember
<sidnei> the name i remember was codemaster or something
<vila> gypsymauro: you go to recover and do: 'bzr revert --no-backup; bzr pull --overwrite -rrevid:<revid of 14.1.2>'
<gypsymauro> vila: what does that?
<gypsymauro> vila: uhm i think is better to resolve conflicts
<vila> gypsymauro: the first one is going forward resolving the conflicts
<gypsymauro> yeah yeah I mean the second
<gypsymauro> but if is it what I suppose I prefer the second :)
<gypsymauro> the first sorry
<vila> gypsymauro: the second one is stepping back, restore your working tree as it was when you miss --local
<vila> gypsymauro: it all depends on what the conflicts are which is hard for me to judge
<gypsymauro> vila: just can you help me telling what to do when there is a . THIS .OTHER conflict?
<jelmer> sidnei: mergebox isn't really shiny
<gypsymauro> vila: I've to move the .THIS over the original file and then run bzr resolve myfile?
<vila> gypsymauro: is there a conflict-type topic in 'bzr help topics' ?
<vila> gypsymauro: that's the general idea, yes
<jelmer> sidnei: it took me a while to hear about bzr.bz too, it's been there for a long time without anybody knowing
<vila> gypsymauro: one by one (especially with bzr-2.1 where I don't remember which bugs were still there)
<vila> gypsymauro: for the record, we have a new series every 6 months and 2.4.0 has just been released so 2.1 is 18 months old
<gypsymauro> vila:  ok, mv or cp? and then the generated files wil disappear? (.this .other..)
<vila> gypsymauro: both should work
<gypsymauro> doh... bzr: ERROR: Could not acquire lock
<gypsymauro> /.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable
<vila> gypsymauro: 'bzr break-lock'
<vila> no wait !
<vila> quit qlog first
<gypsymauro> who is locking that? I've nautilus plugin
<vila> try again
<vila> in 2.1, could be qlog, can't remember the details
<sidnei> jelmer, it totally escapes me now, but i rememember poolie mentioning it in an email, which i can't find. hopefully im not dreaming. it definitely doesn't look like mergebox, unless they rebranded.
<sidnei> for worse that is ;)
<jelmer> sidnei: :)
<gypsymauro> vila: tanx for all ur help :) last question
<gypsymauro> how to solve the Conflict: can't delete foo/bar because it is not empty.  Not deleting =
<gypsymauro> ?
<vila> right, so, what is inside foo.bar ?
<gypsymauro> other folders
<vila> gypsymauro: which are also involved in conflicts ?
<jam> sidnei: sloecode?
<jam> https://launchpad.net/sloecode
<jam> not really a website, though
<sidnei> jam, nope. the site i remember had a black background and some shiny polished metal like images, very apple-y. oh well :/
<jam> sidnei: I remember a pastebin sort of website
<jam> sidnei: http://chopapp.com/#
<jam> but it isn't bzr
<jam> elliot just mentioned http://bzr.bz
<vila> gypsymauro: so you're back on track ?
<gypsymauro> I hope
<gypsymauro> tank you vila
<vila> gypsymauro: no you know why fullermd....
<gypsymauro> I'm sorry but my bzr skills ar so low :( I need to study it again!
<vila> fullermd: I just can't believe you went out/in just around the time we needed to fix gypsymauro issues
<gypsymauro> fullermd: :D
<vila> fullermd: you're just faking those connections msgs right ?
<gypsymauro> you are great guys
<gypsymauro> tanx tanx tanx again
<gypsymauro> really
<gypsymauro> yuhu!
<vila> gypsymauro: well, as fullermd was hinting, --local is.... unusual
<fullermd> My spidey sense made me do it.
<vila> gypsymauro: enjoy !
<vila> and on that positive note, I will join family for dinner ;)
<fullermd> Need to me break something else so you can get out of that?   ;)
<vila> fullermd: so, just read the logs, you went out when he realized he... forgot --local...
<TA1CZ> hello
<TA1CZ> may I ask something about Bazaar explorer for windows.
<TA1CZ> Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir
<TA1CZ> Connected (version 2.0, client Twisted)
<TA1CZ> bzr: ERROR: [Error 5] Access is denied: 'c:\\users\\user\\appdata\\local\\temp\\tmpiawygw.pag'
<TA1CZ> I get this error...
<jelmer> TA1CZ: pag rather than pack?
<jam> TA1CZ, jelmer: I believe that is a failure of pageant
<TA1CZ> is there any suggestion?
<jam> try re-setting up putty
<jam> or making sure your key is set up, etc.
<jam> or just stop pageant entirely
<TA1CZ> I used puttygen for generating the keys..
<TA1CZ> both private and public..
<jam> TA1CZ: the issue with $TEMP is usually while communicating to the local pageant server
<jam> it doesn't really matter what the keys are
<TA1CZ> the putty agent is also working on the right side of windows
<TA1CZ> I added private.ppk key
<jam> TA1CZ: try stopping the local putty agent for a bit
<TA1CZ> o.k.
<TA1CZ> Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir
<TA1CZ> Connected (version 2.0, client Twisted)
<TA1CZ> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
<TA1CZ>   karen-denki@bazaar.launchpad.net
<TA1CZ> supported auth types: ['publickey']
<TA1CZ> Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir
<TA1CZ> Connected (version 2.0, client Twisted)
<TA1CZ> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
<TA1CZ>   myID@bazaar.launchpad.net
<TA1CZ> supported auth types: ['publickey']
<jam> TA1CZ: is the user-id correct?
<TA1CZ> the result is like this when I stop the agent!
<jam> (just to start from the beginning)
<TA1CZ> o.k.
<jam> We can't auth via public-key because you don't have the key agent around, and putty uses a different key
<jam> format by default
<jam> .ppk vs id_rsa.pub
<jam> however, start putty again
<jam> and I think you might see a $TEMP failure
<jam> unfortunately, I've seen this on one machine (our ec2 build host) only, and haven't been able to reproduce it
<TA1CZ> which putty?
<jam> on my home machine, etc.
<jam> "pageant"
<jam> I should have been clearer
<TA1CZ> :(
<jam> TA1CZ: it is failing with TEMP again?
<jam> TA1CZ: what os version/
<jam> ?
<TA1CZ> windows 7
<TA1CZ> so could you say step by step what should I must do is you dont mind?
<TA1CZ> because I totally confused..:(
<TA1CZ> is this relevant with authentication.conf?
<jam> TA1CZ: not really. I think I can work out a workaround for you
<jam> you need to run puttygen again
<TA1CZ> o.k. now I am running puttygen
<jam> (note, I'm discussing it from memory, and I'm not logged into Windows right now, but I'll do my best)
<jam> you should be able to load the private.ppk that you created
<vila> jam: nice mail about fdatasync, make check timing patch landed, first log rsync'ed, the stamps are lost in the noise but nothing a crude parser can't decipher, dinner time here but you'll got a parser first thing I touch this keyboard again ;) Unless you beat me to it that is :-p
 * vila really goes to dinner now ;)
<jam> vila: for now, I'm focusing more on test cases individually. If I have 'pqm-stdout.gz' it has the subunit timestamp stream
<jam> so 'date' doesn't really matter.
<TA1CZ> o.k. when the putty gen is on the stage.. I load the private.ppk key by pressing Load button.. it is loaded.
<vila> jam: great
<jam> TA1CZ: Now you want to export the key into the "openssh" format
<jam> which you've already done a bit of, since you uploaded the openssh public key form to launchpad
<vila> jam: spurious spikes for tests have been encountered when dealing with socket leaks, cycle checks from mgz and so on, you may want to give a spin merging it into one of your born-to-not-land branches
<jam> vila: could be interesting. But I believe Martin also indicated the machine is shared
<jam> so if they're doing stuff at the same time, its gonna get whacky
<jam> the test suite was 2.5hrs for a couple of runs, then 3.5 for the other times of the day
<vila> jam: sure, primary cause, but 3x...
<jam> vila: just the source of variability
<jam> primary cause is still probably fdatasync, which is another failed log I'm looking at
<jam> but there seems to be slightly more than that as a real cause, and then hard-to-measure-because-of-system variability
<jam> 2.3 can finish as fast as 45min, but took 1:45 last night
<jam> etc.
<AuroraBorealis> does bzr hash files when it does a commit?
<Peng> AuroraBorealis: Hash in what way?
<AuroraBorealis> just wondering if this statement is true for bazaar as well
<AuroraBorealis> context: kernel.org was compromised recently
<Peng> It was?
<AuroraBorealis> http://pastebin.com/8CKqBPQC
<AuroraBorealis> yeah it was
<AuroraBorealis> (see https://www.kernel.org/, first news item)
<Peng> Yeah.
<AuroraBorealis> so basically, can someone change something without bazaar knowing about it?
<Peng> Bazaar doesn't uses hashes as revision IDs, but it does hash everything.
<AuroraBorealis> so if someone did do that you would be able to detect it if you rechecked the repo or something
<Peng> I'm not quite awake enough to think about this problem.
<AuroraBorealis> xD
<AuroraBorealis> i dont know enough about the actual structure of the repo itself to figure it out
<Peng> It would most definitely be possile to verify it somehow, but I don't know how easily.
<AuroraBorealis> isn't there a --recheck option
<Peng> Yes.
<mathrick> hiya
<AuroraBorealis> would be an interesting test to see if someone could modify the repo and see if said recheck catches it.
<mathrick> http://doc.bazaar.canonical.com/latest/en/mini-tutorial/index.html#creating-your-own-copy-of-another-branch <-- why does it even talk about init-repo?
<AuroraBorealis> as modifiying the repo malitiously would be bad.
<mathrick> without explaining what it is and why it is there?
<mathrick> that's really outside of the scope of a mini tutorial, IMHO, and should be removed
<AuroraBorealis> file a bug about it
<AuroraBorealis> it is probably overkill for said mini tutorial.
<Peng> AuroraBorealis: "bzr check" would certainly find ordinary corruption, but a clever hacker would modify all the hashes, no? That would probably blow up pretty quickly as people with uncompromised copies of the repo interacted with it, but it's not something I have any knowledge about.
<AuroraBorealis> well what that git comment said was that all the future commits require that all the previous commits are correct
<AuroraBorealis> although i don't really know how that works, but another example is with bitcoin blocks, each block has the hash to the previous block, creating a 'chain', so you can't modify a block or else the hashes won't match up
<Peng> But it can't actually verify that the hashes of all previous revisions are *correct* in every operation.
<Peng> Can it?
<AuroraBorealis> well true.
<AuroraBorealis> if the person manages to maliciously modify commit 100 for example
<AuroraBorealis> and manages to change the hashes for 1-99 then i guess it would be undetectable
<AuroraBorealis> but i'm sure something else would break...
<AuroraBorealis> like a merge would show it as a conflict
<AuroraBorealis> and thats how bitcoin does it as well, is that its a p2p network, so you would have to get everyone to have the malicious block or else you would realize that its wrong
<Peng> Might be an uncommonly-modified file.
<Peng> Like I said, I'm too tired to think about this.
<AuroraBorealis> xD
<AuroraBorealis> well wake up
<Peng> Worst case, even without any hashing, you can obviously do a diff between a questionable copy and a known-good copy.
<AuroraBorealis> yeah, even if its uncommonly modified, if anyone had branched the good copy and tried to merge it back in, it would show up as a conflict
#bzr 2011-09-01
<mathrick> Peng: all important repos are signed anyway, so that removes the ability to change anything
<AuroraBorealis> how do you sign a repo?
<mathrick> well, you sign commits
<AuroraBorealis> never heard of it
<AuroraBorealis> this
<mathrick> bzr help sign-my-commits
<mathrick> http://doc.bazaar.canonical.com/latest/en/user-guide/gpg_signatures.html
<AuroraBorealis> i'm still a bit confused on how this prevents malicious tampering
<mathrick> AuroraBorealis: simple, a commit has a signature, which is a cryptographic certificate of authenticity
<mathrick> you can't modify a commit without invalidating the signature
<mathrick> so chains of hashes or not, it doesn't match up
<mathrick> though I believe bzr would catch that without explicit rechecking too even without signatures
<mathrick> because tree states are referred to by sha1
<mathrick> it's just not ordinarily visible
<mathrick> but it'd still cause any related branch to fail to sync
<AuroraBorealis> because what happens if you change the repo so the commit is no longer signed, or changed the author (so you can use a different gpg key to sign it)
<AuroraBorealis> yeah
<AuroraBorealis> but what if you change the commit, and the signature?
<AuroraBorealis> does it have a chain of hashes?
<AuroraBorealis> hmm.
<mathrick> bzr's signatures are not as robust and integrated with everything else as could be wished for yet, but they definitely give you the ability to say that commits are what they claim to be with absolute certainty (barring physically stolen keys)
<AuroraBorealis> but does it have a 'chain of hashes', like one commit refers to the next one's sha1 (with the signature)
<mathrick> AuroraBorealis: the point of having signatures is that you can't forge one
<mathrick> to sign a commit you need to have the private key
<mathrick> only the original author does
<mathrick> otherwise it wouldn't be much of a signature
<AuroraBorealis> yeah, but what if you just straight up replace the commit, and not really 'forging' it, you are just creating a whole new one and putting that in there
<mathrick> people would notice when pulling / merging
<AuroraBorealis> yeah, i was just thinking because i quoted kernel.org saying that this wouldn't work in git since it seems to have a 'chain' of hashes and that one wouldn't match up
<mathrick> that's the case in bzr too
<mathrick> but bzr can also sign things
<AuroraBorealis> k
<mathrick> meaning you get to know not only that things weren't changed, but that they come precisely from whom they claim to come
<AuroraBorealis> ok, just curious :3
<AuroraBorealis> andddd off to class
<mwhudson> what is the secret decoder ring for using meld to resolve conflicts with bzr again?
<mwhudson> ah, extmerge
<poolie> hi mwhudson, all
<poolie> yes, but i thought that was being moved in
<poolie> maybe not yet
<poolie> jam, hi?
<vila> hi all !
<vila> poolie: have you requeued imports on jubany in the last hour ?
<vila> by the way, a_r_o have been reverted on jubany: http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29
<vila> a_r_o == append_revisions_only, sry for the obfuscated TLA ;)
<jam> hi poolie
<poolie>  hi jam
<poolie> hi vila, i have not
<poolie> thanks for doing thhat
<vila> weird, someone else ? maxb ?
<bradm> poolie: you about?
<poolie> hi brad, i am but i'm on the phone
<bradm> poolie: no worries
<bradm> poolie: when you're done, we need to upgrade wiki.bazaar.canonical.com to the new moin at some point, do you have any preferences as to what sort of times that can be done?
<poolie> hi there
<poolie> do you want us around for it, or not?
<poolie> i don't have any strong feeling so it's just whatever's easiest for you
<vila> 2.4.1 and 2.2.5 were planned to be frozen today, given the delay on 2.4.0, I think we should postponed 2.4.1 to next week and just freeze 2.2.5, thoughts ?
<bradm> poolie: mm, I'm not sure there's any need for you to be around, and we'll have backups etc
<bradm> poolie: although it's very likely going to be me doing it during .au working hours
<vila> see https://launchpad.net/bzr/+milestone/2.4.1 https://launchpad.net/bzr/+milestone/2.2.5 for the pending bug fixes
<bradm> poolie: unless there's a preference for otherwise
<bradm> poolie: ok, I'll let you know, likely will be next week sometime, thanks.
<Riddell> hola chicos
<maxb> vila: not me
<vila> Riddell: hey !
<poolie> ahoy
<vila> hmm, I may have been confused by mass_import querying lp *just* when I was looking...
<vila> poolie: 2.2.5 ? 2.4.1 ? Thoughts ?
<vila> poolie: by the way, ironically, make check stamps worked but the landing encountered a spurious failure ;)
<jam> vila: makes sense to me to push back 2.4.1, I don't really know what is in 2.2.5 that is specifically worth releasing
<vila> jam: that's why I pasted the relevant milestones urls above ^
<vila> bug #609187 may be a good flagship for SRU
<ubot5> Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Fix released] https://launchpad.net/bugs/609187
<vila> and 2.2.4 was released on 2011-02-04, i.e. almost 7 months ago
<vila> also note that pushing 2.4.1 back more or less implies also pushing 2.5b1 from 2011-09-08 to 2011-09-15
<vila> ... or not
<vila> worth discussing at least IMHO
<Riddell> any thoughts on how I can write tests for i18n?  Is it possible for a test to run ./setup build_mo ?
<vila> Riddell: if the input set is small enough yes, but you may want to directly run what ./setup build_mo does no ?
<vila> Riddell: i.e. less blackbox, more unit kind of test
<Riddell> aye
<vila> Riddell: also, there are already some tests around i18n somewhere
<Riddell> yes, looking at those now
<vila> bzrlib.tests.test_help.py
<vila> some refactoring may be needed there to reduce duplication though :-/
<jam> vila: btw, think I should try to land get_parent_map before 2.4.1? Or should we have more time shaking it out in trunk?
<vila> jam: good question, no idea about who shaked it nor how... but nobody complained either
<vila> jam: btw, when you say "I don't really know what is in 2.2.5 that is specifically worth releasing", you mean "nothing there worth releasing" or "no idea what is worth releasing there" ?
<jam> "no idea what is worth releasing there"
<vila> ha ok
<vila> so, since nobody objected and on the basis that 7 months is long enough, I'll freeze 2.2.5 after lunch
 * vila away for lunch
<jelmer> vila: we already support expanding variables in config options?
<jelmer> Riddell, hi
<Riddell> hi jelmer
<jelmer> Riddell, does launchpad pick up the pot file from the bzr branch?
<Riddell> yes it does
<Riddell> https://translations.launchpad.net/bzr/trunk/+pots/bzr/
<jelmer> Riddell: your recent patches update export_pot.py but don't rerun it, is that for a particular reason?
<Riddell> jelmer: which patch?  (probably I just didn't want to make a massive diff)
<jelmer> Riddell, i18n-topic-help
<Riddell> yeah, I would update the .pot file before sending to PQM
<jelmer> Riddell: works for me
<vila> jelmer: via bzr.config.expand = True in bazaar.conf so revno 5684
<vila> jelmer: 2.4b1
<jelmer> ah, cool.. didn't realize that
<jonathanj> is it possible to prepopulate the commit message?
<jonathanj> something like the normal launch-your-editor mode combined with -F
<jelmer> jonathanj: bzr plugins can provide templates for the commit message
<vila> jelmer: option expansion is opt-in only as review raised issues about false positive with people using {xxx}, so feedback welcome if you use it
<neoZ7> I try to add Trac Bazaar Plugin to my Bazaar Explorer (win32), downloaded an .egg file and can't find a tutorial what to do with it. Could someone please point me to a place to read up on it? Thank you.
<jelmer> neoZ7: see the README file
<jelmer> vila: what would be the appropriate thing to report to in PullResult/PushResult ?
<jelmer> we should be reporting to stderr, but is there anything on Command that represents sys.stderr?
<vila> ha
<vila> good question :)
<mgz> jelmer, neoZ7: the README in the egg if you unpack it as a zip?
<vila> the *result* makes sense on stderr since -v will use stdout (self.outf)... but it seems we currently display both on self.out
<jelmer> mgz, I guess so. I don't really know where trac-bzr ships an egg
<vila> jelmer: so, I'd say self.outf for both which is already used for -v
<vila> jelmer: both push and pull I mean
<jelmer> neoZ7, actually, see http://pypi.python.org/pypi/TracBzr
<neoZ7> jelmer: I understand about putting plugins in their respective directories, but the egg file is a renamed zip file and differs from the plugins I find already installed. Will read up your link next.
<mgz> jelmer, vila: just need to use ui.stderr directly maybe?
<mgz> ui.thingy.stderr even
<vila> wfm but I suspect some tests will fail
<jelmer> well, some tests will fail anyway as "bzr pull" currently writes to stdout and "bzr push" currently writes to stderr
<vila> jelmer: you mean for the result ?
<vila> jelmer: if my tweak become too invasive, better file a bug so the issue is discussed there, I noticed the weird duplication and mentioned it but I didn't realize the fallouts
<vila> jelmer: if you end up de-duping by passing 'trace.note' and 'self.outf.write' to a helper, the result may be uglier ;)
<neoZ7> jelmer: maybe I'm following a wrong direction, my goal is to change the way my diff view is displayed, I like the way unidiff shows up but I like trac's view more. My goal is to get this style into bazaar explorer -> http://dev.ryzom.com/projects/ryzom/repository/diff?rev=dfb7fa26474c&rev_to=9f3f37337a56 and someone suggested the trac plugin to get this done. But I think it might be too much since all I want is a different diff result formatting.
<mgz> hm.
<vila> jam: thanks for the review !
<mgz> neoZ7, you mean, in bzr explorer (really qdiff), you want a single panel view rather than old and new side by side?
<mgz> in which case yeah, installing the trac plugin won't help you.
<vila> jam: hmm, {} has no meaning why would you want to warn/error instead of just leaving it alone ?
<neoZ7> mgz: I have a single panel diff already, by checking the (o) unidiff option on bottom, but it doesn't look as nice as the one I posted. I have @, + and - signs, that's too raw for my taste.
<mgz> neoZ7: I suggest filing a bug against qbzr (which is what supplies the diff window for bzr explorer) saying exactly what improvements you'd like to the single panel view
<jelmer> vila, hmm, yeah. I think I'll file a separate bug about it.
<vila> jelmer: mention it in a comment && approve ;)
<jelmer> vila, merci
<mgz> neoZ7: you can also set it to use an external program to do the diff, if you can find one that does what you want
<mgz> neoZ7: like in https://launchpad.net/bzr-difftools but qbzr has its own mechanism (I think you can set it in the explorer options somewhere)
<mgz> that link has a list of like ten programs you could try
<davi_> jelmer, hi, regarding bug 544776, when changing the mapping registry to git-experimental, do i also have to remove the existing idmap or it can be re-used?
<ubot5> Launchpad bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,In progress] https://launchpad.net/bugs/544776
<jelmer> davi_: You should be able to reuse it.
<jelmer> emphasis on should :)
<davi_> yeah, i tried some weeks ago and it failed, was checking whether it should work or not :)
<davi_> anyway, will try again (just for fun, it won't work because all of the memory usage in the later stage..). thanks
<jelmer> davi_: You were trying to push mysql into git right?
<davi_> jelmer, right
<jelmer> davi_: You should be able to use "bzr push -r10" to push just ten revisions, but it will still try to update the full git map beforehand
<davi_> jelmer, that should work then, updating the git map is feasible. thanks
<jelmer> davi_: let me know how/if it works
<vila> urgh, can't run the test suite for 2.2.5 ? Like... not even one test : AttributeError: 'module' object has no attribute '_WritelnDecorator'
<vila> I'm good to dig into testtools/subunit ancestry...
<vila> or may be just ask which are used on pqm
<mgz> use Python 2.6 vila.
<vila> mgz: hmm, yeah, a bit better
<vila> AttributeError: 'module' object has no attribute 'Feature' 8=)
<vila> ha, better with BZR_PLUGIN_PATH=-site
<vila> AttributeError: 'module' object has no attribute 'ExtendedTestResult'
<vila>     capture = testtools.tests.helpers.ExtendedTestResult()
<jelmer> vila, for new options, what do I need to do other than just registering them in the option registry?
<vila> 2.2 was requiring >= 0.9.2
<vila> jelmer: depends on where you expect to find them
<vila> jelmer: if it's only in bazaar.conf, register and then use GlobalStack where GlobalConfig was used before
<vila> jelmer: what kind of option is it ?
<jelmer> vila: It's a branch (or global) option
<jelmer> vila: where do I obtain a BranchStack?
<vila> jelmer: nowhere, yet :-/
<jelmer> vila: Ah, ok
<jelmer> vila: I'll just use get_user_option for the moment
<vila> jelmer: fine
<vila> as long as the option name makes sense it won't be hard to migrate
<vila> jelmer: is it just a string or some more specific type (bool, int) ?
<jelmer> vila: what are the plans for BranchStack?
<jelmer> vila, it's just a string (default_bugtracker)
<vila> argh
<jelmer> hmm?
<vila> well, stacks supports defaults, it's a shame you add to create a new option for that :-/
<vila> the plan for all stacks is to be obtained from a registry
<jelmer> it's not really a default default, perhaps I should just call it "bugtracker"
<jelmer> it's default in the sense that that's what's used if no bugtracker was specified on the command-line
<vila> jelmer: bug #823036
<ubot5> Launchpad bug 823036 in Gephi "AttributeRangeFilter returns main graph when nothing matches filter" [Undecided,Confirmed] https://launchpad.net/bugs/823036
<jelmer> euhm, sure..?
<jelmer> :P
<vila> >-/
<vila> jelmer: bug #832036
<ubot5> Launchpad bug 832036 in Bazaar "Needs a config stack registry" [High,In progress] https://launchpad.net/bugs/832036
<vila> haaa :)
<jelmer> vila: I think Branch needs a get_store() option, rather than defaulting to BranchStore, which is bzr specific.
<jelmer> s/option/method/
<vila> jelmer: hmm, because foreign branches cannot provide the necessary... what... transport, lock, branch.conf ?
<vila> jelmer: it's already fine if branch.conf doesn't exist though
<jelmer> vila: yes, but they'd want to provide something else
<jelmer> vila: they currently have a custom implementation of BranchConfig
<vila> jelmer: oh, I didn't know that
<vila> jelmer: well, the stack registry should returns a factory, and this factory will receive a branch object and be responsible for returning a config stack, so that could be addressed here (including via a branch.get_store() for that matter)
<vila> jelmer: I'll have a look at the custom impls. which plugin is it ?
<jelmer> vila: e.g. bzrlib.plugins.svn.config
<jelmer> I think that's the most advanced one at the moment
<jelmer> bzr-git is supposed to support something similar in the future, but dulwich doesn't do config files jus tyet
<vila> jelmer: wow, I didn't read it for quite some time... looks similar to what stacks are targetting (including the uuid matching), what is use_global ?
<vila> jelmer: uuid are unique inside a given .conf file right, .bazaar/svn.conf and one section by uuid ?
<jelmer> vila: svn has per-repository UUIDs
<vila> yup
<jelmer> vila: but yeah
<jam> Riddell: are you still around? One comment about the 'release-notes' file, we generally sort the entries alphabetically
<vila> and you use them a shared conf options for all the branches in a given repo ?
<jelmer> [a9308255-753e-0410-a2e9-80b3fbc4fff6]
<jelmer> layout = trunk2
<jam> that way we conflict less when merging
<jam> (since my news entry is Foo is faster, and yours is Bar is less buggy, they end up in different sorted spots.)
<Riddell> jam: oh really, I hadn't noticed that
<jelmer> vila: that's useful as some repositories are accessible using multiple URLs
<jam> Riddell: I'll fix up the ones I see
<vila> jelmer: right, and you use that as defaults or overrides ? Hmm, not even that, you use that as a 1-1 relationship for a repo.conf except it's not stored in svn, correct ?
<jelmer> vila: it's one of the stores in the stack, so to speak
<vila> exactly
<jelmer> less important than locations.conf, more important than the global conf
<vila> right, so defaults (not overrides), except that you never redefine 'layout' in a branch right ?
<vila> jelmer: so, yeah definitely worth a separate store where sections are the uuids
<vila> jelmer: I'd like the general case to be path for sections, but I'm all for specific stores if needed so this case fits nicely
<jelmer> vila: cool
<vila> jelmer: the missing bits for you to switch are: the stack registry, migrating the config command and supporting --section --store
<vila> jelmer: which are high on my config TODO list
<vila> jelmer: just below my current work on expansion in fact
<jelmer> vila: being able to provide the stack and store from Branch too
<vila> jelmer: well, you will be able to define any key you need in the registry and any context too
<jelmer> vila: other plugins need to be able to access a bzr-svn-specific stack without having to know about the special UUID store, for example
<vila> jelmer: should be possible
<jelmer> vila: what is the purpose of the registry exactly?
<vila> jelmer: get the right config stack for a given context
<vila> jelmer: for most of the cases, a branch will need a single stack, but there may be exceptions for some options
<vila> jelmer: the uuid store targets some specific options right ?
<jelmer> vila: no, it's usable for any options
<jelmer> I've used it to set append_revisions_only, for example
<vila> jelmer: hmm
<jelmer> vila: BranchStack seems to hardcode BranchStore at the moment, which isn't usable for foreign branches
<vila> jelmer: right
<vila> jelmer: the *Stack are helpers for now
<vila> jelmer: restricted to the migration needs
<vila> jelmer: if bazaar.conf was supporting sections as path to provide default values, would you still need the uuid store for a_r_o ?
<vila> jelmer: path or URL for that matter
<jelmer> vila: yeah, because the svn repository can be accessible over multiple protocols
<jelmer> typically anonymous access over svn:// and authenticated over svn+ssh:// or http:// and https://
<vila> wow
<vila> jelmer: but if you define it for a uuid, it means it applies for all branches right ? You don't have a way to discriminate between branches ?
<jelmer> vila: no
<vila> jelmer: though this problem is also true for locations.conf and remote branches accessed via http: or bzr+ssh:
<jelmer> but that's still useful as it's typically one project per repository
<vila> yup, got that
<jelmer> vila: I can imagine other situations where it might be useful manipulate the stack
<vila> jelmer: hmm, so, that still fall under the stack registry scope
<vila> jelmer: may be, but have you considered using multiple stacks instead ?
<jelmer> vila: how do you mean?
<vila> jelmer: what manipulations are you thinking about ?
<vila> hehe :)
<vila> jelmer: well, compare BranchStack and RemoteBranchStack
<jelmer> vila: The problem is, bzr-svn can't control what stacks its users would use
<vila> jelmer: the later is targeted at a single option (which name escapes me at the moment, the one spiv migrated)
<vila> jelmer: in which case ?
<vila> jelmer: if a bzr-svn branch is involved the registry can query the branch for a given context
<jelmer> vila: either way - I can't make people look at ~/.bazaar/subversion.conf when they e.g. retrieve their username, while I can atm
<vila> jelmer: don't consider BranchStack as a definitive answer ;)
<vila> jelmer: that should be fixed then
<jelmer> that's what I was hoping for :)
<vila> hehe
<vila> jelmer: right now, I don't know exactly what the factory returned by the stack registry will work, but the idea is that since it's a registry, you can perfectly override the 'branch' key there to insest your own that will take subversion.conf into account and provide the relevant section iff an uuid is available around
<vila> jelmer: the section list itself is built lazily so you don't even have to answer the uuid matching until an option is queried
<jelmer> cool
<vila> jelmer: there may be edge case where this breaks :)
<vila> jelmer: like needed a branch with enough state which can be obtained only with a given option but from an bird's eye view such cases sound broken by design
<vila> jelmer: and should already break today anyway ;)
<vila> jelmer: ho, and was is use_global=False ?
<vila> s/was/what/
<jelmer> vila: whether to look at the global config or not
<jelmer> (I think)
<vila> jelmer: look or write ?
<jelmer> vila, read
<vila> yeah, it looks like you use it for your specific options...
<vila> haaaa, so you can get the relevant one based on the uuid ?
<vila> jelmer: anyway, we should definitely pair when you start migrating ;)
<jelmer> vila: heh, sure
<vila> jelmer: hmm, waitasec, do you know other options than a_r_o that can be defined in subversion.conf ?
<vila> jelmer: or are there *all* the options that can be defined in branch.conf ?
<jelmer> vila: all the options that can be in branch.conf can also be in subversion.conf
<vila> ouch
<vila> hehe, ok
<vila> EOD here, food for dreams ;)
<jelmer> :)
<jelmer> bon appetit :)
<vila> thanks ;)
<santagada> is there any graphical ui for interactive merges?
<santagada> qmerge and bazaar explorer don't have this
<santagada> everyone does --interactive only?
<jam> santagada: I know some people do the merge, when it generates a conflict, they resolve it with a gui like kdiff3 or meld
<jam> using the .BASE, .OTHER, THIS files on disk
<jam> santagada: I thought "bzr-extmerge" also had support for defining a custom merge program that would fire during 'bzr merge'
<AuroraBorealis> the bzr docs mention a 'verify signatures' command for verifying signed commits, but my bzr doesn't have it, did it get removed?
<AuroraBorealis> also, after signing commits, the branch doesn't say that it was changed, so what exactly did it do? o.o
<davi_> jelmer, fwiw, push with a existing idmap failed with a assertion error: Invalid sha for <Commit [â¦]
<davi_> jelmer, bzr push -r n still tries to push all revisions
<jelmer> davi_: what bzr are you using?
<jelmer> davi_: it does update the id map for all revisions here, but it doesn't push more than I specify with -r
<davi_> jelmer, bzr 2.4.0
<jelmer> davi_, are you sure it's the push that tries to do the full set of revisions, and not the id map update?
<davi_> jelmer, huh, could be. i left a bzr push running which will make a new id map
<jelmer> davi_: just running "bzr git-objects" in the bzr branch should update the idmap
<jelmer> after that the push shouldn't have to touch it unless more bzr revisions are added
<davi_> ok. let me try...
<davi_> davi@skynet:~/repo/5.5$ bzr push -r 10 ~/git-repo/
<davi_> \ determining revisions to fetch 30199
<davi_> davi@skynet:~/repo/5.5$ bzr push -r 2 ~/git-repo/
<davi_> \ pushing revisions 5/69505
<davi_> jelmer, ^
<jelmer> hmm
 * jelmer tries locally
#bzr 2011-09-02
<jam> morning all
<vila> hey jam
<vila> morning all
<Riddell> good morning
<jelmer> moin
<vila> jelmer: Riddell " moin
<Riddell> oneiric beta's out, time to upgrade everyone!
<poolie> hi Riddell, jelmer, vila
<poolie> vila, so there's no pressure for a 2.3.5 or 2.4.1 yet?
<vila> worth a check but I think we're fine there
<poolie> so 2.2.5 is mostly for the sake of branch-out-of-date warnings?
<vila> I should file a bug probably if only to collect feedback about what the upgrade policies are across ... err... whatever combination of python/subunit/testtools we want to support on ... hardy, lucid and up ?
<vila> so far yes, there is also #805809 but it's unclear that many people can/will encounter it
<jam> vila: if you're just doing "date" on pqm, it tells you the timezone
<vila> jam: UTC then
<vila> jam: but it makes the file stamp origin even more... surprising
<vila> jam: any guess for that ?
<jam> vila: I'm not 100% sure what those timestamps are, let me dig a bit
<jam> vila: 'the file timestamp', is that mtime or ctime?
<jam> (last modification time, creation time)
<jam> its pretty clear that your file times don't correlate well with your datestamps
<vila> jam: I mean the stamp embedded in the file *name*
<jam> vila: I think that might be the time it was submitted, which could certainly vary wildly from when the test starts
<vila> jam: so patch.1314909400.log ==> 2011-09-01 22:36:40
<vila> jam: you mean received ?
<jam> vila: sure
<jam> given that 2 of them are about 3 seconds different
<jam> 2011-09-01 13:03:31: duration: 2:53:02 start: 2011-09-01 15:18:26, end: 2011-09-01 18:11:28
<jam> 2011-09-01 13:03:34: duration: 2:07:47 start: 2011-09-01 18:13:16, end: 2011-09-01 20:21:03
<jam> that can certainly be "submit submit"
<jam> but it won't be running a test in between there
<vila> jam: vary, yes, depending on load, but *after* selftest starts ???!?!?!
 * jelmer will bbiab
<vila> jam: yeah, I noticed the 3 seconds
<jam> vila: not-be-reliable-at-all-because-it-has-nothing-to-do-with-when-the-test-starts
<poolie> hi jam?
<vila> jam: well, the file *has* to exist before we write into it
<jam> hi poolie
<poolie> hey, see my pm?
<jam> poolie: I did not
<jam> ugh, there it is
<vila> jam: so it *has* something to do with when the test starts...
<jam> vila: given the lack of significant correlation, I would ignore it personally
<jam> or read the pqm code to figure out what the number means
<poolie> vila, hey, i'm kind of concerned this pqm investigation is ..
<poolie> being done in a laborious way, i suppose
<poolie> i want the test suite to be fast again
<poolie> IS are working on replacing the machine
<poolie> separately we could look at tarmac
<poolie> hopefully this particular setup has a life expectancy of only days or weeks
<poolie> but, do as you think best i suppose
<jam> poolie: I have a patch that just removes fsync, and I'm happy enough that it fixes the short term issues
<jam> its about 2:1
<poolie> wfm
<poolie> ok, good night then
<vila> poolie: well, I agree with all you've said above, that was my understanding weeks ago when I realize the slowdown (i.e. wait for the new pqm before anything else), as you've seen the patch was minimal and I didn't spend much on it
<poolie> ok
<vila> jam, poolie, jelmer, Riddell : thanks for not targeting lp:bzr/2.2 with your landings today, other branches are fine, will slow me down a bit, but I can work on other stuff
<jam> vila: I shall never submit to your tyranny!
<jam> and vila, you're probably not going to get a merge window before tomorrow, unfortunately
<jam> I'm counting about 12 hours of PQM before your 2.2 branch
<jam> vila: unless you want to prioritize: https://code.launchpad.net/~jameinel/bzr/2.4-disable-selftest-fdatasync-837293/+merge/73757 before the rest :)
<vila> jam: hehe
<vila> yeah, I went to the pqm web page after saying this and... well, the point is: once 2.2.5 lands, I'll need to pull and submit again to open 2.2.6, so please leave 2.2 alone until you see the opening
<danilos> jam: hi, thanks for the review â I think I'll just go with what I have now, just because HTTP headers seem to be set already and I'd have to restructure the code a bit otherwise to be able to raise a HTTPNotFound instead
<jam> danilos: I don't think the headers are sent until we actually start sending data
<jam> but I could be wrong
<danilos> jam: also, LP seems not to have picked up on your "merge:approve": I think you've got to use something like " merge approve\n review approve"
<jam> danilos: no, I just need "merge: approve" vs "merge:approve" I was missing a ' '
<jam> merge approve auto review approves
<danilos> jam: I've actually tried it out and got "AssertionError: Attempt to set headers a second time w/o an exc_info"
<danilos> jam: oh, nice, I didn't know that :)
<jam> danilos: yeah, saves typing
<jam> so sure, go ahead and land it
<danilos> jam: thanks, I will
<danilos> jam, can you please mark it as approved so it doesn't appear as unapproved on the bug (https://code.launchpad.net/~danilo/loggerhead/bug-839395/+merge/73766)
<ubot5> Ubuntu bug 73766 in Bazaar GTK+ Frontends "Remove file does not update view to show file is removed" [Undecided,Fix released]
<danilos> ubot5, very smart, thank you
<ubot5> danilos: I am only a bot, please don't think I'm intelligent :)
<danilos> that's what I said!
<jam> danilos: its marked Merged now, I don't think you need me to regress it back to Approved :)
<danilos> jam: I thought you'd only do a vote, not touch the entire proposal status, but I guess no big deal :)
<jelmer> jam: hi, does bug 839515 look familiar to you?
<ubot5> Launchpad bug 839515 in bzr (Ubuntu) "bzr crashed with BzrCheckError in _commit_write_group(): Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:3c52a9038699157dee61f9bd1b03d255fa021805',)]" [High,Triaged] https://launchpad.net/bugs/839515
<jelmer> I remember there were some stacking bugs that were fixed a while ago that looked similar. Could this be fallout from those bugs?
<jam> jelmer: that specifically looks like the bug that made us default to not fetching tags
<jam> but it does appear that the *.../ubuntu branch is broken
<jelmer> jam: thanks for confirming
<AuroraBorealis> so continuing my question that i didn't get answered, what exactly does 'signing' your commits do? since after signing mine, the branch appears unchanged
<jelmer_> AuroraBorealis, with newer versions of bzr you can see the signatures by running "bzr log" with a particular option
<AuroraBorealis> does that include 2.4.0?
<jelmer_> AuroraBorealis: I'm not sure, it might just be bzr.dev at this point
<AuroraBorealis> it seems natty doesn't have 2.4.0 yet o.o
<jelmer_> AuroraBorealis, though bzr has supported creating signatures since before 2.0 I think
<AuroraBorealis> so should i push my local branch over my remote one to get it to have the signatures?
<AuroraBorealis> since i did it on my local branch, it says that no changes were made
<jelmer_> I'm not sure if we fill in signatures yet, I think we just fetch the signature for a revision when we fetch the revision
<AuroraBorealis> and it seems that at least in 2.3.4, the verify signatures option went away
<jelmer_> AuroraBorealis, there is a verify-signatures command in 2.4 IIUC
<AuroraBorealis> hmm
<jelmer_> AuroraBorealis: the verify signatures option in 2.3.4 had been there for a while but wasn't actually implemented, which was why it was removed
<AuroraBorealis> ah.
<AuroraBorealis> so the entire signing thing needs some more work to actually be useful :3
<jelmer_> AuroraBorealis: you can use "bzr verify-signatures" today
<jelmer_> AuroraBorealis: so it is useful, though there are some more improvements we should make
<AuroraBorealis> well i'm on linux and it hasn't upgraded xD
<jelmer_> it should be in oneiric
<AuroraBorealis> i appear to be in natty
<jelmer_> AuroraBorealis: you can use the bzr PPA for 2.4.0 (should work on natty), or otherwise be patient for another two months
<AuroraBorealis> is the ppa this? https://launchpad.net/~bzr/+archive/ppa
<jelmer_> AuroraBorealis, yep
<Riddell> should I be worried that the test bzrlib.tests.test_setup.TestSetup.test_build_and_install is failing for me in trunk?
<vila> Riddell: locally or only on pqm ?
<Riddell> locally
<vila> then yes
<vila> and I feel your pain :-/
<AuroraBorealis> and yay i made bzr crash
<Riddell> actually it might be due to my new install
<AuroraBorealis> and yeah, verify -signatures don't work :<
<AuroraBorealis> i guess i'll file a bug report, after my bagel
<Riddell> vila: yes it was just that I didn't have everything installed
<vila> Riddell: so it fails on on pqm now ? Missing dependency there ?
<vila> s/on on/only on/
<Riddell> vila: no it only ever failed locally
<vila> ha cool
<vila> just out of curiosity what did you fix ?
<Riddell> vila: sudo apt-get build-dep bzr
<vila> ha, well, yeah ;)
<jo-erlend> I've started working with bzr and I'm really loving it. But I'm a newbie t this, and VCS in general, and I'd like to learn how to actually work with it... I mean, I currently have one directory on my computers, called ~/devel/appname and an lp bzr repository that I push to.
<AuroraBorealis> and? :3
<jo-erlend> and that's good, but I'm only using one branch. I'd now like to start experimenting more widely with my app, so I thought I'd setup different branches to work with, and then merge with a main branch, that in turn is pushed to lp from time to time.  Is it simply a matter of using different directories, or are there other things to consider?
<AuroraBorealis> you have your main branch
<AuroraBorealis> and then you just branch from that
<AuroraBorealis> do stuff with it
<AuroraBorealis> and when you want to merge it back, merge the main one with the other one
<AuroraBorealis> so yeah pretty much the second branch will be a seperate folder inside the repo folder
<jo-erlend> ok, so instead of having my code in ~/devel/appname, I'd have it in ~/devel/appname/trunk, /testing, etc? And the ~/devel/appname directory would only contain branches?
<AuroraBorealis> usually appname is the repository
<AuroraBorealis> trunk is the 'main deveopment branch'
<AuroraBorealis> and then testing can be a seperate branch where you are doing experimental stuff
<AuroraBorealis> then you can merge testing back into trunk and whatever
<jo-erlend> yes, that's what I meant in my question. What does that look like?
<jo-erlend> does it mean I'll have my code in appname and subdirectories of that directory will contain the branches? Or will other branches be in the same parent as the trunk?
<AuroraBorealis> appname is the repository, it stores revisions and stuff
<AuroraBorealis> and everything below that is a branch
<jo-erlend> ok, so it wouldn't make much sense for appname to be versioned?
<AuroraBorealis> well i'm just assuming that the folder appname is a repository
<jo-erlend> right.
<AuroraBorealis> so its not really versioned, it just holds branches
<jo-erlend> unless that requires additional setup. It's only a directory here.
<AuroraBorealis> you have to run bzr init-repo or create it in bazaar explorer
<AuroraBorealis> see: http://doc.bazaar.canonical.com/latest/en/user-guide/shared_repository_layouts.html?highlight=repository
<AuroraBorealis> and http://doc.bazaar.canonical.com/latest/en/user-reference/repositories-help.html?highlight=shared%20repository
<jo-erlend> ok, and that is self contained so it doesn't matter if I change the name of the directory later?
<AuroraBorealis> the name of the repository or the branch?
<AuroraBorealis> i dont think it matters, because the actual information is in the .bzr directory in the repo / branches
<AuroraBorealis> but it will changes obviously the URI of the repo =P
<jo-erlend> :)
<jo-erlend> AuroraBorealis, great links. That's precisely what I was looking for :)
<AuroraBorealis> the thing about bazaar is that it supports multiple models
<AuroraBorealis> so you can do it like git does, or svn and whatnot
<gdoubleu> Using bzr-svn here, and somehow I've got a file that bzr considers versioned but that doesn't exist in the svn repo
<gdoubleu> if I try to bzr remove the file, bzr ci, bzr dush, then I get a "SubversionException: ... path not found" error
<gdoubleu> any ideas on how this can be corrected?  Can I safely add the file using svn and then bzr pull the change into the bzr repo?
<gdoubleu> On a related note, other than diff'ing an export from the bzr repo and svn repo, is there any way to check if there might be other files/contents out of sync between the bzr branch and the svn repo?
<jo-erlend> hmm. I had a branch on launchpad that I was working on .I then proposed a merge for upstream, and it was accepted. Now the branch is gone. Is that normal?
<jo-erlend> oh, it's just hidden. But is it a bad idea to keep working on that branch after it's been merged with upstream, or will that simply mark it as unmerged?
<amaora> test
<sixstring> I've got bzr (client) setup just fine on one machine. But when I try to branch on a second machine, I get SSH key madness. Any idea how to make SSH or BZR happy? Do I need to copy my keys from one machine to another?
<sixstring> Apparently, you just scp them to the target machine, from ~/.ssh/
<jelmer> gdoubleu: what version of bzr-svn are you using?
<poolie> hi jelmer
<jelmer> poolie: g'day!
<vila> hey poolie, jelmer ;)
<jelmer> hey vila
<jelmer> This is just wrong. when I get home on a Friday evening it ought to be quiet on IRC...
<fullermd> Maybe your calendar crashed.
<vila> ok, I'll mute myself ;)
<poolie> it's saturday morning, i'm at google working on the lca programme
<jelmer> poolie: I guess you're excused then; vila however... :-P
<vila> Oh, you went there too ?
<vila> jelmer: Me ? Can't have fun with the importer anymore ?
<jelmer> vila: :)
<vila> We need to record imports success instead of import failures: http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29
<vila> This curve going down is not getting us enough positive feedback :-p
#bzr 2011-09-03
<icehi> hi.  in bazaar, is there a way of removing, say, the top three changesets from my repository, and applying the changes to my working directory?
<vila> icehi: s/repository/trunk, master branch, shared branch, remote branch/: yes
<vila> icehi: if you start with your working tree its parent branch pointing at the same revisions, 'bzr merge -r-4..-1' should give you just that
<vila> icehi: tri it and look at 'bzr st' and 'bzr diff' to check
<vila> icehi: 'bzr revert' to cancel the attempted merge
<vila> icehi: alternatively, use 'merge --preview' if you don't want the changes to be applied to your working tree
<icehi> does that actually delete the changesets from the repository?
<icehi> i want to use commits as temporary patches, apply them all to my working dir, and delete them from the log
<vila> icehi: no changes are ever deleted from a repository, in bzr lingo, a repo is just a place you put changes
<vila> icehi: what matters is the branch history and whether these revisions are part of it ir not
<icehi> i'm basically looking for a way to 'shelve' changes temporarily
<vila> icehi: 'bzr shelve --help' ?
<vila> but shelves apply only to uncommitted changes
<vila> icehi: 'bzr log' (or 'bzr qlog', its graphical equivalent) shows the branch history
<icehi> can i shelve multiple changesets in bzr?
<icehi> or is it just a single patch
<vila> shelves are not part of the branch history, they are changesets what were never committed to any branch, so they don't appear in any branch history
<vila> but you can have as many shelves as you want in a working tree
<icehi> okay, i might give bzr a try
<icehi> i use hg right now, but there is no simple way of shelving/unshelving in hg at the moment
<vila> icehi: you're welcome ;)
<vila> icehi: check http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief , it's a good Rosetta stone for refugees (it's a wiki)
<icehi> thanks.  does bzr support git-diff format?
<jelmer> icehi: if you have the bzr-git plugin installed you can use "bzr diff --git"
<jelmer> sorry, "bzr diff --format=git"
<icehi> thanks
<idnar> bleh, is there any way to have ~/.bazaar/locations.conf override everything?
<idnar> err
<idnar> *not* override everything
<meoblast001> hi, i'm a little confused
<meoblast001> i have a .bzrignore in the root of my project, but it only lists things to ignore in the root directory
<meoblast001> there is no .bzrignore in other directories
<meoblast001> yet, it seems it's ignoring the files i told it to ignore in those directories
<meoblast001> if these ignores are not in the root .bzrignore file, will they be ignored for others too?
<jelmer> meoblast001: hi
<meoblast001> hi jelmer
<jelmer> idnar: I don't think there is a way to do that at the moment; the idea is that locations.conf can be used to override per-branch behaviour (e.g. for remote branches)
<jelmer> idnar: Vincent's config improvements might help with that, though you'd probably have to ask him.. I'm not sure about the details
<jelmer> medberry: I'm not sure if I follow, .bzrignore can only be in the root of the tree
<meoblast001> jelmer: well, it doesn't contain the files i want to ignore within subdirectories
<meoblast001> can i just add *.pyc to bzrignore?
<meoblast001> and it ignore all pyc files in the entire project
<jelmer> meoblast001: yes, if you just add *.pyc it will ignore them everywhere
<jelmer> although I believe *.pyc is already in the global bzr ignore file
<meoblast001> ah, thanks :)
<AuroraBorealis> so, if you have a shared repository within another shared repository, it stores all the stuff in the top most repository?
<AuroraBorealis> cause it seems that way based on my old branches but it says nothing about it in the docs :o
<jelmer> AuroraBorealis: it uses the first shared repository it finds when browsing up the directory stack
<AuroraBorealis> it appears to be going up two repos
<AuroraBorealis> cause i had like java/class1/trunk, and class1 and java are repos, and it seems to be storing stuff in 'java'
<AuroraBorealis> according to the nice new branch location information
<AuroraBorealis> or maybe i'm wrong cause this is on my server, hmm
<AuroraBorealis> no i'm just being silly. you seem to be right =P
#bzr 2011-09-04
<jelmer> jaj.
<jelmer> argh
<jelmer> glad to hear that, otherwise we'd have a nasty bug on our hands :)
<AuroraBorealis> its because "location information" shows the shared repositiory on the local disk
<AuroraBorealis> not necessarily the one on the server
<ESphynx> hey guys, I'm trying to use bzr-git with dulwich here, and I get this  'bzr: ERROR: No module named posix' erro ? any idea?
<mgz> ESphynx: this is on windows I take it?
<mgz> look at your .bzr.log for the traceback showing where the import is happening
<ESphynx> yes!
<ESphynx> mgz: I've figured out it was in bzr-git's workingtree.py
<ESphynx> i've commented that 'import posix' line out and then it worked
<mgz> it sounds like a bug, the normal thing to do is `import os` which then resolves the correct platform functions
<ESphynx> then I got this other error
<ESphynx> which I found in a post that I should add 'raise' on top of a line
<ESphynx> on top of the delete_tree line...
<ESphynx> a db in use type thing, and now that I added that I get a whole bunch of new errors :(
<mgz> it sounds like bzr-git is just not tested (at all) on windows.
<ESphynx> http://pastebin.com/qT5RcBLr
<mgz> hm. that one might need jelmer magic to understand.
<ESphynx> the line I added as 'raise' on top of             to_transport.delete_tree('.')
<ESphynx> in bzrlib/builtins.py
<ESphynx> Without that 'raise', I get: bzr: ERROR: Permission denied: "E:/bzr/sdk/./.bzr/repository/git/idmap.db": [Error 32] The process cannot access the file because it is being used by another process: u'E:/bzr/sdk/./.bzr/repository/git/idmap.db'
<ESphynx> I've waste more than enough time on this, so I think I'll opt for launchpad importing my git repo for me :|
<ESphynx> jelmer :)
<ESphynx> you're the magician?
<mgz> jelmer, does the error in <http://pastebin.com/qT5RcBLr> say anything to you?
<jelmer> hey mgz
<jelmer> ESphynx: mawho ? :)
<ESphynx> <mgz> hm. that one might need jelmer magic to understand.
<jelmer> hmm, that's a tricky one
<ESphynx> jelmer how about:  Without that 'raise', I get: bzr: ERROR: Permission denied: "E:/bzr/sdk/./.bzr/repository/git/idmap.db": [Error 32] The process cannot access the file because it is being used by another process: u'E:/bzr/sdk/./.bzr/repository/git/idmap.db'
<ESphynx> that was  'raise' on top of             to_transport.delete_tree('.')
<jelmer> ESphynx: ah, you're on windows?
<ESphynx> I am
<ESphynx> Mainly because Ubuntu random freezes on my system :P
<ESphynx> (I find that quite depressing)
<mgz> there seem to be a few shallow problems with bzr-git on windows (importing posix as well as os), perhaps also so subtle ones that can cause revisions to go missing?
<jelmer> mgz: I wouldn't be surprised\
<jelmer> ESphynx: can you try running "bzr selftest -s bp.git" ?
<ESphynx> Would I have been aware of that, I would have tried it on Linux :P but now I set up bazaar etc. on Windows and don't feel like doing it again, I had launchpad auto-import it for me :P
<ESphynx> sure I can try that
<ESphynx> bzr: ERROR: No module named testtools
<ESphynx> I get this too now with my version from source: bzr: warning: some compiled extensions could not be loaded; see <https://answers.launchpad.net/bzr/+faq/703>
<jelmer> ESphynx: hmm, yeah, you'll need testtools to run the testsuite
<jelmer> ESphynx: you haven't build the C extensions, which means you'll get less than optimal performance
<ESphynx> why did they not build?
<jelmer> ESphynx: did you try to build them ? :)
<ESphynx> Cython and Pyrex missing?
<mgz> probably you don't have cython or pyrex, again .bzr.log will tell you what exactly you don't have
<mgz> it's not (or shouldn't) be relevent for correctness, only speed
<ESphynx> don't take this the wrong way, i'm trying to be constructive here ;) but all this is way too complicated to setup folks :P
<mgz> yup.
<ESphynx> of course the bugs don't make it easier :P
<mgz> we have easy (installer with lots of stuff added), but if you want to do more on top of that you need to be okay with compiling C python extensions and such like
<ESphynx> jelmer: Would it be helpful if I install the testtools?
<mgz> ESphynx: I'll do it here to save you the bother.
<ESphynx> I got launchpad importing from github directly so I don't care anymore at this point, but I'm all for helping fix open source software :P
<ESphynx> mgz thanks man :)
<mgz> if you could file a bug against bzr-git for your original `import posix` problem with the traceback, that would be helpful
<jelmer> ESphynx: dulwich/bzr-git isn't really tested on Windows, so if it works that's mostly luck. It would be nice to get it to the point where it does work though :)
<mgz> and maybe that one where you added a raise too, if there wasn't one already
<ESphynx> jelmer it would :)
<ESphynx> mgz: that was from a launchpad bug comment
<ESphynx> that's where I got the idea
<mgz> great, what was the bug number?
<ESphynx> let me try to find it :)
<ESphynx> mgz: https://bugs.launchpad.net/bzr-git/+bug/734145/comments/14
<ubot5> Ubuntu bug 734145 in Bazaar Git Plugin "NoSuchId error applying inventory delta" [Medium,Triaged]
<mgz> great, so jelmer knows about that one :)
<ESphynx> oh, right, he's the one who suggested raise :P
<ESphynx> didn't light up here :P
<mgz> file the import posix bug and I'll see how much of this I can quickly squash
<ESphynx> k
<ESphynx> mgz https://bugs.launchpad.net/bzr-git/+bug/841177
<ubot5> Ubuntu bug 841177 in Bazaar Git Plugin "import POSIX in workingtree.py breaks on Windows" [Undecided,New]
<mgz> thanks ESphynx!
<ESphynx> yh :) I've otherwise had more success with launchpad importing it for me: https://code.launchpad.net/ecere =)
<ESphynx> yw*
<jelmer> just removing the posix import isn't sufficient - we need stat_result
<ESphynx> oh.
<mgz> using os instead should be fine though.
<ESphynx> os is already there :P
<mgz> indeed,
<mgz> meh, fastimport as well?
<jelmer> fastimport is used for testing
<mgz> what's the lp project name?
<mgz> python-fastimport and bzr-fastimport too I guess.
 * mgz continues branching and building
<mgz> ...and sqlite?
<mgz> dammit, now I need to rebuild python
<mgz> okay. with ESphynx's bug fixed, I get on the test suite: FAILED (failures=1, known_failure_count=1)
<mgz> Ran 211 tests in 4.875s
<mgz> FAILED (failures=1, known_failure_count=1)
<mgz> and a bunch of non-fatal file lifetime issues
<jelmer> mgz: what's the remaining failure?
<mgz> it's shallow, seem to just be expecting a nix-style file: url in a repr
<mgz> the file lifetime issues seem more relevent
<mgz> I'll put up a mp or two for you.
<jelmer> mgz: cool, thanks
<mgz> okay, that was a pain but it worked finally
<mgz> jelmer: http://float.endofinternet.org/xmlbin/bp.git
<mgz> click little coloured boxes for details, the yellow ones are various warnings about file usage etc
<jelmer> mgz: that still indicates one failure
<mgz> yeah, I had to fix my runner, so haven't fixed that test yet :)
<jelmer> mgz: hah, ok
<jelmer> mgz: awaiting your mps ;-)
<jelmer> mgz: does stat_result have the same contents on Windows?
<mgz> the tests pass :P
<mgz> I think the struct in posixmodule.c has only one definition, it's only how it's populated that is platform dependant.
<mgz> I will double check
<mgz> well, nearly. the ifdefs only kick in on the 14th item
<mgz> so they way you're constructing it is portable.
<mgz> whoa, weird conflicts thing in the diff, I wonder how I messed that up.
<mgz> using uncommit and push twice was probably pretty bogus, I should have just let one branch depend on the other
<mgz> ah, I didn't, you were just already touching that code while I was fiddling with my test runner
<jelmer> mgz: posixpath is correct, the index file always contains slashes
<mgz> yeah, and I think the bug I just filed is mistargetted, I can reproduce it without plugins
<mgz> looks like a bzr 2.5 regression
<mgz> food first, then I'll fix that...
<mgz> jelmer: so the good news is bzr-git kicks ass and just branched a big git repo locally in windows no problem
<mgz> the bad news is bzr itself is broken on trunk and the blame is on one of your colo changes :)
<jelmer> mgz: heh, ok
 * jelmer is still working on getting more bzr.dev tests passing against bzr-svn
<jelmer> down to ~140 failing ones now
<mgz> okay, so _win32_extract_drive_letter is broken if given a url to a drive with no trailing slash
<AuroraBorealis> isn't there a python function that gives you the drive letter?
<mgz> this is for file urls, which python didn't have proper handling for
<AuroraBorealis> hmm.
<mgz> but... why is the drive being used here at all? bzrdir is stripping off all the directories for reasons I don't understand
<AuroraBorealis> i dunno xD
<AuroraBorealis> what file is this?
<mgz> bug 841322
<ubot5> Launchpad bug 841322 in Bazaar "IndexError branching from one windows dir to another" [Medium,New] https://launchpad.net/bugs/841322
<AuroraBorealis> extract_drive_letter looks correct
<AuroraBorealis> since its just stripping off /C:
<AuroraBorealis> and then returning the rest of the string
<mgz> what's not correct is `if len(path) < 3` ... `path[3]`
<mgz> needs to either be `< 4` or not index the fourth character
<AuroraBorealis> the len(path) < 3 seems right
<AuroraBorealis> because if its less then 3, then its just C:
<AuroraBorealis> or it can't be a valid path cuase you need the drive letter
<mgz> this is in the context of file urls
<mgz> and I'm not certain if file:///C: is valid or if it needs to be file:///C:/
<AuroraBorealis> so what are file urls? just file://<whatever> ?
<mgz> different implementations give me different results at least :)
<mgz> ^it's a bit more than that
<AuroraBorealis> i dunno much about the bzr code base but this still seems right
<mgz> throwing an IndexError off a string isn't ever really correct
<mgz> either we need to raise an exception saying the url is invalid,
<mgz> or handle it.
<AuroraBorealis> hmm the code changed from when i last checked out
<AuroraBorealis> so or path[2] not in ':|' or path[3] != '/': is throwing the index out of range?
<mgz> read as "/C:"[3] != "/"
<AuroraBorealis> so there needs to be a check to see if the url is less then 4 then
<AuroraBorealis> or 3
<AuroraBorealis> depending on what you were talking about
<mgz> then there's the problem of LocalTransport.abspath trying to produce such a thing
<AuroraBorealis> its hard to see whats going on >.>
<AuroraBorealis> are you trying to fix it? my code is going to conflict if i update cause i'm changing things
<mgz> feel free to fix the bottom level function, that needs doing whatever
<mgz> the rest of it, as you say, is tough to comprehend
<AuroraBorealis> localtransport.abspath?
<mgz> or I guess Transport.__init__? I'm not really sure where to put the blame
<AuroraBorealis> i can try to take a look but i'm pretty noobish at this codebase xD
<mgz> okay, I'm pretty sure the rstrip there wants changing, you can't just strip abitrary urls
<poolie> hi all
<jelmer> 'evening poolie
<poolie> hi there
<mgz> hey poolie!
<poolie> hello mgz, how are you?
<mgz> rather short of sleep and stressed, but I've had this evening to hack on things at least :)
<poolie> i'm sorry to hear about that first part
#bzr 2012-08-27
<mardy> hi! I'm trying to update the upstream, but one of my debian patches now fails to apply -- I have no idea how to proceed, someone can please give me a hint?
<mardy> it's a package maintained in merge mode
<mardy> (shotwell)
<tbf> http://doc.bazaar.canonical.com/latest/en/user-guide/organizing_your_workspace.html - is there also an easy in-tree workflow
<tbf> i really don't like to reconfigure my build environment every time i start a new feature branch, or i switch between them
<mgedmin> you're looking for colocated branches
<mgedmin> there's some kind of support for them in latest bzr releases; before that there was a plugin
<tbf> mgedmin: http://doc.bazaar.canonical.com/developers/colocated-branches.html? this looks good. now let's figure out if bzr 2.5.1 already has them
<jelmer> tbf: 2.5.1 only has some of the API work
<jkcaj> Hello!
<jkcaj> I'm new to IRC.  Can anybody see this?
<jelmer> jkcaj: hi
<jkcaj> Hi.  How am I doing?
<jkcaj> Better yet, how are you doing?
<jelmer> jkcaj: :-) Alright
<jkcaj> I'm looking for help with Bazaar version control.  Can you help?
<jkcaj> I think I'm in the wrong place.  I'm going to sign off and go someplace else
#bzr 2012-08-28
<mgz> morning
<vila> mgz: morning
<mgz> hey vila!
<ChristopheT> Has any of you experienced the bug https://bugs.launchpad.net/bzr-git/+bug/1042102 ?  Do you know a workaround?
<ubot5> Ubuntu bug 1042102 in Bazaar Git Plugin "dpush "overrides" commits" [Undecided,New]
<jelmer> ChristopheT, that's a known issue
<mgz> ...a workaround would be to just manually check if the branches have diverged before you use dpush?
<jelmer> mgz: yes
<ChristopheT> jelmer: I did not find a previous report of this.  Is there one?
<ChristopheT>  "manually check": sure but I am sure I am bound to forget now and then!  Maybe a hook?
<jelmer> ChristopheT, I don't see one either yet
<jelmer> ChristopheT, I guess you could implement it as a hook
<jelmer> ChristopheT, though if you have time to spare, a patch would also be great
<ChristopheT> jelmer: the question is: is it possible? "bzr hooks|grep push" returns "post_push:" only...
<ChristopheT> jelmer: I'd like to try to understand the issue better (and possibly provide a patch).  I find the issue very annoying...  Where do I start (I guess I also need pointers to understand git protocol or is it just the way bzr handles it)?
<jelmer> ChristopheT, you'll need some knowledge of the bzr and git models
<jelmer> ChristopheT, the relevant code would be in bzr-git's branch.py
<jelmer> in fact, there is already a FIXME for this
<mgz> ChristopheT: `bzr alias dpush=remember-to-check-if-branch-has-diverged`
<mgz> ...that should be annoying enough to make you want to fix the actual bug instead :)
<mgz> you'd need `bzr alias dpush-yes-i-checked=dpush` too.
<ChristopheT> jelmer: what quick reference do you recommend to get acquainted with git model (I do not even really use git, my coworkers do!).
<jelmer> ChristopheT, the dulwich tutorial is a good start, and has some links to further docs
<ChristopheT> jelmer: If I understand correctly, the dulwich library possesses the needed functions; the problem is to use them appropriately in bzr-git.
<jelmer> ChristopheT: basically
<jelmer> ChristopheT: or, hmm
<jelmer> ChristopheT, the problem is that git doesn't allow remote graph access so the standard bzr functions don't work to check for diversion
<jelmer> euhm, divergence
<jelmer> ChristopheT, so you'll have to check locally whether the current remote head is an ancestor of the proposed head (and --overwrite wasn't specified)
<ChristopheT> jelmer: If I undertand correctly, there is a FIXME missing in InterFromGitBranch._basic_push since it is the code used by the commands in the bug report, right.
<ChristopheT> As a short term "solution", I am wondering if is is not better to add an --overwrite flag to dpush (which is what it does ATM) and output an explanation if it is not set.  That will avoid users tripping over this issue and wondering what they have done wrong...
#bzr 2012-08-29
<mgz> morning!
<mgz> hey jelmer.
<jelmer> hmm, botched quantal upgrade :(
<mgz> ...what did you do, jelmer?
<jelmer> mgz: I ran apt-get upgrade ? :-)
<jelmer> uninstalled vim and broke my X
 * jelmer files bugs
<mgz> ah, you're on quantal and did an upgrade
<mgz> not that you just dist-upgraded to quantal from precise and things broke
<mgz> we're short of people to say rude things about uninstalling vim
<mgz> as for X being broken though, how can you tell?
<jelmer> mgz: bits are where other bits should be
<mgz> sounds like normal behaviour to me!
<eridu> hi, is this an appropriate venue to ask questions about bzr-git?
<eridu> I'm running into lp:818318, and I'd appreciate help getting my changeset into github by any means necessary, but optimally without breaking one or both systems
#bzr 2012-08-30
 * jaimef hunts for the bzr fetch/update
<jaimef> ahh pull
<mgz> morning
<jam> morning mgz, any luck on the ppa stuff?
<jml> why you no build daily for quantal?
<mgz> there was some discussion on list about what value we were getting from dailies
<mgz> but the short answer is because no one has set it up
<jml> ah right
<jml> well, basically, I want to patch core a couple of times for better colo branch support
<jml> but I'm not really interested unless I get to use the patches
<jml> I guess I could just add ~/src/bzr to my PATH or something
<mgz> I tend to use setup.py install --user
<mgz> but a daily for quantal is probably reasonable.
<mgz> it's only really the dailies on older (non-lts) releases that were really questioned
<mgz> so... I could go around adding precise in the recipes everywhere and see what breaks, then go crying to maxb
<vila> mgz: you meant 'adding *quantal*' ?
<mgz> I should mind my p-s and q-s...
<jml> heh heh
<jml> man, so long since I've hacked on bzr
<mgz> hm, dulwich ftbs currently...
<mgz> quilt error on:
<mgz> Applying patch 01_less_strict_index_tests
<mgz> patching file dulwich/tests/test_index.py
<mgz> should be safe to just pop that patch
<mgz> bah, not paying attention, why is bzr-build(?:er|deb) installing postfix on this vm...
 * jml gives up and files a bug instead
<maxb> It is probably time that we should be turning on dailys for quantal
<maxb> My value argument is mainly against maintaining dailys for more than the current stable and current development release
<mgz> maxb: I've flipped a few things on and will try to remember to see if there are any new build failures reported
<tbf> ...if the main branch moves forward it happens that feature branches develop merge conflicts. is there a better way to solve such issues, than to create a new branch from the main branch and then merge the conflicting feature branch into the new feature branch?
<tbf> ...if this'd be git i'd just rebase... but well.
<jam> tbf: that doesn't get rid of merge conflicts, it just moves them into the rebase. If you just merge from trunk you can resolve the conflicts in the feature branch without creating yet-another-one.
<tbf> jam: of course: i'll have to resolve the conflicts at some point
<tbf> jam: let's try
<tbf> how does bzr chose its submit branch?
<tbf> looks like "bzr info" is showing me total nonsense
<LeoNerd> Surely, whatever is named in .bzr/branch/branch.conf ?
<jelmer> LeoNerd, and ~/.bazaar
<santagada> how do I fork a branch in launchpad?
<santagada> the obvious bzr branch lp:... then bzr push lp:~myuser/branch takes a looong time so it apears to be wrong
<santagada> shouldn't this be almost instantaneous? or at least not take a long time on the client?
<mgz> santagada: the push is slow?
<mgz> you probably aren't pushing back to the right location
<mgz> eg, I branch lp:bzr, and push back to lp:~gz/bzr/name_of_my_feature
<santagada> mgz: it needs the bzr?
<santagada> and where can I find this documentation
<SamB_MacG5> Hmm... How come INSTALL and setup.py state different minimum required versions of Python?
<mgz> SamB_MacG5: doc bug in INSTALL, please feel free to branch lp:bzr/2.4 fix, and propose
<mgz> note cElementTree is in python 2.6 core so that bit is also wrong
<SamB_MacG5> mgz: Yes, I could swear I've seen somewhere else that mentioned cElementTree as required by bzr but said something about it being bundled in some versions of Python.  (It might have been referring to a version of bzr that actually supports Python 2.5, though.)
<mgz> SamB_MacG5: looks like doc/en/admin-guide/introduction.txt also needs updating
 * SamB_MacG5 absently wonders how updates to translations are handled
<SamB_MacG5> oh, huh, so 2.5 also includes cElementTree
<mgz> I tend to update trivial command name changes and stuff in all of them, but leave wording changes for native speakers
<mgz> for the admin-guide, there are no translations to worry about at least.
<SamB_MacG5> I was more thinking about the problem of figuring out which bits have changed and (likely) need retranslation
<mgz> `bzr log -l1 doc/ja` to get N last rev translated docs were changed, then `bzr diff -rN..-1 doc/en` and update would do
<SamB_MacG5> makes that gettext-based thing aptitude uses sound like fun, it does!
<mgz> gettext is bad enough in general, using it on whole documents even uglier
<mgz> (bzr actually does something like that for command help, splits things up into paragraph looking things and hopes, but it's not a very nice way of working)
<SamB_MacG5> what would *you* use to track up-to-date/fuzzy/untranslated paragraphs and such?
<mgz> I've never really done any translation. Does not seem to be a solved problem though.
<SamB_MacG5> at least with ReST like you're using, it presumably isn't terribly tricky to explain which markup should cause something to be considered on its own...
<SamB_MacG5> Unlike with docbook and such
 * SamB_MacG5 realizes he doesn't need to google for the software, he has an Emacs window open to his Debian box and can just check the source tree for aptitude...
<SamB_MacG5> ah, it's called po4a
 * SamB_MacG5 has to go
<mgz> bye!
<jelmer> SamB_MacG5, the minimum required version should be 2.6
<SamB_MacG5> okay, what's the *maximum* supported version of Python for bzr 2.4?
<fullermd> 2.7, pretty sure.
<SamB_MacG5> Hmm, what should become of the bullet items in http://doc.bazaar.canonical.com/developers/code-style.html#python-versions ?
<SamB_MacG5> are those things now good?
<SamB_MacG5> or are there other reasons any of them shouldn't be allowed?
<fullermd> Well, anything talking about pre-2.6 is certainly OBE.
<SamB_MacG5> OBE ?
<fullermd> Overtaken By Events
<SamB_MacG5> And there's a paragraph in http://doc.bazaar.canonical.com/developers/ui.html#progress-and-activity-indications that hinges on Python 2.4's lack of finally blocks in generators
 * SamB_MacG5 wishes bzr's docs were in .rst files and/or that Emacs' dir-locals mechanism was a *bit* more expressive ... for example, supporting filename wildcards instead of just modes to act on ...
<fullermd> Hm, that works fine in vim.  Maybe you should upgrade  8-}
<SamB_MacG5> ... don't you have little cookies at the ends of the files for vim?
<fullermd> Well, you could do that too.  But I have all sorts of glob'd up paths in .vimrc for setting this&that.
<SamB_MacG5> I'm sure I could do something in ~/.emacs ...
<fullermd> Probably.  If nothing else, you could throw together a quick little filesystem implementation that indirects through the raw disk device...
<SamB_MacG5> but it would be nicer if something adequate could be added to the repository (regardless of whether or not it would actually be accepted)
<SamB_MacG5> something that says "all the .txt files in this tree should be assumed to be in ReStructuredText format"
<SamB_MacG5> I had something that almost worked, but it ended up redirecting `log-edit-mode' to `rst-mode' too, so I that's a bust...
<SamB_MacG5> soo ... how come nothing seems to link to http://doc.bazaar.canonical.com/developers/win32_build_setup.html ?
#bzr 2012-08-31
<milleja46> anyone know how to fix http://pastebin.com/haeK7p0J? I'm on mac if it helps...
<milleja46> but it's more of a key error I guess
<milleja46> anyone? I can't even checkout branches on my computer because of this key error and I gave launchpad my ssh public key that I generated....
<lifeless> lets see
<lifeless> milleja46: check you have the right username
<milleja46> I should....because I use the same username on launchpad...
<milleja46> yea same id I set on bzr as my launchpad-login is listed under my profile on launchpad....
<lifeless> you might try ssh-add
<lifeless> check that ssh can see the identity
<milleja46> how would I check with that command?
<milleja46> well too bad he's gone I was going to thank him for his help >_<
<mgz> morning!
<jam> morning mgz
<jam> how's bzr-2.5 coming today?
<jelmer> hi mgz, jam
<jelmer> jam: So, db-devel-bzr-2.5.1 ran through ec2 successfully yesterday
<jam> great
<jelmer> jam: so I'm hoping to get it cowboyed on staging today
<mgz> hm, annoying
<jelmer> mgz: who is?
<jml> :)
<jelmer> mgz: new try:
<mgz> even gazillionier faster?
<fullermd> Gaaah, stupid can't-resolve freakin conflicts.
<mgz> fullermd: which ones, just for my edification?
<fullermd> Removed directories.  They don't go away until you manually type every zarking last one of them in.
<mgz> want to know if the branches I have up will solve your pain
<mgz> ah, great, they will.
<fullermd> Or swing the "resolve --all" sledgehammer, but that's WAY too big.
<fullermd> Oh?  That would be nice.
<mgz> okay, so, I need to push through the branches I have up, then you can rm -rf then `bzr resolve`
<fullermd> I was just seeing if I'd filed a bug about it, and I did.  5 years ago.
<mgz> not quite the "make `bzr rm` do the right thing" you asked for in the bug, but nearly
<fullermd> Yeah, that'd be close.
<fullermd> Actually, this particular case, I'm not sure it should be a conflict anyway.
<fullermd> Giant directory tree, that was removed.  I happened to have a few scraps floating around in it.
<fullermd> So when I update'd, I got a giant pile of "can't remove dir because it's not empty" conflicts.
<fullermd> I guess it's not entirely insensible in general for that to be a conflict that sticks around bugging you in stat/etc forever, but it sure is in this case.
<mgz> that's the ignored junk/precious problem, which is part of what has gunked people up who wanted to get this fixed
<fullermd> Well, I dunno.
<fullermd> I mean, it shouldn't _delete_ the files, sure.
<fullermd> Or even move them aside, probably.
<fullermd> And if they were versioned files, deleting the dir absolutely should be a conflict.
<fullermd> But they weren't.  Why is it a conflict that the now-unversioned directory just can't be deleted?
<fullermd> The junk/precious would be more like a dir becoming versioned, and what to do with the existing unversioned dir of the same name with files in it.
<mgz> well, you can set vila's config option I can never remember the name of to move them
<fullermd> Furrfu.
<fullermd> Repository checkout (format: 1.9)
<fullermd> I really should get around to fixing that one of these days...
<mgrandi> so
<mgrandi> has anyone had any luck dpushing to a bitbucket git repo?
<mgrandi> cause i'm getting 'invalid repo syntax'
<mgrandi> now i cant get it to just push to a regular localhost git repo =/
<mgrandi> so i dunno if oyu are there jelmer
<jelmer> mgrandi, hi
<jelmer> mgrandi, still there?
<mgrandi> yeah
<mgrandi> i figured it out, you answered it in a launchpad question thingy
<mgrandi> but i agree its very confusing
<mgrandi> https://answers.launchpad.net/bzr-git/+question/148313
<jelmer> ah
<mgrandi> but yeah that should be fixed
<mgrandi> also, i can't seem to dpush to bitbucket, have you had any luck with that?
<jelmer> mgrandi: dpush doesn't create new branches yet, that's the issue
<jelmer> mgrandi: I think that should work - how does it fail?
<mgrandi> let me create a separate bitbucket thingy, one sec
<mgrandi> bitbucket responds with 'conq: invalid repository syntax.'
<mgrandi> with git bzr dpush git+ssh://git@bitbucket.org:mgrandi/myscriptstmp.git,branch=master
<mgrandi> i cloned the empty bitbucket git repo, added a file so it created branch master, pushed that to bitbucket, then tried to run that ^
<jelmer> mgrandi: that's not a valid URL
<jelmer> mgrandi: : is used to separate hsot and port
<jelmer> mgrandi, you want / rather than : there
<mgrandi> thats how bitbucket shows the url
<mgrandi> Clone this repository (size: 580 bytes): HTTPS / SSH  / SourceTree
<mgrandi> $ git clone git@bitbucket.org:mgrandi/myscriptstmp.git
<jelmer> mgrandi: that's not a URL, but a git-specific location specifier
<mgrandi> ah
<jelmer> git+ssh://git@bitbucket.org/mgrandi/myscriptstmp.git,branch=master
<mgrandi> well i changed it to a slahs, it seemed to work but then it says "bzr: ERROR: The file id "None" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x10fb39ed0>.                           "
<jelmer> mgrandi, that's just a bug in dpush from bzr-git I suspect; it's all still experimental
<mgrandi> ok
<mgrandi> it converted it to git at least for the other repo that i cared about, so its all fine and dandy =)
<jelmer> cool
#bzr 2012-09-01
<SamB_MacG5> okay, so I got this branch merged into 2.4, anything I should do to get it merged also in 2.5 and bzr.dev? https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6
<mgrandi> if you propose to merge into 2.5 and trunk they will review it i believe
<SamB_MacG5> merge from where, 2.4 or my branch?
<mgrandi> go to the link you pasted and click 'propse for merging'
<mgrandi> and then select the branch, probably lp:bzr-2.5 or whatever its called, and lp:bzr (need to do it twice)
 * SamB_MacG5 wishes he could start by cloning https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6/+merge/122168 ...
<mgrandi> i mean thats pretty much what happens
<mgrandi> when you click "propose for merging"
<mgrandi> just link the same bug report
<mgrandi> actually you don't eve need to do that, the bug is already linked
<mgrandi> just propose to merge into the trunk bzr branch and the 2.5 one
<SamB_MacG5> This really doesn't look right, though... https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6/+merge/122377
<SamB_MacG5> in fact, some irrelevant (for my purposes) changes have conflicts ...
 * SamB_MacG5 wonders why the 2.5 code from this conflict wasn't backported, rather than being re-written from scratch ...
 * SamB_MacG5 realizes that these conflict markers leave out the "ancestor" bits ... 
 * SamB_MacG5 grumbles at jam, who is evidently not here anyway ...
<mgrandi> yeah they are all on in like..5 hours! haha
 * SamB_MacG5 accidentally adds a second review request ... how did the first one get there?
 * SamB_MacG5 specifically left that box unchecked to start with...
<PMS> Why is Bazaar better than Mercurial? :)
<quotemstr> What do I need to do to resolve "bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting"?
<quotemstr> I just added a change to trunk, merged, and then tried to push.
<quotemstr> I'm not trying to change history. What gives?
<fullermd> PMS: bzr has 3 A's; hg only has 1.  So it's 3x better.
<fullermd> quotemstr: AppendRevisionsOnly prevents changes to the mainline.  So you did something like 'branch off trunk ; make changes ; merge changes to trunk since initial branch ; try pushing over trunk"
<fullermd> Which means the 'new' revs on trunk are now no longer on your mainline, ergo it disallows it.
<fullermd> The resolution would be either (a) merge into trunk and push, rather than merging trunk and pushing, or (2) unset a_r_o, if you don't really want it.
<quotemstr> fullermd: I don't control the remote, so it sounds like I really need two local branches.
<quotemstr> fullermd: One in which I make changes and occasionally merge from trunk, and another slaved to upstream, into which I only ever merge changes from the first branch, then push.
<fullermd> Yeah, it's simplest to keep a 'pristine' trunk for gating things upstream.
<fullermd> Maybe as a checkout; that expresses intent well.
<vila> fullermd, mgz: bzr.transform.orphan_policy=move
<quotemstr> So if I merge a change from branch B into branch A, what happens to the commit messages attached to the changes in B?
<quotemstr> bzr log just displays the merge commit message.
<quotemstr> Is there a way to make history linear instead
<quotemstr> ?
<fullermd> It's in there, log just doesn't expand out the merges by default.
<fullermd> With '-n0' it'll show all the merged revs.
<quotemstr> Ah, okay. Thanks.
<quotemstr> Okay --- I have branches A and B. A is the pristine upstream branch; B is the forked dev branch.
<quotemstr> I merged B into A, and bzr log -n0 shows B's commit as a child of the merge commit into A.
<quotemstr> I pushed from A, then pulled into B. Now B's log matches A's and the trunk's.
<quotemstr> But didn't that pull just silently change the history in B? Now B has a merge commit where it previously had a direct commit.
<fullermd> Not exactly.  It changed the _mainline_, but merely appended to the history.
<fullermd> Neither push nor pull will ever do more than append new revs (unless you smack it with --overwrite).  a_r_o additionally prevents you from appending revs in such a way that the mainline changes.
<quotemstr> So the mainline is a _linear_ series of commits. Pull only adds commits, but it can change this "mainline" path that connects them. Right?
<fullermd> Not...   exactly.  May be close enough for understanding, but I generally feel compelled to over-explain...
<fullermd> The mainline is a subset of the revisions in the branch, chosen by taking a particular path through the history.
<fullermd> It winds up creating a purely linear series.  In the event of a branch with purely linear history (i.e., no merges), it winds up being equivalent to the whole history.
<fullermd> But most nontrivial branches have merges, so the mainline goes down one side of that history and elides the other.
<fullermd> The result, in a loose colloquial sense, becomes a list of "commits made on this branch" (as distinct from "commits made elsewhere and merged into this branch").
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering   may be helpful
<fullermd> Anyway, it happens via backtracking in a certain way from the head rev of the branch.  So any time the head changes, the mainline potentially can change (well, it DOES change, by getting new stuff appended to it.  It may change by stuff that previously wound up on it not doing so anymore; that's what a_r_o prevents)
<fullermd> In the case of your pull there, you appended history; the previous head rev is still in the history, which means all the stuff before it is too.  You only added new revs to the pile.
<fullermd> But the mainline changed, because the path you get from walking back using the particular rules from the _new_ head rev doesn't include the old head.
 * fullermd wanders off for a little while, content that he's thoroughly confused what was once somewhat clear.
<quotemstr> No, that makes sense. Thanks.
 * SamB_MacG5 would have told PMS that bzr has a better command parsing API; mercurial's seems to be all lists of tuples, which presumably makes it hard to improve without breaking existing plugins/extensions
<SamB_MacG5> so, can anyone tell me what to do with https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6/+merge/122377 ?
 * SamB_MacG5 suddenly recalls having dreamed that he ran into water in a channel called #bazaar
<jelmer> hi SamB_MacG5
<SamB_MacG5> jelmer: hi
<jelmer> SamB_MacG5, I'm not sure I follow your comment
<jelmer> why does this have extra revisions that aren't on lp:bzr/2.5
<jelmer> ?
<SamB_MacG5> jelmer: because it was originally made for lp:bzr/2.4
<SamB_MacG5> and it hadn't occurred to me to start my branch with a common ancestor of lp:bzr{/2.4,/2.5,}
<SamB_MacG5> hmm, how would I even *do* that?
 * SamB_MacG5 wonders why git makes hard things easy and easy things hard ...
<vila> SamB_MacG5: you don't ;)
<vila> SamB_MacG5: but did you merge lp:bzr/2.5 before making your proposal ?
<fullermd> Oh, it's easy to get a common ancestor.  Just branch rev 1   ;p
<SamB_MacG5> fullermd: You know very well that that's not what I meant!
<fullermd> When has that ever stopped me?   O:-}
<vila> SamB_MacG5: you don't know fullermd very well ;)
<SamB_MacG5> fullermd: yeah, usually doesn't stop me, either
<SamB_MacG5> Regardless, I was clearly referring to a function like that specified in git-merge-base(1)
<SamB_MacG5> er, or not.
<SamB_MacG5> I hadn't seen what it did in the more-than-two-args case yet ...
<fullermd> The usual answer is probably something like "run missing, and backstep manually (mentally)".
<SamB_MacG5> I couldn't get missing to work for some reason :-(
<SamB_MacG5> it kept telling me everything was up to date
<fullermd> In this particular case, you could cheat and know that 2.4 gets merged into 2.5 aperiodically (and never the reverse), so just scroll through the 2.5 log until you see the last 2.4 merge and take that rev.
<SamB_MacG5> true
<vila> or just merge lp:bzr/2.5...
<fullermd> That wouldn't give you something mergeable into 2.4  ;p
<fullermd> ... well, it WOULD, but you'd have to sneak it through...
<vila> my understanding is that the patch has already been landed in 2.4
<jelmer> SamB_MacG5, just propose a merge to the oldest branch you care about
<jelmer> SamB_MacG5, that branch will be periodically upmerged
<SamB_MacG5> okay, so I should delete this proposal since I already did that?
<SamB_MacG5> (In this case, the oldest branch it makes sense for is 2.4, since it's updating documentation to account for the Python dependancy having been upped to Python 2.6 at that point ...)
 * SamB_MacG5 waits for someone to confirm that he should delete before pushing the button
 * SamB_MacG5 wishes bzr had a functional syntax for revisions ...
<SamB_MacG5> jelmer: I should delete my proposal, then, since my branch is already merged into lp:bzr/2.4 ?
<jelmer> SamB_MacG5, I tihnk so
 * SamB_MacG5 discovers that his IRC client is under a hilarious dual license
<SamB_MacG5> Oh, it looks like that's just the YAML library ... still ;-)
 * SamB_MacG5 gripes about Python's broken SIGINT handling
#bzr 2012-09-02
<SamB_MacG5> whoops, I reported a bug against bzr when I meant to report it against qbzr ...
 * SamB_MacG5 fixes
<gumnos> Is there an easy way to just get bzr to spit out the hash of the current checkout?
<gumnos> (something like "git rev-parse HEAD")
<SamB_MacG5> gumnos: have you checked "bzr help hidden-commands"?
<gumnos> I just stumbled across it and am fighting with "version-info" which seems to be my best bet.  However it's spewing lots of unneeded detail
<SamB_MacG5> gumnos: look at the help for that command, I think you'll find what you want ;-)
<gumnos> I keep poking at it, but can't get it to just give the ID.  Lots of other stuff keeps coming along for the ride.  Trying bzr version-info --template='{revision_id}'
<gumnos> ah...I'm missing "--custom"
<SamB_MacG5> yeah, I have no clue why --template doesn't imply --custom ...
<gumnos> okay, it's working now with version-info --custom --template '{revision_id}'
<gumnos> thanks for prodding me along until I got it
<SamB_MacG5> you're welcome
 * SamB_MacG5 wonders if the FSF Europe admits requires Fellowship applicants to be european
 * SamB_MacG5 notices that all these ".html" hyperlinks in the documentation work *really* well in the PDF output ...
#bzr 2013-08-26
<anonym> hi
<anonym> hello all
<jelmer> hi anonym
<serg> I'd like to discuss a patch/fix for https://bugs.launchpad.net/bzr-git/+bug/351317
<ubot5> Launchpad bug 351317 in Bazaar Git Plugin "file ids are not very unique" [Wishlist,Triaged]
<serg> it shows no activity since 2010, so I'd rather ask here
<serg> anyone?
<jelmer> serg: hi
<serg> hi
<jelmer> serg: I can offer some opinions on that bug :-)
<serg> so, at the moment I'm mainly interested to know the problems that my suggested solutions might have
<serg> thanks
 * jelmer looks at the patch
<jelmer> serg: it looks like you're basically adding the revision id that the path was introduced in?
<serg> yes
<serg> exactly
<serg> it makes file ids unique
<serg> and stable
<serg> in the sence that one can fork, merge, uncommit/pull, etc
<serg> and file ids won't change
<serg> probably even roundtripping will work
<serg> but I personally don't need it
<serg> one can also rename files in the bzr repo (branched from git)
<serg> that will work too
<jelmer> serg: this breaks renames
<jelmer> serg: so, for the basic case this approach works well I think
<jelmer> there a couple of issues that I can see:
<jelmer> - it breaks all existing bzr-git imports
<serg> sure, I understand that
<jelmer> - it's quite common in git to have multiple additions of the same file done independently ("parallel imports"). This makes it impossible to merge those with bzr (since they'll have different file ids)
<serg> what does "multiple additions of the same file done independently" mean?
<jelmer> - this breaks renames (though no worse than before) - once you push the renamed file into git it'll get a new file id when you pull it back into bzr
<jelmer> serg: if I work on a branch that's based on a release tarball, the files in that branch will have a different file id than the upstream branch.
<serg> was that a feature? that users can create a branch from a release tarball? it never worked in bzr, I didn't expect people to do that in any vcs
<serg> but okay
<jelmer> serg: it doesn't work in bzr because of file ids, but it works particularly well in git
<serg> this can never work with any stable bzr-like file ids, for this feature to work one must track files by names
<jelmer> serg: right, this was one of the reasons we were looking at path tokens (an alternative to file ids)
<serg> okay. so if my approach kind of works for my usage pattern (I understand, you agreed with it), I can keep a private branch of bzr git. But because of migration issues and this "tarball" git feature, this my patch can never be the only bzr-git behavior. now, the last question
<jelmer> serg: I posted some thoughts here: https://lists.ubuntu.com/archives/bazaar/2011q2/072368.html
<serg> jelmer: if you'd like I can polish it a bit and add as an option, so that one can enable it, say, per-branch
<serg> fixing what can be fixed, and keeping fundamental issues up to the user's decision
<jelmer> serg: note that it breaks the testsuite at the moment
<jelmer> serg: I think it would be reasonable to have it as an optional thing
<serg> sure, if you'll want to make it generally usable, I'll fix the test suite
<jelmer> serg: there is actually already a config variable you can use to set the bzr-git mapping method for a branch
<serg> I must've missed it, I did look. sorry :)
<jelmer> serg: I think it would be reasonable to have as a patch; nobody is maintaining bzr-git at the moment though
<serg> my use case is to pull various mysql/mariadb extensions into mariadb tree. not pushing back though
<serg> okay, thanks. I'll try to fix the patch, then
<jelmer> serg: that's from git into bzr or the other way around?
<serg> mariadb is in bzr
<serg> extensions - in bzr or git
<serg> from git into bzr. from many trees into one
<jelmer> ah, I see
<jelmer> serg: I don't actually see the option for overriding the mapping anymore; it might have been removed at some point.
<serg> no problem, now that you've mentioned it, I can dig it up in the history, and hopefully the comment will explain why it was removed
<jelmer> serg: are you already using this workflow?
<serg> I was pulling from another bzr tree. but only now I'm starting to pull from 3 git repos
<serg> and they have COPYING, README.md, and - particlarly annoying src/ and include/
 * serg could live with COPYING and README being clashed into one file
<jelmer> serg: if you need reviews/help landing stuff, feel free to ping me here
<serg> thanks! I'll need to fix the patch first (add an option, fix tests, etc)
<serg> one problem is that once we start using this approach, it'll be difficult to change it, so I wanted to be more confident that it works. Thanks for your help
<jelmer> serg: do you have control over the git repositories?
<serg> no
<jelmer> serg: there are some open issues in bzr-git that might affect you
<jelmer> if one of the repositories uses submodules or signed tags, that will break bzr-git
<serg> I see. So far it worked, if it'll break, I'll need to figure something out, may be add a fix to bzr-git
<jelmer> see pad.lv/963525, pad.lv/1084403
<serg> what was the story with the second bug going to "fixed" and back few times?
<jelmer> serg: see the comments - somebody who is not involved with bzr-git marked them as fixed
<serg> ah, "not involved", ok. (I thought it's one of your developers, who might've had a different opinion, or something)
<jelmer> serg: he spammed launchpad by changing the status of a large number of bugs
<jelmer> also, s/developers/developer/ :-)
#bzr 2013-08-27
<alexlist> Hi... I am re-familiarizing myself with packaging and could need some advice ... is anyone using the (experimental) 3.0 (bzr) source format here?
<mgz> I don't think so
<Wiz_KeeD> hey guys
<Wiz_KeeD> How can i set a bzr repo on a server from which i can push locally via ssh to make changes?
<mgz> just create a branch on a server you have ssh access to
<Wiz_KeeD> with bzr-init repo
<Wiz_KeeD> and the bzr init
<Wiz_KeeD> ?
<mgz> or any other means of getting a branch on there, scp from local, for instance
<achiang> 'allo, someone checked large binary files into our tree; i am bzr rm'ing them now, but is there a way to wipe them from history too, so that pulling the branch doesn't take forever?
<spiv> achiang: not easily
<achiang> bleah
<spiv> achiang: probably the easiest path is to make a new repository from just before the point the large files were added, then rebase the later history on top.
<achiang> spiv: ok, that seems doable
<achiang> spiv: thanks
<spiv> Yeah, it's doable.  Just not what I'd call easy :)
<achiang> "The downside to cherrypicking is that Bazaar does not track cherrypicked revisions, although this feature is firmly on the wish list."
<achiang> does this mean when i cherry pick revisions, i don't get changelogs and individual commits?
<achiang> (because that is what i experimentally observe)
<jelmer> achiang: basically
<achiang> jelmer: thanks
<jelmer> achiang: it sounds like what you want isn't actually cherrypicking tracking though - since you don't care about the relation to the old history
<jelmer> you want to have a look at "bzr replay" from the bzr-rewrite plugin
<achiang> jelmer: looking
<achiang> jelmer: thanks, replay does what i want, except did i find a bug in how it handles revspecs?
<achiang> jelmer: i did: bzr replay -r4..9 ../otherbranch
<achiang> jelmer: and i would have expected it to commit r5, r6, r7, r8, and r9 into 'currentbranch'
<jelmer> achiang: it's experimental, and has some known issues
<achiang> jelmer: instead, it committed r4, r5, r6, r7, and r8
<achiang> jelmer: fair enough, just giving a heads up that i think the behavior is different from what standard 'bzr merge' does...
<achiang> from the bzr merge man page:
<achiang> If you specify two values, "--revision BASE..OTHER", only revisions BASE
<achiang>   through OTHER, excluding BASE but including OTHER, will be merged.
<achiang> so it's like (a, b]
<achiang> but what i got from replay was [a, b)
<achiang> or rather, how replay handled the -r arg was [a, b)
<rozzin> Who should I be bothering about a Windows build of Bazaar 2.6.0?
<mgrandi> Hello, i'm curious about how bazaar 'handles' renaming of directories
<mgrandi> Renaming a directory
<mgrandi>     does not count as renaming all its contents.
<mgrandi> sorry, that is a comment in delta.py, and sure enough if i get the delta of a revision that renamed a directory, the stuff inside the directory is not in any of the DeltaTree lists
<mgrandi> err TreeDelta*
<mgrandi> so basically i have a post commit hook that is interfacing with another version control system, and when i rename a directory i dont see that any of the stuff inside gets renamed so...im confused on how bazaar handles this
<lifeless> the directory is a first class object itself
<lifeless> objects in a directory tree are (parent, name, kind, mode, content) tuples, basically.
<lifeless> a rename occurs when either parent or name change.
<lifeless> For instance bzr mv foo bar
<lifeless> changes the name
<mgrandi> yeah
<lifeless> and bzr mv foo/file bar/file
<lifeless> changes the parent
<lifeless> when you rename a directory: bzr mv dir1 dir2
<mgrandi> so, how do i detect or figure out when a directory has changed for instance? like in a post_commit hook
<mgrandi> or is there no nice way to do that
<lifeless> the children of dir1 keep the same parent, and the same name.
<lifeless> look at the kind
<mgrandi> hmm.
<mgrandi> So im guessing there is no nice way to do that
<mgrandi> and i just have to see if its a directory
<mgrandi> and then figure out all the 'children' of that directory then rename them in the hook? (for the other vcs)
<lifeless> Your question has it's own answer: to see when a directory has changed, see if the thing that has changed is a directory.
<mgrandi> yeah.
<mgrandi> I just have to figure out whats in that directory and rename those as well
<mgrandi> I'm using bazaar to interface with "team foundation server'
<lifeless> yes; you'll want to exclude from that any things that have been moved outside of the directory as part of the same commit
<lifeless> mgrandi: someone wrote a tfs plugin
<lifeless> mgrandi: you could just use that :)
<mgrandi> haha that would be great
<lifeless> I *think* they released it, not sure.
<mgrandi> mine is just a simple post commit hook that just runs add/edit/remove/rename on the tree delta stuff
<mgrandi> but then silly things like...tfs doesn't rename stuff inside directories like bazaar does
<mgrandi> if you could find that, that would be great.
<mgrandi> is it this? https://launchpad.net/bzr-tfs
<lifeless> sounds like it :)
<mgrandi> seems like it doesn't work on 2.6, maybe have to edit it a little bit..
<mgrandi> its trying to register a custom transport, but the method it wants isn't there anymore
<mgrandi> BzrDirFormat.register_control_server_format(TfsControlFormat)
<mgrandi> any idea where that got moved to?
#bzr 2013-08-28
<lifeless> mgrandi: sorry no, since my time
<jelmer> mgrandi: you want ControlDirFormat.register_server_prober() I think, but that's not quite the same as .register_control_server_format()
<mgrandi> TfsControlFormat is a subclass of BzrDirFormat if that helps any
<jelmer> mgrandi: yeah, that's the old style mechanism for registering/probing formats
<mgrandi> hmm ok
<mgrandi> What should it be using? i might try and make this plugin work for 2.6
<Wiz_KeeD> hey guys
<Wiz_KeeD> If i have a bzr repository that has in it another bzr branch
<Wiz_KeeD> Is there a way I can subversion that as well?
<Wiz_KeeD> I pull multiple branches from launchpad and include them into one big pack which I'd like to push on a server
<Wiz_KeeD> Without updating all the small branches individually
<Wiz_KeeD> what can i do to solve that?
<Wiz_KeeD> anyone?
<Wiz_KeeD> nobody?
<maxb> I'm confused. How does Subversion fit into any of this?
<Wiz_KeeD> how come?
<Wiz_KeeD> I make a project with 4-5 modules i build
<Wiz_KeeD> and one module that is pulled from somewhere else
<Wiz_KeeD> yet when I push i want to push all modules including this one
<Wiz_KeeD> that has a subversion of it's own
<Wiz_KeeD> anyone?
<vila> Wiz_KeeD: by 'subversion', do you mean the VCS software or something else ?
<Wiz_KeeD> just a bzr branch inside another bzr branch
<vila> right, mgz and I both thought you were referring to the subversion software...
<vila> nested trees (and their respective nested branches) are how this is called in bzr but it's not implemented
<vila> some plugins allow some workflows, bzr-externals and .... damn memory
<vila> there is another
<fullermd> Another Skywalker?  ;p
<mgz> you can just have multiple branches for different projects Wiz_KeeD
<mgz> there's no need to try and stuff everything into one
<vila> scmproj
<rozzin> I always thought the reason svn externals worked the way the did was that svn was trying to ween people off of the idea....
#bzr 2013-08-29
<hakermania> Will adding * everytime harm my project on any way? Should I remember the files that I added to my project each time?
#bzr 2013-08-30
<mathrick> jelmer: poke?
<mathrick> mathrick@megumi: $ bzr branch git+ssh://git@github.com/mathrick/multiple-cursors.el.git,branch=master
<mathrick> bzr: ERROR: The repository you are fetching from contains submodules, which are not yet supported.
<mathrick> but git doesn't seem to see any submodules anywhere
<mathrick> oh, okay, so it had submodules earlier
<mathrick> git is a complete trainwreck, btw, there's no way known to #git to check that other than grepping the log for .gitmodules
<mathrick> jelmer: is there a way to promise bzr I won't use submodules, just check it out already?
<jelmer> mathrick: hi
<jelmer> mathrick: you're already using submodules :-)
<mathrick> howso?
<jelmer> mathrick: they're in the history - bzr-git requires that it can roundtrip *all* data that is in git into bzr and back out
<mathrick> jelmer: but isn't "git submodules support" the same as saying "here's a .gitmodule file"? I mean on git's side
<jelmer> mathrick: no, there's more to it than that - the place where the submodule lives has a magic file with special file modes
<mathrick> then as long as I'm prepared not to be informed of things (which git submodule already doesn't do anyway), it wouldn't be a lot of a loss
<mathrick> oh
<jelmer> mathrick: bzr-git supports converting this into a bzr nested tree and back into a git submodule, but bzr itself doesn't support nested trees properly yet
<mathrick> that's a shame
<mathrick> nested trees are probably the oldest planned feature that still doesn't work properly
<mathrick> jelmer: how are they different from bzr join / split anyway?
<mathrick> I was never entirely clear on that
<mathrick> oh, right, nested trees stay independent?
<quicksilver> vila: ping?
<jelmer> mathrick: yeah, they're a different branch/repository
<jelmer> mathrick: a nested tree or submodule is just a reference
<jelmer> the terminology Aaron used was that join/split are "by-value nested trees" and that submodules are "by-reference nested trees"
<mathrick> any idea how far away they are from working properly? I really remember seeing them planned back in 0.5 days
<mathrick> that makes sense
<jelmer> mathrick: I don't think they are going to appear anytime soon, considering bzr's current level of activity and the fact nobody is working on them.
<vila> quicksilver: pong
<mathrick> jelmer: oh, sorry, I meant more of "how much work would it require to get them fully working", disregarding the fact nobody's doing it atm
<quicksilver> vila: dvc-log (C-x V L) always seems to do "bzr log <thisfile>", is there a way do just do a plain "bzr log" ?
<quicksilver> (also it seems to be slow when lots of changes)
<vila> quicksilver: sorry no idea, I never use that. Have you tried from a line without a file ?
<jelmer> mathrick: Quite a lot. I have some thoughts on the best way to approach them, but it's at least a couple of months worth of work.
<quicksilver> vila: how would you bring up a diff between two versions?
<mathrick> jelmer: oh, ow
<vila> quicksilver: from dvc ? for a given file ? I have a couple of shortcuts defined for 'bzr diff', 'bzr diff -rsubmit:' and 'bzr diff -r $whatever' and that's all I use
<vila> quicksilver: in other words http://paste.ubuntu.com/6044322/
<mathrick> quicksilver: fwiw, I just use the plain old terminal (Guake, so it's easy to access) or if doing more, just open bzr explorer and use that. The graphical tree history and diff viewers are just too valuable to give them up for some rather lame integration with Emacs, really
<vila> mathrick: I won't call diff-mode (which dvc uses) "lame" ;) That covers 90% of my needs: overiview of current diff, instant access to modified files, reverting any hunk
<quicksilver> vila: oh, those are useful. I think what I was missing is any way to call bzr-dvc-diff with useful arguments.
<quicksilver> vila: (I meant, any built-in keybinding to call with useful arguments)
<mathrick> vila: diff mode is very nice in many cases, but a lot of the time, I prefer the qdiff view
<quicksilver> mathrick: I prefer diff-mode to qdiff generally
<quicksilver> better integration with the rest of the emacs workflow
<vila> mathrick: yeah, I can read the qdiff view (and often do so while exploring from qlog)
 * vila nods at quicksilver 
<quicksilver> I occasionally use the qbzr stuff to explore things like who committed certain merge subrevisions
<vila> mathrick: but otherwise, full agreement with quicksilver
<quicksilver> often starting from qblame
<mathrick> speaking of integration, I should bind "bzr qdiff" to something and avoid calling it by hand from terminal
<quicksilver> M-& bzr qdiff
<vila> same here, qblame (which is shorter than qpraise and qannotate sadly ;)
<mathrick> that's just terminal in disguise
 * vila blinks
<vila> quicksilver: holy cow, why did I never thought of binding qblame and qlog in the dvc buffer...
<vila> mathrick: you mean M-x shell ? ;)
<vila> truth is shell-mode lacks a lot of terminal goodness, there is a lot to be said about completion for example
<vila> (yeah I know it's more bash than the terminal itself)
<mathrick> either way, now that I've cleaned up my emacs config, I can actually look at binding bzr sensibly into my workflow
<vila> mathrick: seriously, you managed to really clean it up or was it more like "reasonably clean up" ? ;)
 * fullermd . o O ( <--- has an rm if you need to clean emacs up... )
 * vila manages to remove stuff at each upgrade but some pieces are there for decades (literally ;)
<quicksilver> mathrick: it is and it isn't.
<mathrick> vila: https://github.com/mathrick/emacs-config vs. https://github.com/mathrick/emacs-config/tree/16fe55f48771768ae448b826f1ef3fc99da5841a :)
<quicksilver> mathrick: it saves you switching window and it has a separate command history.
<vila> fullermd: vade retro satanas , we all know your number is VIVIVI
<mathrick> vila: tell me about it, I removed some 15 yo junk from tit
<vila> mathrick: :-D
<mathrick> protip: (setq foo 42) is not the proper way of making function-local variables...
 * mathrick smacks younger mathrick up the head
<mathrick> in my defence, it was my first contact with both emacs and lisp of any sort
<mathrick> vila: I've been putting off the cleanup itself for years, and I basically reached the point where I couldn't really install a package because there was no way to stuff it into the pile of mess my config was without doing some sort of cleanup, so I did
<mathrick> technically I've been "using" grail.el for a few years, but that was really little more than just mv .emacs ~/elisp/user.el plus some load-path magic
<vila> hehe, that's a good reason ;)
<mathrick> vila: if you want, take a look at the readme, I've actually documented it and made sure to make it bootstrappable
<mathrick> I have verified that I can bring up my config on a vanilla emacs with a single command, including emacs23 :)
<vila> I haven't installed a emacs package yet
<mathrick> oh, man, ELPA is glorious, especially if you pair it with Cask/Pallet
<mathrick> I needed to hack them to stop assuming ~/.emacs.d/, but they work and I have no junk at all in there
<mathrick> vila: https://github.com/mathrick/emacs-config/blob/master/Cask <-- this is how I store my deps in bzr
<vila> wow, single command, nice, my setup have been following me from sunos to solaris, osx, freebsd, gentoo, ubuntu, all with minimal tweaks but I also relies on bzr to keep them all under control
<mathrick> no checking in external libs \o/
<vila> wow, nice
<mathrick> vila: yeah, I've done some work on win32, which made the config all that more horrible, and it'd take me a day to get it to work on whatever zany version I managed to get to run
<vila> ha yeah, win32 too but only slightly
<mathrick> one problem I haven't solved properly yet is how to track non-ELPA packages
<mathrick> it will require some legwork to integrate VCS checkouts as much as at all possible with Grail
<vila> yeah, I don't try, I manage to keep all dependencies optional
<mathrick> "be as smart as possible but not smarter"
<mathrick> vila: yeah, that too, will do it simultaneously I guess
<vila> I've been using 3 small packages for which I keep the source
<mathrick> right now I just assume all of ELPA will install
<mathrick> actual win32 testing presumably will teach me to know better than that :)
<mathrick> vila: if you want, I can ping you when I'm done with that, I actually plan to make a skeleton branch which is that except with all my config removed and only the support bits left in
<vila> mathrick: I'd love too, but I keep the little free time I can gather here and there to bzr :-/
<mathrick> aye
<mathrick> vila: I decided to do it now, because I've been honestly avoiding doing actual coding work out of fear of dealing with the packages I'd need to install onto my old mess
<mathrick> and that's just not good
<mathrick> oh, right, one thing you WANT to check out: http://emacsrocks.com/e13.html https://github.com/magnars/multiple-cursors.el
<mathrick> it's absolutely fantastic, and managed to supplant CUA-rectangle which I've been madly in love with for years
<mathrick> quicksilver: ^ you too, if you don't know it yet
<mathrick> works best when paired with https://github.com/magnars/expand-region.el
<vila> mathrick: hmpf, I'm not even sure I will be able to use that O_O granted it looks nice (multiple cursors that is)
<mathrick> oh, you will
<mathrick> it's instantly useful everywhere the moment you have it available
<vila> mathrick: note that I'm still quite new to CUA-rectangle
<mathrick> vila: think of it as better CUA-rectangle, which is already pretty damn great. All kinds of refactoring is possible, and it serves a fantastic replacement of macros and regexes in many cases
<fullermd> Sheesh.  Why would you want to replace a regex with anything but a more complicated regex?
<mathrick> vila: for example, https://github.com/magnars/multiple-cursors.el/issues/76#issuecomment-23531660 <-- I wrote it writing all key sequences like [C-u C-x n n]
<mathrick> then replacing them with the fantastically readable <kbd>C-u</kbd><kbd>C-x</kbd><kbd>n</kbd><kbd>n</kbd>, then selected all such instances and converted them to
<mathrick> er
<mathrick> aside from the fact my xchat buffer got messed up
 * quicksilver doesn't even use CUA-rectangle
<quicksilver> I use builtin rectange commands every day though
<mathrick> quicksilver: MC is that on steroids. You'd use either built-in rectangles or CUA-rectangle, but MC is strictly better than both
<mathrick> because it doesn't require you to have consecutive, aligned lines
<quicksilver> intersting.
<mathrick> quicksilver: watch that screencast, it explains perfectly what it's useful for
<vila> yeah, sounds interesting, I wonder though if that won't make myself a bit lazier for refactorings...
<mathrick> well, shows, which is even better
<mathrick> vila: what do you mean?
<quicksilver> why do the best emacs tips always come as off-topic conversiations in other channels?
<mathrick> because Emacs is too big to be a single topic!
<vila> if there are multiple lines where I need to apply the same modifications, shouldn't that be abstracted ?
<quicksilver> mathrick: the more powerful your editor, the more likely you are to put up with ugly boilerplate / repated code
<quicksilver> just look at Java ;)
<mathrick> serendipity, thy name is Emacs :)
<mathrick> quicksilver: yeah, I know
<mathrick> but it also makes it really easy to refactor things
<vila> but the example where he handles the i18n is different, there, it *helps* the refactoring hugely
<fullermd> Well, because most localities have banned door-to-door emacs proselytization, so the pushers have gone online to tempt children into the ways of sin...
<mathrick> so "meh, I don't feel like fixing it in 5 places, I will paste it once more" is no longer an excuse
<jelmer> mathrick: I think the simpelst thing to do if you can is to fastexport/fastimport the git repo to remove the submodules, and then redo the bzr-git command.
<mathrick> jelmer: doesn't really work for pull requests though :\
<jelmer> mathrick: ah, yeah..
<mathrick> jelmer: oh, speaking of that, how can I replay a fi stream on top of a repo? I have a repo which starts out with a file structure identical to a git repo I want to graft onto, but the history is different and includes other junk. I wanted to filter out all but the files I care about, but replays don't work, they simply replace everything rather than adding to the history
<mathrick> specifically, https://github.com/codermattie/Grail and https://github.com/mathrick/emacs-config/tree/16fe55f48771768ae448b826f1ef3fc99da5841a
<mathrick> my repo starts with grail files textually identical (they were downloaded as blobs from github), but the history is interleaved with everything that happened to my repo
<quicksilver> mathrick: OK, I watched the screencast. I do stuff like that all the time but I have to use a cmobination of rectangle commands, align-regexp, and regexp replace. Neat.
<mathrick> I want to isolate just the things I did with grail*.el and graft that on top of a Grail checkout
<mathrick> quicksilver: yep, it removes a lot of drudge regexp hackery from my day
<mathrick> and trying to divine why align-regexp doesn't work and is it still saving time if I debug it?
<jelmer> mathrick: sorry, not sure about that.
<mathrick> jelmer: hmm, any idea who knows about bzr fast-import?
<jelmer> mathrick: I think Ian and myself are the main people who have worked on it
<jelmer> I swapped that stuff out a long time ago :)
<jelmer> perhaps try the list?
<mathrick> will do
<mathrick> thanks
<mgrandi> hey, I was wondering if a plugin existed, to kind of, 'pin' a file. I have a file that is dynamically generated and the contents differ occasionally on a rebuild, and i don't want to commit it each time as its derived from something else, but i don't want to ignore the file either cause then it wont get checked out if someone branches the repo
<jelmer> mgrandi: no, there isn't anything like that. generally what happens is that people check in foo.in, and then have a build script that copies foo.in to foo and makes local modifications to it
<jelmer> (and then add 'foo' to the ignore list)
<spiv> I suppose locally you could have a pre-commit that drops that file from the list of changes to commit.
<spiv> But that won't help casual developers avoid committing it unecessarily.
<mgrandi> yeah
<mgrandi> i might do that, thanks jelmer
#bzr 2013-08-31
<vexo> Anyone care to comment on http://bazaar.launchpad.net/~vexo/bzr/gpg_verify_download_missing/revision/6587?start_revid=6587&remember=6583&compare_revid=6583  ?
<vexo> Added an option to verify-signatures to attempt to download missing public keys
<vexo> As it stands, even if a revision was signed by a key you might consider valid, it will always just show as having a missing key in verify-signatures unless you go and manually find it, which makes the whole feature a bit useless, imho
#bzr 2014-08-25
<user65419> Will the windows version of bzr pull the username automatically from the environment if author info is not configured?
#bzr 2014-08-26
<mark06> is it possible to amend a forgotten --fixes to a commit?
<jelmer> mark06: only if you uncommit or something like that
<jelmer> (commits are immutable)
<mark06> ok :'(
#bzr 2014-08-27
<stbatduke> Ohai #bzr !!  I have a weird question, and there may not be a good answer .... How do I explain the importance of using a version control system such as bzr to my management team and development team?  The context is this:  We have been using bzr for the last maybe 2 years, and we have lots of version history in our application, however we have not be properly utilizing the power of bzr properly (at least in my opinion), but at least we have been using it.  I 
<stbatduke> So my question is:  What would be a good way to discuss this with my management team to convince them that we need to force the dev team to use bzr the way we have been the whole time, and to reject any completed work that has the .bzr folders deleted?
<stbatduke> Let me put that into a paste in case someones irc client cuts it off (sorry for the long question):
<stbatduke> http://pastebin.com/fM0BMCc3
<stbatduke> My Boss answered my own question!!
<stbatduke> Version Control System use is required for HIPAA
#bzr 2014-08-28
<edakiri> Is there a better way to create a backup of an archive than archiving the .bzr directory?
<edakiri> 'export' appears to only capture a specific revision.
<beuno> edakiri, not that I know of, the .bzr dir has all the right information in the right way. You could do a checkout without a working tree and compress that, but it's essentially the same thing
<LeoNerd> edakiri: bzr push  it somewhere
#bzr 2015-08-24
<rindolf> Hi all. Why am I Gettiing this - Hi all! Why am I getting this - http://paste.debian.net/304422/ ? ?
#bzr 2015-08-25
<BigBear> good day
<BigBear> I have run into a newbie problem with bzr whilst trying to 'push' my local commit back up to lp. anyone here able to help me with this?
<BigBear> i follow project instructions and they say to push my local changes up to launchpad like 'bzr push lp:~urs-rau-k/openlp/name-of-my-new-fix-branch' but lp says that '-urs-rau-k' can't be the name of a project?
<BigBear> what is the correct path to push to if my lp login id is urs-rau-k ?
#bzr 2016-09-01
<erry> what's the correct way to change to an older revision?
<erry> bzr revert -r or bzr update -r?
<erry> or is it the same
<erry> am i right in my assumption that it's the same except revert makes your working directory dirty?
<mgz> depends what you're trying to do exactly
<mgz> if you just want to test an older rev, update is fine
<mgz> if you actually want to make a change to trunk, you want revert
<erry> thankie
#bzr 2016-09-04
<Jfault> is it normal for bzr branch to operate at about 100 kb/s?
<Jfault> this is taking forever...
<Jfault> normally say with hg or git i get about 2 mb/s
<Jfault> can anyone here help me?
#bzr 2017-09-01
<b00tstr4p> hi i am new with bzr, i am working with a repo but when i run bzr info
<b00tstr4p> try to access to server
<b00tstr4p> via ssh
<b00tstr4p> y see .bzr/location
<b00tstr4p> and there is bzr+ssh//host...
<b00tstr4p> there is any way to read the log without remote server ?
<b00tstr4p> also bzr st
<b00tstr4p> ask me for ssh pass
